IAM リソース - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

IAM リソース

簡単なアンケートを実施して、AWSセキュリティリファレンスアーキテクチャ (AWSSRA) のfuture に影響を与えましょう。

AWS Identity and Access Management (IAM) は従来のアーキテクチャ図に含まれるサービスではありませんが、AWS 組織、AWS アカウント、および AWS サービスのあらゆる側面に関係しています。最初に IAM エンティティを作成してアクセス権限を付与しない限り、AWS サービスをデプロイすることはできません。IAM の詳細な説明はこのドキュメントの範囲を超えていますが、このセクションでは、ベストプラクティスの推奨事項の重要な要約と、その他のリソースへのポインタを紹介します。

 

ユースケースまたはポリシー

[Effect] (効果)

によって管理されています

目的

に関係する

影響

にデプロイされました

サービスコントロールポリシー (SCP)

Restrict

プラットフォームチームやセキュリティチームなどの中央チーム [1]

ガードレール、ガバナンス

組織、OU、アカウント

組織、OU、アカウントのすべてのプリンシパル

組織管理アカウント [2]

ベースラインアカウント自動化ポリシー (プラットフォームがアカウントを運用するために使用する IAM ロール)

許可と制限

プラットフォーム、セキュリティ、IAM チームなどの中央チーム [1]

(ベースライン) 非ワークロード自動化ロールの権限 [3]

単一アカウント [4]

メンバーアカウント内のオートメーションで使用されるプリンシパル

メンバーアカウント

ベースラインヒューマンポリシー (ユーザーに作業を実行する権限を付与する IAM ロール)

許可と制限

プラットフォーム、セキュリティ、IAM チームなどの中央チーム [1]

ヒューマンロールの権限 [5]

単一アカウント [4]

フェデレーテッド・プリンシパル [5] と IAM ユーザー [6]

メンバーアカウント

権限の境界 (権限を与えられた開発者が別のプリンシパルに割り当てることができる最大アクセス権)

Restrict

プラットフォーム、セキュリティ、IAM チームなどの中央チーム [1]

アプリケーションロールのガードレール (適用が必要)

シングルアカウント [4]

このアカウントのアプリケーションまたはワークロードの個々のロール [7]

メンバーアカウント

アプリケーションのマシンロールポリシー (開発者がデプロイしたインフラストラクチャにアタッチされたロール)

許可と制限

開発者に委任 [8]

アプリケーションまたはワークロードの権限 [9]

単一のアカウント

このアカウントのプリンシパル

メンバーアカウント

リソースポリシー

許可と制限

開発者に委任 [8,10]

リソースへのアクセス許可

単一のアカウント

アカウントのプリンシパル [11]

メンバーアカウント

  

表のメモ:

  1. 企業には、これらの独立した統制の責任を分担し、互いのポリシーを相互にレビューする一元化されたチーム (クラウドプラットフォーム、セキュリティ運用、ID およびアクセス管理チームなど) が多数あります。表の例はプレースホルダです。お客様の企業にとって最も効果的な職務の分離を決定する必要があります。

  2. SCP を使用するには、AWS Organizations 内のすべての機能を有効にする必要があります。

  3. 自動化を有効にするには、通常、パイプラインのアクセス許可、デプロイツール、モニタリングツール (AWS Lambda や AWS Config ルールなど)、その他の権限など、共通のベースラインロールとポリシーが必要です。この設定は、通常、アカウントのプロビジョニング時に提供されます。

  4. これらは 1 つのアカウントのリソース (ロールやポリシーなど) に関するものですが、AWS を使用して複数のアカウントに複製またはデプロイできます。 CloudFormation StackSets

  5. 中央チームによってすべてのメンバーアカウントに展開される (多くの場合、アカウントのプロビジョニング中)、基本的な人間の役割とポリシーのコアセットを定義します。例としては、プラットフォームチームの開発者、IAM チーム、セキュリティ監査チームなどがあります。

  6. 可能であれば、(ローカルの IAM ユーザーの代わりに) ID フェデレーションを使用します。

  7. 権限の境界は、委任された管理者によって使用されます。この IAM ポリシーでは、アクセス許可の上限を定義し、その他のポリシー (リソースに対するすべてのアクションを許可する “*:*” ポリシー) をオーバーライドします。ロール (ワークロードパフォーマンスロールなど) を作成したりポリシーを添付したりする条件として、ベースラインのヒューマンポリシーに権限の境界を設定する必要があります。SCP などの追加設定では、権限境界の添付が強制されます。

  8. これは、十分なガードレール (SCP や権限境界など) がデプロイされていることを前提としています。

  9. これらのオプションポリシーは、アカウントのプロビジョニング中に提供することも、アプリケーション開発プロセスの一環として提供することもできます。これらのポリシーを作成してアタッチする権限は、アプリケーション開発者自身の権限によって管理されます。

  10. ローカルアカウントの権限に加えて、一元化されたチーム (クラウドプラットフォームチームやセキュリティ運用チームなど) は、アカウントを操作するためのクロスアカウントアクセスを可能にする (たとえば、ロギング用の S3 バケットへのアクセスを提供する) ためのリソースベースのポリシーを管理することがよくあります。

  11. リソースベースの IAM ポリシーは、任意のアカウントの任意のプリンシパルを参照して、そのリソースへのアクセスを許可または拒否できます。匿名プリンシパルを参照してパブリックアクセスを可能にすることもできます。

 IAM アイデンティティが明確に定義された一連のタスクに必要なアクセス許可のみを持つようにすることは、悪意のあるまたは意図しないアクセス権限の悪用のリスクを軽減するために重要です。最小限の特権を認めるモデル を確立し、維持するには、超過特権を継続的に更新、評価、軽減するための意図的な計画が必要です。ここでは、そのプランに関するその他のレコメンデーションを示します。

  • 組織のガバナンスモデルと確立されたリスクアペタイトを活用して、特定のガードレールと権限の境界を設定してください。

  • 継続的に繰り返されるプロセスを通じて、最小限の権限を導入してください。この演習を行うのは 1 回限りではありません。

  • SCP を使用して、実用的なリスクを軽減します。これらは、狭義のターゲットコントロールではなく、幅広いガードレールを目的としています。

  • アクセス権限の境界を使用して、より安全な方法で IAM 管理を委任します。

    • 委任された管理者が、作成したロールとユーザーに適切な IAM 境界ポリシーをアタッチしていることを確認します。

  • defense-in-depth アプローチとして (ID ベースのポリシーと併せて)、リソースベースの IAM ポリシーを使用してリソースへの広範なアクセスを拒否します。

  • IAM アクセスアドバイザー、AWS CloudTrail、AWS IAM Access Analyzer、および関連ツールを使用して、使用状況と付与された権限の履歴を定期的に分析します。明らかなオーバーパーミッションをすぐに修正します。

  • アスタリスクをワイルドカードとして使用し、すべてのリソースを示す代わりに、幅広いアクションを特定のリソースに適用します。

  • リクエストに基づいて IAM ポリシーの例外を迅速に識別、確認、承認するメカニズムを実装します。