クロスアカウントロールとリソースポリシー
あるアカウントに、別のアカウントのリソースへの範囲限定アクセスを付与します。
「クロスアカウントロールとリソースポリシー」はCoddyKit上の無料AWS Security Academyレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAWS Security Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Security Academyコースには全4レッスンが含まれています。
アカウント間アクセスの理由
実際のアーキテクチャは、本番アカウント、ログ記録アカウント、共有サービスアカウントなど、多数のアカウントにまたがります。ワークロードやユーザーは、これらの境界を越えてリソースにアクセスする必要があります。
安全な方法は、アカウント間で認証情報をコピーすることではありません。代わりに、アカウント間ロールまたはリソースベースポリシーを使って、範囲を限定したアクセスを許可します。
アカウント間ロールのパターン
最も一般的なパターンは、ソースアカウントのプリンシパルがターゲットアカウントのロールを引き受ける方式です。
- ロールの信頼ポリシーで、ソースアカウントまたはプリンシパルを指定します。
- ソースのプリンシパルがAssumeRoleを呼び出し、一時的な認証情報を受け取ります。
- その後、ロールの権限の範囲内でターゲットアカウントを操作します。
2つのポリシーの一致が必要
アカウント間でロールを引き受けるには、両方の側で許可する必要があります。
- ターゲットロールの信頼ポリシーが、ソースのプリンシパルを許可します。
- ソースプリンシパルのアイデンティティポリシーが、そのロールに対するsts:AssumeRoleを許可します。
どちらか一方が欠けていると、ロールの引き受けに失敗します。この二重の確認は、試験で頻出するポイントです。
リソースベースポリシー
一部のサービスでは、S3バケットポリシー、KMSキーポリシー、SQSキューポリシーなど、リソースに直接アタッチするリソースベースポリシーをサポートしています。
これらを使うと、別のアカウントのプリンシパルにロールを引き受けさせずにアクセスを許可できます。外部アカウントは独自のアイデンティティを使用し、リソースポリシーがそのアクセスを承認します。
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::444455556666:root" },
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::shared-logs-bucket/*"
}ロールチェーンとリソースポリシーの比較
サービスに応じて方式を選択します。
- リソースポリシーがないサービス（EC2やほとんどのAPI）では、アカウント間ロールを使用します。
- S3、KMS、SNS、SQS、Lambdaなどでは、リソースポリシーによってアカウント間の直接アクセスを許可できます。
リソースポリシーを使うと、追加のAssumeRole呼び出しを省略できます。
外部IDによる保護
SaaSベンダーなどの第三者にアカウント間アクセスを許可する場合は、信頼ポリシーに外部IDの条件を追加します。
ロールを引き受ける際、ベンダーは一意の秘密値を渡す必要があります。これにより、攻撃者がベンダーをだまして別の顧客のアカウントにアクセスさせる混乱した代理人の問題を防げます。
アカウント間での最小権限
アカウント間ロールには、特定のリソースとアクションに限定した必要最小限の権限を付与します。
よくある誤りは、外部アカウント全体に対する広範な信頼と、管理者権限を組み合わせることです。信頼の範囲を特定のロールまたはユーザーに絞り、権限も実行するタスクに必要なものだけに限定してください。
集中型サービスアカウント
よくある設計では、ある機能を1つのアカウントに集約し、他のアカウントからロール経由で利用します。たとえば、セキュリティアカウントが各ワークロードアカウントの読み取り専用ロールを引き受けます。
各ワークロードアカウントには、セキュリティアカウントを信頼する同名のロールを配置します。これにより、ツールで全アカウントを統一的にスキャンできます。
RAMによる共有
AWS Resource Access Manager（RAM）は、サブネットやTransit Gatewayなどの特定のリソースを、組織内のアカウント間で共有します。
RAMは、リソースを操作するAPI権限を付与するのではなく、リソース自体を共有するためのものです。ネットワークやインフラストラクチャの共有において、ロールやリソースポリシーを補完します。
アカウント間のアクセス経路の監査
アカウント間アクセスでは信頼の範囲が広がるため、定期的に監査してください。
- CloudTrailは、すべてのAssumeRoleとアカウント間API呼び出しを記録します。
- IAM Access Analyzerは、アカウント外へのアクセスを許可するリソースポリシーにフラグを付けます。
これらを確認して、意図しない共有を早期に発見します。
全体を組み合わせる
アカウントを安全に接続するには、コンピューティングとAPIにはロール、ストレージとメッセージングサービスにはリソースポリシーを優先し、第三者には外部IDを使用して、常に最小権限を適用します。
アカウント間で長期的なキーを共有してはいけません。
クイックチェック
アカウント間アクセスについて考えてみましょう。
まとめ
アカウントを安全に接続する方法を学びました。
- アカウント間ロールには、信頼ポリシーとソースのアイデンティティポリシーの両方が必要です。
- リソースベースポリシーを使うと、S3やKMSなどのサービスへの直接アクセスを許可できます。
- 第三者には外部IDを使用し、Access AnalyzerとCloudTrailで監査します。
よくある質問
「クロスアカウントロールとリソースポリシー」レッスンは無料ですか？
はい。「クロスアカウントロールとリソースポリシー」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Security Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Security Academyコースには全4レッスンが含まれています。
「クロスアカウントロールとリソースポリシー」で何を学びますか？
あるアカウントに、別のアカウントのリソースへの範囲限定アクセスを付与します。 ブラウザで直接実行するハンズオンコードでAWS Security Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
AWS Security Academyを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのAWS Security Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。
「クロスアカウントロールとリソースポリシー」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このAWS Security Academyレッスンでコードを書いて実行できますか？
はい。すべてのAWS Security Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- IAM Identity Centerによるシングルサインオン
- SAML、OIDC、Web Identity Federation
- クロスアカウントロールとリソースポリシー
- IAM Access Analyzerによる共有の監査