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

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

IAM リソース

セキュリティ AWS リファレンスアーキテクチャ (AWS SRA) の未来に影響を与えるために、簡単なアンケートに回答してください。

AWS Identity and Access Management (IAM) は従来のアーキテクチャ図に含まれているサービスではありませんが、AWS 組織、AWS アカウント、AWS サービスのあらゆる側面に触れています。AWS エンティティを作成し、最初にアクセス許可を付与しない限り、IAM サービスをデプロイすることはできません。IAM の完全な説明は、このドキュメントの範囲外ですが、このセクションでは、ベストプラクティスの推奨事項の重要な概要と、追加のリソースへのポインタを提供します。

 

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

[Effect] (効果)

による管理

目的

が対象

影響

にデプロイ

サービスコントロールポリシー (SCPs）

Restrict

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

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

組織、OU、アカウント

Organization、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. 企業には、これらの独立したコントロールの責任と相互のポリシーを分担する集中型チーム (クラウドプラットフォーム、セキュリティ運用、アイデンティティとアクセス管理チームなど) が多数あります。表の例はプレースホルダです。お客様の企業にとって最も効果的な職務の分離を決定する必要があります。

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

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

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

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

  6. 可能な限り、ID フェデレーション (ローカル IAM ユーザーではなく) を使用します。

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

  8. これは、十分なガードレール (SCPs やアクセス許可の境界など) がデプロイされていることを前提としています。

  9. これらのオプションのポリシーは、アカウントのプロビジョニング中、またはアプリケーション開発プロセスの一環として配信できます。これらのポリシーを作成およびアタッチするアクセス許可は、アプリケーションデベロッパー自身のアクセス許可によって管理されます。

  10. ローカルアカウントのアクセス許可に加えて、一元化されたチーム (クラウドプラットフォームチームやセキュリティオペレーションチームなど) は、多くの場合、一部のリソースベースのポリシーを管理して、アカウントを運用するためのクロスアカウントアクセスを有効にします (ログ記録用の S3 バケットへのアクセスを提供するなど）。

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

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

  • 組織のガバナンスモデルと確立されたリスク選好を使用して、特定のガードレールとアクセス許可の境界を確立します。

  • 継続的な反復プロセスを通じて最小特権を実装します。この演習を行うのは 1 回限りではありません。

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

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

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

  • a defense-in-depth アプローチ (アイデンティティベースのポリシーと組み合わせて) では、リソースベースの IAM ポリシーを使用して、リソースへの広範なアクセスを拒否します。

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

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

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