【AWS_23】IAMを理解する

AWSのIAMについて、机上のテスト勉強だけでいまいち理解できていなかったため、検証して理解を深めたいと思います。
今回勉強のために以下サイトを参考にさせていただきました、ありがとうございました。
今回の記事は検証をもとにした自分用にまとめたものとなりますので内容は薄いです・・・ご了承ください。
詳細を知りたい方は参考サイトを参照ください。

参考にさせていただいたサイト：

【2022年版ベストプラクティス】AWS IAMまとめ https://qiita.com/c60evaporator/items/0121399880625cc1de51

IAMとは

IAMは、「ユーザー」、「ユーザーグループ」、「ロール」、「ポリシー」などを作成して
誰がどのAWSのサービスやリソースにどのような条件でアクセスできるかを管理するためのシステムです。
ポリシーはもともと作成されているものを利用したり、カスタムして作成したものを利用したりすることができます。
ポリシーはユーザーやグループに割り当てて利用できます。

　　　

ユーザー、ユーザーグループ、ロール、ポリシー

ユーザー

・ルートユーザー（AWSへの最初の登録時に作成されるユーザーであり、最も強い権限を持つ）
・IAMユーザー（※おおまかには以下に分類）
　　管理者ユーザー（管理者）
　　パワーユーザー（多数のサービスを利用する開発者）
　　個別に権限付与するユーザー（一般的な開発者）

ユーザーグループ

複数のIAMユーザーをまとめて管理できる。グループに特定のポリシーを適用して、そのグループへ所属するユーザーへ同じポリシーを利用させることができる。

ロール

サービスから他のサービスへのアクセスする際に、アクセス元のサービス(EC2など)に権限を付与するための仕組みをロールと呼ぶ。※私が検証環境を用意できるレベルでないため、今回の記事では触れておりません

ポリシー

アクセス権限を適用する「対象サービス」と「アクセス条件」の管理をするのがポリシーです。
　●管理ポリシー → スタンドアロン（ユーザーやロールとは別個に作成する）ポリシー
　　　・AWS管理ポリシー → AWSがデフォルトで準備しているIAM管理ポリシー
　　　・カスタマー管理ポリシー → 利用者が独自に作成、管理する管理ポリシー
　●インラインポリシー → 1つのアイデンティティ（ユーザー、ロール、グループ）に埋め込まれたポリシー

※管理ポリシーは「複数のユーザーやグループ、ロール（アイデンティティ）で使い回し」できるのに対し、インラインポリシーはアイデンティティと1対1で紐づいているため、使い回しできない事が最大の差となります。※今回、インラインポリシーには触れていません

※AWS管理ポリシーを使用 → 必要に応じてカスタマー管理ポリシーを追加の順で選択・運用する事が推奨されているそうです。

　　　

ルートユーザーの作成と設定

ルートユーザーを作成されてない場合は、以下の記事を参考に作成してください。

【AWS_02】AWSアカウントの作成

ルートユーザーの位置づけは、AWSのお金の管理など全体的な管理の時に利用するようで、EC2インスタンスを作成して設定してというような使い方はセキュリティ的にもしないようです。
ここではルートユーザーのMFAを有効化します。必須ではないですが参考サイトを見て興味があったので設定しました。
スマホへGoogle Authenticatorのインストールが必要となります。

MFAを有効化

検索ボックスで「IAM」を検索します。

「IAM」を選択するとIAMダッシュボードが表示され、以下のような「rootユーザーのMFAを追加する」が表示されるので「MFAを追加」をクリックします。

デバイス名欄に任意の名前を入力（今回は mfa-iphone）します。
MFA device 項目で「認証アプリケーション」を選択し、「次へ」をクリックします。

スマホにGoogle Authenticatorをインストールします。
Google AuthenticatorでAWS側の画面に表示されているQRコードを読み込み、AWS側の画面に表示されているワンタイムパスワードを2回連続（30秒で切り替わる）で以下の画面に入力します。「MFAを追加」をクリックします。

IAMダッシュボードに戻ると「rootユーザーはMFAが設定されている」に緑レ点チェックが付いて有効かされていることが確認できます。
一度サインアウトしてサインインするとMFAの認証が発生することが確認できました。

　　　

管理者ユーザーの作成

ルートユーザーとは別にIAMで管理者ユーザを作成します。
管理者ユーザーが起点となり、他ユーザーの作成やAWSの設定を行うようにします。

ルートユーザーでコンソールにログインした状態でIAMに入り、「ユーザー」>「ユーザーの作成」をクリックします。

作成したい管理者ユーザー名を入力し、「AWSマネジメントコンソールへのユーザーアクセスを提供する – オプション」をチェックし、「IAMユーザーを作成します」を選択します。
任意の「カスタムパスワード」を入力、「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります – 推奨」のチェックを外し「次へ」をクリックします。

管理者用グループの作成
今回はグループ単位で権限を設定するので「グループの作成」をクリックします。
（ユーザー単位で直接権限を設定したい場合は「ポリシーを直接アタッチする」を選択します）

任意のユーザーグループ名を入力、管理者向けのポリシーとしてAWS管理ポリシーである「AdministratorAccess」を選択し、「ユーザーグループを作成」をクリックします。

ユーザーグループ「admin-g」が作成されたので「次へ」をクリックします。

「ユーザーの作成」をクリックします。

「.csvファイルをダウンロード」をクリックするとCSVファイルがダウンロードされます。
ダウンロードしたCSVファイルにはサインインに必要な情報が記載されています。サインインにはAccount IDも必要のようで専用URLでアクセスするとAccount IDが入力された状態でユーザー名,パスワードを入力するとサインインできます。

この時点では作成したユーザーグループにユーザー「admin」が所属していません。IAM > ユーザーグループを選択、ユーザーグループ「admin-g」をクリックします。

「ユーザーを追加」をクリックし、ユーザー「admin」にチェックを入れ、「ユーザーを追加」をクリックします。

ユーザーグループ「admin-g」へユーザー「admin」が追加されました。

許可タブを選択するとユーザーグループへ適用した「AdministratorAccess」が設定されていることが確認できます。

ルートユーザーからサインアウトし、管理者「admin」でサインインできることを確認します。

　　　

パワーユーザーの作成

管理者ユーザー（ルートユーザーではない）でサインインしてIAMコンソールに入り、パワーユーザーを作成します。
手順は上記で作成した管理者ユーザーとおおよそ同じです。
異なる点としてパワーユーザーは、「パスワードのリセットが必要」をチェックして初回ログイン時にパスワードを変更してもらうよう設定します。（任意です）
あと違いとして、ユーザーグループ名は「power-g」、ポリシーは「PowerUserAccess」を適用します。

ユーザーグループ名を「power-g」、管理者向けのポリシーとして「PowerUserAccess」を選択します。「ユーザーグループを作成」をクリックします。

次へをクリックし、ユーザーの作成をクリックします。※画面は管理者と同じため割愛しています

ユーザー「power」が作成されました。忘れずにCSVファイルをダウンロードしておきます。

ユーザーグループ「power-g」へユーザー「power」を追加します。
左ペインからユーザーグループを選択、「power-g」をクリックします。
ユーザータブから「ユーザーを追加」をクリックし、ユーザー「power」を追加します。

管理者ユーザー（ルートユーザーではない）からサインアウトして作成したユーザー「power」でサインインしてみます。
ユーザー作成時に設定したとおりにパスワード変更が促された後、サインインできました。

　　　

個別に権限付与するユーザーの作成

イメージとしては一番権限が少ない、必要なサービスのみ利用できるユーザーを作成する場合に使用します。
今回はEC2へのアクセス権限を持った個別に権限付与するユーザーを作成します。
（実際は、使用するサービスに絞って与える権限を適宜変更してください）
個別に権限付与するユーザーを2アカウント作成します。
　user01、user02

user01は、ユーザーグループ（group01）を作成してAWS管理ポリシーを割り当て、そのユーザーグループへユーザーを所属させます。
user02は、カスタマー管理ポリシーを作成し、ユーザーに直接ポリシーを適用します。

すべての作成作業を管理者ユーザー（ルートユーザーではない）で行います。

ユーザーグループへAWS管理ポリシーを割り当てるユーザーを作成

ユーザーグループ（group01）を作成

ユーザーグループ（group01）を作成し、AWS管理ポリシーを割り当てます。
管理者ユーザー（ルートユーザーではない）でコンソールにログインした状態でIAMに入り、「ユーザーグループ」>「グループを作成」をクリックします。

「ユーザーグループ名」へ「group01」を入力、「許可ポリシーを添付 – オプション」の検索ウィンドウで「ec2full」を入力すると「AmazonEC2FullAccess」のポリシーが表示されます。
左側にチェックを入れて「ユーザーグループを作成」をクリックします。

ユーザーグループ（group01）が作成されました。

ユーザー（user01）を作成

管理者ユーザー（ルートユーザーではない）でコンソールにログインした状態でIAMに入り、「ユーザー」>「ユーザーの作成」をクリックします。

「ユーザー名」へ「user01」を入力、「AWSマネジメントコンソールへのユーザーアクセスを提供する – オプション」をチェックし、「IAMユーザーを作成します」を選択します。
任意の「カスタムパスワード」を入力、「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります – 推奨」にチェックを入れて「次へ」をクリックします。

「許可のオプション」は、「ユーザーをグループに追加」を選択、「ユーザーグループ」は、「group01」にチェックを入れ、「次へ」をクリックします。

選択内容を確認し、「ユーザーの作成」をクリックします。

ユーザーが作成されるので「.csvファイルをダウンロード」をクリックし、CSVファイルをダウンロードしておきます。URL、ID、パスワードが記載されていますので大切に保存しておきます。「ユーザーリストに戻る」をクリックします。

「user01」が作成されていることが確認できました。

作成したuser01でサインインし、パスワード変更が促されることを確認します。
サインイン後、EC2マネジメントコンソールでインスタンスが起動できることを確認します。（EC2に関するポリシーが適用されていないとアクセス拒否のメッセージが表示されます）

参考：
EC2に関するポリシーが適用されてないと以下のように権限がないとメッセージが表示されます。

　　　

カスタマー管理ポリシーを直接割り当てるユーザーを作成

カスタマー管理ポリシーを作成

ユーザー（user02）を作成、カスタマー管理ポリシーを作成し、ユーザーへ直接割り当てます。
管理者ユーザー（ルートユーザーではない）でコンソールにログインした状態でIAMに入り、「ポリシー」>「ポリシーの作成」をクリックします。

「サービスを選択」から「EC2」を選択します。
「すべてのEC2アクション（ec2:*）」にチェックを入れます。
※展開される画面が長いの一部省略しています

画面下へ進み、「リソース」で「すべて」を選択し、「次へ」をクリックします。

「ポリシー名」に任意の名前を入力します。今回は「CustomEC2」とします。
「ポリシーの作成」をクリックします。

「CustomEC2」ポリシーが作成できました。

ユーザー（user02）を作成

管理者ユーザー（ルートユーザーではない）でコンソールにログインした状態でIAMに入り、「ユーザー」>「ユーザーの作成」をクリックします。
（user01と操作は同じため画像は割愛しています）

「ユーザー名」へ「user02」を入力、
「AWSマネジメントコンソールへのユーザーアクセスを提供する – オプション」をチェックし、「IAMユーザーを作成します」を選択します。
任意の「カスタムパスワード」を入力、「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります – 推奨」にチェックを入れて「次へ」をクリックします。
（user01と操作は同じため画像は割愛しています）

「許可のオプション」は、「ポリシーを直接アタッチする」を選択、「許可ポリシー」は、先ほど作成した「CustomEC2」を検索してチェックを入れ、「次へ」をクリックします。

選択内容を確認し、「ユーザーの作成」をクリックします。
（user01と操作は同じため画像は割愛しています）

ユーザーが作成されるので「.csvファイルをダウンロード」をクリックし、CSVファイルをダウンロードしておきます。URL、ID、パスワードが記載されていますので大切に保存しておきます。「ユーザーリストに戻る」をクリックします。
（user01と操作は同じため画像は割愛しています）

「user02」が作成されていることが確認できました。

作成したuser02でサインインし、パスワード変更が促されることを確認します。
サインイン後、EC2マネジメントコンソールでインスタンスが起動できることを確認します。（EC2に関するポリシーが適用されていないとアクセス拒否のメッセージが表示されます）

参考：実際どうかわかりませんが、検証においてアカウント作成後すぐにサインインをすると初回パスワード変更時に失敗することが多々ありました。古いパスワードが間違っていますと・・・しばらく時間をおいてからサインインすると問題なかったので参考にしていただければと思います。

　　　

まとめ

IAMを理解するため実際にユーザー、ユーザーグループ、ポリシーを作成し検証してみました。検証することで簡単な使い方は理解できました。

ロールについては、まずサービス（S3など）を使えるようにならないと検証できなさそうなので、後ほど検証して記事に追加したいと思います。

以下、他の記事をまとめた一覧です。AWSもまとめています。

記事一覧