AWSを使ったお手軽ディザスタリカバリ対策を社内で構築したお話を書きましたが、その続きです。
ファイル共有としてS3を使おうとした経緯
ファイルをやり取りする時など、イントラにあるファイルサーバー（SambaやAFP、NFSなど）を経由させるのが一番お手軽な方法だと思います。実際、最近のNASは安いですし、RAIDも簡単に組めてそこそこ信頼性もあります。ちなみに弊社では
BuffaloのTera Station
を利用しています。
ですが、このファイルサーバーをクラウドに持って行くとなると結構大変です。弊社の場合ですと、エンジニアと印刷オペレーターとでファイルをやり取りする機会も多いので、エンジニア以外の人たちでも簡単に扱える仕組みが必要となります。AWSでこの手の「ファイル共有」プロトコルを喋らせるにはEC2を仕立ててあげなければなりませんが、今回はそのような時間もお金もかける事が出来ません。
AWS最強のサービスS3
AWSにはS3という容量無制限のストレージサービスがあります。
CloudBerry Explorerや
Cyberduckを使えば、FTPライクに扱う事が出来ますし、AWS純正の
AWS Management Consoleはブラウザで利用出来るので、基本的なPCリテラシーがある人であれば扱えるものです。
※ただし、UIの日本語化が行われていませんので、場合によっては問題になるかもです。
そこで、ファイル共有の代わりにこの辺のツールを使う事にして、あとはファイルの書き込み、読み込みなどの権限管理を
IAM（Identity and Access Management）を利用して設定してみました。
IAMに関しては、サーバーワークス小倉さんがJAWS-UGの勉強会で発表してくださった超わかりやすいスライドがありますので、そちらをご覧ください。
IAMまわりのツール
今の所IAMの設定は、AWS Management Consoleから扱えません。しかし、日本には
Cloudworksという神サービス（笑）があり、こちらでIAMをサポートしています。また、Firefoxエクステンションの
IAM Foxもあるので、コマンド叩くの嫌だ！という人でもだいぶ敷居が低くなっています。ただ、細かい所をいじるには、やはりコマンド、もしくはSDKを使ってAPIを叩かなければなりません。
また、設定自体は
Access Policy Languageと呼ばれる形式（中身はJSON）で書く必要があるので、それなりに大変です。ですが、JSONを生成してくれる
AWS Policy Generatorが用意されているので、イチから手書きするよりも、こちらを使う方が良いかもしれません。
この記事では Policy GeneratorでJSONを作成 → 少々手直し → Cloudworksにて設定
いうやり方で行いました。その他、GUIのツールでサポートしていない部分はコマンドラインを利用しました。
概要
考え方としてはこのような感じです。
- ファイルサーバーとして利用するバケットを一つ作ります。リージョンはもちろん東京です。このバケットを仮に「共有バケット」と呼ぶ事にします。バケット名は「s3-shared」とします。
- 印刷部門の人間には、この共有バケットに対してのみ、自由に読み書きが出来ます。
- その他バケットは、管理者以外は読み書き出来ない事とします。
IAMで「admin」と「s3-user」という二つのグループを作ります。adminは管理者権限、s3-userはS3の共有バケットの読み書きのみ出来るという意味です。adminグループにはadminというユーザー、s3-userグループにはkenとsachikoというユーザーがいるとします。（名前に他意はありませんよw）
CloudworksでIAMを設定する
まずはユーザーを作らないと何も出来ません。コマンドでのやり方はググれば沢山出てくるので、Cloudworksでのやり方を説明してみます。
Cloudworksにログインし、左のIAMユーザーを選択、右上の「IAMユーザーの追加」をクリックします。admin、ken、sachikoというユーザーを作成します。
次にadminグループとs3-userグループを作成します。
adminグループ配下にユーザーadminを、s3-userグループ配下にkenとsachikoを入れます。グループを選択して、「IAMユーザーをグループに追加」をクリックします。以下の画面は、s3-userを選択した場合です。
s3-userグループにkenを追加します。追加するユーザーは、ちゃんとプルダウンで選択出来るようになっているので便利ですね！
同様にsachikoも追加して、s3-userグループの設定が完了しました。
ポリシーの記述
さて、ここからJSONでポリシーの記述を行います。ここではAWS Policy Generatorを使ってみます。
AWS Policy Generator
まずは、adminからやってみます。
adminはS3だけではなく、その他のサービスも全て利用出来るものとしますので、All Servicesにチェックを入れるだけです。
「Add Statement」をクリック、「Generate Policy」をクリックすると、このようにJSONが生成されます
このJSONをCloudworksにコピペするという訳です。
Cloudworksに戻ります。adminグループのIAMグループポリシーの追加をクリックします。ポリシー名は何でも良いのですが、判りやすくadmin-policyとでもしておきましょう。
次に、s3-userのポリシーを作成します。Policy Generatorに戻って、以下の事をやります。
- Type of PolicyはIAM Policyを選択
- EffectはAllow、AWS ServiceはAmazon S3を選択。以下の操作も同じ。
- ActionsでListAllMyBucketsを選択。Amazon Resource Name（ARN）には、 arn:aws:s3:::* と記入。「Add Statement」をクリック。
- ActionsでListBucketとGetBucketLocationを選択。ARNは arn:aws:s3:::s3-shared と記入。「Add Statement」をクリック。
- ActionsでAll Actionsをチェック。ARNは arn:aws:s3:::s3-shared/* と記入。「Add Statement」をクリック。
結果、このような感じになります。
出来上がったポリシーはこんな感じです。
{
"Statement": [
{
"Sid": "Stmt1303292722962",
"Action": [
"s3:ListAllMyBuckets"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "Stmt1303292848143",
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::s3-shared"
},
{
"Sid": "Stmt1303292879145",
"Action": "s3:*",
"Effect": "Allow",
"Resource": "arn:aws:s3:::s3-shared/*"
}
]
}
まず、IAMのデフォルトポリシーは全てDenyです。Allowを付け加えて行くやり方で考えています。
ListAllMyBucketsとは、S3バケットの一覧を表示するかどうかです。これはDenyしても良さそうですが、Management Consoleでは左側にバケット一覧が表示される為、Allowしておく必要があるみたいです。（情報求む）
共有バケット名は「s3-shared」です。これをARNで書くと
arn:aws:s3:::s3-shared となります。ここに対してGetBucketLocationとListBucketをAllowしてやると、このバケット内のオブジェクト一覧を取得する事が出来ます。
さらに、このバケット内部を読み書きする為には、
arn:aws:s3:::s3-shared/* に対して全てのActionをAllowしてやります。これは文字通り全てのアクションを許可してしまうので、例えばファイルのパーミッションにあたるACL（Access Control List）の変更もs3-userグループの人が出来てしまいます。この辺はどこまで制限するかによるでしょう。
このJSONをCloudworksにコピペします。
これでIAMの設定は終わりました。
s3-userでAWS Management Consoleを使う場合
通常、Management Consoleにアクセスするには、
- https://console.aws.amazon.com/s3/home
に行くと思いますが、ここで入力するのはAWSアカウントのEメールとパスワードです。せっかくIAMを設定したのに、これではログイン出来ません（笑）
IAMでManagement Consoleにログインする為には、特別なURLが用意されています。（参考：
AWSドキュメント）
- https://your_AWS_Account_ID.signin.aws.amazon.com/console/s3
your_AWS_Account_IDは、AWSアカウントに設定されている12桁の数字です。ただ、この数字を覚えている人は極めてまれだと思いますので、AWSアカウントIDのエイリアスを作って覚えやすいURLに変更してしまいましょう。下記のコマンドを打ちます。
$ iam-accountaliascreate -a hogehoge
Alias: hogehoge
Direct Signin Link: hogehoge.signin.aws.amazon.com
これでめでたく、
https://hogehoge.signin.aws.amazon.com/console/s3でログインする事が出来るようになりました。
さて、ユーザー名とパスワードを入力してログインしてみましょう…って、パスワードってどこかで設定しましたっけ？（笑）
実は、このパスワードの設定はCloudworksでは出来ません。しかたがないので、コマンドを打ちましょう。
$ iam-useraddloginprofile -u ken -p PASSWORD
これでようやくログインする事が可能になります。
ログインするとおなじみのコンソール画面が出て、バケット一覧が表示されます。試しに共有していないバケットをクリックしてみるとこんな感じでアクセス出来ません。うまく設定出来ているようです。
共有バケットは、自由にフォルダを作ったり、ファイルをアップロード／ダウンロードが出来ます。sachikoユーザーでも全く同じ事が出来ます。
s3-userグループは、S3の共有バケットの操作のみ許可されていますので、もちろんEC2は触れません。
もちろん、Elastic Beanstalkも無理です。
こんな感じで、共有バケットの操作のみに権限を絞ったIAMユーザーに対して、AWS Management Consoleを使ってもらう準備ができました。めでたしめでたし。
CyberduckやCloudBerry Explorerの場合
これらのツールを使う場合は、先ほど作ったIDとパスワードでは出来ません。従来通りアクセスキーとシークレットアクセスキーを使う必要があります。これはユーザーごとに発行します。
Cloudworksではこのようにやります。
アクセスキーを発行したいユーザーを選択し、アクセスキーの追加ボタンをクリックします。
そうすると、このようにキーが発行されますので、メモっておきます。シークレットアクセスキーは、この画面でしか表示されません。あとで確認する手段がないので、もし忘れてしまったらキーの再発行となります。（これはAWS側の仕様です。コマンドラインでやっても同じ事です。）
Cyberduckでは、ユーザー名にアクセスキーを、パスワードにシークレットアクセスキーを入力します。
共有バケットへはアクセス出来ますし、それ以外はアクセスが拒否される事が判ります。
まとめ
なんか、思いがけず長文エントリになってしまいましたが、ここで紹介している事は非常に単純なものです。ポリシーは時間帯でIP制限をかけるなど、きめ細かく記述出来ますし、そもそもS3だけでなく、EC2などのサービスにも適用出来ます。（私は全然使いこなしていませんがw）
また、Cloudworksのように周辺のツールを組み合わせれば、色々と作業が楽になります。
手軽でセキュアな無制限ストレージが格安で手に入る時代になりました。
いやー、S3って、ほんといいもんですね！
