セキュリティ AWS Organizations のための の使用

AWS Organizations は、 AWS リソースの拡大とスケーリングに合わせて環境を一元管理および管理するのに役立ちます。を使用すると AWS Organizations、プログラムで新しい を作成し AWS アカウント、リソースを割り当て、アカウントをグループ化してワークロードを整理し、ガバナンスのためにアカウントまたはアカウントのグループにポリシーを適用できます。 AWS 組織は を統合し AWS アカウント 、それらを 1 つのユニットとして管理できるようにします。1 つの管理アカウントと、ゼロ以上のメンバーアカウントを含みます。ほとんどのワークロードはメンバーアカウントにあります。ただし、管理アカウントまたは特定の の委任管理者として割り当てられたアカウントのいずれかに存在する必要がある、一元管理されたプロセスを除きます AWS のサービス。セキュリティチームが AWS 組織に代わってセキュリティニーズを管理するためのツールとアクセスを一元的に提供できます。 AWS 組織内で重要なリソースを共有することで、リソースの重複を減らすことができます。アカウントを AWS 組織単位 (OUs は、ワークロードの要件と目的に基づいて異なる環境を表すことができます。 には、組織内のすべてのメンバーアカウントに追加のセキュリティコントロールを一元的に適用できる複数のポリシー AWS Organizations も用意されています。このセクションでは、サービスコントロールポリシー (SCPs)、リソースコントロールポリシー (RCPs)、宣言ポリシーに焦点を当てます。

では AWS Organizations、SCPs と RCPs を使用して、 AWS 組織、OU、またはアカウントレベルでアクセス許可ガードレールを適用できます。SCPsは、管理アカウント (このアカウントでワークロードを実行しない理由の 1 つ) を除き、組織のアカウント内のプリンシパルに適用されるガードレールです。SCP を OU にアタッチすると、SCP はその OUs の子 OU とアカウントによって継承されます。SCP はいかなるアクセス許可も付与しません。代わりに、 AWS 組織、OU、またはアカウントのプリンシパルで使用できる最大アクセス許可を指定します。実際にアクセス許可を付与するには、アイデンティティベースまたはリソースベースのポリシーを AWS アカウント のプリンシパルまたはリソースにアタッチする必要があります。例えば、SCP がすべての Amazon S3 へのアクセスを拒否した場合、SCP の影響を受けるプリンシパルは、IAM ポリシーを通じて明示的にアクセス が許可されていても Amazon S3 にアクセスできません。IAM ポリシーの評価方法、SCPs「ポリシー評価ロジック」を参照してください。

RCPsは、リソースが同じ組織に属しているかどうかに関係なく、組織のアカウント内のリソースに適用されるガードレールです。SCPs と同様に、RCPs管理アカウントのリソースには影響せず、アクセス許可も付与しません。RCP を OU にアタッチすると、RCP は OUs の子 OU とアカウントによって継承されます。RCPsは、組織内のリソースに対して使用可能なアクセス許可の最大数を一元的に制御し、現在 のサブセットをサポートしています AWS のサービス。OUs 用に SCPs を設計する場合は、IAM ポリシーシミュレーターを使用して変更を評価することをお勧めします。また、IAM でサービスの最終アクセス時間データを確認し、 を使用してAWS CloudTrail サービス使用状況を API レベルでログに記録し、SCP の変更による潜在的な影響を理解する必要があります。

SCP と RCP は独立したコントロールです。SCPs または RCPs のみを有効にするか、適用するアクセスコントロールに基づいて両方のポリシータイプを一緒に使用することを選択できます。たとえば、組織のプリンシパルが組織外のリソースにアクセスできないようにするには、SCPs。外部 ID がリソースにアクセスできないように制限または防止する場合は、RCPs を使用してこのコントロールを適用します。RCP と SCP の詳細SCPsSCPs RCPs」を参照してください。 AWS Organizations

AWS Organizations 宣言ポリシーを使用して、組織全体 AWS のサービス の大規模な特定の に必要な設定を一元的に宣言して適用できます。例えば、組織全体の Amazon VPC リソースへのパブリックインターネットアクセスをブロックできます。SCPs や RCPs などの認可ポリシーとは異なり、宣言ポリシーは AWS サービスのコントロールプレーンで適用されます。認可ポリシーは APIs へのアクセスを規制しますが、宣言ポリシーはサービスレベルで直接適用され、永続的なインテントを適用します。これらのポリシー AWS のサービス は、サービスが新機能や APIs を導入した場合でも、 のベースライン設定が常に維持されるようにするのに役立ちます。ベースライン設定は、新しいアカウントが組織に追加された場合や、新しいプリンシパルやリソースが作成された場合でも維持されます。宣言ポリシーは、組織全体、または特定の OUs またはアカウントに適用できます。

すべての AWS アカウント には、デフォルトですべての AWS リソースに対する完全なアクセス許可を持つ単一のルートユーザーがあります。  セキュリティのベストプラクティスとして、ルートユーザーを明示的に必要とするいくつかのタスクを除き、ルートユーザーを使用しないことをお勧めします。複数の AWS アカウント を通じて管理する場合 AWS Organizations、ルートサインインを一元的に無効にし、すべてのメンバーアカウントに代わってルート特権アクションを実行できます。メンバーアカウントのルートアクセスを一元管理した後、ルートユーザーのパスワード、アクセスキー、署名証明書を削除し、メンバーアカウントの多要素認証 (MFA) を非アクティブ化できます。一元管理されたルートアクセスで作成された新しいアカウントには、デフォルトではルートユーザーの認証情報はありません。メンバーアカウントは、ルートユーザーでサインインしたり、ルートユーザーのパスワード復旧を実行したりすることはできません。

AWS Control Tower は、複数のアカウントを設定と管理を簡素化する方法を提供します。組織内のアカウントのセットアップを自動化し AWS 、プロビジョニングを自動化し、コントロール (予防コントロールと検出コントロールを含む) を適用し、可視性のためのダッシュボードを提供します。追加の IAM 管理ポリシーである アクセス許可の境界 は、特定の IAM プリンシパル (ユーザーまたはロール) にアタッチされ、アイデンティティベースのポリシーが IAM プリンシパルに付与できるアクセス許可の上限を設定します。

AWS Organizations は、すべてのアカウントAWS のサービスに適用される を設定するのに役立ちます。例えば、CloudTrail を使用して AWS 組織全体で実行されるすべてのアクションの中央ログ記録を設定し、メンバーアカウントによるログ記録の無効化を防ぐことができます。 CloudTrail また、 を使用して定義したルールのデータを一元的に集約できるためAWS Config、ワークロードのコンプライアンスを監査し、変更に迅速に対応できます。AWS CloudFormation StackSets を使用して、 AWS 組織内のアカウントと OUs 間で CloudFormation スタックを一元管理できるため、セキュリティ要件を満たすために新しいアカウントを自動的にプロビジョニングできます。

のデフォルト設定では、拒否リストとしての SCPs の使用 AWS Organizations がサポートされています。拒否リスト戦略を使用することで、メンバーアカウント管理者は、特定のサービスや一連のアクションを拒否する SCP を作成してアタッチするまで、すべてのサービスとアクションを委譲できます。拒否ステートメントは、 が新しいサービス AWS を追加するときに更新する必要がないため、許可リストよりもメンテナンスが少なくて済みます。拒否ステートメントは通常、文字長が短いため、SCPs の最大サイズ内に留まりやすくなります。Effect 要素に Deny の値があるステートメントでは、特定のリソースへのアクセスを制限したり、SCP 有効時における条件を定義することもできます。対照的に、SCP の Allow ステートメントは、すべてのリソース ("*") に適用され、条件による制限を受けることができません。詳細と例については、 AWS Organizations ドキュメントのSCPs」を参照してください。