こんにちは、セブテク編集部です。
皆さんは、AWSを利用したことはありますか?
このシリーズでは、AWS初心者向けに、少しだけAWSのことが分かる入門編となるような記事を作成しています。
第一弾はこちら↓↓
第二弾はこちら↓↓
今回は【IAM / アクセス管理編】として、AWSのアクセス管理の基本機能であるIAM(アイアム)についてご紹介します。
IAMとは
IAMとは、Identity and Access Management (アイデンティティおよびアクセス管理)の略で、AWSリソースを操作するために、認証・認可の仕組みを提供するためのものです。
AWSを利用する際、担当者一人だけではなく様々な関係者が操作を行うことがあります。また、担当者がアカウントを使い分けたいケースや、人ではなくアプリケーションに権限を付与したいケースもあります。そんなとき、アクセス範囲や実行できることを管理するのがIAMの役割です。
IAMに関連して、覚えておきたい単語が4つあります。
- ユーザー
- グループ
- ポリシー
- ロール
それでは、一つ一つ確認していきましょう。
ユーザー
ルートユーザー
AWSアカウントを作成時に作られるアカウントを「ルートユーザー」と呼びます。ルートユーザーはすべての権限を持つため、万が一流出した場合のリスクも高いです。そのため、日常的にルートユーザーを使用することは推奨されません。
その代わりに使用するのが「IAMユーザー」です。 次の項目では、IAMユーザーについて詳しく見ていきましょう。
IAM ユーザー
IAM ユーザーは、個別のAWSアカウントではなく、そのアカウントに所属するユーザーです。
ルートユーザーがすべての権限を持つ「最強のユーザー」であるのに対して、IAMユーザーは「一般ユーザー」と考えるとわかりやすいでしょう。
現時点でAWSにアクセスする担当者が自分一人であったとしても、日常使用のために IAMユーザーを作成することが推奨されています。これは、ルートユーザーを使い続けるリスクを避けるためです。
また、新しいメンバーがチームに参加したときにもIAM ユーザーを作成することができます。IAMユーザーは、1アカウントあたり5000ユーザーまで作成可能です。
グループ
作成したIAMユーザーは、グループに所属させることができます。 ユーザー一人一人に権限を与える代わりに、グループに権限を与えてそこにユーザーを所属させることで、より管理がしやすくなります。「管理者グループ」「開発者グループ」「運用グループ」などを作成すると便利でしょう。
ポリシー
作成したIAMユーザーやグループに、どのように権限を与えていけばよいのでしょうか。ここで登場するのが「ポリシー」です。
ポリシーは、アクセス許可を定義したものです。これをユーザーやグループなどに割り当てることで、そのユーザーやグループが「どこに、どのレベルで」アクセスしてよいかを明確にすることができます。
ポリシーは、3つの種類に分けられます。
AWS管理ポリシー
AWSが作成・管理するポリシーです。多くの一般的なユースケースでアクセス許可を提供できるように設計されています。
カスタマー管理ポリシー
AWSアカウントでユーザーが独自に作成・管理できるポリシーです。既存のAWS管理ポリシーをコピーしてカスタマイズすることでも作成ができます。
インラインポリシー
IAMユーザー、IAMグループなどに直接埋め込まれるポリシーです。
各ユーザーやグループに対し独自に埋め込まれ、そのアイデンティティの一部になります。そのため、埋め込み先のIAMユーザーやIAMグループを削除すると、インラインポリシーも同時に削除されます。管理ポリシーに比べ再利用性が低いことなどから、インラインポリシーの利用はできるだけ避けることが望ましいとされています。
ロール
ここまで、IAMユーザー、IAMグループ、IAMポリシーを紹介してきました。もう一つIAMの主要な要素として、IAMロールがあります。
IAMロールは、AWSサービスやアプリケーションなどに対して、AWSリソースの操作権限を付与するための仕組みです。ユーザーまたはアプリケーションがロールを一時的に引き受けることで関連付けられたアクセス許可を受けることができます。
ロール、つまり役割を「一時的に引き受ける」ということがここでのポイントになります。「引き受ける」という表現は「切り替える」と言い換えることもできます。
ロールを使用した例を二つご紹介します。
クロスアカウントアクセス
IAMロールによるクロスアカウントアクセスの例です。
次のようなケースを想定します。
- 自社でAWSアカウントを「開発用」「本番用」の二つ持っている
- 開発者(IAMユーザー)は開発用アカウントに所属して作業を行っているが、必要に応じて本番用アカウントの S3 バケット にアクセスしたい
通常、別アカウントを使用する場合はそのアカウント用の認証情報を使用しなければならないのですが、ID管理が煩雑になってしまいます。そんなとき、ロールを引き受け/切り替えすることで別アカウントでの作業ができます。
フローは次の通りです。
1.「本番用アカウントの管理者」が「開発用アカウントへの信頼ポリシー」を定義したロールを作成し、 ロールのアクセス許可ポリシーで「S3 バケットに対するユーザーの読み取りと書き込みのアクセス」を指定する。
2.「開発用アカウントの管理者」が「開発用アカウント内の開発者グループのメンバー」に対して、1のロールに切り替えるアクセス許可を付与する
3.「開発用アカウント内の開発者グループのユーザー」がロールの切り替えをリクエストして、一時的に認証される
4.3のユーザーが、ロールを使用して本番用アカウントの S3 バケット にアクセスする
5. 3のユーザーがロールの使用を終了し、元のユーザーアクセス権限に戻る
このシナリオでは、開発用アカウントに所属するユーザーが本番用アカウントのS3にアクセスするためのロールを一時的に引き受けることで、必要な作業を行うことができます。
ロールを引き受けている間はロールによって許可されているリソースのみにアクセスできますが、元のユーザーアクセス権限は停止されます。ユーザーがそのロールを終了すると、元のユーザーのアクセス権限に戻ります。
EC2インスタンスのAWSサービスロール
次に、サービスロールを使用した例を見ていきましょう。サービスロールとは、サービス(EC2など)がユーザーに代わって、ユーザーのアカウントでアクションを実行するために引き受けるロールです。
次のようなケースを想定します。
- EC2インスタンス上に設置したアプリケーションから、 S3バケット にアクセスしたい
ロールを使用しない場合、各インスタンスにAWS認証情報を配布する必要があります。これは管理が難しく、漏洩のリスクが高まります。ロールを使用すれば、アプリケーションが他の AWS リソースへの呼び出しを行うときに使用できる一時的なアクセス許可を提供できます。
フローは次の通りです。
1. EC2用のロールを作成します。アクセス許可ポリシーで、S3バケットに対する読み取り専用アクセス許可を指定します。
2. EC2を立ち上げて、1で作成したロールを指定します。
3. 2で立ち上げたEC2インスタンスで実行されるアプリケーションは、ロールから提供される一時的な認証情報を取得します。
4. 取得された一時的な認証情報を使用して、アプリケーションはS3バケットにアクセスできます。ここで使用される一時的な認証情報は失効前に自動的に更新されるため、有効な認証情報を常に使用できます。
参考
IAMについては、AWS公式ドキュメントやオンラインセミナー資料でさらに詳しく確認ができます。
AWS Identity and Access Management ユーザーガイド
[AWS Black Belt Online Seminar] AWS Identity and Access Management (AWS IAM) Part1 資料公開
まとめ
今回は【IAM / アクセス管理編】として、AWSのアクセス管理機能であるIAMについて確認しました。 文章中に出てきた「EC2」「S3」などの用語が気になる方は、【用語・サービス編】、 AWSのアカウント作成の手順やログイン後の画面操作について 知りたい方は 【はじめかた編】 もチェックしてみてくださいね。
非エンジニアでも知っておきたいAWSの基本【用語・サービス編】
https://blog.sprobe.com/aws01/
非エンジニアでも知っておきたいAWSの基本②【はじめかた編】
https://blog.sprobe.com/aws02/