マルチアカウントでのAWS Security Hubの通知について考えてみる

エンタープライズクラウド部の松田です。こんにちは。

今回はマルチアカウント環境での AWS Security Hub の通知についてです。

はじめに
シングルアカウントでの実装方法
マルチアカウントでの実装方法
イベントパターンのサンプル
まとめ
参考記事

はじめに

AWS Security Hub では、AWSアカウント内のリソースの状態（セキュリティリスクのある設定をしてしまっていないか、ベストプラクティスに則っているか、など）をチェックすることができます。

AWS CloudTrail や AWS Config と並んで、とりあえず有効化しておきたいサービスとしてよく名前が上がりますが、ロギングを目的としたサービスではないため、ある程度運用込みで考えなければ、活用できずに利用料だけが積もっていくような事態になりかねません。

今回はそんな Security Hub を活用する第一歩として、通知の実装について考えてみたいと思います。

なお、本記事で記載する実装はあくまで一例である点はご留意ください。

シングルアカウントでの実装方法

主題はマルチアカウント環境での通知ですが、まずはシングルアカウントでの実装から説明したいと思います。

シングルアカウントでの実装は、以下の様になります。

まず前提として、Security Hubは全てのリージョンで有効化されていることとしています。またリージョン集約機能も利用している前提としています。
※利用予定のないリージョンでも、オペミスや不正アクセスを考慮し有効化するケースが多いです。

またセキュリティ系のサービスとして Amazon GuardDuty や Amazon Insepctor 、AWS Config （Config rules）を使用しており、それらが Security Hub に統合されていることを想定しています。
※参考：Security Hub と統合可能な AWS サービスの一覧

通知には Amazon SNS を使用しています。Security Hub で発生したイベントを Amazon EventBridge ルールが検知し、イベントを SNS トピックに渡すことでメールを送信するような仕組みになっています。

ちなみに EventBridgeルールには以下のようなイベントパターンを設定することで、Security Hub のイベント発生を検知することができます。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Compliance": {
        "Status": [{
          "anything-but": "PASSED"
        }]
      }
    }
  }
}

ここで押さえておきたいポイントは以下の通りです。

EventBridge ルール（SNS トピックも）は Security Hub の集約リージョンに作ればよい。
他リージョンのイベントも、集約リージョンの Security Hub イベントとして処理できる。
GuardDuty などの統合サービスのイベントも、集約リージョンの Security Hub イベントとして処理できる。

マルチアカウントでの実装方法

ではマルチアカウントだとどうなるのかを説明します。

Security Hubのアカウント集約機能を利用することで、異なるアカウントで発生した検出を、集約先アカウントのイベントとして処理できるようになります。アカウント集約機能は AWS Organizations を介して利用すると、組織内のアカウントを簡単に集約できます。

また集約元アカウントで Security Hub に GuardDuty などを統合していた場合、統合サービスのイベントも集約してくれます。マルチリージョンにも対応しています。

まとめると、以下のように言えます。

EventBridge ルール（SNS トピックも）は、Security Hub 集約アカウントの集約リージョンに作ればよい。
- アカウントごとに作る必要はない。
他リージョンのイベントも処理できる。
統合サービスのイベントも処理できる。
アカウント集約には AWS Organizations を使うのが簡単。

イベントパターンのサンプル

紹介した実装で、複数アカウントの Security Hub 検出を通知することができるようになりました。ですが、例えば先に紹介したようなイベントパターン（再掲 ↓ ）で実装すると、通知の量がとんでもないことになってしまいます（アカウント数にもよりますが、毎日1,000件近く通知が飛んだりします）。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Compliance": {
        "Status": [{
          "anything-but": "PASSED"
        }]
      }
    }
  }
}

流石にそれでは運用が耐えられないので、まずは通知量を抑制する必要があるかと思います。このための方法は、不要な Security Hub のチェック項目（コントロール）を無効化するか、イベントパターンを調節して不要な検出をフィルタリングするかの2つがあり得ますが、ここでは後者についてのお話です。

なお「不要な」の基準はケースバイケースなので一概には言えませんが、イベントパターンの実装例を以下に挙げてみます。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Compliance": {
        "Status": [{
          "anything-but": "PASSED"
        }]
      },
      "ProductName": ["Security Hub", "Inspector"],
      "Severity": {
        "Label": ["CRITICAL", "HIGH"]
      },
      "Workflow": {
        "Status": ["NEW"]
      },
      "RecordState": ["ACTIVE"]
    }
  }
}

上記の実装では、EventBridge が検知する条件に、「特定の重要度レベルかどうか（ Severity ）」と「特定のサービスかどうか（ ProductName ）」を追加しています。追加した条件に対して、一例にはなりますがケーススタディ的に「なぜ（Why）」を記載しておきます。

まず「特定の重要度レベルかどうか（ Severity ）」ですが、例えば重要度が LOW の検出をわざわざ通知する必要があるかというと、「そこまでしなくてもよい」という感覚を持たれる方が多いのではないでしょうか。通知する基準をどこに設けるかは企業のポリシーや担当者の考え方に依りますが、今回は「緊急性の高いものだけを通知の対象にする」と定め、HIGH と CRITICAL だけを通知することにしました。

ちなみに、 Security Hub における Severity 属性は以下の様に定められていますのでご参考まで。

INFORMATIONAL - No issue was found.

LOW - The issue does not require action on its own.

MEDIUM - The issue must be addressed but not urgently.

HIGH - The issue must be addressed as a priority.

CRITICAL - The issue must be remediated immediately to avoid it escalating.

次に「特定のサービスかどうか（ ProductName ）」ですが、サンプルでは Security Hub と Inspector で発生した検出だけを通知する設定としています。これは、検出の特性に応じて対応者が異なるようなケースを想定しています。例えばですが、Security Hub と Inspector はリスクを孕む実装の検出という意味で（レイヤーは異なりますが）同質ですが、不審なアクティビティを検出する GuardDuty は少し毛色が違います。

こういった検出の特性に応じて対応部署や担当者が異なるようなケースでは、サンプルの様な実装にすることで、対応する必要のない検出が通知されないようにできます。

これは余談ですが、Security Hub によるリソースのチェックは定期的に再実行されます（参考）。この仕様により、昨日飛んできた通知が今日も明日も飛んでくる...という事態になりがちです。サンプルのイベントパターンでは、Workflow -> Status を NEW に限定してフィルタしているため、一度通知された検出は NOTIFIED に変更するなどすれば、連日同じ通知が飛ばないようになります。ステータスの変更は Step Functions ステートマシンで可能なので、EventBridge ルールに追加のターゲットとしてステートマシンを関連付けるなどすれば自動化もできます。