Security Hub — セキュリティの司令塔は何をしているか

はじめに — 司令塔の本来の仕事

今日はですね、Security Hubというサービスについて話していきます。前回のGuardDutyの話を覚えてますか。脅威を検出する専門家でしたね。今日はそれを集約する司令塔の話です。

このサービス、名前だけ聞くと「最強のセキュリティサービス」だと思う人がいるんですよ。でも実は、ここが最大の誤解なんです。

警察の指令室を想像してください。110番通報が鳴りっぱなし。「〇〇町で火事です」「駅で喧嘩してます」「□□銀行で強盗です」。いろんな情報がバラバラで集まってくる。指令室は何をするか。集まってきた情報を整理して、優先順位つけて、各警察車両に指示を出す。ここが重要なんですが、指令室自身は犯人を逮捕しません。火も消しません。パトカーが行ってやる。

Security Hubはそれです。情報の「集約・整理・優先順位付け」をする司令塔。自分で脅威を検出しない、修復もしない。では、まずこの誤解を解いてから入りましょう。

実際、Security Hubが有効化された瞬間から、複数のAWSサービスからのFindingが自動で流れ込んできます。GuardDutyが「異常なネットワーク活動検出」と報告してくれる。Inspector が「EC2に脆弱性発見」と通知する。Config が「S3バケット暗号化されてない」と指摘する。これらが全部バラバラのフォーマットで届くんですよ。どういうフォーマットか。GuardDutyは JSON のある形式、Config はまた別の形式、みたいに。それを Security Hub が統一する。まるで国連の通訳みたいに。

「自分で何も検出しない」という真実

左側に「検出者たち」がいます。GuardDuty、Inspector、Macie、AWS Config、カスタムツール。右側に「司令塔」がいます。Security Hub。各検出者たちが、バラバラのフォーマットで「見つけました」って報告してくる。Security Hubはそれを「待ってました、その情報ちょっと整理させてください」って言って、全部同じ形式に直します。それがASFF、エーエスエフエフですね。

試験問題が出ます。「Security Hubはどうやって脅威を検出するのか」。答えは何でしょう。SecurityHubは検出しません。本当です。Security HubはFinding生成装置じゃなくて、Finding集約・翻訳装置なんです。

例え話をしましょう。昔、国連で各国の代表が「日本語で喋ります」「中国語です」「フランス語です」って好きなように喋ってたら、何も決まらない。だから通訳がいる。「あ、これは領土問題についてですね。これは核兵器についてですね」って統一する。ASFFが通訳の役割です。

GuardDutyが「暗号マイニング検出：EC2-AnomalyDetection」と報告しても、ASFFを通じて「EC2 instance i-xxxx has anomalous network activity」に統一される。みんなが同じフォーマットで報告してくるから、Security Hubは「あ、重大度高いのが3件あるな」「このアカウントはいつもこういう失敗してるな」「この基準で100個の違反が出てる」ってパターンが見える。それが司令塔の価値です。

ASFF の詳しい仕組み

ASFF フォーマットって、実際はどんな構造か。主要なフィールドをいくつか説明しますね。

Type フィールドというのがあります。「EC2.NetworkAnomalyDetection」「IAM.PublicKeyExposure」「S3.BucketEncryptionDisabled」みたいに。これが「何が見つかったか」を示します。

Severity フィールドは重大度。これは 0 から 10 の数値。10 が最悪。つまり「この違反、本当にヤバいのか」を数字化する。

ResourceId フィールドには、問題の出たリソース情報。例えば「バケット名は my-production-bucket」「インスタンスIDは i-0123456789abcdef0」みたいに。

WorkflowStatus フィールドがあります。これが重要。最初は NEW。つまり「発見されたばかり」。それから NOTIFIED になる。「関係者に通知済み」。そして RESOLVED。「解決した」。もしくは SUPPRESSED。「意図的に無視している」。この状態遷移を追跡することで「あ、このFinding 3ヶ月前から SUPPRESSED になってるな。本当に許容可能なのか確認しろ」みたいなマネジメントができます。

試験でよく引っかかるのは「RESOLVED は自動修復された」と思うこと。違う。RESOLVED は「セキュリティチームが調査して、実はこれは問題じゃない、または別途対応済み」という判断。修復したかどうか、は別の話です。

「チェックリストの自動化」としてのセキュリティ基準

実は、Security Hubの仕事の半分は検出じゃなくて、ルールをチェックすることなんです。企業のセキュリティ部長が言うでしょ。「ルート認証情報、MFA有効にしてるか確認しろ」「セキュリティグループ、0.0.0.0/0を許可してないか確認しろ」「S3バケット、一般公開になってないか確認しろ」。これ全部、自動化できます。毎日誰かが手でチェックするのか、それともAWSに自動でやらせるのか。

Security Hubは複数の「セキュリティ基準」というチェックリスト集を持ってます。CIS AWS Foundations Benchmark、これが最も有名で、220個以上のチェック項目があります。業界標準のベストプラクティスって感じです。具体例を出すと、「ルートユーザーに MFA が有効か」「セキュリティグループが 0.0.0.0/0 から SSH を許可してないか」「CloudTrail がマルチリージョン有効か」みたいな。これが自動でチェックされるわけです。

PCI DSSはクレジットカード業界向けで、決済情報扱ってるなら必須。「暗号化されてるか」「アクセス制御が厳密か」「ログが保持されてるか」みたいなチェック。AWS基礎セキュリティベストプラクティスはAWS謹製で、AWSが「こうしてください」って推奨してるやつ。NIST Cybersecurity Frameworkは政府機関とか規制厳しい業界向けです。

どの基準を有効にするかは、皆さんのビジネスと規制環境次第です。クレジットカード扱ってなければPCI DSSは不要。NIST対応が契約で必要なら、NIST基準を有効化する。ここが重要なんですが、基準有効化にはAWS Configが必須です。CISの「EC2のセキュリティグループ確認」ってチェック項目、これはAWS Configを使ってAWSのリソース設定をスキャンするんです。ConfigがないとSecurity Hubのチェックが走らない。

実務シナリオを想像してください。新しい環境を立ち上げました。「さあ、Security Hub 有効化するぞ」。ダッシュボード開く。見ると Findings が 0 件。「え、何も問題ないですか」。いや、そうじゃない。Config がないから、設定チェックが走ってないんです。つまり「セキュリティグループチェック、全くされてません」。何百個の違反があるかもしれないのに、見えない状態。これが試験の落とし穴です。

「Security Hub有効化したのに、Findingがほぼ0件です。何故ですか」って質問、本当によくあります。答えは「Config有効化してないからです」。これ試験に出ます。忘れないでください。

Finding集約の力：クロスリージョン・クロスアカウント

これは大規模企業向けの話です。例えば、100個のAWSアカウント持ってる。東京リージョン、大阪リージョン、アメリカ東部、アメリカ西部で稼働してる。各アカウント、各リージョンでSecurityHubを有効化してます。でも、100×4、つまり400画面を毎日見たら、管理者は死にます。

ここで「アグリゲータアカウント」の出番です。1つのアカウントを「司令部」に指定して、他の99個の「支部」から全Findingを集める。そうするとですね、「あ、全社で見たらXXX基準の違反が3000件あるな」「あ、Yパートナー環境で重大な検出が2件出てる」「あ、東京と大阪で設定にズレがあるな」って全体パターンが見える。

具体例を出しましょう。本番アカウント 20 個で CIS チェック走らせます。各アカウントで「セキュリティグループ 0.0.0.0/0 SSH」の違反が合計 50 個。アグリゲータなしだったら「アカウント A で 3 個」「アカウント B で 5 個」みたいにバラバラに見える。パターン分からない。でもアグリゲータで集約すると「全社 50 個。優先度高い」と分かる。一括で施策打てます。セキュリティグループを標準化する、とか。

試験でよく出ます。「マルチアカウント統合するには」という問題。答え方は「アグリゲータアカウントを指定して、各メンバーアカウントをそこに登録する。そのとき各リージョンで委任管理者アカウントを指定することで、Organizations統合も完成する」。ここまで言えば完璧です。

実装パターンとしては、親アカウント（Organizations 管理アカウント）で Security Hub アグリゲータ設定。「すべてのリージョンから集約」を指定。子アカウント側で「親アカウントの Security Hub に統合」と設定。自動的に全子アカウントの Finding が親に流れ込む。新規アカウント追加されても、自動対応。

ASFFの見た目と構造理解

ASFFはJSONフォーマットです。主要なフィールドを覚えておくといいです。Typeは何が見つかったか、例えば「EC2.NetworkAnomalyDetection」「IAM.PublicKeyExposure」。Severityは重大度で1から10の数字、10が最悪。ResourceIdは問題が出たAWSリソース、バケット名やインスタンスID。FindingTimeはいつ見つかったか。RecordStateは「NEW」か「NOTIFIED」か「RESOLVED」。WorkflowStatusは「NEW」「NOTIFIED」「RESOLVED」「SUPPRESSED」などです。

ここで勘違い多いのが、「RESOLVEDは修復されました」と思うことです。違います。RESOLVEDは「うちの調査班が見て、これは実際には問題じゃない」と判断した状態です。修復した・してない、は別の話。修復はユーザー側でやります。ここが本当に重要なんですが、修復はセキュリティハブがやってくれません。

セキュリティ基準の具体的なチェック項目

話を少し戻して、実際のチェック例を見てみましょう。

CIS AWS Foundations Benchmark の場合、220 個以上のチェック項目があります。例えば。「1.1 Ensure AWS account has multi-factor authentication (MFA) enabled for the root user」。これはルート認証情報に MFA が有効か。違反があれば Finding が出ます。

「4.1 Ensure no security groups allow ingress from 0.0.0.0:0 to port 22」。つまり「全インターネットから SSH 許可」がないか。もし 0.0.0.0/0 からポート 22 を許可している SG があれば、Finding。

「2.2 Ensure CloudTrail log file validation is enabled」。CloudTrail のログファイル整合性検証が有効か。無効だと Finding。

「2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs」。CloudTrail がCloudWatch Logs に配信されてるか。されてなければ Finding。

これが 220 個、全部自動で実行される。毎日。SG が 100 個あれば「4.1 チェック」は 100 回実行。そのうち 10 個が「0.0.0.0/0 SSH」なら、10 個の Finding が出ます。つまり「あ、このアカウントは 10 個の SG が危険状態」がすぐ分かる。管理者が手でチェックしたら 1 週間かかる。自動なら数分。

実務では「このチェック項目は除外してください」という要件も出ます。例えば「実験環境だから、0.0.0.0/0 SSH 許可はいい」。そういう場合は、その SG に対してチェック除外設定する。Finding は出ない。ただし理由を記録しておかないと「何で除外してるのか」が分からなくなります。監査対応で困ります。

「Security Hubが全部やってくれる」という誤解

質問が飛んできます。「ちょっと待ってください。Findingが出たなら、Security Hubが自動で修復してくれるんですか」。違います。これが本当に重要な誤解です。Security Hubがやることは、Findingを集約する、ワークフローステータスを追跡する、アラートを飛ばす、ダッシュボードを表示する。修復は全部ユーザーです。

例えば「セキュリティグループが0.0.0.0/0からのSSHを許可してる」というFindingが出ました。ここからどうするか。パターン1はEventBridgeで自動化です。EventBridgeルール作る。「Security Hub from AWS Config: FAILED」という通知が来たら、Lambdaをトリガー。Lambdaは「SecurityGroupの該当ルール削除」という修復コードを書いて、実行。完了。Findingを「RESOLVED」にマーク。

パターン2はSNSで通知、手動対応です。EventBridgeルール作る。Slack通知飛ばす。「〇〇リージョン SGで問題検出」。担当者が見て、マニュアルで修復。完了後、FindingをRESOLVEDにマーク。どちらにせよ、修復ロジックを書くのはお前だ。試験での頻出問題は「Security Hubに自動修復機能がある」なんですが、それは嘘です。EventBridge+Lambdaで自分で作ります。

Finding抑制とワークフロー管理

時々ですね、「このFinding、うちの環境では許容してる、毎回見たくない」ってことあります。例えば「実験環境なので、セキュリティ厳しくする必要ない」「外部監査対応なので、このチェック無視していい」。ここでFinding抑制の機能が出てくる。

Findingを選んで「このFinding、抑制する」とマーク。そうするとダッシュボードには表示されなくなる。でもログには残る。後で「やっぱり有効化する」って復活できます。これ監査対応で大事なんです。「何で抑制してるのか、なぜそれが許容可能か」を記録しておくと、外部監査官に説明できる。

ワークフローステータスも同じです。NEW は初めて見つかった。NOTIFIED は関係者に通知済み。RESOLVED は対応完了。SUPPRESSED は意図的に無視（抑制）。これらを追跡することで、「あ、このFinding、3ヶ月前から RESOLVED になってるけど、実際に修復されてるかな」って確認できます。

実務例。Finding「S3 バケット MFA Delete 未設定」が出ました。実験用バケットだから SUPPRESSED。コメント「実験環境なので許容」と記録。3 ヶ月後、監査。「このバケット、MFA Delete 設定してないですね」。「あ、実験環境だから SUPPRESS しました」。「了解。では本番環境を確認」。本番環境は RESOLVED。「修復済みですね。OK」。このように SUPPRESSED と RESOLVED の区別が、監査対応のポイント。

Config依存性の全体像と「有効化したのにFindingが0」の罠

ここで一度、構成をまとめましょう。Security Hubは以下のサービスからFindingを集めます。AWS Configはリソース設定のコンプライアンスチェック。GuardDutyは脅威検出。Inspectorは脆弱性スキャン。Macieはデータセキュリティ（S3の個人情報検出など）。IAM Access Analyzerはポリシー分析です。この中で、ConfigがCISのチェック項目の多くを担当しています。ConfigRuleとして実装されてるんです。

「有効化したのに Finding が 0 件」という罠。これ本当によくある。新しい環境を作った。Security Hub 有効化。ダッシュボード見る。Finding ゼロ件。「あれ、何も問題ないですか？」いや違う。Config が無効化されてるから、設定チェックが走ってないんです。

具体例。セキュリティグループ 50 個ある。そのうち 20 個が「0.0.0.0/0 SSH」という危険な状態。でも Config がないから、Security Hub はそれを見つけられない。見えない。存在しない。のと同じ。

実装パターンは、まず AWS Config を有効化（各リージョン）。ConfigRecorder を起動。DeliveryChannel を設定（S3 に設定履歴を保存）。Config Rules を作成（CIS チェックを指定）。Security Hub を有効化。セキュリティ基準（CIS/PCI DSS等）を有効化。これで初めて「あ、違反が 100 件出た」ってなります。これ本当に重要です。

試験では「Security Hub 有効化しても Finding が出ません。原因は何ですか」という問題が出ます。答え「AWS Config を有効化してください」。これだけで OK。

自動修復パイプラインの設計思想

最後に、実際の自動修復パイプラインを説明します。

ステップ1はConfigRuleで検出。AWS Configが定期的にリソース設定をスキャン。例「S3バケット暗号化されてるか」。毎時間、定期的に。全S3バケットをチェック。

ステップ2はConfigからFindingを生成。違反があれば「s3-bucket-server-side-encryption-enabled: FAILED」。バケット名とか詳細情報も含む。

ステップ3はSecurity Hubに集約。ConfigのFindingがSecurity Hubに自動で送られる。ASFFフォーマットに正規化される。ダッシュボードに表示。

ステップ4はEventBridgeトリガーです。EventBridgeルール。ここで「source: ‘aws.securityhub’ かつ detail-type: ‘Security Hub Findings - Imported’ かつ detail.findings[0].Type が特定パターン」なら、Lambda をトリガー。

ステップ5はLambdaで修復。Lambdaは問題のリソースIDを取得。例えば Finding から「バケット名は production-data」と抽出。AWS SDK で修復実行。「その S3 バケットに ServerSideEncryptionConfiguration を追加」。修復完了後、Security Hub API を呼んでFindingのワークフローステータスを RESOLVED に更新。

ステップ6はSNSで管理者に通知。「XXXバケットの暗号化設定が自動修復されました」「実行時刻は 2026-04-27 14:30」「修復者は Lambda」。これで人間も「あ、自動でやってくれたんだ」と確認できます。

この 6 ステップが完全に自動で回ります。夜中 3 時に違反が出ても、人間が寝てようが、Lambda が勝手に修復を進めます。これが Cloud Native なセキュリティの姿です。

試験で出る落とし穴

試験対策として、以下3つは確実に頭に入れてください。落とし穴1は「Security Hub=脅威検出」という誤りです。Security Hubは脅威検出エンジンではなく、集約・整理エンジンです。検出はGuardDuty、Inspector、Macieが担当。

落とし穴2は「Configなしで Security Hub有効化」です。試験問題「セキュリティ基準チェックが動いていません、何が足りませんか」。答え「AWS Configを有効化してください」。これ出ます。

落とし穴3は「Remediation（修復）をSecurity Hubに期待する」です。試験問題「Findingが自動で修復されるようにするには」。答え「EventBridgeルール+Lambdaで自動修復パイプラインを実装してください。Security Hubは検出と通知のみ」。

デザイン上の問いかけ

実は、Security Hubの設計思想で興味深いのは「複数の検出ツール、複数の基準を同時に運用できる」という点です。CISとPCI DSSを同時に有効化できます。理由は？ビジネスの複雑性に対応するためです。

「うちの決済サービスはPCI DSS対応が必須。でも他の部門はCISで足りる。」こういう場合、両方有効化して、Findingをフィルタリングすればいい。こういう「複雑な現実に対応する柔軟性」がSecurity Hubの価値です。ポリシー一本では世界は回らない、って割り切ってます。

Finding ライフサイクルと実務管理

実務では、Finding の状態遷移がすごく大事です。NEW で見つかった违反。例えば「セキュリティグループが 0.0.0.0/0 から SSH 許可」。これが NEW 状態で出る。セキュリティチーム「あ、これ見つけました」。NOTIFIED に変える。「関係者に通知しました」。すると、該当する EC2 担当者に Slack 通知が飛びます。「お前のセキュリティグループ、修正してくれ」。修正されました。RESOLVED に変える。「完了」。

ここで重要なのは SUPPRESSED 。これは「ルール違反だけど、うちでは許容する」という状態。例えば「実験環境だから、一時的に 0.0.0.0/0 SSH アクセス許可したい」。これを SUPPRESSED にしておけば、ダッシュボードに表示されない。ただし、ログには残る。後で「なぜこれを SUPPRESSED にしてるのか」という理由をコメントで記録しておけば、監査官に「ここは意図的です」と説明できます。

試験シナリオがよく出ます。「このFinding、3ヶ月前から SUPPRESSED になってるけど、本当に許容可能ですか」「実は実験環境のはずが、本番環境になってた」「あ、これ危ない。SUPPRESSED 解除して修復する」。この判断が、セキュリティマネジメントのキモです。

まとめ — 司令塔の本当の仕事

Security Hubは何か。セキュリティの司令塔です。司令塔の仕事は、情報を集約する（GuardDuty、Inspector、Macie、Configから）、標準フォーマットに統一する（ASFF）、優先順位つけて見せる（ダッシュボード、アラート）、ワークフロー追跡する（NEW→NOTIFIED→RESOLVED→SUPPRESSED）。

司令塔の仕事ではないものは脅威検出（GuardDutyの仕事）、脆弱性スキャン（Inspectorの仕事）、修復（お前の仕事）です。修復パイプラインはEventBridge+Lambdaで自分で作ります。Security Hubはあくまで通知先です。

試験に出るポイント。CIS+AWS Config+Security Hub+EventBridge+Lambda、この5つの組み合わせができれば「あ、もう自動で回ってる」ってなります。実務でも試験でも、この「司令塔は集約するだけ。修復は自分」ってマインドを持ってれば、Security Hubの本質が見えます。

クロスアカウント集約の実装細部

実装には一つテクニックが必要です。メンバーアカウント側で「アグリゲータアカウントに統合を承認」という設定が必要。そうしないと、アグリゲータ側から「統合しろ」と指示しても、メンバーアカウントはそれを受け入れません。

具体的には、メンバーアカウント側で「Security Hub 有効化」「アグリゲータアカウント ID を指定」という操作。すると、アグリゲータ側に「アカウント B が統合リクエスト送信」という通知。アグリゲータ側で「OK」を押す。両者が合意。同期開始。Finding 流れ込み開始。

試験では「マルチアカウント集約の設定手順」という問題が出ます。「アグリゲータアカウントで create-finding-aggregator。メンバーアカウントで Security Hub 有効化。アグリゲータにメンバーを登録。完成」。流れを覚えておけば OK。

試験頻出落とし穴 3 つ

試験対策として、以下 3 つは確実に頭に入れてください。

落とし穴 1 は「Security Hub = 脅威検出」という誤り。Security Hub は脅威検出エンジンではなく、集約・整理エンジン。検出は GuardDuty、Inspector、Macie が担当。

落とし穴 2 は「Config なし」で Security Hub 有効化。試験問題「セキュリティ基準チェックが動いていません。何が足りませんか」。答え「AWS Config を有効化してください」。これ出ます。

落とし穴 3 は「Remediation（修復）を Security Hub に期待する」。試験問題「Finding が自動で修復されるようにするには」。答え「EventBridge ルール + Lambda で自動修復パイプラインを実装してください。Security Hub は検出と通知のみ」。

クロスリージョン集約の全体像

大企業向けの話。複数リージョンで運用してる場合、各リージョンの Finding をどう管理するか。

パターン1：各リージョンで separate ダッシュボード。東京用、大阪用、米国用。管理者が 3 画面見る。パターン2：Security Hub アグリゲータで全リージョンから集約。1 画面で全体把握。

実装は ALL_REGIONS オプション。「すべてのリージョンから集約」と指定。すると、東京の Security Hub で「大阪の Finding」「米国の Finding」が自動表示。管理が楽。新規リージョン追加されても、自動対応。

ただし注意点。リージョン数が増えると Finding 数が増える。東京 500 個 + 大阪 300 個 + 米国 200 個 = 合計 1000 個。ダッシュボードが重くなる可能性。フィルター設定で「CRITICAL だけ見る」みたいに絞る必要があります。

試験対策：コンボ問題

「複数リージョン、複数アカウント、複数基準（CIS + PCI DSS）の環境。全 Finding を一箇所で管理。要件は何ですか」という問題が出ます。

答え：「Security Hub アグリゲータを親アカウントで設定。ALL_REGIONS で全リージョン集約。Organizations Trail で全子アカウント集約。CIS + PCI DSS 基準を有効化。全子アカウントでも有効化。EventBridge で自動化。」。できれば CloudWatch Logs も連携。もっと完璧。

最後に一つ

複数の基準（CIS と PCI DSS を同時に有効化する）、複数のアカウント（100個のアカウントのログを一箇所に集約）、複数のリージョン（東京・大阪・米国 region すべての Finding を一個のダッシュボードで）。こういう複雑性に対応するのが Security Hub の真価。単純な環境なら Security Hub は不要。でも、複雑で、規制要件も多くて、運用負荷も大きい環境なら、Security Hub がないと崩壊します。では、次は VPCセキュリティに行きましょう。