組織管理アカウント - AWS 規範ガイダンス

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

組織管理アカウント

簡単な調査を行い、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えます。

次の図は、組織管理アカウントで設定されている AWS セキュリティサービスを示しています。

組織管理アカウントのセキュリティサービス

このガイドの前半のAWS Organizations を使用したセキュリティ」セクションと「管理アカウント」、「信頼されたアクセス」、および「委任された管理者」セクションでは、組織管理アカウントの目的とセキュリティ目標について詳しく説明しました。組織管理アカウントのセキュリティのベストプラクティスに従います。これには、ビジネスによって管理される E メールアドレスの使用、適切な管理およびセキュリティ連絡先情報の維持 (AWS がアカウントの所有者に連絡する必要がある場合にアカウントに電話番号をアタッチするなど)、すべてのユーザーの多要素認証 (MFA) の有効化、組織管理アカウントにアクセスできるユーザーを定期的に確認することが含まれます。組織管理アカウントにデプロイされたサービスは、適切なロール、信頼ポリシー、およびその他のアクセス許可で構成して、それらのサービスの管理者 (組織管理アカウントでサービスにアクセスする必要があるユーザー) が他のサービスにも不適切にアクセスできないようにします。

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

AWS Organizations を使用すると、複数の AWS アカウント間でポリシーを一元管理できます。たとえば、組織のメンバーである複数の AWS アカウントにサービスコントロールポリシー (SCPs) を適用できます。SCPs を使用すると、組織のメンバー AWS アカウントで AWS Identity and Access Management (IAM) エンティティ (IAM ユーザーやロールなど) が実行できる AWS サービス APIs と実行できない AWS サービス API を定義できます。SCPsは、組織の作成時に使用した AWS アカウントである組織管理アカウントから作成および適用されます。SCPs の詳細については、このリファレンスの前半のAWS Organizations を使用したセキュリティ」セクションを参照してください。 

AWS Control Tower を使用して AWS 組織を管理する場合、一連の SCPs を予防ガードレールとしてデプロイします (必須、強く推奨、または選択的に分類)。これらのガードレールは、組織全体のセキュリティコントロールを適用することで、リソースを管理するのに役立ちます。これらの SCPs、 の値が Managed-by-control-tower である aws-control-tower タグを自動的に使用します。 managed-by-control-tower 

設計上の考慮事項
  • SCPsAWS 組織のメンバーアカウントのみに影響します。これらは組織管理アカウントから適用されますが、そのアカウントのユーザーまたはロールには影響しません。SCP 評価ロジックの仕組みと推奨される構造の例については、AWS ブログ記事「AWS AWS Organizations でサービスコントロールポリシーを使用する方法」を参照してください。

リソースコントロールポリシー

リソースコントロールポリシー (RCPsは、組織内のリソースに対して使用可能なアクセス許可の最大数を一元的に制御します。RCP は、アクセス許可ガードレールを定義するか、アイデンティティが組織内のリソースに対して実行できるアクションに制限を設定します。RCPs を使用して、リソースにアクセスできるユーザーを制限し、組織のメンバー AWS アカウントでリソースにアクセスする方法に関する要件を適用できます。RCPs、個々のアカウント、OUs、または組織のルートに直接アタッチできます。RCPs「RCP 評価AWS Organizations 」を参照してください。RCPs の詳細については、このリファレンスの前半のAWS Organizations を使用したセキュリティ」セクションを参照してください。

AWS Control Tower を使用して AWS 組織を管理する場合、一連の RCPs を予防ガードレールとしてデプロイします (必須、強く推奨、または選択的に分類)。これらのガードレールは、組織全体のセキュリティコントロールを適用することで、リソースを管理するのに役立ちます。これらの SCPs、 の値を持つaws-control-towerタグを自動的に使用しますmanaged-by-control-tower

設計上の考慮事項
  • RCPs、組織のメンバーアカウント内のリソースにのみ影響します。管理アカウントのリソースには影響しません。つまり、委任管理者として指定されたメンバーアカウントにも RCPs が適用されます。

  • RCPs、AWS サービスのサブセットのリソースに適用されます。詳細については、AWS Organizations ドキュメントのRCPs をサポートする AWS サービスのリスト」を参照してください。 AWS Organizations AWS Config Rules および AWS Lambda 関数を使用して、RCPs で現在サポートされていないリソースに対するセキュリティコントロールの適用をモニタリングおよび自動化できます。

宣言ポリシー

宣言ポリシーは、AWS Organizations 管理ポリシーの一種であり、組織全体の大規模な特定の AWS サービスに必要な設定を一元的に宣言して適用するのに役立ちます。宣言ポリシーは現在、Amazon Elastic Compute Cloud (Amazon EC2)Amazon Virtual Private Cloud (Amazon VPC)、Amazon Elastic Block Store (Amazon EBS) サービスをサポートしています。使用可能なサービス属性には、インスタンスメタデータサービスバージョン 2 (IMDSv2) の強制、EC2 シリアルコンソールを使用したトラブルシューティング、Amazon マシンイメージ (AMI) の設定、Amazon EBS スナップショット、Amazon EC2 AMIs、Amazon VPC リソースへのパブリックアクセスのブロックなどがあります。サポートされている最新のサービスと属性については、AWS Organizations ドキュメントの「宣言ポリシー」を参照してください。

AWS Organizations および AWS Control Tower コンソールでいくつかの選択を行うか、いくつかの AWS コマンドラインインターフェイス (AWS CLI) および AWS SDK コマンドを使用することで、AWS サービスのベースライン設定を適用できます。宣言型ポリシーはサービスのコントロールプレーンで適用されます。つまり、サービスが新機能や APIs を導入した場合でも、新しいアカウントが組織に追加された場合や、新しいプリンシパルやリソースが作成された場合でも、AWS サービスのベースライン設定が常に維持されます。宣言ポリシーは、組織全体、または特定の OUs またはアカウントに適用できます。有効なポリシーは、組織ルートと OUs から継承される一連のルールと、アカウントに直接アタッチされるポリシーです。宣言ポリシーがデタッチされると、属性の状態は宣言ポリシーがアタッチされる前にその状態に戻ります。

宣言ポリシーを使用して、カスタムエラーメッセージを作成できます。たとえば、宣言ポリシーが原因で API オペレーションが失敗した場合、エラーメッセージを設定したり、内部 Wiki へのリンクや失敗を説明するメッセージへのリンクなどのカスタム URL を提供したりできます。これにより、ユーザー自身が問題をトラブルシューティングできるように、ユーザーに詳細情報が提供されます。AWS CloudTrail を使用して、宣言ポリシーの作成、宣言ポリシーの更新、宣言ポリシーの削除のプロセスを監査することもできます。

宣言ポリシーはアカウントステータスレポートを提供します。これにより、対象範囲内のアカウントの宣言ポリシーでサポートされているすべての属性の現在のステータスを確認できます。レポートスコープに含めるアカウントと OUs を選択するか、ルートを選択して組織全体を選択できます。このレポートは、AWS リージョンごとに内訳を提供し、属性の現在の状態がアカウント間で一様であるか ( 値を使用numberOfMatchedAccounts)、アカウント間で不整合であるか ( 値を使用numberOfUnmatchedAccounts) を指定することで、準備状況を評価するのに役立ちます。

設計上の考慮事項
  • 宣言ポリシーを使用してサービス属性を設定すると、ポリシーが複数の APIs に影響を与える可能性があります。非準拠のアクションは失敗します。アカウント管理者は、個々のアカウントレベルでサービス属性の値を変更することはできません。

一元化されたルートアクセス

AWS Organizations のすべてのメンバーアカウントには独自のルートユーザーがあります。これは、そのメンバーアカウントのすべての AWS サービスとリソースへの完全なアクセス権を持つ ID です。IAM は、すべてのメンバーアカウントのルートアクセスを管理するための一元的なルートアクセス管理を提供します。これにより、メンバールートユーザーの使用が防止され、大規模な復旧が可能になります。一元化されたルートアクセス機能には、ルート認証情報管理とルートセッションの 2 つの重要な機能があります。

  • ルート認証情報管理機能は、一元管理を可能にし、すべての管理アカウントでルートユーザーを保護するのに役立ちます。この機能には、長期的なルート認証情報の削除、メンバーアカウントによるルート認証情報の復旧の防止、デフォルトでルート認証情報を使用しない新しいメンバーアカウントのプロビジョニングが含まれます。また、コンプライアンスを示す簡単な方法も提供します。ルートユーザー管理が一元化されている場合、ルートユーザーのパスワード、アクセスキー、署名証明書を削除し、すべてのメンバーアカウントから多要素認証 (MFA) を非アクティブ化できます。

  • ルートセッション機能を使用すると、組織管理アカウントまたは委任管理者アカウントのメンバーアカウントで短期認証情報を使用して、特権ルートユーザーアクションを実行できます。この機能は、最小特権の原則に従って、特定のアクションを対象とする短期ルートアクセスを有効にするのに役立ちます。

一元化されたルート認証情報管理では、組織管理アカウントまたは委任管理者アカウントから、組織レベルでルート認証情報管理とルートセッション機能を有効にする必要があります。AWS SRA のベストプラクティスに従って、この機能を Security Tooling アカウントに委任します。一元化されたルートユーザーアクセスの設定と使用の詳細については、AWS セキュリティブログ記事AWS Organizations を使用するお客様のルートアクセスを一元管理する」を参照してください。

IAM アイデンティティセンター

AWS IAM Identity Center (AWS Single Sign-On の後継) は、すべての AWS アカウント、プリンシパル、クラウドワークロードへの SSO アクセスを一元管理するのに役立つ ID フェデレーションサービスです。IAM Identity Center は、一般的に使用されるサードパーティーの Software as a Service (SaaS) アプリケーションへのアクセスとアクセス許可の管理にも役立ちます。ID プロバイダーは、SAML 2.0 を使用して IAM アイデンティティセンターと統合します。一括プロビジョニングとjust-in-timeプロビジョニングは、クロスドメインアイデンティティ管理システム (SCIM) を使用して実行できます。IAM Identity Center は、AWS Directory Service を使用して、ID プロバイダーとしてオンプレミスまたは AWS が管理する Microsoft Active Directory (AD) ドメインと統合することもできます。IAM Identity Center には、エンドユーザーが割り当てられた AWS アカウント、ロール、クラウドアプリケーション、カスタムアプリケーションを 1 か所で検索してアクセスできるユーザーポータルが含まれています。

IAM Identity Center は AWS Organizations とネイティブに統合され、デフォルトで組織管理アカウントで実行されます。ただし、最小特権を行使し、管理アカウントへのアクセスを厳密に制御するために、IAM アイデンティティセンターの管理を特定のメンバーアカウントに委任できます。AWS SRA では、共有サービスアカウントは IAM Identity Center の委任管理者アカウントです。IAM Identity Center の委任管理を有効にする前に、以下の考慮事項を確認してください。委任の詳細については、「共有サービスアカウント」セクションを参照してください。委任を有効にした後でも、IAM Identity Center は組織管理アカウントで実行して、組織管理アカウントでプロビジョニングされたアクセス許可セットの管理など、特定の IAM Identity Center 関連タスクを実行する必要があります。 

IAM Identity Center コンソール内では、アカウントはカプセル化 OU によって表示されます。これにより、AWS アカウントをすばやく検出し、一般的なアクセス許可のセットを適用し、一元的な場所からのアクセスを管理できます。 

IAM Identity Center には、特定のユーザー情報を保存する必要がある ID ストアが含まれています。ただし、IAM Identity Center がワークフォース情報の信頼できるソースである必要はありません。エンタープライズにすでに信頼できるソースがある場合、IAM Identity Center は次のタイプの ID プロバイダー (IdPsをサポートしています。

  • IAM Identity Center Identity store – 次の 2 つのオプションが利用できない場合は、このオプションを選択します。ユーザーが作成され、グループの割り当てが行われ、アクセス許可が ID ストアに割り当てられます。信頼できるソースが IAM Identity Center の外部にある場合でも、プリンシパル属性のコピーは ID ストアに保存されます。

  • Microsoft Active Directory (AD) – AWS Directory Service for Microsoft Active Directory のディレクトリまたは Active Directory のセルフマネージドディレクトリのいずれかでユーザーの管理を継続する場合は、このオプションを選択します。

  • 外部 ID プロバイダー – 外部のサードパーティーの SAML ベースの IdP でユーザーを管理する場合は、このオプションを選択します。

エンタープライズ内で既に導入されている既存の IdP を使用できます。これにより、アクセスの作成、管理、および取り消しを 1 箇所で行うことができるため、複数のアプリケーションおよびサービス間のアクセス管理を簡単に行うことができます。例えば、誰かがチームを離れた場合、1 つの場所からすべてのアプリケーションとサービス (AWS アカウントを含む) へのアクセスを取り消すことができます。これにより、複数の認証情報の必要性が減り、人事 (HR) プロセスと統合する機会が得られます。

設計上の考慮事項
  • そのオプションがエンタープライズで利用可能な場合は、外部 IdP を使用します。IdP がクロスドメインアイデンティティ管理 (SCIM) のシステムをサポートしている場合は、IAM アイデンティティセンターの SCIM 機能を活用して、ユーザー、グループ、アクセス許可のプロビジョニング (同期) を自動化します。これにより、AWS アクセスは、新規採用者、別のチームに移行する従業員、および退職する従業員の社内ワークフローと同期し続けることができます。いつでも、1 つのディレクトリまたは 1 つの SAML 2.0 ID プロバイダーのみを IAM アイデンティティセンターに接続できます。ただし、別の ID プロバイダーに切り替えることはできます。

IAM アクセスアドバイザー

IAM アクセスアドバイザーは、AWS アカウントと OUs のサービスの最終アクセス時間情報としてトレーサビリティデータを提供します。この検出制御を使用して、最小特権戦略 に貢献します。IAM エンティティの場合、許可された AWS サービス情報と許可されたアクション情報の 2 種類の最終アクセス情報を表示できます。情報には、試行が行われた日時が含まれます。 

組織管理アカウント内の IAM アクセスを使用すると、AWS 組織内の組織管理アカウント、OU、メンバーアカウント、または IAM ポリシーのサービスの最終アクセス時間データを表示できます。この情報は、管理アカウント内の IAM コンソールで利用でき、AWS コマンドラインインターフェイス (AWS CLI) の IAM アクセスアドバイザー APIs またはプログラムクライアントを使用してプログラムで取得することもできます。この情報は、組織またはアカウント内のどのプリンシパルが最後にサービスにアクセスしようとしたかを示しています。最終アクセスの情報は、実際のサービス利用状況を把握できるため (シナリオ例 を参照)、実際に利用されているサービスのみに IAM アクセス許可を消去することが可能です。

AWS Systems Manager

AWS Systems Manager の機能である高速セットアップと Explorer はどちらも AWS Organizations をサポートし、組織管理アカウントから動作します。 

クイックセットアップ は、Systems Manager の自動化機能です。これにより、組織管理アカウントは、Systems Manager が AWS 組織内のアカウント間でユーザーに代わってやり取りするための設定を簡単に定義できます。AWS 組織全体で高速セットアップを有効にするか、特定の OUs を選択できます。高速セットアップでは、AWS Systems Manager Agent (SSM Agent) が EC2 インスタンスで隔週更新を実行するようにスケジュールし、それらのインスタンスの毎日のスキャンを設定して、欠落しているパッチを特定できます。 

Explorer は、AWS リソースに関する情報をレポートするカスタマイズ可能なオペレーションダッシュボードです。Explorer は、AWS アカウントおよび AWS リージョン全体のオペレーションデータの集約ビューを表示します。これには、EC2 インスタンスに関するデータやパッチコンプライアンスの詳細が含まれます AWS Organizations 内で統合セットアップ (Systems Manager OpsCenter も含む) を完了したら、OU または AWS 組織全体のデータを Explorer に集約できます。Systems Manager は、Explorer に表示する前に、データを AWS Org Management アカウントに集約します。

このガイドの後半の ワークロード OU のセクションでは、アプリケーションアカウントの EC2 インスタンスでの SSM Agent (Systems Manager Agent) の使用について説明します。

AWS Control Tower

AWS Control Tower では、ランディングゾーンと呼ばれる安全なマルチアカウント AWS 環境を簡単にセットアップして管理できます。AWS Control Tower は、AWS Organizations を使用してランディングゾーンを作成し、継続的なアカウント管理とガバナンス、実装のベストプラクティスを提供します。AWS Control Tower を使用して、アカウントが組織ポリシーに準拠していることを確認しながら、いくつかのステップで新しいアカウントをプロビジョニングできます。既存のアカウントを新しい AWS Control Tower 環境に追加することもできます。 

AWS Control Tower には、広範で柔軟な一連の機能があります。主な機能は、AWS Organizations、AWS AWS Service Catalog、IAM Identity Center など、他のいくつかの AWS サービスの機能をオーケストレーションしてランディングゾーンを構築する機能です。 AWS Organizations 例えば、AWS Control Tower はデフォルトで AWS CloudFormation を使用してベースラインを確立し、AWS Organizations サービスコントロールポリシー (SCPs) を使用して設定変更を防止し、AWS Config ルールを使用して不適合を継続的に検出します。AWS Control Tower は、マルチアカウント AWS 環境を AWS Well Architected セキュリティ基盤設計原則とすばやく一致させるのに役立つ設計図を採用しています。ガバナンス機能の中で、AWS Control Tower には、選択したポリシーに準拠しないリソースのデプロイを防ぐガードレールが用意されています。 

AWS Control Tower を使用して AWS SRA ガイダンスの実装を開始できます。たとえば、AWS Control Tower は、推奨されるマルチアカウントアーキテクチャを使用して AWS 組織を確立します。ID 管理の提供、アカウントへのフェデレーティッドアクセスの提供、ログ記録の一元化、クロスアカウントセキュリティ監査の確立、新しいアカウントのプロビジョニングワークフローの定義、ネットワーク設定によるアカウントベースラインの実装を行うための設計図を提供します。 

AWS SRA では、AWS Control Tower はこのアカウントを使用して AWS 組織を自動的にセットアップし、そのアカウントを管理アカウントとして指定するため、AWS Control Tower は組織管理アカウント内にあります。このアカウントは、AWS 組織全体の請求に使用されます。また、アカウントの Account Factory プロビジョニング、OUs の管理、ガードレールの管理にも使用されます。既存の AWS 組織で AWS Control Tower を起動する場合は、既存の管理アカウントを使用できます。AWS Control Tower は、指定された管理アカウントとしてそのアカウントを使用します。

設計上の考慮事項
  • アカウント全体でコントロールと設定の追加のベースラインを作成する場合は、AWS Control Tower のカスタマイズ (CfCT) を使用できます。CfCT では、AWS CloudFormation テンプレートとサービスコントロールポリシー (SCP) を使用して、AWS Control Tower ランディングゾーンをカスタマイズできます。 SCPs カスタムテンプレートとポリシーは、組織内の個々のアカウントと OUs にデプロイできます。CfCT は AWS Control Tower ライフサイクルイベントと統合して、リソースデプロイがランディングゾーンと同期していることを確認します。 

AWS Artifact

AWS Artifact は、AWS セキュリティおよびコンプライアンスレポートと一部のオンライン契約へのオンデマンドアクセスを提供します。AWS Artifact で利用できるレポートには、System and Organization Controls (SOC) レポート、Payment Card Industry (PCI) レポート、および AWS セキュリティコントロールの実装と運用の有効性を検証する、地理的およびコンプライアンス垂直的な認証機関からの証明書が含まれます。AWS Artifact は、セキュリティコントロール環境の透明性を高めながら、AWS のデューデリジェンスを実行するのに役立ちます。また、新しいレポートにすぐにアクセスして、AWS のセキュリティとコンプライアンスを継続的にモニタリングすることもできます。 

AWS Artifact Agreements を使用すると、個々のアカウントと AWS Organizations の組織の一部であるアカウントの Business Associate Addendum (BAA) などの AWS 契約のステータスを確認、承諾、追跡できます。 

AWS 監査アーティファクトは、AWS セキュリティコントロールの証拠として監査人または規制当局に提供できます。また、AWS 監査アーティファクトの一部が提供する責任ガイダンスを使用して、クラウドアーキテクチャを設計することもできます。このガイダンスは、システムの特定のユースケースをサポートするために導入できる追加のセキュリティコントロールを決定するのに役立ちます。 

AWS Artifacts は組織管理アカウントでホストされ、AWS との契約を確認、受諾、管理できる一元的な場所を提供します。これは、管理アカウントで承諾された契約がメンバーアカウントに流れるためです。 

設計上の考慮事項
  • 組織管理アカウント内のユーザーは、AWS Artifact の契約機能のみを使用するように制限する必要があります。職務の分離を実装するために、AWS Artifact は Security Tooling アカウントでもホストされ、監査アーティファクトにアクセスするためのアクセス許可をコンプライアンス関係者と外部監査人に委任できます。きめ細かな IAM アクセス許可ポリシーを定義することで、この分離を実装できます。例については、AWS ドキュメントの「IAM ポリシーの例」を参照してください。

分散型および一元化されたセキュリティサービスガードレール

AWS SRA、AWS Security Hub CSPM、Amazon GuardDuty、AWS Config、IAM Access Analyzer、AWS CloudTrail 組織の証跡、および多くの場合 Amazon Macie は、適切な委任管理または集約を使用して Security Tooling アカウントにデプロイされます。これにより、アカウント間で一貫したガードレールのセットが可能になり、AWS 組織全体で一元的なモニタリング、管理、ガバナンスが可能になります。このサービスのグループは、AWS SRA で表されるすべてのタイプのアカウントにあります。これらは、アカウントのオンボーディングとベースライン作成プロセスの一環としてプロビジョニングする必要がある AWS のサービスの一部である必要があります。GitHub コードリポジトリは、AWS 組織管理アカウントを含む アカウント全体で AWS セキュリティに焦点を当てたサービスの実装例を提供します。 

これらのサービスに加えて、AWS SRA には、AWS Organizations の統合と委任された管理者機能をサポートする Amazon Detective と AWS Audit Manager の 2 つのセキュリティに焦点を当てたサービスが含まれています。ただし、アカウントベースライン作成の推奨サービスには含まれていません。これらのサービスは、次のシナリオで最適に使用されています。

  • デジタルフォレンジックおよび IT 監査機能を実行する専任のチームまたはリソースグループがある。Amazon Detective はセキュリティアナリストチームが最適に活用でき、AWS Audit Manager は内部監査またはコンプライアンスチームに役立ちます。

  • プロジェクトの開始時に GuardDuty や Security Hub CSPM などのツールのコアセットに重点を置き、追加の機能を提供するサービスを使用してこれらを構築したいと考えています。