翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # IAM リソース | | | --- | | [簡単な調査](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)を行い、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えます。 | AWS Identity and Access Management (IAM) は従来のアーキテクチャ図に含まれるサービスではありませんが、 AWS 組織のあらゆる側面、 AWS アカウント、および に影響します AWS のサービス。IAM エンティティを作成し、最初にアクセス許可を付与 AWS のサービス しない限り、 をデプロイすることはできません。IAM の完全な説明は、このドキュメントの範囲外ですが、このセクションでは、ベストプラクティスの推奨事項と追加のリソースへのポインタの重要な概要を提供します。 + IAM のベストプラクティスについては、「 AWS ドキュメント」の[「IAM のセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」、 AWS 「 セキュリティブログ」の[「IAM 記事](https://aws.amazon.com/blogs/security/category/security-identity-compliance/aws-identity-and-access-management-iam/)」、および[AWS 「re:Invent プレゼンテーション](https://www.youtube.com/watch?v=YQsK4MtsELU)」を参照してください。 + AWS Well-Architected セキュリティの柱は、[アクセス許可管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)プロセスの主要なステップの概要を示しています。アクセス許可ガードレールの定義、最小特権アクセスの付与、パブリックアクセスとクロスアカウントアクセスの分析、リソースの安全な共有、アクセス許可の継続的な削減、緊急アクセスプロセスの確立です。 + 次の表とそれに付随するメモは、使用可能な IAM アクセス権限ポリシーの種類と、セキュリティアーキテクチャでのそれらの使用方法に関する推奨ガイダンスの概要を示しています。詳細については、次を参照してください。[AWS re:Invent 2020のビデオで IAMポリシーの適切な組み合わせを選択について](https://www.youtube.com/watch?v=o1bfA0SIxBk) 参照してください。 | | | | | | | | | --- |--- |--- |--- |--- |--- |--- | | **ユースケースまたはポリシー** | **[Effect]** (効果) | **による管理** | **目的** | **に関連** | **影響** | **にデプロイ** | | **サービスコントロールポリシー (SCP)** | Restrict | プラットフォームチームやセキュリティチームなどの中央チーム [1] | ガードレール、ガバナンス | 組織、OU、アカウント | Organization、OU、および アカウントのすべてのプリンシパル | 組織管理アカウント [2] | | **リソースコントロールポリシー (RCPs)** | Restrict | プラットフォームチームやセキュリティチームなどの中央チーム [1] | ガードレール、ガバナンス | 組織、OU、アカウント | メンバーアカウントのリソース [12] | 組織管理アカウント [2] | | **ベースラインアカウントの自動化ポリシー** (アカウントを運用するためにプラットフォームが使用する IAM ロール) | 許可と制限 | プラットフォーム、セキュリティ、IAM チームなどの中央チーム [1] | (ベースライン) 非ワークロード自動化ロールのアクセス許可 [3] | 単一アカウント [4] | メンバーアカウント内のオートメーションで使用されるプリンシパル | メンバーアカウント | | **ベースラインヒューマンポリシー** (作業を実行するためのアクセス許可をユーザーに付与する IAM ロール) | 許可と制限 | プラットフォーム、セキュリティ、IAM チームなどの中央チーム [1] | ヒューマンロールのアクセス許可 [5] | 単一アカウント [4] | フェデレーティッドプリンシパル [5] と IAM ユーザー [6] | メンバーアカウント | | アクセス**許可の境界** (権限のある開発者が別のプリンシパルに割り当てることができるアクセス許可の最大数) | Restrict | プラットフォーム、セキュリティ、IAM チームなどの中央チーム [1] | アプリケーションロールのガードレール (適用する必要があります) | 単一アカウント [4] | このアカウントのアプリケーションまたはワークロードの個々のロール [7] | メンバーアカウント | | **アプリケーションのマシンロールポリシー** (開発者がデプロイしたインフラストラクチャにアタッチされたロール) | 許可と制限 | デベロッパーに委任 [8] | アプリケーションまたはワークロードのアクセス許可 [9] | 単一のアカウント | このアカウントのプリンシパル | メンバーアカウント | | **リソースポリシー** | 許可と制限 | 開発者に委任 [8,10] | リソースへのアクセス許可 | 単一のアカウント | アカウントのプリンシパル [11] | メンバーアカウント | | **中央ルートユーザー管理** | 許可と制限 | プラットフォーム、セキュリティ、IAM チームなどの中央チーム [1] | メンバーアカウントのルートユーザーを大規模に一元管理する | 組織 | メンバーアカウントのすべてのルートユーザー | 組織管理アカウント、委任管理者アカウント | テーブルからのメモ: 1. 企業には、これらの独立したコントロールの責任と相互のポリシーを分担する集中型チーム (クラウドプラットフォーム、セキュリティオペレーション、アイデンティティおよびアクセス管理チームなど) が多数あります。表の例はプレースホルダです。お客様の企業にとって最も効果的な職務の分離を決定する必要があります。 1. SCPs を使用するには、 内のすべての[機能を有効にする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)必要があります AWS Organizations。 1. パイプラインのアクセス許可、デプロイツール、モニタリングツール ( AWS Lambda や など AWS Config ルール)、その他のアクセス許可など、自動化を有効にするには、一般的に共通のベースラインロールとポリシーが必要です。この設定は、通常、アカウントのプロビジョニング時に提供されます。 1. これらは 1 つのアカウントのリソース (ロールやポリシーなど) に関連していますが、[AWS CloudFormation StackSets ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)を使用して複数のアカウントにレプリケートまたはデプロイできます。 1. 中央チームによってすべてのメンバーアカウントに展開される (多くの場合、アカウントのプロビジョニング中)、基本的な人間の役割とポリシーのコアセットを定義します。例としては、プラットフォームチームの開発者、IAM チーム、セキュリティ監査チームなどがあります。 1. 可能であれば、(ローカルの IAM ユーザーの代わりに) ID フェデレーションを使用します。 1. 権限の境界は、委任された管理者によって使用されます。この IAM ポリシーでは、アクセス許可の上限を定義し、その他のポリシー (リソースに対するすべてのアクションを許可する `"*:*"` ポリシー) をオーバーライドします。ロール (ワークロードパフォーマンスロールなど) を作成し、ポリシーをアタッチするための条件として、ベースラインのヒューマンポリシーでアクセス許可の境界が必要です。SCP などの追加設定では、権限境界の添付が強制されます。 1. これは、十分なガードレール (SCP や権限境界など) がデプロイされていることを前提としています。 1. これらのオプションポリシーは、アカウントのプロビジョニング中またはアプリケーション開発プロセスの一部として配信できます。これらのポリシーを作成してアタッチするアクセス許可は、アプリケーション開発者自身のアクセス許可によって管理されます。 1. ローカルアカウントのアクセス許可に加えて、一元化されたチーム (クラウドプラットフォームチームやセキュリティオペレーションチームなど) は、多くの場合、一部のリソースベースのポリシーを管理し、アカウントを運用するためのクロスアカウントアクセスを有効にします (ログ記録用の S3 バケットへのアクセスを提供するなど）。 1. リソースベースの IAM ポリシーは、任意のアカウントの任意のプリンシパルを参照して、そのリソースへのアクセスを許可または拒否できます。また、匿名プリンシパルを参照してパブリックアクセスを有効にすることもできます。 1. RCPs、 のサブセットのリソースに適用されます AWS のサービス。詳細については、 ドキュメント[の「RCP AWS のサービス をサポートする のリスト RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#rcp-supported-services)」を参照してください。 AWS Organizations IAM アイデンティティが明確に定義された一連のタスクに必要なアクセス許可のみを持つようにすることは、悪意のあるまたは意図しないアクセス権限の悪用のリスクを軽減するために重要です。[最小限の特権を認めるモデル](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) を確立し、維持するには、超過特権を継続的に更新、評価、軽減するための意図的な計画が必要です。ここでは、そのプランに関するその他のレコメンデーションを示します。 + 組織のガバナンスモデルと確立されたリスク選好度を使用して、特定のガードレールとアクセス許可の境界を確立します。 + *継続的な反復プロセス*を通じて最小特権を実装します。この演習を行うのは 1 回限りではありません。 + SCP を使用して、実用的なリスクを軽減します。これらは、狭義のターゲットコントロールではなく、幅広いガードレールを目的としています。 + アクセス権限の境界を使用して、より安全な方法で IAM 管理を委任します。 + 委任された管理者が、作成したロールとユーザーに適切な IAM 境界ポリシーをアタッチしていることを確認します。 + 詳細な防御アプローチとして (アイデンティティベースのポリシーと組み合わせて)、リソースベースの IAM ポリシーを使用して、リソースへの広範なアクセスを拒否します。 + IAM アクセスアドバイザー、 AWS CloudTrail、IAM Access Analyzer、および関連するツールを使用して、付与された使用状況とアクセス許可の履歴を定期的に分析します。明らかなオーバーパーミッションをすぐに修正します。 + アスタリスクをワイルドカードとして使用し、すべてのリソースを示す代わりに、幅広いアクションを特定のリソースに適用します。 + リクエストに基づいて IAM ポリシーの例外を迅速に識別、確認、承認するメカニズムを実装します。