実用的なインサイトのためのセキュリティ概要ダッシュボードの構築
2026-03-10 | Rachel Smith、Hemanth Kasula | 9分で読める
長年にわたり、業界の脅威に対する答えは「より多くの可視性」でした。しかし、コンテキストのない可視性は単なるノイズに過ぎません。現代のセキュリティチームにとって、最大の課題はもはやデータの不足ではなく、データの圧倒的な過剰さです。
ほとんどのセキュリティ専門家は、ダッシュボードの海を航行し、異なるログを探し回って、一つの一見シンプルな質問に答えることから一日を始めます：「今、何をすべきか？」
単一の設定ミスを特定するために異なるツール間を行き来することを強いられているとき、インシデントを防ぐ機会の窓を失っています。そのため、私たちは刷新されたセキュリティ概要ダッシュボードを構築しました：反応的な監視から積極的な制御へと移行することで、防御者を支援するように設計された単一のインターフェースです。
ノイズからアクションへ：セキュリティ概要の再考
従来、ダッシュボードは起こっているすべてのことを表示することに焦点を当てていました。しかし、忙しいセキュリティアナリストにとって、より重要な質問は「今すぐ修正する必要があるものは何か？」です。
これを解決するために、私たちはセキュリティアクションアイテムを導入しています。この機能は検出と調査の間の機能的な橋渡しとして機能し、脆弱性を表面化させるため、もはやそれらを探し回る必要がありません。
効果的なトリアージを支援するため、アイテムは重要度によってランク付けされています：
- Critical：悪用を防ぐために即座の注意が必要な緊急リスク
- Moderate：強固なセキュリティ態勢を維持するために対処すべき問題
- Low：ベストプラクティスの最適化と強化の提案
Insight Type（疑わしいアクティビティや安全でない設定など）でフィルタリングすることで、組織が最も直面する特定の脅威にワークフローを調整できます。
設定ギャップの解消
侵害の最も一般的な原因の一つは、セキュリティツールの不在ではなく、そのツールが有効化されていなかったり、誤って設定されていたりすることです。私たちはこれを設定ギャップと呼んでいます。
新しい検出ツールモジュールは、この盲点を排除します。トラフィックが実際に検査されているかどうかを確認するためにネストされた設定ページを掘り下げる代わりに、Cloudflareセキュリティスタック全体の高レベルステータスを一つのビューで提供します：
- 主要なシールドがアクティブか、それとも不安定な期間中に「ログのみ」モードになっているか？
- シャドウAPIを発見しているか、それとも盲目的に飛行しているか？
これらのツールをセキュリティアクションアイテムと直接並べて表示することで、会話を「このツールはあるか？」から「このツールは今現在私たちを積極的に保護しているか？」へと移行させます。
シームレスなワークフロー統合
高レベルの要約は、その背後にあるデータと同じくらい良いものです。赤旗からソリューションへの移行をシームレスにするため、私たちは疑わしいアクティビティカードの可視性を統一しました。
これらのカードは現在、2つの戦略的な場所に存在します：セキュリティ概要とセキュリティ分析ページです。概要ページで興味を引く疑わしいアクティビティカードを見つけた場合、手動で分析に移動してフィルターを再作成する必要はありません。カードをクリックすることで、関連するすべてのフィルターが自動的に適用されたセキュリティ分析ダッシュボードに直接ディープリンクされます。
これにより、インシデント対応を遅らせる「タブ切り替え税」が排除され、ワークフローが流動的で応答時間が速く保たれます。
新しいセキュリティ概要ダッシュボードの構築方法
積極的な防御を維持するため、私たちのエンジンは保護が常に最新であることを確保するために、毎日1000万以上の実用的なインサイトを生成し、更新しています。このレベルでの運用は、2つの異なるエンジニアリング課題を提示します。
最初はスケール：大量のデータをシームレスに処理することです。2番目の、そしておそらくより困難な課題は、幅の広さです。真のセキュリティは水平的で、スタック全体にわたります。
リスクと脆弱性の包括的なビューを提供する実用的なインサイトを生成するため、私たちのエンジンは単純なSSL証明書から複雑なAIボット設定まで、すべてを検証する必要があります。
これを解決するため、私たちはチェッカーと呼ぶ、より小さな専門化されたマイクロサービスで構成されたシステムを構築しました。各チェッカーは、DNSレコードなど、スタックの特定の部分の専門家です。
チェッカーの分散により、それらは独立してスケールでき、2つの方法でシステムにフックされています：スケジュールされた設定チェックまたはイベントが発生した瞬間にリスクをフラグするリアルタイムリスナー。
1. スケジュールされたチェック
深い検査が必要なリスクに対してこのモードを展開します。これらはオーケストレーター（スケジューラー）によってトリガーされ、チェッカーが実行するタスクを定期的にプッシュします。
チェッカーのワークロードを大規模並列システム全体に分散します。例えば、DNSチェッカーに送信されるタスクは次のようなものかもしれません：「zone xyz.comのDNS関連設定をすべてスキャンし、異常を見つけよ。」
チェッカーはこれらのタスクを独立して取得します。彼らは専門的なインテリジェンスを使用してアセットと設定をスキャンします。DNSチェッカーの場合、A/AAAA/CNAMEレコードやDMARC、SPFレコードなど、ゾーンのすべてのDNSアセットと設定をスキャンするために専門的で知的なルールを使用します。
インサイトのライフサイクルは次のようになります：
- メッセージを受信するとチェッカーがアクティブになる
- チェッカーがゾーンまたはアカウントに関する関連アセット（例：DNSレコード）を収集する
- チェッカーがアセットのステータスを検証するためにいくつかのチェックを実行する（例：CNAMEレコードがサーバーを指しているか）
- 状態または設定が必要な閾値を満たさない場合、インサイトがフラグされる
- 次のチェック中にインサイトが持続する場合、タイムスタンプが更新される
- 次のチェック中にインサイトが修正されている場合、データベースから削除される
2. イベントハンドラー
チェッカーがスケジュールで24時間稼働するのに対し、イベントハンドラーはリアルタイムで機能します。コントロールプレーンからの信号とイベントをリッスンします。
リアルタイムルールセットインサイトのライフサイクルは次のようになります：
- WAFルール設定が変更される
- 変更の詳細を含むイベントが即座にトリガーされる
- アクティブにリッスンしているルールセットハンドラーが動作を開始する
- ハンドラーが異常を検出する（例：Cloudflare Managed Rulesetを有効にしたが「ログのみ」モードのままにしている）
- ハンドラーが攻撃が記録されているがブロックされていないと推定する
- ハンドラーがインサイトを登録し、ダッシュボードで利用可能にする
- 設定が安全な設定に更新されている場合、ハンドラーがインサイトをクリアする
ルールセットハンドラーのリアルタイム性により、設定ミスをフラグしたり、修正を即座に確認したりできます。
コンテキストインサイトによるセキュリティ可視性の統一
私たちの顧客は一貫して、単なる可視性以上のものを求めてきました：コンテキストを求めています。レコードが誤設定されているという通知は役立ちますが、それは話の半分に過ぎません。即座に自信を持ってアクションを取るため、防御者はビジネスへの影響と技術的な根本原因を含む「だから何？」を知る必要があります。
これに対処するため、私たちは検出エンジンのためのコンテキストインサイトを開発しました。壊れたAレコードへのトラフィック量などのデータを表面化することで、すべてのインサイトがアクションへの招待であることを確保します。
私たちはDNSインサイトの深度を拡張することで、このコンテキストインサイトの旅を始めています。単に壊れたレコードをフラグするだけでなく、ダングリング信号を追加のコンテキストとリアルタイムトラフィックデータと関連付けて、「なぜ」と「どのように」を提供します：
- ターゲットコンテキスト：レコードが指している削除されたリソース（例：古いS3バケットやクラウドインスタンス）を正確に特定します
- 影響コンテキスト：その壊れたレコードにまだ到達しようとしているユーザーの正確な数を表示します
ダングリングDNSレコードインサイトの例
「ダングリングA/AAAA/CNAMEレコード」インサイトを例として探ってみましょう。これらのインサイトを提供するため、私たちは毎秒ネットワークを流れる大量のデータを分析する必要があります。
舞台裏で起こっている作業のアイデアを提供するために：
- 1億以上のDNSレコードが私たちのエンジンによって週次でスキャンされています
- 過去1週間で、私たちのエンジンは100万以上のダングリングDNSレコードを特定しました
- 大部分（97%）はダングリングA/AAAAレコードで、残りの3%はダングリングCNAMEレコードです
- 31,000のダングリングCNAMEレコードのうち：
- 95%がMicrosoft Azureサービスを指している
- 3%がAWS Elastic Beanstalkを指している
これは、これらがサブドメイン乗っ取りの高優先度ターゲットであることを示しています。攻撃者はこれらの放棄されたクラウドリソースを要求し、即座にサブドメインを制御して、信頼されたブランドの下でフィッシング攻撃を開始したり、誤情報を拡散したりできます。
数千のヒットがあるダングリングレコードは、サブドメイン乗っ取りの高優先度リスクを提示し、脅威を即座に評価し軽減するための即座の修復を必要とします。
DNSチェッカーの2段階プロセス
私たちのDNSチェッカーは、これらのインサイトを生成するために2段階のプロセスを使用します：
ステップ1：アクティブインサイト検出
チェッカーは、スキャンを開始するメッセージを受け取るとすぐに検証を開始します。
ステップ2：コンテキスト強化
インサイトが生成されると、チェッカーは顧客がセキュリティインサイトの影響を理解するのに役立つ、インサイトに関連する関連コンテキストデータを収集します。
ダングリングDNSレコードインサイトの生成プロセス
関与する2段階のプロセスに焦点を当てて、ダングリングDNSレコードインサイトがどのように生成されるかを詳しく探ってみましょう。
フェーズ1：アクティブ検証
IPアドレスを指すDNSレコードは、背後のサーバーが数ヶ月前に廃止されていても、紙面上では完全に有効に見えることがよくあります。リスクが実際のものかどうかを確認するため、私たちのエンジンはネットワークの外に出て、リアルタイムで宛先を調査する必要があります。
実行されるチェックは次のように分類できます：
デッドサーバーチェック（A/AAAAレコード）
IPアドレスを直接指すレコードについて、宛先がまだアクティブかどうかを検証します。私たちのエンジンは専用のエグレスプロキシを起動して、HTTPとHTTPS経由でオリジンへの接続を試行します。この特別なゲートウェイを使用することで、実際のユーザーがCloudflareのネットワークの外部から接続する方法をシミュレートします。
接続がタイムアウトするか、サーバーが「404 Not Found」エラーを返す場合、リソースが死んでいることを確認します。これにより、DNSレコードが「ダングリング」、つまり空き地を指すライブ標識であることが証明されます。
乗っ取りチェック（CNAMEレコード）
ドメインエイリアス（CNAME）は、ヘルプデスクやストレージバケットなどのサードパーティサービスにトラフィックを委任することがよくあります。そのサービスをキャンセルしてもDNSレコードを削除し忘れると、攻撃者が要求できる「ダングリング」リンクを作成します。
これらを見つけるため、私たちのエンジンは3段階のプロセスを実行します：
- チェーンの追跡：CNAMEレコードを再帰的に解決して最終的な宛先を見つけます（例：my-bucket.s3.amazonaws.com）
- プロバイダーの特定：その宛先がAWS、Azure、Shopifyなどの既知のクラウドサービスに属するかどうかをチェックします
- 空室の確認：各クラウドプロバイダーは、リソースが存在しない場合に特定のエラーパターンを返します（例：S3の「NoSuchBucket」）。宛先URLを調査し、これらのパターンと照合してリソースが要求可能かどうかを確認します
私たちのエンジンがリソースが解放されているがDNSレコードが残っていることを検出した場合、攻撃者がサブドメインを乗っ取る前にレコードを削除するよう促すインサイトを作成します。
フェーズ2：コンテキスト強化
レコードが壊れていることが検証されると、より良いアクションを取るのに役立つ必要なコンテキストをインサイトに追加します。チェッカーは必要なコンテキストを収集するために異なるシステムに接続します。
ダングリングインサイトについて、私たちは3つの重要な次元に焦点を当てています：
トラフィック量（影響）
私たちのグローバルClickHouseクラスターは情報の宝庫です。レコードが実際に使用されているかどうかを理解するため、チェッカーは私たちのグローバルClickHouseクラスターにクエリを実行して、過去7日間のそのレコードに対するDNSクエリの総数を合計します。
この貴重なコンテキストにより、修復の優先順位を付けることができます。0クエリのレコードは時間があるときに修正できますが、10,000クエリのレコードは即座にパッチを当てる必要があるアクティブな脆弱性です。
ClickHouseへのクエリは次のようになります：
SELECT query_name, sum(_sample_interval) as total FROM <dnslogs_table>