クラウドにおいて、「誰が、どの操作をできるのか」といった権限の設定は慎重におこなう必要があります。
そんなときに役に立つのが、「AWS IAM」です。
AWS IAM（Identity and Access Management、以下IAM）とは、各ユーザーがアクセスできるAWSのリソースのアクセス許可を集中管理するためのウェブサービスです。IAMを使用することで、誰を認証して、誰にリソースの使用を承認するかを簡単に制御できます。
本記事では、そんなIAMのカスタマー管理ポリシーの書き方や、主なデザインパターンについて解説します。
目次
カスタマー管理ポリシーとは
カスタマー管理ポリシーとは、ユーザーが作成したIAMポリシーのことで、利用するユーザーに合わせて自由に権限を付与したり、制限をかけることができます。たとえば、Admin権限を与えた自由度の高い管理者向けのポリシーを作ったり、インフラ構築のために必要な権限に絞ったポリシーを作成できます。
カスタマー管理ポリシーのほかにも、AWSがあらかじめ用意したAWS管理ポリシーというものがあり、このAWS管理ポリシーの組み合わせだけでもある程度柔軟な役割を与えたユーザーを作ることが可能です。
ただし、より柔軟で制限を絞った運用をするためにカスタマー管理ポリシーは必須ともいえる機能となっています。
カスタマー管理ポリシーの書き方
続いては、カスタマー管理ポリシーの具体的な書き方について説明します。カスタマー管理ポリシーは、IAMの「ポリシーを作成」から作成し、JSON形式で記述します。主なJSONのキーは以下の通りです。
- Version
- Statement
- Effect
- Action
- Resource
では、それぞれのキーについて、詳しく説明します。
Version
Version要素ではポリシーのバージョンを指定します。作成開始時に「2012-10-17」と記載されており、「2012-10-17」は原稿バージョンなので特に変更する必要はありません。なお、「2012-10-17」よりも前は「2008-10-17」で、IAMポリシーには2つのバージョンしかありません。
この状況からもわかる通り、IAMポリシーのバージョンはほとんど変更されていないので、一度覚えてしまえば新たに学習する必要は少なくなります。
Statement
Statement要素は必須の要素で、ポリシーの主要要素となります。Statement要素の中にJSONオブジェクトを格納していき、任意のポリシーを作っていきます。
Statementは複数の配列で記述することができ、個々のステートメントは「{}（中括弧）」で囲います。複数のステートメントを作成した場合の配列は、「[]（角括弧）」で囲む必要があります。
Effect
Statementの結果を許可する（Allow）か、拒否する（Deny）のどちらかをEffectに設定します。
Action
Actionには利用、もしくは否定するサービスを記述します。ワイルドカードが利用できるので、すべてのサービスを指定する場合は「*（アスタリスク）」を使います。
Resource
Resourceには利用するリソースの指定をします。たとえば、利用するリージョンを特定するときや、IAMユーザー名や特定のS3バケットに限定するときなどに利用します。
カスタマー管理ポリシーのデザインパターン
IAMポリシーのデザインパターンはいくつかあるのですが、ここでは代表的な３つのパターンを紹介します。
ホワイトリスト・パターン
ホワイトリスト・パターンは、許可する権限のみを付与していくパターンです。
必要最低限の権限のみを付与するので、許可を記述していないアクションについては暗黙的に拒否されます。このポリシーが与える権限の範囲は明確なので、セキュリティ面での信頼性は高いです。
たとえば、EC2の参照権限と起動・停止の権限だけを付与することによって、本来許されない通信を許可してしまうことを防ぐことができます。
ただし事前に役割が決まっていないと付与する権限が決まらず、探索的に開発していくようなプロジェクトでは扱いにくいデザインパターンとなります。
ブラックリスト・パターン
ブラックリスト・パターンは、剥奪したい権限のみを追加していくパターンです。
比較的自由に権限を付与した形でIAMユーザーを作成し、明示的に与えてはいけない権限を剥奪していきます。禁止事項のみを定義すれば良いので、IAMポリシーの設計および設定が少ない作業で済み、事前に必要な権限が確定していない場合でも禁止事項さえ定義すれば、その段階で運用を始めることができます。
一方で、新しいAWSの機能がはじまった場合などには自動的に新しい機能が使えるようになってしまい、結果として予期せぬ機能が使えるようになってしまうというデメリットもあります。
ハイブリット・パターン
ハイブリット・パターンは、ホワイトリスト・パターンとブラックリスト・パターンを組み合わせたデザインパターンです。
ハイブリット・パターンは１つのステートメントで許可したくない権限を明示的に拒否（ホワイトリスト・パターン）し、そのほかのステートメントで梱包的に許可をする（ブラックリスト・パターン）という構成をとることができます。
また、個々に作成したポリシーをグループで組み合わせるといった方法も可能です。たとえば、FullAccessなどAWSの定義済みポリシーと自分で作ったブラックリスト・パターンのポリシーを組み合わせると言った具合です。
上記のようにハイブリット・パターンは最小の労力で実用的なポリシーを作ることができ、ほとんどのケースで運用することができます。
まとめ
今回は、AWS IAMのカスタマー管理ポリシーとデザインパターンについて解説しました。
本記事を参考にして、ぜひAWS IAMの導入を検討してみてください。
