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

AWS Organizations は、AWS リソースの成長や拡張に伴い、環境の一元管理およびガバナンスを支援します。AWS Organizations を使用すると、プログラムで新しい AWS アカウントを作成し、リソースを割り当て、アカウントをグループ化してワークロードを整理し、ガバナンスのためにアカウントまたはアカウントのグループにポリシーを適用できます。AWS 組織は AWS アカウントを統合し、単一のユニットとして管理できるようにします。1 つの管理アカウントと、ゼロ以上のメンバーアカウントを含みます。ほとんどのワークロードはメンバーアカウントにありますが、管理アカウントまたは特定の AWS サービスの委任管理者として割り当てられたアカウントのいずれかに存在する必要がある、一元管理されたプロセスの一部を除きます。セキュリティチームが AWS 組織に代わってセキュリティニーズを管理するためのツールとアクセスを一元的に提供できます。AWS 組織内で重要なリソースを共有することで、リソースの重複を減らすことができます。アカウントを AWS 組織単位 (OUs) にグループ化できます。OU は、ワークロードの要件と目的に基づいて異なる環境を表すことができます。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 の変更による潜在的な影響を理解する必要があります。

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

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

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

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

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

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