記事公開日
IAMポリシー設計の基本を体験 ― AWSセキュリティの第一歩
この記事のポイント
AWSセキュリティの第一歩であるIAMポリシーについて、実際にJSONポリシーを作成しながら学んだ内容をまとめました。
- IAMの基本要素：
IAMユーザー、IAMユーザーグループ、IAMロール、IAMポリシーそれぞれの役割の違いを整理します。 - IAMポリシーの構成要素：
Effect、Action、Resource、Conditionの各要素を実際のJSONサンプルとともに解説します。 - 最小権限の原則：
アイデンティティベースポリシーとリソースベースポリシーの違い、そして必要最低限の権限を付与する重要性について触れます。
こんにちは。DXソリューション営業本部の松榮です。
今回はAWSセキュリティの第一歩ともいえるIAMポリシーについて実際に手を動かして経験してみました。
IAMポリシーなどのIAM関連は、AWS学習を進めていくうえで最初の壁といっても過言ではありません。
私自身も、学習を進めていくうえでIAMポリシーやIAMロールなどの理解が足りず困ることがよくありました。
AWSの他のサービスに触れる際も、IAMポリシーやIAMロールといった分野は関係してくるのでしっかりと理解を深めることが重要です。
IAMユーザー、IAMポリシー、IAMロールなどのそれぞれの言葉の違いを説明しながら、実際に経験して感じたことを共有したいと思います。
IAM
AWS IAM(Identity and Access Management)とは、AWSリソースへのアクセスを安全に管理するためのサービスです。
IAMを用いることにより、各ユーザーや各リソースが、どのリソースにアクセスできるかを制限することができます。
まず、AWS IAMの主な要素を整理してみます。
| 要素 | 説明 |
|---|---|
| IAMユーザー | AWSアカウント内で作成するユーザーです。IAMポリシーを使用して必要な権限を付与することができます。 長期的な認証情報(パスワードやアクセスキー)を持ち、複数人で共有しないのが基本とされています。 |
| IAMユーザーグループ | IAMユーザーグループとは、IAMユーザーの集合です。ユーザーグループでは、グループ単位でIAMポリシーをアタッチすることができます。グループ単位でIAMポリシーをアタッチすることで、それぞれのユーザーのアクセスを容易に管理することができます。 |
| IAMロール | AWSサービスや他のアカウントなどに対して、AWSリソースへのアクセス権限を一時的に付与する際に利用します。 IAMユーザーと異なり、長期的な認証情報が関連付けられず、信頼ポリシーで許可されたロールを必要とする任意の人が引き受けることができるようになっています。 |
| IAMポリシー | ユーザーやサービスが「どのリソースに対して」「どの操作を許可/拒否するか」を定義したものです。 JSON形式のテキストで定義され、IAMユーザーやIAMユーザーグループ、IAMロール、AWSリソースにアタッチできます。 |
IAMポリシーの設計
では実際のポリシーのJSONファイルをもとに要素を説明していきたいと思います。
今回作成したポリシーはs3バケットに対してのアップロードとダウンロードを許可した簡単なものです。
ポリシーの主な構成要素として、Effect、Action、Resource、Conditionが挙げられます。
Effect
Effect要素は必須の要素であり、Actionに対する許可または明示的な拒否にするのかを指定します。
Effectの有効値はAllowとDenyです。
AllowステートメントとDenyステートメントが含まれる場合は、Denyステートメントが優先されます。
該当するAllowステートメント、Denyステートメントがない場合はデフォルトでDenyが選択されます。
Action
Action要素は、許可または拒否される特定の操作を表します。
今回作成したAction要素は、s3バケットに対してPutObject(アップロード)、s3バケットからGetObject(ダウンロード)の操作が記述されています。
対象となるサービスを記述し、アクション名を続けて記述します。s3:*のように記述することで、特定サービス内の全アクションを対象にできます。
Resource
Resource要素では、Actionの対象とするオブジェクトを1つ以上定義します。
Amazonリソースネーム(ARN)を使用してリソースを指定します。
今回作成したResourceでは、example-bucketというs3バケットのすべてのオブジェクトが指定されています。
Actionの中の操作がs3バケットのオブジェクトへの操作なので、s3バケットのオブジェクトをリソースとして定義する必要があります。
例えば、s3:ListBucketがActionで記述されていた場合には、Resourceには"arn:aws:s3:::example-bucket"とs3バケットそのものを定義します。
Condition
Condition要素では、ポリシーを実行する条件を指定することができます。
今回作成したポリシーでは、アクセスを要求しているusernameがexampleで始まっているかを確認します。
今回作成したポリシーは、IAMユーザーやIAMユーザーグループ、IAMロールが実行できるアクション、リソース、条件の制御を記したアイデンティティベースのポリシーです。
アイデンティティベースのポリシーは、以下のように分類されます。
- 管理ポリシー
- AWS管理ポリシー：AWSが作成および管理するポリシー
- カスタマー管理ポリシー：AWSアカウントで作成および管理するポリシー
（今回作成したポリシーはこちらに該当します）
- インラインポリシー
また、s3などのAWSリソースにアタッチすることができるリソースベースのポリシーがあります。
アイデンティティベースのポリシーは何が行えるのかを定義したものでしたが、リソースベースのポリシーでは、誰がこのリソースにアクセスできるかを定義することができます。
リソースベースのポリシーでは「誰が」の部分を定義する必要があります。
ここでは、赤線で囲ったPrincipal要素で権限を付与する対象を定義します。
example-bucketのすべてのオブジェクトに対して、"arn:aws:iam::111122223333:root"がアクセスできることを記述しています。
最小限のアクセス権の付与
AWS IAMサービスを使用する最大の理由は、それぞれのサービスに対してアクセスを管理するなどのセキュリティの面にあります。
折角IAMを使用してアクセスを管理しているのに、その管理の仕方が大雑把で多数のユーザーが様々なリソースにアクセスすることができたら、セキュリティ面でよくありません。
そこで重要なのが「最小権限の原則」です。必要最低限の権限のみをIAMユーザーやIAMロールに付与することで、セキュリティリスクを回避するという考え方です。
むやみに広い権限を付与するのではなく、必要最低限の権限を付与することを意識して、ポリシーを作成することが求められます。
実際に触れて得たこと
今回実際にポリシーの作成を経験してみて、IAMに関する理解を深めることができました。
IAMを学ぶ前は、IAMユーザー、IAMロール、IAMポリシーなどの言葉が表すことを理解できていませんでしたが、それぞれの言葉が表すものを理解するだけでも全体像が浮かぶようになりました。
特に私自身はIAMロールとIAMポリシーの違いを理解していなかったので、どちらもリソースなどにアタッチできるから何が違うの？という印象でした。
IAMロールはIAMユーザーなどの一時的な権限を付与するという役割を担っており、IAMポリシーは権限の内容を記述したJSON形式の定義書であるなど、今回の経験でそれぞれの言葉を役割と結び付けて理解することができました。
まとめ
今回実際にポリシーの作成を通してAWS IAMを学んだことで、複雑なIAM関連の理解を深めることができました。
AWSの触れ始めは、IAMは似ている言葉が多くそれぞれが何を表しているのかを理解できないことがほとんどでした。
IAMは他のAWSサービスと密接にかかわりあっているサービスなので、他のAWSサービスを学習する際にも躓くポイントの一つでした。
今回の経験を通して、複雑なIAMの知識は一つ一つの項目をしっかりと理解することが必要だなと思いました。
一つ一つの言葉の理解を進めていくことによって、おのずとほかの言葉の意味が理解できるようになります。
複雑で密接に関わりあっているからこそ、一つ一つを理解することがIAM全体を理解することにつながっていたと思います。
単にAWSサービスを使用してインフラを構築できるだけでなく、今回学んだIAMのように、セキュリティなど様々な要素を考慮しながら構築をしていけるようにしたいです。
AWSの導入支援につきましては、弊社お問い合わせフォームまでお気軽にご連絡ください。 複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。 また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞
＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞
※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
