openaijamodel: gpt-5-mini-2025-08-07

実用的なインサイトのためのセキュリティ概要ダッシュボードの構築

Published: 2026-03-10T13:00:00.000Z
Authors: Rachel Smith, Hemanth Kasula
読み取り時間: 約9分

概要

長年にわたり業界の脅威への回答は「可視性の向上」でした。しかし、文脈のない可視性は単なるノイズに過ぎません。現代のセキュリティチームが直面する最大の課題は、データ不足ではなく、その圧倒的な過剰です。多くの担当者は、複数のダッシュボードと分散したログを行き来しながら、ひとつの一見シンプルな問いに答えようとしています: 「今、何をすべきか？」

単一の誤構成を特定するためにツール間を行き来している間に、インシデントを未然に防ぐ機会が失われています。そこで我々は、リアクティブな監視からプロアクティブな制御へと移行するため、再設計した Security Overview dashboard（セキュリティ概要ダッシュボード）を構築しました。

ノイズからアクションへ: セキュリティ概要の再考

従来のダッシュボードは「何が起きているか」を全て見せることに注力していました。しかし忙しいアナリストにとって重要なのは「今、何を直すべきか？」です。

Security Action Items

この課題を解決するために、Security Action Items を導入しました。これは検知と調査の間を機能的に橋渡しする機能で、脆弱性や誤構成を自動で表面化します。トリアージを支援するため、アイテムは重要度別にランク付けされます:

Critical: 悪用を防ぐため直ちに対応が必要な緊急リスク。
Moderate: 強固なセキュリティ姿勢を維持するために対処すべき問題。
Low: ベストプラクティスの最適化やハードニング提案。

また、Insight Type（例: Suspicious Activity、Insecure Configuration）でフィルタリングすることで、組織が最も対処すべき脅威にワークフローを合わせられます。

検出ツール（Detection Tools）モジュール

侵害の最も一般的な原因の一つは、セキュリティツールが存在しないことではなく「ツールが有効化されていない」または「誤って設定されている」ことです。これを我々は "configuration gap（構成ギャップ）" と呼びます。新しい Detection Tools モジュールはこの盲点を排除します。

ダッシュボード上でクラウドフレアのセキュリティスタック全体の高レベルなステータスを一目で確認できます: 主要な保護がアクティブか、または変動期に "Log Only" モードになっていないか、シャドウ API を発見しているか、それとも何も見えていない状態か。

Security Action Items と並べてこれらのツールを表示することで、会話は「このツールを持っているか？」から「このツールは今アクティブに保護しているか？」へと移行します。

Suspicious Activityカードの統合

ハイレベルなサマリは、その裏にあるデータが正確であってこそ有効です。Suspicious Activity カードの可視性を統合し、カードは Security Overview と Security Analytics の両方に配置されます。Overview 上のカードをクリックすると、関連フィルタが自動適用された状態で Security Analytics ダッシュボードへダイレクトにディープリンクします。これにより、タブ切り替えの“税”を排し、インシデント対応のワークフローを高速化します。

新しいセキュリティ概要ダッシュボードの構築方法

プロアクティブな防御を維持するため、我々のエンジンは毎日1,000万件以上のアクショナブルなインサイトを生成・更新しています。この規模で運用するには二つの主要なエンジニアリング上の課題があります。

スケール: 大量データをシームレスに処理すること。
ブレッドス: 真のセキュリティは水平的であり、スタック全体を横断すること。インサイトは単純な SSL 証明書から複雑な AI ボット設定に至るまで、あらゆるものを検証する必要があります。

このため、我々は小規模で専門化されたマイクロサービス群、いわゆる "checkers" を構築しました。各 checker は DNS レコードのようなスタックの特定領域の専門家です。チェックの分散により各 checker は独立してスケールでき、二つの方法でシステムに接続されます: スケジュールされた構成チェック、またはイベント発生時に即時リスクをフラグするリアルタイムリスナー。

1) Scheduled checks（スケジュールチェック）

深い検査を必要とするリスクにはこのモードをデプロイします。オーケストレータ（scheduler）が定期的にタスクを push し、checkers はそれを実行します。チェックワークロードは大規模な並列システムに分散されます。

例: DNS checker に送られるタスクは「ゾーン xyz.com の DNS 関連構成を全てスキャンして異常を検出せよ」のようなものです。checker は独自の専門ロジックでアセットと構成をスキャンします（A/AAAA/CNAME レコード、DMARC、SPF など）。

インサイトのライフサイクルは次の通りです:

チェッカーがメッセージを受け取って起動する。
ゾーンやアカウントに関する関連アセット（例: DNS レコード）を収集する。
アセットの状態を検証するために複数のチェックを実行する（例: CNAME がサーバーを指しているか）。
状態や構成が閾値を満たさない場合、インサイトがフラグされる。
次回のチェックでインサイトが持続すればタイムスタンプが更新され、修正されていればデータベースから削除される。

2) Event handlers（イベントハンドラ）

Checkers は定期的に動作しますが、イベントハンドラはリアルタイムで制御プレーンからのシグナルやイベントをリッスンします。リアルタイムなルールセットインサイトのライフサイクル例:

WAF ルール構成が変更される。
変更内容を含むイベントが即座にトリガーされる。
常時リッスンしている ruleset handler が起動する。
ハンドラが異常を検知する（例: Cloudflare Managed Ruleset を有効化したが "Log Only" のままにしている）。
ハンドラは攻撃を記録しているが遮断していないと判断し、インサイトを登録してダッシュボードに表示する。
構成が安全な設定に更新されれば、ハンドラはインサイトをクリアする。

ルールセットハンドラのリアルタイム性により、誤構成のフラグ立てや修正の確認を即時に行えます。

文脈を伴うインサイトで可視性を統合する

顧客は単なる可視化以上のもの、つまりコンテキストを求めてきました。誤構成の通知は有益ですが、それだけでは不十分です。即座に自信を持ってアクションを取るには「だから何か（so what）」が必要であり、ビジネスインパクトや技術的な根本原因を含める必要があります。

これに対応するため、我々は検出エンジン向けに Contextual Insights を開発しました。破損した A レコードへのトラフィック量のようなデータを表示することで、各インサイトが即座に行動に繋がるようにします。

まずは DNS インサイトの深さを拡張することからこの旅を始めています。単にレコードが壊れているとフラグする代わりに、切れたシグナルを追加のコンテキストとリアルタイムのトラフィックデータと相関させて “なぜ” と “どのように” を提示します:

Target Context: レコードが指している削除済みリソース（例: 古い S3 バケットやクラウドインスタンス）を特定します。
Impact Context: その壊れたレコードにどれだけのユーザーがまだアクセスしようとしているかを示します。

例: Dangling A/AAAA/CNAME record インサイト

これらのインサイトを提供するために、毎秒ネットワークを流れる膨大なデータを解析する必要があります。規模感を示すと:

週次で100万件以上ではなく100+ million DNS records をエンジンがスキャンしています。
先週だけでエンジンは1,000,000件超の dangling DNS records を特定しました。
その大部分（97%）は Dangling A/AAAA records、残り3%が Dangling CNAME records。
31,000件の dangling CNAME のうち:
- 95% が Microsoft Azure サービスを指している。
- 3% が AWS Elastic Beanstalk を指している。

これはサブドメインテイクオーバーの高優先度ターゲットであることを示唆します。攻撃者はこれら放棄されたクラウドリソースを奪取してサブドメインを掌握し、フィッシングやブランド偽装の媒介にできます。アクセスが多数ある dangling record は即時の修復を要する高優先度のリスクです。

DNS checker の2段階プロセス

Step 1: Active Insight detection

チェックはスキャン開始メッセージを受け取ると検証を開始します（前節で説明した流れ）。

Step 2: Contextual enrichment

インサイトが生成されると、checker は顧客が影響を理解しやすくするための関連コンテキストを収集します。dangling インサイトでは以下の3つの重要な次元に注力します:

トラフィックボリューム（影響度）
ターゲットコンテキスト（指し示す削除済みリソースの特定）
追加のリアルタイム情報

深堀: Dangling DNS record インサイトの生成

フェーズ1: アクティブ検証

IP アドレスを指す DNS レコードは、裏側のサーバーが数ヶ月前に廃棄されていても表面上は有効に見えることがあります。リスクが実際に存在するか確認するため、エンジンはネットワーク外部から送信先をリアルタイムにプローブします。

検証は主に以下のカテゴリに分類されます:

Dead server check（A/AAAA レコード）: IP を直接指すレコードについては、送信先がまだアクティブかどうかを検証します。エンジンは専用の egress proxy を立ち上げ、HTTP と HTTPS でオリジンへの接続を試みます。これにより、Cloudflare ネットワーク外から実際のユーザーが接続した場合の挙動をシミュレートします。接続がタイムアウトするか "404 Not Found" が返る場合、リソースは死んでいると確定し、その DNS レコードは "dangling" と判定されます。
Takeover check（CNAME レコード）: CNAME はよくサードパーティサービス（ヘルプデスクやストレージバケット等）へトラフィックを委譲します。サービスをキャンセルしても DNS レコードを削除し忘れると、攻撃者がそのリンクを奪える "dangling" な状態が生まれます。検出は3ステップで行われます:
1. CNAME を再帰的に解決して最終的な宛先（例: my-bucket.s3.amazonaws.com）を追跡する。
2. その宛先が AWS、Azure、Shopify 等の既知クラウドサービスに属するか特定する。
3. リソースが存在しない場合に返される各プロバイダ固有のエラーパターン（例: S3 の "NoSuchBucket"）に照らして空き状況を確認する。

エンジンがリソースが解放されていると検出し、DNS レコードが残っている場合、インサイトを生成して攻撃者に奪われる前にレコードを削除するよう促します。

フェーズ2: コンテキスト強化

レコードが破損していると確認できたら、インサイトに必要なコンテキストを追加して対応を容易にします。checker は複数のシステムに接続して情報を収集します。dangling インサイトでは特に以下に注力します:

トラフィックボリューム（影響）: 我々のグローバル ClickHouse クラスタには豊富な情報があります。該当レコードが実際に利用されているかを把握するため、checker は過去7日間の該当レコードに対する DNS クエリの合計をグローバル ClickHouse クラスタに対して集計クエリを行います。このコンテキストにより優先度付けが可能になります。クエリが0のレコードは時間をかけて修正できますが、10,000 のクエリがあるレコードは即時の脆弱性です。

クエリ例:

SELECT query_name, sum(_sample_interval) as total FROM <dnslogs_tabl

(注: 上記クエリはソースドキュメントの切り出しのため途切れています。実運用では適切なテーブル名・期間条件を付与して実行してください。)

まとめ

新しい Security Overview dashboard は、単なる可視化を超え、コンテキスト付きのアクショナブルなインサイトを通じて防御側をエンパワーします。Security Action Items、Detection Tools モジュール、Suspicious Activity の深い統合、マイクロサービス化された checkers による大規模かつリアルタイムな検出、そして Contextual Insights による影響度の見える化により、チームは「何が起きているか」ではなく「今すぐ何をすべきか」に集中できるようになります。

Building a security overview dashboard for actionable insights

要約

Summary

Key Points

翻訳

概要