コーヒーが好きな木谷映見です。
「IAM ってどんなもの？」という概念をざっくりと掴むことを目的として書きました。
この記事で書くこと
- IAM の主要概念のみざっくり説明
この記事で書かないこと
- 具体的な IAM の操作方法
- 具体的な IAM ポリシーの記述方法
AWS Identity and Access Management (IAM) とは？
AWS リソースへのアクセスを安全に管理するためのサービスです。
AWS における認証・認可を制御します。
- 認証（誰なのか確認する、サインインさせる）
- 認可（承認する、許可する）
IAM で重要な 4 つの要素
AWS IAM で重要な以下 4 つの要素をおさえていきます。
- IAM ユーザ （ユーザ）
- IAM ポリシー （ポリシー）
- IAM ユーザーグループ （ユーザーグループ）
- IAM ロール （ロール）
IAM ユーザ （ユーザ）
AWS リソースの操作をするユーザです。私たちは IAM ユーザを使用して、AWS マネジメントコンソールにログインしたり、AWS の様々なサービスにアクセスします。
ゲームのプレイヤーのようなものです。
IAM ポリシー （ポリシー）
IAM ポリシーは、AWS サービスにアクセスするための権限です。実行できるアクション、リソース、および条件を制御します。
たとえば、IAM ユーザを作成しただけでは、AWS サービスに対するアクセス権限が何もないため、AWS サービスを利用することができません。
例えば、
- 「○○部のユーザは Amazon EC2 サービスのすべての機能にアクセスできる」
- 「△△部のユーザは この S3 バケットにアクセスできる」
- 「□□部のユーザは IAM ユーザを作ることができる」
などの IAM ポリシーを作成し、IAM ユーザに付与することで、与えられた権限の範囲内でAWS サービスを利用することができます。
実は IAM ポリシーの中にもいろいろと種類があるのですが、今回は「アイデンティティベースのポリシー」について言及しています。今はざっくりと、
IAM ポリシーとは、権限を与えるものである
ということをご理解いただければと思います。
アイデンティティベースの IAM ポリシーは
- IAM ユーザ
- IAM ユーザーグループ
- IAM ロール
に付与することができます。
IAM ユーザーグループ （ユーザーグループ）
IAM ユーザーグループとは、IAM ユーザをグループ化するものです。
例えば、AWS を利用するユーザが何百人もいる場合、ユーザ一人ひとりに必要なポリシーを付与する作業は大変です。同じ役割の人をIAM ユーザーグループにまとめ、ユーザーグループにポリシーを付与することで、複数のユーザにまとめて権限を付与することができ、管理も楽になります。
IAM ロール （ロール）
IAM ロールとは、AWS サービス自体に権限を持たせることができる帽子のようなものです。力が宿る帽子です。 かぶると力を得ます。
大まかに以下2つの目的で使用します。
1. （IAM ユーザ以外の）AWS サービス自体にアクセス権限を付与したいとき
2. IAM ユーザに、別のアカウントへのアクセス権限を付与したいとき
1. AWS サービス自体にアクセス権限を付与したいとき
例えば、AWS Lambda で EC2 インスタンスを起動する Lambda 関数を作成したとします。しかし、このままではこの Lambda 関数は EC2 インスタンスを起動することができません。 Lambda 関数には、EC2 インスタンスへのアクセス権がないからです。
そこで IAM ロールの出番です。まずIAM ロールを作成し、「EC2 インスタンスを起動するポリシー」を IAM ロールに付与します。
この IAM ロールを Lambda 関数に付与します。すると、この Lambda 関数は IAM ロールに宿った力を得て、 EC2 インスタンスを起動することができるようになります。
なぜわざわざ IAM ロールを介して Lambda 関数に IAM ポリシーを付与するかというと、 IAM ポリシー（アイデンティティベースのポリシー）はAWS サービスに直接付与することができないからです。
実はAWS サービスに直接設定する IAM ポリシーも存在するのですが、本記事では触れません。
2. IAM ユーザに、別の AWS アカウントへのアクセス権限を付与したいとき
IAM ロールを使うと、別の AWS アカウントのリソースにアクセスすることができます。いわゆる「スイッチロール」というものです。 スイッチロールすることで、 AWS アカウントをまたいだ AWS リソースの操作（クロスアカウントアクセス）が可能になります。
AWS アカウント Aの IAM ユーザから、AWS アカウントB の AWS リソースにアクセスしたい場合を考えます。
まず準備として、スイッチ先である AWS アカウントBに、「AWS アカウントBの EC2 インスタンスを起動するポリシー」を付与したIAM ロールを作成しておきます。
スイッチ元である AWS アカウントAのユーザは、スイッチ先である AWS アカウントBの IAM ロールをかぶることで、 IAM ロールに宿った力を得て、AWS アカウントBの EC2 インスタンスを起動することができるようになります。
細かくご説明しますと、スイッチ元であるAWS アカウント Aの IAM ユーザには「AWS アカウントBの IAM ロールをかぶることを許可するポリシー」を、 AWS アカウントBのIAM ロールには「AWS アカウントBの EC2 インスタンスを起動するポリシー」と「AWS アカウント Aの IAM ユーザを信頼するポリシー」の両方を設定する必要があります。
少々ややこしく感じるかもしれませんが、今回はざっくりとスイッチロールの概念をご理解いただきたいので、
「人んちの帽子をかぶったら人んちで遊べるようになるんだ！」
というようなイメージを持ち帰っていただければと思います。
IAM のベストプラクティス
IAM のベストプラクティスの一部、主要な点をご紹介します。
最小権限の原則
IAM ポリシーでアクセス許可を設定するときは、
タスクの実行に必要な最小限のアクセス許可のみを付与します。
権限を付与する場合は、その権限を有するユーザーの認証情報が漏洩したときのことを想像いただくとよいかもしれません。
全てのユーザーになんでもできる強い管理者権限を与えてしまうと、もしユーザーパスワードが漏洩した際、パスワードを手に入れた悪意のある第三者が何でもできる状態になってしまいます。
開発者にユーザーを払い出す場合、例えば EC2 アクセスのみ許可を付与する等、必要な権限を絞るように意識するとよいでしょう。
とはいえ、最初から必要最小限の権限を洗い出すのは大変な場合もありますので、まずはワークロードやユースケースに必要なアクセス許可を検討しながら、大まかなアクセス許可から始めるとよいでしょう。
IAM ユーザーは使いまわさない
IAM ユーザーの掴まわしは推奨されません。
IAM ユーザーの操作は CloudTrail というサービスによって記録されています。
IAM ユーザーを使いまわしてしまうと、どの操作を誰がやったか特定できず、情報が漏洩した際も、何が原因で漏洩してしまったか分からなくなってしまいます。 このため、IAM ユーザーは分けて、誰が何の操作を実施したか分かるようにしておくとよいでしょう。
終わりに
AWS IAM の主要な4つの要素について、なるべくかみ砕いて書いてきました。「AWS の学習は IAM に始まり IAM に終わる」という名言もあるほど、 IAM は重要で、 IAM なしにAWS を利用することはできません。一緒に IAM と仲良くなりましょう！
参考
emi kitani(執筆記事の一覧)
AS部LX課。2022/2入社、コーヒーとサウナが好きです。執筆活動に興味があります。AWS認定12冠。
