- 普段お酒ばかり飲んでいて、あまり（技術っぽい）仕事をしていません。
- 理系出身なのですが、どちらかというと財務とか人事などの仕事を好みます。
- ITのことが嫌いなのではありませんが、一つのことを突き詰める気持ちはあまり強くありません。
- そして、今回初めてブログらしいブログを書きます。
- しかもそれが技術ブログということで些か緊張気味です。
と、IAMに掛けて、いきなり自己紹介から入ってしまいました、サーバーワークスの鈴木です。
今回は以前から興味を持っていたAWS Identity and Access Managementが今月から正式版となり、AWS Management Console対応も始まったので、早速少し試してみたところ、社長の大石（蔵人之助）からブログにした方がいい！と煽てられ、調子に乗って書いてみました。
IAM（Identity and Access Management）とは？
2010年9月にベータ版がリリースされたAWSアカウント内での権限管理のしくみのことです。IAMを使うことで、１つのAWSアカウントの下にユーザーやグループを作成でき、EC2やS3などのサービス毎に操作を許可、禁止することができるので、部署や委託先の担当者毎の業務範囲に応じた制御という企業利用にとって非常に重要な機能といえます（制御概略）。
IAMは素晴らしい機能であり、当社のCloudworksでも優先度を上げて早期に組み込んでいたのですが、制御ポリシーをJSON形式で書かねばならず、ベータ版ではコマンドラインが中心だったため、ここ3年ほどコーディングから足を洗っていた私は全く手が出せずにいました。また、AWS Management Consoleへのログイン制御ができなかったため、課金情報などをそのまま閲覧できてしまう点が管理業務の実務からみるとネックでもありました。
AWS Management ConsoleにIAMタブ登場！
今回、IAMからベータがとれ、正式版になると同時に（リリースブログ）、AWS Management Console（以下AWSコンソール）からも操作できるようになり（リリースブログ）、一気に私（ふつうの人）でも触れるようになりました。
AWSコンソールにログイン後、一番右のタブ「IAM」が増えていることが確認できます。
AWSコンソールで操作できることを中心にいくつか試してみたいと思います。
AWSコンソールからポリシー作りが楽
まずは上記の「IAM」タブDashboardの「Create a New Group of Users」ボタンから進んでみましょう。権限設定を行いたいグループ名を入れた後、権限ポリシーを設定するのですが、既に20種類ものポリシーテンプレートが下図のように用意されていますので、一般的なものを設定する場合はこれで十分です。
ここでは「Power User Access」（IAM権限設定以外の全ての操作が可能）を選びました。その後、ユーザー名（サンプルユーザー：ooishi）を登録すれば、簡単に権限ポリシーに基づいたユーザーが作られます。
ユーザーパスワードと専用コンソール画面
ここからが今回の真骨頂。AWSコンソールを今までとは違う形で使えるようになります。
「Sign-In Credentials」のところにある「Manage Password」ボタンから進むことにより、このAWSアカウント専用コンソール（後述）からログインすることができます。
なお、今回はIAMのAWSコンソールサポートのことを中心に書いているので詳細は割愛しますが、作られたユーザー毎に「Access Key」「Secret Access Key」「X.509 certificates」等、APIなどでのアクセスに必要な項目を個別に設定することもできます。
専用コンソール？（IAM User sign-in page）
IAMがAWSコンソール対応になった＝IAMで設定したユーザーがそれぞれログインできる入り口が必要、ということで、今回あらたにAWSアカウント毎に専用コンソールが用意されています。
「IAM」タブDashboardの「AWS Account Alias」でそのIAM User sign-in URLが確認できるのですが、初期設定は機械的に割り当てられた数字のURL。これでは素っ気ないので「Create Account Alias」ボタンから登録することにより任意のFQDNが設定可能です（当たり前ですがAWS全アカウントの中でユニークでなければダメ）。
IAMユーザーでのログイン
IAMが無事効いているかどうか、さきほど作った「Power User Access」権限のユーザー ooishiさんで専用コンソールからログインして確かめてみます。
EC2やS3など普通に操作できましたが、下図のとおりIAMだけはnot authorizedで先に進むことができません。ということで、意図通りの制限が効いていることが確かめられました。
なお、IAMユーザーはどのような権限であってもAWSアカウント画面（請求情報やセキュリティ証明書が表示される画面）にはアクセスすることができません。AWS側が用意したテンプレートのフルアクセス権限「Administrator Access」ユーザーであってもダメでした。
EC2だけ操作できるユーザーを試す
AWS上でのシステム初期構築はSIerが請け負うが、通常の運用業務ではお客様が直接サーバー（EC2）を操作・確認する、といった場合（実はそのような場合には当社のCloudworksがとても有効なのですが）、を想像してみます。
EC2周りの機能に限定したユーザーを作ることでこれにも対応できると思うので、AWS側が用意したテンプレートの「Amazon EC2 Full Access」ユーザー（サンプルユーザー：hashiba）を試してみます（一応技術ブログらしくするために、ポリシーのJSONコードも載せます）。
Policy “AmazonEC2FullAccess”
{
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "elasticloadbalancing:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "cloudwatch:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "autoscaling:*",
"Resource": "*"
}
]
}
さきほど同様にパスワードをユーザーhashibaさんにも設定し、専用コンソールからログイン。
すると意図通り、AWSコンソール「S3」タブではダッシュボードの表示がされず、「EC2」タブではAMIが閲覧、操作可能になりました。
ところが、、、
問題発生！
AWSコンソールの「EC2」ダッシュボードには困ったことに、「Reserved Instances」「Spot Requests」といった項目が表示されています。やっかいなのは、ここからいきなりReserved InstanceやSport Instanceを購入できたり、今までに購入していたInstance情報が見えてしまったりするのです。
単にお客様に見せたくない情報を見られてしまうだけでなく、不要なInstanceを簡単に購入できてしまうため、通常の単純な運用をユーザーhashibaさんに任せるにはビジネス上のリスクが残ってしまいます。
ちなみに、高額なReserved Instance 「東京リージョン、Windows with SQL Server、High-Memory Quadruple Extra Large、3年」だと、1台のお値段なんと $16,800。かるーく100万円超えますし（普通のカードだと一発で限度額!?）、毎月20台までは購入できてしまうはずなので、おそろしい金額に。。。（小心者の私は実際に購入したわけではないので金額上限があるのではないかとも思いますが）。
そこでポリシー追加
このままでは管理者として怖くて夜も眠れないので、Reserved InstanceやSpot Requestを制限すべく、ポリシーを追加します。
Policy “NoReservedInstances”
{
"Statement": [
{
"Action": [
"ec2:DescribeReservedInstances",
"ec2:DescribeReservedInstancesOfferings",
"ec2:PurchaseReservedInstancesOffering"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
Policy “NoSpotInstances”
{
"Statement": [
{
"Action": [
"ec2:CancelSpotInstanceRequests",
"ec2:DescribeSpotInstanceRequests",
"ec2:RequestSpotInstances"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
上記のポリシー「NoReservedInstances」「NoSpotInstances」を追加設定することにより、ユーザーhashibaさんは「Reserved Instances」や「Spot Requests」リンクを押下しても権限無しとして情報が表示されず、Reserved Instance購入やSpot Instance申込等の操作禁止という期待通りの制御をかけることに成功しました。
AWS Policy Generator
上記の2つのポリシーはコーディングの3年間のブランクを乗り越えて、私が必死に調べて作ったわけではなく、便利なAWS Policy Generatorを使って作ったものです。該当するActionがどれなのか探すのが少し大変ですが、選択するだけなので比較的簡単にポリシー作成ができると思います。
おわりに
今回の「IAM正式版＆AWSコンソール対応」で、管理業務も含めたビジネス実務にほぼ利用できる権限設定機能となりました。
が、上述の通り、AWSアカウント画面（請求情報やセキュリティ証明書が表示される画面）が非表示となったため、ユーザー毎の使用実績や費用を知るすべがありません（もちろんAWSアカウント合計では分かります）。この辺りはAWS FAQにも計画中と書かれてありますので、機能追加を待ちたいと思います。
また、上記のように設定したIAM情報は当社のCloudworksでも設定、確認することができますが（過去ブログ）、更に企業向けに拡張し、権限設定も簡単に行える「Cloudworks Business Edition」をもう少ししたらみなさまにご案内できるものと思います。乞うご期待！
その他のIAM参考情報
コンテンツ
サービス名から探す
Facebook
twitter
