Security Hub ポリシーの挙動を確認してみた

こんにちは、アノテーション カスタマーサクセス部 運用支援チームの kaz です！

はじめに

下記のブログで組織の AWS Security Hub Advanced 構成手順を紹介しましたが、その際 Security Hub ポリシーの設定についてはあまり詳しく触れていませんでした。

https://dev.classmethod.jp/articles/enabling-aws-security-hub-advanced-in-organizations/

そこで、今回は Security Hub ポリシーの設定時に想定されるケースをいくつか挙げて、挙動を確認していきたいと思います。

Security Hub ポリシーを使用すると、AWS Organizations 内のアカウントに対してセキュリティ設定を一元的に管理でき、特徴と利点は以下の通りです。

Security Hub ポリシーは、 AWS 組織全体のセキュリティ設定を管理および適用するのに役立つ包括的な機能セットを提供します。
これらの機能は、マルチアカウント環境を一貫して制御しながら、セキュリティ管理を合理化します。

• 組織内のアカウントとリージョン全体で Security Hub を一元的に有効にする
• アカウントと OUs
• 新しいアカウントが組織に参加するときに、セキュリティ設定を自動的に適用する
• 組織全体で一貫したセキュリティ設定を確保する
• メンバーアカウントが組織レベルのセキュリティ設定を変更できないようにする

Security Hub ポリシー - AWS Organizations より抜粋

前提条件

• 組織で Security Hub Advanced が有効化されていること

また、Security Hub ポリシーは SCP (Service Control Policies) に近しい概念となっており、以下のような制限があります。

• ルートレベルでアタッチされたポリシーは、すべてのアカウントに適用される
• アカウントは親組織単位からポリシーを継承する
• 1 つのアカウントに複数のポリシーを適用できる
• より具体的なポリシー（よりアカウントに近い階層）が優先される

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_security_hub.html#security-hub-policies-inheritance

検証してみた

いくつかのケースを想定して Security Hub ポリシーの設定を行い、挙動を確認します。

主に検証したいのは Security Hub ポリシーの適用有無によって、メンバーアカウントの Security Hub Advanced の設定がどのように変化するかです。
とくに Security Hub Advanced はスタンドアロンで有効化することもできるため、その辺りの制御を組織としてきちんと行いたいケースを想定します。

あまり多くのことを想定すると検証の複雑さが増すので、今回は以下のケースを想定して検証を行います。

• 検証に使用するのは Verification of AWS Security Hub Advanced という名前のポリシー 1 つのみ
  
• Security Hub ポリシーは Organizations の Root OU にアタッチする
• 対象リージョンは ap-northeast-1 (東京) と us-east-1 (バージニア北部) のみ
• 確認対象のメンバーアカウントの Security Hub Advanced はどちらのリージョンも無効化されている状態

また、ポリシー設計の原則を参考にしながらベストプラクティスに則った設定を行います。

Security Hub ポリシーを作成する前に、ポリシー構造の明確な原則を確立します。
ポリシーはシンプルに保ち、最終的な結果を判断するのが難しい複雑な属性間ルールやネストされたルールは避けてください。
組織のルートレベルで大まかなポリシーから始め、必要に応じて子ポリシーで絞り込みます。

空のリージョンリストを戦略的に使用することを検討してください。
特定のリージョンで Security Hub を無効にする必要がある場合は enable_in_regions を空のままにし、ポリシーによって管理されないリージョンを維持する場合は disable_in_regions を空のままにします。
この柔軟性により、セキュリティモニタリングカバレッジを正確に制御できます。

Security Hub ポリシーを使用するためのベストプラクティス - AWS Organizations より抜粋

ケース 1

東京リージョンのみ Security Hub Advanced を有効化するケースです。

{
  "securityhub": {
    "enable_in_regions": {
      "@@append": [
        "ap-northeast-1"
      ],
      "@@operators_allowed_for_child_policies": [
        "@@all"
      ]
    },
    "disable_in_regions": {
      "@@append": [],
      "@@operators_allowed_for_child_policies": [
        "@@all"
      ]
    }
  }
}

東京リージョン

自動的に Security Hub Advanced が有効化され、このリージョンは「管理対象」のため無効化することはできません。

バージニア北部リージョン

一方、こちらは当然ですが Security Hub Advanced は有効になっていません。

しかし、メンバーアカウントのバージニア北部リージョンは「管理対象」ではないため、スタンドアロンとして自由に有効 / 無効にできます。

ケース 2

ケース 1 でわかったことは、管理対象リージョンは、メンバーアカウントで無効化できず、常に有効な状態が維持されることになります。
では、メンバーアカウントでスタンドアロンとして Security Hub Advanced を有効化させたくない場合はどうすればよいでしょうか。

ケース 2 では、バージニア北部リージョンを Disable の管理対象下にして、スタンドアロンでの有効化を禁止するケースを検証します。

{
  "securityhub": {
    "enable_in_regions": {
      "@@append": [
        "ap-northeast-1"
      ],
      "@@operators_allowed_for_child_policies": [
        "@@all"
      ]
    },
    "disable_in_regions": {
      "@@append": [
        "us-east-1"
      ],
      "@@operators_allowed_for_child_policies": [
        "@@all"
      ]
    }
  }
}

東京リージョン

ケース 1 と同様の状態なので省略します。

バージニア北部リージョン

検証する前にバージニア北部リージョンの Security Hub Advanced はスタンドアロンで有効化されている状態でした。
しかし、ポリシーを適用した後は Security Hub Advanced が無効化されており、スタンドアロンでの有効化が禁止されていることがわかります。

ケース 3

最後のケースとなります。
また、ケース 1 とケース 2 の検証をまとめると以下のようになります。

• 管理対象リージョンはメンバーアカウントで無効化できず、常に有効な状態が維持される
• スタンドアロンでの有効化を禁止するには disable_in_regions に対象リージョンを指定する必要があることです。

では、東京リージョンとバージニア北部リージョンだけ Security Hub Advanced を有効化し、残りのリージョンではスタンドアロンでの有効化を禁止するケースを検証します。

すべてのリージョンで Security Hub Advanced を有効化しないケースでは、基本的にこちらの設定を利用することになると思います。
たとえば、コストを抑える場合や SCP (Service Control Policies) でリージョン制限を行っている場合などが該当するでしょう。

{
  "securityhub": {
    "enable_in_regions": {
      "@@append": [
        "ap-northeast-1",
        "us-east-1"
      ],
      "@@operators_allowed_for_child_policies": [
        "@@all"
      ]
    },
    "disable_in_regions": {
      "@@append": [
        "us-west-1",
        "us-east-2",
        "us-west-2",
        "af-south-1",
        "ap-east-1",
        "ap-southeast-3",
        "ap-south-1",
        "ap-northeast-3",
        "ap-northeast-2",
        "ap-southeast-1",
        "ap-southeast-2",
        "ca-central-1",
        "eu-central-1",
        "eu-west-1",
        "eu-west-2",
        "eu-south-1",
        "eu-west-3",
        "eu-north-1",
        "me-south-1",
        "sa-east-1"
      ],
      "@@operators_allowed_for_child_policies": [
        "@@all"
      ]
    }
  }
}

東京リージョンとバージニア北部リージョン

どちらのリージョンも Security Hub Advanced が有効化されており、管理対象のため無効化することはできません。

また、試しに大阪リージョンを開いてみると、Security Hub Advanced は無効化されており、スタンドアロンでの有効化も禁止されていることがわかります。

まとめ

今回は Security Hub ポリシー設定を検証し、メンバーアカウントの Security Hub Advanced の有効 / 無効に関する挙動を確認しました。

検証ではあまり触れていませんでしたが 有効 と 無効 が競合する場合は、IAM ポリシーなどと同様に 無効 が優先されますので注意が必要です。
また、Security Hub ポリシーは複雑にならないようにシンプルに保つことを心がけましょう。
詳細な構文については以下のドキュメントを参照してください。

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_security_hub_syntax.html

スタンドアロンで有効化されていると管理上、不都合となるケースもあると思いますので本記事が参考になれば幸いです。

アノテーション株式会社について

アノテーション株式会社 は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。
「らしく働く、らしく生きる」のスローガンを掲げ、さまざまな背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けています。

現在当社では AWS の構築・運用経験があり、以下の業務に携わってくれるメンバーを募集中です。

• AWS 環境の運用設計支援や構築
• 運用監視とインシデント対応
• 定型業務などの自動化

AWS 関連資格をお持ちの方、クラウドネイティブな運用経験者は大歓迎です。
少しでもご興味がありましたら 募集職種 よりご応募ください！！

一緒に働ける日を心待ちにしています！