こんにちは、アイレットの日下です。

今回は、画面の基本的な操作よりも、一歩踏み込んで「実際の運用でここを知っているとスムーズだな」と感じた ASFFの構造 や、検証中に少し悩んだオートメーションルールの挙動 について、お話しできればと思います。

0. Security Hubを一言でいうと「セキュリティの司令塔」

AWSには、GuardDuty（脅威検知）やInspector（脆弱性診断）など、便利なセキュリティサービスがたくさんあります。しかし、それぞれがバラバラにアラートを出してくると、運用者は「結局どこを最初に見ればいいの？」と混乱してしまいます。

そこで登場するのが AWS Security Hub です。 このサービスの役割は、主に2つあります。

  1. 情報の集約（司令塔）： あちこちから届くアラートを1ヶ所にまとめ、共通の形式（ASFF）に整えてくれます。
  2. 設定の健康診断（CSPM）： 「S3が丸見えになっていないか？」といった設定ミスを、AWSのベストプラクティスに沿って自動でチェックしてくれます。

今回は、この「司令塔」が情報をどう整理しているのか、実機を見て気づいたポイントを深掘りしていきます。

AWS Security Hub より

1. Security Hub の「共通言語」を知る：ASFFの正体

Security Hubの便利なところは、InspectorやGuardDutyといったバラバラなサービスの情報を、ASFF（AWS Security Finding Format） という共通の形（JSON）にまとめてくれる点にあります。このJSONの中身を覗いてみた際、特に「ここを見ると分かりやすいな」と感じた4つのポイントをご紹介します。

  • Compliance.Status（技術的なチェック結果）： Security Hub CSPM（主にAWS Config）が評価した機械的な事実です。「FAILED（不合格）」のほか、「PASSED（合格）」「WARNING（警告）」などがあります。これはシステムが下した判定なので、私たちが手動で書き換えることはできません。
  • GeneratorId（詳細な発生元）： 単にどのサービスかだけでなく、具体的にどのチェック項目かを特定する重要なIDです。例えば .../RDS.4 という記述を見れば、「RDSインスタンスの暗号化設定に関するルールだな」と一意に特定できます。
  • Severity.Normalized（共通の尺度）： ツールごとにバラバラな深刻度を、Security Hubが 0〜100 の数字に揃えてくれます。これがあるおかげで、「70点以上（HIGH）なら即対応」といった運用ルールが作りやすくなります。元のツールのスコアも裏側に保持されているので安心です。
  • Workflow.Status（私たちの対応状況）： 「NEW（未着手）」「NOTIFIED（通知済み）」「RESOLVED（解決済み）」「SUPPRESSED（抑制）」の4種類があり、私たちが自由に書き換えられます。機械の判定（Compliance）が「FAILED」であっても、私たちが「この環境では許容できる」と判断して「SUPPRESSED」のラベルを貼ることで、今の状況を正しく管理できます。

※実際の検出結果のJSONから一部抜粋したものになります。

{
"Compliance": {
"Status": "FAILED"
},
"GeneratorId": "aws-foundational-security-best-practices/v/1.0.0/RDS.4",
"Severity": {
"Label": "HIGH",
"Normalized": 70
},
"Workflow": {
"Status": "NEW"
}
}

2. 検証して分かった「オートメーションルール」の仕様

「オートメーションルールを作ったのに、既存のアラートが変わらない？」という疑問。その理由は、裏側で動いているAPIの仕様にありました。

  • 新しい結果はすぐに適用： 新しく検知されたり、検知元のツールから情報が更新された瞬間に適用されます。技術的には、システム側からのデータ取り込み処理（BatchImportFindings）が走った時のみ、オートメーションルールがトリガーされる仕組みです。
  • 既存の結果は定期スキャン待ち： ルール作成直後、すでに出ている古いアラートには反映されません。ただし、Security Hub CSPMの結果であれば、システムが 12〜24時間ごと に行う定期スキャンのタイミングで「情報の更新」とみなされ、ルールが適用されます。
  • 手動で変えた時の制約（APIの制約）： コンソールから手作業でステータスを変えたりメモを追記したりしても、ルールは発動しません。これは、手動更新用の処理（BatchUpdateFindings）に対しては、オートメーションルールが反応しないという仕様があるためです。

ちょっとしたコツ： GuardDuty由来の項目をすぐに更新したい場合は、一度「アーカイブ → アーカイブ解除」を試してみてください。これによりデータの再送が行われ、ルールが即座に反応してくれます。

オートメーションルールの設定例

今回作成したルールの詳細がこちらです。

  • 条件： SeverityLabel が LOW かつ WorkflowStatus が NEW（新着）のもの。
  • アクション： ワークフローステータスを SUPPRESSED（抑制済み）に変更。

画像にある通り、他にも「GuardDuty由来であること（ProductName）」や「現在有効なレコードであること（RecordState）」などを条件に組み込んでいます。このように条件を絞ることで、対応不要な通知だけをピンポイントで整理できます。

3. 「抑制（Suppressed）」を上手に使う

「FAILED（不合格）」が出ていると少し焦りますが、とりあえず「解決済み（Resolved）」で閉じてしまうのではなく、Suppressed（抑制） の活用もおすすめです。

先ほどの設定画面の「自動アクション」欄（画像下部）に注目してください。

Suppressed（抑制）： 「内容を確認して、この環境では問題ないと判断したよ」という運用上の意思表示です。

活用するメリット

  • 通知は残るが、リストは整理される： 検知履歴自体は残しつつも、日々の「対応が必要なリスト」からは消せるため、運用が非常にクリアになります。
  • 「判断の証跡」になる： 後で見返した時も、「これはResolved（解決）したのではなく、意図を持ってSuppressed（抑制）した」と履歴が残せます。

画像で設定したように、「重要度が低く（LOW）、かつ新着（NEW）のもの」を自動で抑制するようにしておけば、本当に対応すべき深刻なアラートにだけ集中できる環境が整います。

4. マルチアカウントで使う時の制約

管理アカウントから一括で設定できる「中央設定」ですが、メンバーアカウント単体で試してみると、以下のようなメッセージが出ることがあります。

「お客様はこのアカウントの管理者ではありません……」

これは「クロスリージョン集約」の設定画面ですが、このようにメッセージが出て設定がロックされているのは、「組織全体のルールに従って、中央でしっかり統制されていますよ」という信頼の印でもあります。もし自分たちで自由に設定を変えたい時は、管理者に相談が必要になります。

5. まとめ：Security Hubは「前処理」と「後処理」で仲良くなる

Security Hubは、ただアラートを眺めるだけでなく、私たちの手で少し整理してあげると、もっと使いやすくなります。

  1. 前処理： オートメーションルールを使って、日々のノイズを少しずつ減らしてあげる。
  2. 後処理： 本当に大切なことだけが、Slackなどに届くようにしてあげる。

こうして環境を整えてあげると、Security Hubが頼もしい司令塔になってくれます。まずは、小さな「抑制ルール」を一つ作るところから、ゆっくり始めてみませんか？