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

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

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

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

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

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

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

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

  • 設定ポリシーを有効にするには、設定ポリシーを関連付ける必要があります。設定ポリシーを作成したら、1 つ以上のアカウント、組織単位 (OUs）、またはルートに関連付けることができます。設定ポリシーは、アカウント、OUs直接アプリケーション、または親 OU からの継承を通じて関連付けることができます。

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

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

  • 設定ポリシーを元に戻すことができない – アカウントまたは に関連付けた後、設定ポリシーを元に戻すオプションはありませんOUs。例えば、 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 レコーダーの設定。個別に を有効にする必要があります AWS Config と は、Security Hub がコントロールの検出結果を生成するために必要なリソースの記録を有効にします。詳細については、「設定 AWS Config Security Hub 用の」を参照してください。

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

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

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

カスタム設定ポリシー

委任管理者は、推奨されるポリシーの代わりに最大 20 件のカスタム設定ポリシーを作成できます。1 つのカスタムポリシーを組織全体に関連付けることも、異なるカスタムポリシーを異なるアカウントと に関連付けることもできますOUs。カスタム設定ポリシーの場合は、必要な設定を指定します。例えば、インターネットセキュリティセンター (CIS) である FSBPを有効にするカスタムポリシーを作成できます。 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 に設定ポリシーを適用しますOUs。

  3. テストアカウントまたは OU が、ホームリージョンとリンクされているすべてのリージョンで設定ポリシーを想定どおりに使用していることを確認します。また、組織OUs内の他のすべてのアカウントと が自己管理されたままであり、各リージョンで独自の設定を変更できることを検証することもできます。

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