AWSリソースへのアクセス管理に苦労していますか?組織が成長するにつれて?心配しないでください!AWSセキュリティトークンサービス(STS)がお手伝いします。
AWS STSを使用してロール特権を仮定すると、長期的な資格情報が不要な状態でユーザーやアプリケーションにAWSリソースへの一時的なアクセス権限を付与できます。そして、このチュートリアルでは、リソースを効率的に管理しながら安全かつ安全に保つ方法を学びます。
続けて、AWSインフラストラクチャとリソースを完全にコントロールしやすくなります!
前提条件
このチュートリアルは実演形式です。ステップに従うためには、AWSアカウントがアクティブな請求が有効になっていることを確認してください。ただし、無料利用枠アカウントでも十分です。
アクセス権限のないIAMユーザーの作成
AWS STSを使用してロール特権を仮定する前に、まずアクセス許可が割り当てられていないIAMユーザーを作成する必要があります。この操作は直感に反するように見えるかもしれませんが、IAMユーザーは直接ロールを仮定することはできません。まず、AWS STSサービスを介して役割を仮定することで一時的なセキュリティ資格情報を取得する必要があります。
アクセス権限のないIAMユーザーを作成するには、以下の手順に従ってください:
1. お気に入りのウェブブラウザを開き、ルートAWSアカウントでAWS管理コンソールにログインしてください。
2. 次に、サービスのリストからIAMを検索して選択し、IAMコンソールにアクセスします。

3. IAMコンソールで、ユーザー(左ペイン)に移動し、新しいユーザーの追加を開始するために[ユーザーの追加]をクリックします。

4. 今、以下のユーザー詳細を設定してください。このアクションにより、IAMユーザーはユーザー名とパスワードでAWS管理コンソールにサインインできます。
- ユーザー名 – 新しいユーザーの名前を入力し、以下のチェックボックスをオンにしてAWS管理コンソールへのユーザーアクセスを提供します。
- IAMユーザーを作成しているため、[IAMユーザーの作成]オプションを選択してください。
- コンソールのパスワード – 後で変更できるパスワードを生成するために[自動生成されたパスワード]オプションを選択します。
設定が完了したら、[次へ]をクリックしてIAMユーザーの作成を続行してください。

5. 次のページでは、デフォルトのままにしておき、[次へ]をクリックしてユーザーのアクセス許可の設定をスキップします。
このユーザーに権限を割り当てる必要はありません。なぜなら、権限がなくAWS管理コンソールへのアクセス権がないユーザーを作成しているからです。
権限がない場合、ユーザーは必要な権限を付与する役割を前提としてアクションを実行できません。

6. 次に、構成されたユーザー詳細を確認し、[ユーザーの作成]をクリックしてIAMユーザーの作成を確定します。

7. IAMユーザーのサインインURLとパスワードをコピーして保存してください。後でIAMユーザーでサインインする際にこの情報が必要です。

8. IAMコンソールに戻り、ユーザーページ(左ペイン)に移動し、新しく作成したユーザーの名前をクリックして、その概要ページにアクセスします。

9. 最後に、概要ページで、ユーザーのAmazonリソース名(ARN)、つまりユーザーの一意の識別子をメモしてください。後でユーザーに役割を割り当てる際にこのARNが必要になります。

カスタムトラストポリシーの準備
専用のIAMユーザーが作成されたので、AWSリソースへのアクセスを許可する役割を引き受ける準備が整いました。ただし、IAMユーザーが役割を引き受けるには、役割がまずユーザーを信頼する必要があります。
カスタムトラストポリシーを作成することで、IAMユーザーと役割の間に「信頼関係」を確立します。この信頼関係では、どのユーザーまたはアカウントが役割を引き受けることができ、どの条件の下で引き受けることができるかが指定されます。
カスタムトラストポリシーを準備するには、以下の手順に従ってください。
1. IAMコンソールのロール(左ペイン)に移動し、新しいロールを作成するために[ロールの作成]をクリックします。

2. 次に、カスタムトラストポリシーオプションをクリックしてカスタムポリシーを作成します。

3. 以下のポリシーをテキストフィールドに入力し、[次へ]をクリックします。最後のステップでメモしたIAMユーザーのARNを、”Creating an IAM User with Zero Access”セクションの最後のステップで指定したものに置き換えてください。
以下は、特定のIAMユーザーまたはロールが特定のIAMロールを前提とするカスタム信頼ポリシーの基本的な例です:
Field | Function |
---|---|
Version | Specifies the version of the policy language. |
Statement | Contains the policy statement(s). |
Effect | Specifies whether the statement allows or denies access, with Allow, in this case, granting access. |
Principal | Specifies the entity allowed to assume the role; in this example, it is an empty string. |
Action | Specifies the action the IAM user or role is allowed to perform. The sts:AssumeRole value allows the user to assume the specified IAM role. |

4. 次のページで、ポリシーのリストからAmazonEC2FullAccessを検索して選択し、「次へ」をクリックします。このポリシーはすべてのEC2リソースへのフルアクセスを付与します。

5. 次に、カスタム信頼ポリシーの名前を指定します(例:AWSEC2FULLACCESS)。

6. その他の設定はそのままにして、「ロールの作成」をクリックしてロールの作成を完了します。
この時点で、ロールはIAM(sts_user)によって前提とされるはずです。前提とされた場合、ユーザーはリスト、作成、削除などのすべてのEC2リソースにアクセスできます。

7. 下図に示すように、新しく作成したロールをクリックして詳細を表示します。

8. 最終的に、コンソールで役割を切り替えるリンクをコピーして保存します。IAMユーザー(sts_user)でサインインしてコンソールで役割を切り替える際に、このリンクが必要になります。

IAMユーザーと役割の切り替えと前提の設定
役割を作成した後、専用のIAMユーザーでその役割を前提とできるようになります。IAMユーザーでAWSコンソールにログインし、作成した役割に切り替えてEC2アクセスをテストします。
IAMユーザーで役割を切り替えて前提とする方法を見るには:
1. “Creating an IAM User with Zero Access” セクションのステップセブンでメモしたサインインURLに移動し、IAMユーザーのパスワードでログインしてください。
?別のブラウザまたはインコグニートウィンドウを使用して、ルートアカウントとの競合を回避してください。

2. ログインしたら、EC2コンソールに移動すると、赤いAPIエラーがいくつか表示されます。これらのエラーはIAMユーザーがEC2リソースにアクセスする権限がないことを示しています。
これらのエラーを修正するには、作成したロールを仮定して、次の手順ですべてのEC2リソース(AWSEC2FULLACCESS)へのアクセス権を付与する必要があります。AWSでロールを仮定すると、そのロールに関連付けられた権限を一時的に取得します。

3. 新しいブラウザタブを開き、”Preparing a Custom Trust Policy” セクションの最後でメモした “リンクを切り替える” に移動してください。
このリンクは、AWS Management Consoleのスイッチロールページに直接移動する特別なURLです。スイッチロールページでは、異なるロール、AWSリソースへのアクセスを決定する権限のセットを仮定できます。
4. セッションに説明的な表示名を提供し、”Switch Role” をクリックしてロールを仮定してください。表示名はアクティブなセッションを追跡するのに役立ちます。
ロールを仮定した後、ブラウザは選択したロールの権限でAWS Management Consoleにリダイレクトされます。

5. IAMユーザーがEC2リソースへのアクセス権を取得したかどうかを確認するために、再びEC2コンソールに移動してください。
すべてがうまくいけば、以前に見たAPIエラーはもう表示されなくなるはずです。なぜなら、今では役割の権限を持ってログインしており、EC2リソースへのアクセスを含む権限が付与されているからです。

6. 最後に、セッションの表示名(右上)をクリックし、元のIAMユーザーに切り替えるを選択します。
現在のセッションからログアウトし、元のIAMユーザーとその元の権限セットでログインします。この操作は、意図しないアクションを実行するリスクを軽減するためのベストプラクティスです。

結論
AWSでの役割の前提は、永続的な資格情報を共有せずに一時的なリソースへのアクセスを許可する強力な機能です。そして、このチュートリアルを通じて、AWS STSを使用した役割の前提権限を活用する方法を学びました。
この時点で、リソースのセキュリティを確保し、意図しないまたは悪意のあるアクションの潜在的な影響を最小限に抑えるために、限られた権限で役割を前提することができます。
AWS Management Consoleは、役割の前提などのAWSサービスを利用するための優れた方法です。しかし、AWSコマンドラインインターフェース(CLI)を使用して役割を前提するのはどうですか?AWS CLIを探索して自動化スクリプトに統合することで、より高度な機能が利用できるかもしれません。