あらゆる形態、規模の組織にAWSの利用が拡がり続けるに従い、ユーザーおよびアプリケーションに付与する権限をさらに細かく制御できる必要性がはっきりとしてきています。制御の必要性は、エンタープライズレベルで特に顕著になってきています。 例えば、クラウドアプリケーションを構築している開発者に、本番システムで使われているクラウドリソースを変更する権利を持って欲しくなかったり、ある本番システムのオペレータに他のシステムで使われているクラウドリソースへのアクセス権を持って欲しくないといったようなケースが考えられます。
これまでのストーリー
2010年の半ばにIAMのサービスを開始し、組織内のユーザーがAWSのAPIにアクセスできるよう、ポリシーを作成し適用することができるようになりました。
その後、DynamoDB、Elastic Beanstalk、 Glacier、Route53、 SNS、SQS、S3、 SimpleDB、およびStorage Gatewayのリソースへのアクセスを個々に制御するために、ポリシーを使うことができるようになりました。
そして本日、Amazon EC2とAmazon RDSのリソースレベルのアクセス許可を導入したことで、IAMはさらにパワーアップいたしました! この機能は、RDS MySQL、RDS Oracle、RDS SQL Serverの全てのエンジンでご利用いただけます。
EC2では、IAMポリシーを作成・利用することで、EC2インスタンス、EBSボリューム、マシンイメージ、Elastic IP アドレスへのアクセスを制御することができるようになりました。 RDSでは、同じようなポリシーを利用することで、DBインスタンス、リードレプリカ、DBイベントサブスクリプション、DBオプショングループ、DBパラメータグループ、DBセキュリティグループ、DBスナップショット、サブネットグループへのアクセスを制御することができます。
詳しく見ていきましょう!
EC2のリソースレベルのアクセス許可
IAMポリシーを使って、重要なEC2のユースケースのいくつかをサポートできるようになりました。ここではそのいくつかを紹介いたします。
- 非常に大きく、複数のユーザーが利用するEC2環境内で、ユーザーが一部の制限されたリソースにのみアクセスできるようにする。
- Set different permissions for "開発" と "テスト" のリソースに別の制限を設定する。
- インスタンスを終了(Terminate)することができるユーザーを制御する。
- 特定のリソースへのアクセスで、MFA認証といった追加のセキュリティ対策を要求する。
これは複雑で広範囲に及ぶ機能ですので、段階的に展開していきます。第一段階では、次のとおり、指定されたリソースの特定のアクションがリソースレベルのアクセス許可をサポートいたします。
- インスタンス - 再起動(Reboot)、開始(Start)、停止(Stop)、終了(Terminate)
- EBSボリューム - アタッチ(Attach)、削除(Delete)、デタッチ(Detach)
上記に記載されていないEC2のアクションは、現時点では、リソースレベルのアクセス許可を設定できません。2013年中には、他のAPIもサポートしていく予定です。
これに加えて、全てのEC2リソースに対して、特定およびワイルドカードのARN (Amazon Resource Name)がご利用いただけるようになりました。 arn:aws:ec2:us-east-1:1234567890:instance/i-i-96d811feといったようなARNを使って、個々のリソースを参照したり、 arn:aws:ec2:us-east-1:1234567890:instance/*.といった形のARNを使って複数のリソースを参照することができます。
EC2ポリシーステートメントは、EC2リソース上のタグへの参照を含むことができます。これにより、アクセス許可と課金レポートに同じタグモデルおよびスキーマを使うことができるようになります。
ポリシーの有効性のテスト、検証を簡単にするために、EC2のAPIを拡張し、新しいフラグと2つの機能を追加しています。 新しいフラグは、“DryRun”フラグで、EC2 APIの新しい一般オプションとしてご利用いただけます。このフラグを設定すると、APIリクエストはアクセス許可の判定は行いますが、実際にはAPIリクエストを処理しません。(例えば、インスタンスを実際に終了することなしに、ユーザーが終了する権限があるかどうかを判定できます。)
また、APIバージョン 6-15-2013 以上を使うと、エンコードされた認証メッセージを受けとれます。このメッセージにはDecodeAuthorizationMessageといった、認証拒否のエラー情報も含みますので、STS APIと組みあわせて、特定の認証の判定を行っているIAMポリシーと評価コンテキストについて詳しく知ることができます。 (STS APIへのアクセス許可はsts:DecodeAuthorizationMessageアクションを使って、IAMポリシーで制御できます。).
今回の新しいリリースのEC2側の最後のピースは、ポリシーの中で利用できる条件タグの拡張セットです。 ec2:Region、ec2:Owner、ec2:InstanceTypeといった条件をご利用いただけます。(条件タグの完全なリストについては、EC2のドキュメントをご参照ください。)RDSのリソースアクセス許可
IAMポリシーを使って、重要なRDSのユースケースのいくつかもサポートできるようになりました。サンプルは次のとおりです。
- 特定のグループのユーザーに対するDBエンジンとインスタンス利用ポリシーを実装する。 例えば、“Staging users”または“Production users”グループ内のユーザーに対して、m2.4xlインスタンスタイプとProvisioned IOPSの利用を制限したいといったような場合です。
- 特定のDBパラメータグループとセキュリティグループを使用するDBインスタンスの作成をユーザーに許可する。 例えば、“Web application developers”に対して、“Web application”パラメータグループと、“Web DB”セキュリティグループを持ったDBインスタンスのみ作成できるよう制限したいといった場合です。 これらのグループには、管理者が設定した特定のDBオプションとセキュリティグループが含まれていることでしょう。
- DBインスタンスを作成するのに特定のパラメータグループ使わないよう、ユーザーまたはユーザーグループを制限する。 例えば、“Test users”グループに対しては、テストDBインスタンスを作成する際に、“Production”パラメータグループを使用できないようにしたいといった場合です。
- 特定のタグを持ったDBインスタンスを操作する許可を、特定のユーザーだけに与える。(例: "production"としてタグ付けされたDBインスタンス) 例えば、“Production”ラベルがタグ付けされたDBインスタンスへのアクセスを“Production DBAs”にだけ、許可するいった場合です。
最後の例から推測されているかもしれませんが、あらゆるRDSリソース上にタグへの参照を作成することができるようになっています。 (拡張されたRDSへのタグ付け機能についての詳しい情報については、こちらの記事を参照ください。) そして、課金目的でも同様のタグとタグ付けスキーマを使用することができます。
EC2同様、RDSにも条件タグを追加しています。ポリシー内で、rds:DatabaseClass, rds:DatabaseEngine, and rds:Piopsといった値を参照することができます。
さらに詳しい情報については、RDSドキュメント内のManaging Access to Your Amazon RDS Resources and Databaseの章を参照ください。
AWS Security Blogでも、この機能に関する詳細に触れています。使い方についても記述がありますので是非こちらも合わせてご覧ください。
すぐにお試しいただけます!
是等の新機能は本日より利用可能となっています。是非お試しください。