AWS IAM ロール

  • IAM ロールは、AWS で ID ができることとできないことを決定するアクセス権ポリシーを持つ ID であるという点で、ユーザーと非常によく似ています。
  • IAM ロールは、特定のユーザー、グループ、またはサービスと一意に関連付けられることを意図したものではなく、必要とする人は誰でも想定できるものです。
  • ロールには、それに関連付けられた資格情報 (パスワードまたはアクセスキー) がなく、ロールが動的な一時資格情報と共に提供されることを前提としています。
  • ロールは、アクセス委任において、ユーザーが制御するリソースへのアクセスを許可する権限を付与するのに役立ちます。
  • ロールは、機密性の高いリソースへの偶発的なアクセスや変更を防ぐのに役立ちます。
  • ロールの変更はいつでも行うことができ、直ちにロールに関連付けられたすべてのエンティティに反映されます。
  • IAM ロールは、次のシナリオで非常に重要な役割を果たします。
    • 他の AWS サービスにアクセスする必要があるアプリケーションを実行している EC2 インスタンスなどのサービス
    • 異なる AWS アカウントのユーザーが、ユーザーを作成するのではなく、異なるアカウントの AWS リソースにアクセスできるようにする
    • 会社は企業認証メカニズムを使用し、ユーザーが2回認証したり、AWS で重複したユーザーを作成したりしたくない
    • 外部認証メカニズム (Amazon、Facebook、Google など) によるログインを許可するアプリケーション
  • ロールが引き受けることができる
    • 同じ AWS アカウント内の IAM ユーザー
    • 別の AWS アカウントからの IAM ユーザー
    • EC2、EMR などの AWS サービスが他のサービスと対話する
    • SAML 2.0 または OpenID Connect (OIDC)、またはカスタム構築された ID ブローカと互換性のある外部 ID プロバイダ (IdP) サービスによって認証された外部ユーザー。
  • ロールには2つのポリシーの定義が含まれる
    • 信頼ポリシー
      • 信頼ポリシーの定義 – ロールを引き受けることができる人
      • 信頼ポリシーでは、リソース (信頼するアカウント) を所有するアカウントと、リソース (信頼されたアカウント) へのアクセスを必要とするユーザーを所有するアカウントとの間に信頼を設定する必要があります
    • 権限ポリシー
      • 権限ポリシー定義 – アクセスできる
      • 権限ポリシーによって承認が決定され、ユーザーに対して必要な権限がリソースに対して実行されるようになります。
    • フェデレーションは、外部 ID プロバイダー (IdP) と AWS との間の信頼関係を作成しています
      • ユーザーは、SAML と互換性のあるエンタープライズ ID システムにサインインすることもできます。
      • ユーザーは、Amazon、Facebook、Google、または OpenID connect (OIDC) と互換性のある IdP を使用したログインなど、Web ID プロバイダにサインインできます。
      • OIDC と SAML 2.0 を使用してこれらの外部 ID プロバイダと AWS 間の信頼関係を構成する場合、ユーザーは IAM ロールに割り当てられ、ユーザーが AWS リソースにアクセスできるようにする一時的な資格情報を受け取ります。
    • IAM ベストプラクティス – EC2 インスタンスで実行されるアプリケーションにロールを使用する。
    • IAM ベストプラクティス – 資格情報を共有する代わりに役割を使用して委任する。

AWS STS と一時的な資格情報

  • AWS セキュリティトークンサービス (STS) は、AWS リソースへのアクセスを制御できる一時的なセキュリティ認証情報を使用して、信頼されたユーザーを作成および提供するのに役立ちます。
  • AWS STS は、単一のエンドポイント https://sts.amazonaws.com を持つグローバルサービスです。
  • AWS STS API 呼び出しは、グローバルエンドポイントまたはリージョンエンドポイントのいずれかに対して行うことができます。地域エンドポイントは、待ち時間を短縮し、API 呼び出しのパフォーマンスを向上させるのに役立ちます。
  • 一時的な資格情報は、長期の資格情報に似ています。
    • 短期的であり、定期的にローテーションされている
    • 数分から数時間まで続くように構成可能
    • 埋め込みまたは分散する必要はありません
    • ユーザーに対して保存または添付されず、動的に生成され、要求時にユーザーに提供されます。

ロールの種類

AWS サービスのロール

  • いくつかの AWS サービスは、S3、SQS などと相互作用する EC2 などの他の AWS サービスと対話する必要があります。
  • 長期の資格情報を複数のインスタンスに配布したり、複数のインスタンスにローテーションすることは、管理が難しく、潜在的なセキュリティリスクがあるため、IAM のユーザー資格情報をインスタンスに直接埋め込むか、IAM ロールに割り当てるのがベストプラクティスです。
  • AWS は、アプリケーションに代わって Amazon EC2 インスタンスなどのサービスに対して一時的なセキュリティ認証情報を自動的に提供します。
  • 実行中の EC2 インスタンスに関連付けられているロールまたはインスタンスプロファイルを削除すると、インスタンスで実行されているすべてのアプリケーションが中断されます。

プロセスフローの完了

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

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

  • インスタンスプロファイルは、インスタンスの起動時に EC2 インスタンスにロール情報を渡すために使用できる IAM ロールのコンテナです。
  • EC2 インスタンスまたは AWS マネジメントコンソール経由で EC2 を使用するその他のサービスに対してロールが作成された場合、AWS はロールと同じ名前のインスタンスプロファイルを自動的に作成します。ただし、CLI を使用してロールを作成する場合は、インスタンスプロファイルも作成する必要があります。
  • インスタンスプロファイルには、1つの IAM ロールのみを含めることができます。ただし、ロールは複数のインスタンスプロファイルに含めることができます。

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

  • IAM ユーザーは、同じ AWS アカウント内のロールを切り替える権限、または所有する他の AWS アカウントで定義されているロールを許可することができます。
  • ロールを使用して、サードパーティが所有する AWS アカウントから IAM ユーザーにアクセス許可を委任することもできます。
    • ロールを引き受ける権限をユーザーに明示的に付与する必要があります。
    • ユーザーは、AWS マネジメントコンソールを使用して、積極的にロールに切り替える必要があります。
    • MFA デバイスでサインインするユーザーだけが役割を引き受けることができるように、役割に対して多要素認証 (MFA) 保護を有効にすることができます。
  • ただし、一度に適用できる権限のセットは1つだけです。ロールを想定しているユーザーは、一時的に自分の権限を与え、代わりにロールの権限を取得します。ユーザーがロールの使用を終了または停止すると、元のユーザーの権限が復元されます。

完全なプロセスフロー

個別の開発用アカウントと本稼働用アカウントを使用したシナリオ

  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 と混乱した代理問題

  • 外部 ID を使用すると、ロールを想定しているユーザーが、動作している状況をアサートできます。
  • 外部 ID は、アカウント所有者が特定の状況下でのみ役割を引き受けることを許可し、未承認の顧客がリソースにアクセスできないようにする手段を提供します。
  • 外部 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認定試験の練習問題

  • 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
  • AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
  • AWSのアップデートのペースを追うために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より）」を日本語に訳した記事です。