Security Hub での設定ポリシーの仕組み - AWS Security Hub
ポリシーに関する考慮事項設定ポリシーのタイプアプリケーションと継承によるポリシーの関連付け設定ポリシーのテスト

Security Hub での設定ポリシーの仕組み

委任 AWS Security Hub 管理者アカウントは、組織の Security Hub、セキュリティ標準、およびセキュリティコントロールを設定するための設定ポリシーを作成できます。設定ポリシーを作成した後に、委任管理者はそれを特定のアカウント、組織単位 (OU)、またはルートに関連付けることができます。その後、ポリシーは、指定されたアカウント、OU またはルートで有効になります。

中央設定の利点とその仕組みについては、「Security Hub の中央設定について」を参照してください。

このセクションでは、設定ポリシーの詳細な概要を示します。

ポリシーに関する考慮事項

Security Hub で設定ポリシーを作成する前に、次の点について考えます。

  • 設定ポリシーを有効にするには関連付ける必要がある — 設定ポリシーを作成した後に、1 つ以上のアカウント、組織単位 (OU)、またはルートに関連付けることができます。設定ポリシーは、直接適用するか、親 OU からの継承によってアカウントまたは OU に関連付けることができます。

  • アカウントまたは OU は 1 つの設定ポリシーにのみ関連付けることができる — 設定の競合を防ぐため、アカウントまたは OU は常に 1 つの設定ポリシーにのみ関連付けることができます。または、アカウントまたは OU をセルフマネージドすることもできます。

  • 設定ポリシーが完全である — 設定ポリシーには設定の完全な仕様が記載されています。例えば、子アカウントでは、あるポリシーの一部のコントロールの設定と、別のポリシーのその他のコントロールの設定を受け入れることはできません。ポリシーを子アカウントに関連付けるときは、その子アカウントで使用したい設定のすべてがポリシーで指定されていることを確認します。

  • 設定ポリシーを元に戻すことはできない – アカウントまたは OU に関連付けると、設定ポリシーを元に戻すオプションはありません。例えば、CloudWatch コントロールを無効にする設定ポリシーを特定のアカウントに関連付けると、そのポリシーの関連付けを解除しても、そのアカウントでは CloudWatch コントロールは引き続き無効になります。CloudWatch コントロールを再度有効にするには、コントロールを有効にする新しいポリシーをアカウントに関連付けることができます。または、アカウントをセルフマネージドに変更し、アカウント内の各 CloudWatch コントロールを有効にすることもできます。

  • 設定ポリシーが、ホームリージョンとリンクされているすべてのリージョンで有効になっている — 設定ポリシーは、ホームリージョンとリンクされているすべてのリージョンの関連付けられているアカウントのすべてに影響します。これらのリージョンの一部でのみ有効で、他のリージョンでは有効にならない設定ポリシーを作成することはできません。ただし、グローバルリソースが使用するコントロールは例外です。Security Hub は、ホームリージョンを除くすべてのリージョンでグローバルリソースが含まれる定期的なコントロールを自動的に無効にします。

    AWS で 2019 年 3 月 20 日以降に導入されたリージョンは、オプトインリージョンと呼ばれます。設定ポリシーを有効にする前に、アカウントでこのようなリージョンを有効にする必要があります。Organizations 管理アカウントでは、メンバーアカウントのオプトインリージョンを有効にできます。オプトインリージョンを有効にする手順については、「AWS アカウント管理リファレンスガイド」の「アカウントで使用できる AWS リージョンを指定する」を参照してください。

    ポリシーでホームリージョンまたは 1 つ以上のリンクされたリージョンでは使用できないコントロールが設定されている場合、Security Hub は使用できないリージョンのコントロール設定をスキップし、コントロールが利用可能なリージョンの設定を適用します。ホームリージョンまたはリンクされたリージョンのいずれかで利用できないコントロールがカバーされなくなります。

  • 設定ポリシーがリソースである — リソースとして、設定ポリシーには、Amazon リソースネーム (ARN) と一意識別子 (UUID) があります。ARN は次の形式を使用します: arn:partition:securityhub:region:delegated administrator account ID:configuration-policy/configuration policy UUID。セルフマネージド設定には ARN または UUID はありません。セルフマネージド設定の識別子は、SELF_MANAGED_SECURITY_HUB です。

設定ポリシーのタイプ

各設定ポリシーでは、次の設定を指定します。

  • Security Hub を有効または無効にします。

  • 1 つ以上のセキュリティ標準を有効にします。

  • 有効な標準でどのセキュリティコントロールが有効になっているかを示します。そのためには、有効にすべき特定のコントロールのリストを指定します。Security Hub は、リリース時に新しいコントロールを含め、他のすべてのコントロールを無効にします。または、無効にすべき特定のコントロールのリストを指定して、Security Hub がリリースされた時点の新しいコントロールを含め、他のすべてのコントロールを有効化することもできます。

  • オプションで、有効な標準全体で有効になっているコントロールを選択してパラメータをカスタマイズできます。

中央設定ポリシーには AWS Config レコーダー設定は含まれません。Security Hub がコントロールの検出結果のほとんどを生成するには、AWS Config を有効にして、必要なリソースに個別に記録する必要があります。詳細については、「Security Hub の AWS Config の設定」を参照してください。

中央設定を使用する場合、Security Hub は、ホームリージョンを除くすべてのリージョンでグローバルリソースが含まれるコントロールを自動的に無効にします。設定ポリシーを通じて有効を選択したその他のコントロールは、利用可能なすべてのリージョンで有効になります。これらのコントロールの検出結果を 1 つのリージョンのみに限定するには、AWS Config レコーダーの設定を更新し、ホームリージョンを除くすべてのリージョンでグローバルリソースの記録をオフにします。中央設定を使用する場合、ホームリージョンまたはリンクされたリージョンのいずれかで利用できないコントロールがカバーされなくなります。グローバルリソースを含むコントロールのリストについては、「グローバルリソースを使用するコントロール」を参照してください。

Security Hub コンソールで初めて設定ポリシーを作成する場合、Security Hub の推奨されるポリシーを選択するオプションもあります。

推奨されるポリシーにより、AWS 基礎セキュリティのベストプラクティス (FSBP) 標準である Security Hub、および既存および新規すべての FSBP コントロールが有効になります。パラメータを受け入れるコントロールは、デフォルト値を使用します。推奨されるポリシーはルート (新規および既存のすべてのアカウントと OU) に適用されます。組織用の推奨されるポリシーを作成した後に、委任管理者アカウントから変更できます。例えば、追加の標準やコントロールを有効にしたり、特定の FSBP コントロールを無効にしたりできます。設定ポリシーを変更する手順については、「設定ポリシーの更新」を参照してください。

カスタム設定ポリシー

委任管理者は、推奨されるポリシーの代わりに最大 20 件のカスタム設定ポリシーを作成できます。1 つのカスタムポリシーを組織全体に関連付けることも、別のカスタムポリシーをさまざまなアカウントや OU に関連付けることもできます。カスタム設定ポリシーの場合は、必要な設定を指定します。例えば、FSBP、Center for Internet Security (CIS) AWS Foundations Benchmark v1.4.0、および Amazon Redshift のコントロールを除くこれらの標準のすべてのコントロールを有効にするカスタムポリシーを作成できます。カスタム設定ポリシーで使用する細分性のレベルは、組織全体で想定された範囲のセキュリティカバレッジによって異なります。

注記

Security Hub を無効にする設定ポリシーを、委任管理者アカウントに関連付けることはできません。このようなポリシーは他のアカウントと関連付けることはできますが、委任管理者との関連付けはスキップされます。委任管理者アカウントは現在の設定を保持します。

カスタム設定ポリシーを作成した後に、推奨される設定を反映するように設定ポリシーを更新することで、推奨される設定ポリシーに切り替えることができます。ただし、最初のポリシーを作成した後は、Security Hub コンソールに推奨される設定ポリシーを作成する選択肢は表示されません。

アプリケーションと継承によるポリシーの関連付け

最初に中央設定にオプトインした時点では、組織は関連付けられておらず、オプトイン前と同じように動作します。その後、委任管理者は設定ポリシーまたはセルフマネージド型の動作とアカウント、OU、またはルートとの関連付けを確立できます。関連付けは、アプリケーションまたは継承によって確立できます。

委任管理者アカウントから、設定ポリシーをアカウント、OU、またはルートに直接適用できます。または、委任管理者がアカウント、OU、またはルートをセルフマネージド型指定を直接適用することもできます。

ダイレクトアプリケーションが適用されない場合、アカウントまたは OU は、設定ポリシーまたはセルフマネージド型の動作を持つ最も近い親の設定を継承します。最も近い親が設定ポリシーに関連付けられている場合、子はそのポリシーを継承し、設定できるのはホームリージョンの委任管理者のみです。最も近い親がセルフマネージド型の場合、子はセルフマネージド型の動作を継承し、それぞれの AWS リージョンに独自の設定を指定できます。

適用は継承よりも優先されます。つまり、委任管理者がアカウントまたは OU に直接適用した設定ポリシーまたはセルフマネージド型指定を継承によって上書きされることはありません。

設定ポリシーをセルフマネージドアカウントに直接適用すると、ポリシーはセルフマネージド指定を上書きします。アカウントは一元管理され、設定ポリシーに反映された設定を採用します。

設定ポリシーをルートに直接適用することをお勧めします。ルートにポリシーを適用すると、組織に参加する新しいアカウントは、別のポリシーに関連付けたり、セルフマネージド型として指定したりしない限り、自動的にルートポリシーを継承します。

アプリケーションまたは継承によって、一度に 1 つのアカウントまたは OU に関連付けることができる設定ポリシーは 1 つだけです。これは設定の競合を防ぐためのものです。

次の図は、中央設定におけるポリシーの適用と継承の仕組みを示しています。

Security Hub 設定ポリシーの適用と継承

この例では、緑色で強調表示されているノードには設定ポリシーが適用されています。青色で強調表示されているノードには、設定ポリシーが適用されていません。黄色で強調表示されているノードは、セルフマネージド型として指定されています。各アカウントと OU は以下の設定を使用します。

  • OU:Root (緑) — この OU は、適用されている設定ポリシーを使用します。

  • OU:Prod (青) — この OU は OU:Root から設定ポリシーを継承します。

  • OU:Applications (緑) — この OU は、適用されている設定ポリシーを使用します。

  • Account 1 (緑) — このアカウントは、適用されている設定ポリシーを使用します。

  • Account 2 (青) — このアカウントは OU:Applications の設定ポリシーを継承します。

  • OU:Dev (黄) — この OU はセルフマネージド型です。

  • Account 3 (緑) — このアカウントは、適用されている設定ポリシーを使用します。

  • Account 4 (青) — このアカウントは OU:Dev のセルフマネージド型の動作を継承します。

  • OU:Test (青) — このアカウントは OU:Root の設定ポリシーを継承します。

  • Account 5 (青) — このアカウントは OU:Root の設定ポリシーを継承します。これは、その直接の親である OU:Test には設定ポリシーが関連付けられていないためです。

設定ポリシーのテスト

設定ポリシーの仕組みを確実に理解するには、1 つのポリシーを作成し、テストアカウントまたは OU に関連付けることをお勧めします。

設定ポリシーをテストするには

  1. カスタム設定ポリシーを作成します。Security Hub の有効化、標準、およびコントロールに指定されている設定が正しいことを確認します。

  2. 子アカウントや OU を持たないテストアカウントまたは OU に設定ポリシーを適用します。

  3. テストアカウントまたは OU が、ホームリージョンとリンクされているすべてのリージョンで設定ポリシーを想定どおりに使用していることを確認します。また、組織内の他のすべてのアカウントと OU が引き続きセルフマネージドされ、各地域で独自の設定を変更できることを確認できます。

1 つのアカウントまたは OU で設定ポリシーをテストした後に、その設定ポリシーを他のアカウントや OU に関連付けることができます。