STAY KOBE

[SolutionArchitect Pro] AWS IAM ロール

Atsushi Marumo

AWS IAM ロール

AWS STS と一時的な資格情報

ロールの種類

AWS サービスのロール

プロセスフローの完了

  1. EC2 などの信頼できるエンティティとして使用するサービスで IAM ロールを作成し、サービスが必要とする権限ポリシーを定義します。
  2. インスタンスが起動されたときに EC2 サービスとのロール (実際にはインスタンスプロファイル) に関連付けられている。
  3. 一時的なセキュリティ認証情報がインスタンスで使用可能になり、有効期限が切れる前に自動的にローテーションされます。
  4. アプリケーションは、インスタンスメタデータを直接使用するか、AWS SDK を通じて一時的な資格情報を取得できます。
  5. EC2 インスタンスで実行されているアプリケーションは、ロールで定義されている権限を使用して他の AWS リソースにアクセスできるようになりました。
  6. アプリケーションは、資格情報をキャッシュする場合、有効期限が切れる前に正しい資格情報を使用していることを確認する必要があります

インスタンスプロファイル

クロスアカウントアクセスの役割

完全なプロセスフロー

  1. 信頼アカウントは、IAM ロールを作成します。
    • リソースにアクセスできるプリンシパルとしてアカウント (信頼されたアカウント) として指定する信頼ポリシーを定義します。
    • アクセス権限ポリシーによって、信頼されたアカウントのユーザーがアクセスできるリソースを定義できます。
    • 信頼するアカウントには、アカウント ID とロール名 (または ARN) が提供されます。
    • 信頼するアカウントが第三者によって所有されている場合は、必要に応じて外部 ID (追加のセキュリティを推奨) を提供し、信頼されたアカウントを一意に識別し、条件として信頼ポリシーに追加することができます。
  2. 信頼するアカウントは、ロールへを切り替えるアクセス権限（AWSセキュリティトークンサービス（AWS STS）AssumeRole APIを呼び出す権限）を持つIAMユーザーを作成します。
  3. 信頼されたアカウントの IAM ユーザーがロールに切り替え、役割を引き受け、役割の ARN を渡します。
    • サードパーティに所属する信頼されたアカウントは、信頼するアカウントに割り当てられた外部 ID も渡します。
  4. AWS STS は、役割の信頼ポリシーに一致する信頼されたリソースからのものであれば、ロール ARN、外部 ID の要求を検証し、
    検証が成功したときに AWS STS は一時的な資格情報を返します。
  5. 一時的な資格情報により、ユーザーは信頼するアカウントのリソースにアクセスできます。
    • ユーザーがロールを終了すると、ユーザーのアクセス許可は、ロールに切り替える前に保持されていた元のアクセス許可に戻ります。

外部 ID と混乱した代理問題

  1. お客様は、Example Corp のサービスの使用を開始するとき、AWS1:ExampleRole の ARN を Example Corp に提供します。
  2. Example Corp はそのロールの ARN を使用して、お客様の AWS アカウントのリソースにアクセスするために必要な一時的なセキュリティ認証情報を入手します。この方法では、お客様に代わって操作を実行できる “代理” として Example Corp を信頼します。
  3. 別の AWS ユーザーも Example Corp のサービスを利用し始め、このユーザーも AWS1:ExampleRole の ARN を Example Corp が使用できるように提供するとします。この別のユーザーは、秘密ではない AWS1:ExampleRole を知った、または推測した可能性があります。
  4. その別のユーザーが Example Corp に自分のアカウントの AWS リソース（そう自称しているリソース）へのアクセスを依頼すると、Example Corp は AWS1:ExampleRole を使用してお客様のアカウントのリソースにアクセスします。

このようにして、その別のユーザーはお客様のリソースに不正にアクセスできます。Example Corp は、この別のユーザーによって操られ、無意識にお客様のリソースにアクセスしたため、”混乱した代理” になります。

外部IDを使用して混乱した代理問題に対処する

  1. お客様は、Example Corp のサービスを利用し始めるとき、AWS1:ExampleRole の ARN を Example Corp に提供します。
  2. Example Corp がそのロールの ARN を使用して AWS1:ExampleRole ロールを引き受けるとき、Example Corp は AssumeRole API 呼び出しにお客様の外部 ID（”12345 “）を含めます。この外部 ID はロールの信頼ポリシーと一致するため、AssumeRole API 呼び出しは正常に実行され、Example Corp はお客様の AWS アカウントのリソースにアクセスするための一時的なセキュリティ認証情報を取得します。
  3. 別の AWS ユーザーも Example Corp のサービスを利用し始め、先ほどと同様、このユーザーも AWS1:ExampleRole の ARN を Example Corp が使用できるように提供するとします。
  4. しかし今回は、Example Corp が AWS1:ExampleRole ロールを引き受けるとき、別の顧客に関連付けられている外部 ID（”67890″）を提供するとします。その別の顧客がこの ID を変更することはできません。Example Corp がこれを行うのは、ロールを使用するリクエストが別の顧客から発生しており、”67890″ は Example Corp が業務を遂行する環境を示すからです。お客様は自身の外部ID（”12345″）を使用する条件を AWS1:ExampleRole の信頼ポリシーに追加したため、AssumeRoleAPI 呼び出しは失敗し、別の顧客がお客様のアカウントのリソースに不正にアクセスすることが防止されます（図の赤色の “X” で示しています）。

外部 ID により、Example Corp が別の顧客によって操られ、無意識にお客様のリソースにアクセスすることを防止でき、”混乱した代理” 問題が解消されます。

アイデンティティプロバイダとフェデレーション

AWS認定試験の練習問題

  1. 会社は、さまざまな AWS サービスへのアクセスを必要とする AWS のソフトウェアを構築しています。AWS 認証情報 (アクセスキー ID/シークレットアクセスキーの組み合わせ) が侵害されないようにするには、どの構成を使用する必要がありますか。
    1. AWS ルートアカウントに対して多要素認証を有効にします。
    2. Amazon EC2 インスタンスに IAM ロールを割り当てます。
    3. ソフトウェアコメントに AWS アクセスキー ID/シークレットアクセスキーの組み合わせを格納します。
    4. Amazon EC2 インスタンスに IAM ユーザーを割り当てます。
  2. 企業は、AWS マネジメントコンソールへのアクセスを開発者に提供する準備を進めています。会社のポリシーは、ID フェデレーションとロールベースのアクセス制御を義務付けています。ロールは現在、企業の Active Directory のグループを使用して割り当てられます。次のどのような組み合わせを使用すると、開発者は AWS コンソールにアクセスできますか。2つの回答を選択
    1. AWS ディレクトリサービスの AD コネクタ
    2. AWS ディレクトリサービスのシンプル AD
    3. AWS ID およびアクセス管理グループ
    4. AWS ID およびアクセス管理の役割
    5. AWS ID およびアクセス管理ユーザー
  3. お客様は、企業の IT ガバナンスと、その部門が消費するすべての AWS リソースのコストを監視する必要があります。部門は、消費する個別の AWS リソースの管理制御を維持し、他の部門のリソースとは別のリソースを維持したいと思っています。以下のオプションを併用することで、ガバナンスとコストの監視を維持しながら、部門の自主性/統制をサポートします。2つの回答を選択
    1. AWS 統合請求を使用して、子アカウントの AWS ルートアカウントアクセスを無効にします。
    2. 各子アカウントのすべての企業の IT 管理者に対して、IAM クロスアカウントアクセスを有効にします。(IT ガバナンスを提供)
    3. 企業の IT AWS アカウント内の各部門に個別の VPC を作成します。
    4. AWS 統合請求を使用して、部門の勘定を親企業アカウントにリンクします。(費用の監視を提供する)
    5. すべての子 AWS CloudTrail と Amazon CloudWatch ログを各子アカウントの Amazon S3 ‘Log’ バケットに書き込みます。
  4. EC2 インスタンスにデプロイされたアプリケーションが DynamoDB テーブルにデータを書き込むことを許可するには、次の項目のうちどれが必要ですか。EC2 インスタンスにセキュリティキーを格納できないことを前提としています。(2 つの回答を選択)
    1. DynamoDB テーブルへの書き込みアクセスを許可する IAM ロールを作成します。
    2. 実行中の EC2 インスタンスに IAM ロールを追加します。(AWS からの最新の拡張機能により、IAM ロールは実行中の EC2 インスタンスに割り当てることができます)
    3. DynamoDB テーブルへの書き込みアクセスを許可する IAM ユーザーを作成します。
    4. 実行中の EC2 インスタンスに IAM ユーザーを追加します。
    5. 起動構成に含まれている IAM ロールを使用して EC2 インスタンスを起動します (AWS が既存のインスタンスに IAM ロールを追加できなかったため、これは前の正解でした)
  5. 開発 (Dev) およびテスト環境を AWS に移行しようとしています。個別の AWS アカウントを使用して各環境をホストすることにしました。連結請求書を使用して、各勘定科目をマスター AWS アカウントにリンクする予定です。予算内で維持するには、マスターアカウントの管理者が、開発アカウントとテスト用の両方でリソースの停止、削除、または終了にアクセスできるようにする方法を実装することをお考えください。どのオプションがこの目標を達成できるかを特定します。[PROFESSIONAL]
    1. 完全な管理者権限を持つマスターアカウントで IAM ユーザーを作成します。マスターアカウントからアクセス許可を継承することによって、アカウントのリソースへのアクセスをマスターアカウントに付与する、開発アカウントとテスト勘定にクロスアカウントロールを作成します。
    2. マスターアカウントに IAM ユーザーとクロスアカウントロールを作成し、Dev および Test アカウントに完全な管理者権限を付与します。
    3. マスターアカウントで IAM ユーザーを作成する完全な管理者権限を持ち、マスターアカウントへのアクセスを許可する、Dev アカウントとテスト勘定のクロスアカウントロールを作成します。
    4. 連結請求を使用して勘定をリンクします。これにより、マスターアカウント内の IAM ユーザーは、Dev アカウントとテスト用資産のリソースにアクセスできるようになります。
  6. EC2 インスタンス上で実行されているアプリケーションを使用して、事前に割り当てられた URL を使用してプライベート S3 バケットからファイルをダウンロードすることができます。URL を生成する前に、アプリケーションは S3 でファイルの存在を確認する必要があります。アプリケーションが　AWS　認証を使用して　S3　バケットに安全にアクセスするにはどうすればよいですか？[PROFESSIONAL]
    1. アプリケーションがアプリケーションのソースコードから資格情報を取得する AWS アカウントアクセスキーを使用します。
    2. S3 バケットへのリストアクセスを許可するアクセス許可を持つアプリケーション用の IAM ユーザーを作成し、IAM ユーザーとしてインスタンスを起動し、EC2 インスタンスユーザーデータから IAM ユーザーの資格情報を取得します。
    3. EC2 の IAM ロールを作成して、S3 バケット内のオブジェクトへのリストアクセスを許可します。ロールを使用してインスタンスを起動し、EC2 インスタンスメタデータからロールの資格情報を取得します。
    4. S3 バケットへのリストアクセスを許可するアクセス許可を持つアプリケーションの IAM ユーザーを作成します。アプリケーションは、アプリケーションユーザーに対してのみ読み取りアクセスを許可するアクセス許可を持つ一時ディレクトリから IAM ユーザーの資格情報を取得します。
  7. 管理者は Amazon CloudFormation を使用して、CloudFormation テンプレートの作成時に Amazon DynamoDB を使用する Web 層とアプリケーション層で構成される3層 Web アプリケーションを展開し、次のようなアプリケーションインスタンスは、API 資格情報を公開せずに DynamoDB テーブルにアクセスできますか。[PROFESSIONAL]
    1. 必要な DynamoDB テーブルからの読み書きに必要なアクセス許可を持つ ID およびアクセス管理の役割を作成し、インスタンスプロファイルを参照してそのロールをアプリケーションインスタンスに関連付けます。
    2. Cloud Formation テンプレートの Parameter セクションを使用して、必要な DynamoDB テーブルの読み取りと書き込みに必要な権限を持つ、すでに作成された IAM ユーザからのユーザー入力のアクセスとシークレットキーの位置付けを行います。
    3. 必要な DynamoDB テーブルからの読み書きに必要なアクセス許可を持つ ID およびアクセス管理の役割を作成し、アプリケーションインスタンスの [インスタンスプロファイル] プロパティでロールを参照します。
    4. 必要な DynamoDB テーブルを読み書きする権限を持つ CloudFormation テンプレートで ID とアクセス管理のユーザーを作成し、GetAtt 関数を使用してアクセスと秘密のキーを取得し、ユーザーデータを使用してアプリケーションインスタンスに渡します。
  8. 企業はサードパーティの SaaS アプリケーションを使用したいと考えています。 SaaS アプリケーションは、エンタープライズアカウント内で実行されている Amazon EC2 リソースを検出するための API コマンドをいくつか発行する必要があります。 企業には、社内のセキュリティポリシーがあり、その環境への外部アクセスは最小限の特権の原則に従わなければならず、SaaS ベンダーが使用する資格情報を他の第三者が使用できないようにするためのコントロールが必要です。 これらの条件のすべてを満たすのは次のうちどれですか？
    1. AWS マネジメントコンソールから [セキュリティ資格情報] ページに移動し、アカウントのアクセスとシークレットキーを取得します。
    2. エンタープライズアカウント内に IAM ユーザーを作成する SaaS アプリケーションが必要とするアクションだけを許可するユーザーポリシーを IAM ユーザーに割り当て、ユーザーの新しいアクセスとシークレットキーを作成し、これらの資格情報を SaaS プロバイダに提供します。
    3. クロスアカウントアクセス用の IAM ロールを作成すると、SaaS プロバイダのアカウントがその役割を引き受け、SaaS アプリケーションが必要とするアクションのみを許可するポリシーを割り当てることができます。
    4. EC2 インスタンスの IAM ロールを作成し、それに割り当てますポリシーマットは、SaaS アプリケーションが動作するために必要なアクションのみを許可し、アプリケーションインスタンスを起動するときに使用する SaaS プロバイダにロールアームを提供します。
  9. ユーザーが EC2 でホストされるアプリケーションを作成しました。アプリケーションは DynamoDB を呼び出して特定のデータをフェッチします。アプリケーションは、DynamoDB SDK を使用して EC2 インスタンスから接続します。このシナリオでのセキュリティのベストプラクティスに関して、以下のステートメントのうちどれが当てはまりますか。
    1. ユーザーは、EC2 インスタンスへの DynamoDB アクセスを使用して IAM ロールをアタッチする必要があります。
    2. ユーザーは DynamoDB アクセスを使用して IAM ユーザーを作成し、アプリケーション内のその資格情報を DynamoDB に接続する必要があります。
    3. ユーザーは、アプリケーションのデプロイを許可するように EC2 アクセスを持つ IAM ロールを作成する必要があります。
    4. ユーザーは、DynamoDB および EC2 アクセスを使用して IAM ユーザーを作成する必要があります。ルートアカウントの資格情報を使用しないように、アプリケーションにユーザーをアタッチします。
  10. お客様は、さまざまな開発チームによって所有および運用される AWS に複数のアプリケーションをデプロイする過程にあります。各開発チームは、他のチームとは無関係にユーザーの承認を維持します。お客様の情報セキュリティチームは、ユーザーの承認を個々の開発チームに委任できるようにしますが、ユーザーのデバイスや場所などの要素に基づいて、ユーザーのアクセス許可に制限を適用することができます。たとえば、情報セキュリティチームは、ユーザーが企業ネットワークの外部から認証を受けているときに、読み取り/書き込みとして開発チームによって定義されたユーザーに読み取り専用のアクセス許可を付与することを希望します。情報セキュリティチームは、この機能を実装するためにどのような手順を実行できますか。[PROFESSIONAL]
    1. アプリケーション定義の IAM ロールから IAM ポリシーを使用して AWS STS トークンを生成する認証サービスを操作します。(ユーザーの分離はなく、単に一時的なトークンを生成するのに役立ちます)
    2. 情報セキュリティポリシーに基づいてユーザー特権を拒否するアプリケーション IAM ロールに、追加の IAM ポリシーを追加します。(場所、デバイス、およびより限定的な wins に基づくルールを拒否するポリシーが異なります)
    3. アプリケーション IAM ロールの変更を情報セキュリティチームのみに制限する IAM ポリシーを構成します。(承認は依然として開発者のコントロールである必要があります)
    4. 内部 LDAP ディレクトリとのフェデレーションを有効にし、ユーザーを変更するためのアプリケーションチームのアクセス許可を付与します。
  11. カスタムメトリックを CloudWatch に挿入する必要があるインスタンスを持つ自動スケーリンググループを作成しています。CloudWatch PUT リクエストを認証する最善の方法はどれですか。
    1. Put MetricData 権限を持つ IAM ロールを作成し、自動スケーリング起動構成を変更してそのロールのインスタンスを起動します。
    2. Put MetricData 権限を持つ IAM ユーザーを作成し、自動スケーリング起動構成を変更して、インスタンスユーザーデータにユーザー資格情報を挿入します。
    3. 適切なクラウドウォッチメトリックポリシーを変更して、自動スケーリンググループからインスタンスに Put MetricData アクセス許可を許可する
    4. PutMetricData 権限を持つ IAM ユーザーを作成し、資格情報をプライベートリポジトリに配置し、サーバー上のアプリケーションに必要に応じて資格情報を取得します。

Jayendra’s Blog

この記事は自己学習用に「AWS IAM Role – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。