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

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

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

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

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

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

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

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

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

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

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

    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 を有効にして、必要なリソースに個別に記録する必要があります。詳細については、「の設定 AWS Config」を参照してください。

中央設定を使用する場合、Security Hub は、ホームリージョンを除くすべてのリージョンでグローバルリソースに関連するコントロールを自動的に無効にします。他のコントロールは、使用可能なすべてのリージョンで有効になります。これらのコントロールの検出結果を 1 つのリージョンのみに限定するには、AWS Config レコーダーの設定を更新し、ホームリージョンを除くすべてのリージョンでグローバルリソースの記録をオフにします。グローバルリソースに関連するコントロールのリストについては、「」を参照してくださいグローバルリソースを処理するコントロール

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

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

カスタム設定ポリシー

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

注記

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

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

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

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

委任管理者アカウントから、設定ポリシーをアカウント、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 に関連付けることができます。ポリシーの作成と関連付けの手順については、「Security Hub 設定ポリシーの作成と関連付け」を参照してください。適用されたアカウントの子アカウントは、セルフマネージド型であるか、別の設定ポリシーが適用されている場合を除き、ポリシーを継承します。また、必要に応じて設定ポリシーを編集したり、追加の設定ポリシーを作成したりすることもできます。