2026年3月10日

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

16分で読了

この記事は以下でも利用可能です English、한국어.

このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。

長年にわたり、脅威に対する業界の答えは「可視性の向上」でした。しかし、コンテキストなしで可視性を高めることは、単なるノイズの増加につながります。現代のセキュリティチームにとって、最大の課題はもはやデータ不足ではありません。圧倒的に余剰であることです。ほとんどのセキュリティ担当者は、大量のダッシュボードをナビゲートし、さまざまなログをたどり、単一の、一見シンプルな質問に答えます。

一つの設定ミスを特定するために別のツールに切り替えを強いられ、インシデントを防ぐ機会を失ってしまいます。そこで当社は、刷新されたセキュリティ概要ダッシュボードを構築しました。事後対応型の監視から事前対応的な制御へと移行することで、防御者を強化するためにデザインされた単一のインターフェースです。

^{新しいセキュリティ概要ダッシュボード。}

ノイズから行動へ：セキュリティの概要を再考する

これまで、ダッシュボードは、発生しているすべてを表示することに重点を置いていました。しかし、多忙なセキュリティアナリストにとって、より重要な疑問は「今、何を修正する必要があるのか？」ということです。

これを解決するために、セキュリティアクションアイテムを導入します。この機能は、検出と調査の間の機能的なブリッジとして機能し、脆弱性を表面化するため、もはや脆弱性を探す必要はなくなります。効果的に選別できるように、項目は重要度によってランク付けされます：

重大：エクスプロイト防止に即時対応が必要な緊急リスク。
中程度：強力なセキュリティ体制を維持するために対処が必要な問題。
低：ベストプラクティスの最適化と強化の提案。

インサイトの種類（不審な活動や安全でない設定など）でフィルタリングすることで、組織が最も直面している特定の脅威に合わせたワークフローを調整することができます。

最も一般的な漏えいの原因の一つは、セキュリティツールの欠如ではなく、そのツールが一度も有効になっていない、または正しく設定されていないという事実です。これをコンフィギュレーションギャップと呼びます。

新しい検出ツールモジュールは、この死角を排除します。ネストされた設定ページでトラフィックが実際に検査されているかどうかを確認する代わりに、Cloudflareのセキュリティスタック全体の高レベルのステータスを単一の画面で表示します。

プライマリシールドはアクティブですか？それとも変動が高まる期間、「ログのみ」モードですか？
シャドーAPIを発見できていますか？それとも把握していないでしょうか？

これらのツールを、セキュリティアクション項目と直接表面化することで、「このツールはありますか？」から会話を移動させることができます。「このツールは今、積極的に保護しているか？」そして

概要は、その背後にあるデータが大切です。警告表示からソリューションへの移行をシームレスにするために、不審アクティビティカードの可視性を統合しました。これらのカードは現在、「セキュリティ概要」と「セキュリティ分析」ページの2つの戦略的な場所に掲載されています。

「概要」ページで「不審な活動」カードが気になる場合、手動で「分析」に移動してフィルタを再作成する必要はありません。カードをクリックすると、セキュリティ分析ダッシュボードに直接ディープリンクされ、関連するフィルターがすべて自動的に適用されます。これにより、インシデント対応を遅くする「タブ切り替え税」が排除され、ワークフローと応答時間を短縮することができます。

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

積極的な防御を維持するために、当社のエンジンは毎日1,000万件以上の実用的なインサイトを生成し、更新して、常に最新の保護を提供します。

このレベルでの運用には、2つの異なるエンジニアリング課題があります。1つ目は、大量のデータをシームレスに処理することのできる規模です。2つ目の、おそらくより困難な課題は、幅広さです。真のセキュリティは水平で、スタック全体にわたるものです。リスクと脆弱性を包括的に把握できる実用的なインサイトを生成するには、シンプルなSSL証明書から複雑なAIボット構成まで、すべてを検証する必要があります。

これを解決するために、より小さく、専用のマイクロサービスで構成されたシステムを構築し、私たちはこれをチェッカーと呼びます。各チェッカーは、DNSレコードなどスタックの特定の部分に対する専門家です。チェッカーの分散により、独立して拡張することが可能になり、スケジュールされた設定チェックと、イベントが発生した時にリスクをフラグを立てるリアルタイムリスナーの2つの方法でシステムに接続することができます。

1. スケジュールされたチェック: 詳細な検査が必要なリスクに対して、このモードをデプロイします。これらは、チェッカーに実行させるタスクを定期的にプッシュするオーケストレーター（スケジューラー）によってトリガーされます。当社は、チェッカーの作業負荷を超並列システム全体に分散します。たとえば、DNSチェッカーに送信されるタスクは、「ゾーンxyz.comのDNS関連設定をすべてスキャンし、異常を発見してください」というものです。

チェッカーは、これらのタスクを独立して選択します。専門的なインテリジェンスを使用して、アセットや設定をスキャンします。DNSチェッカーの場合、専用のインテリジェントなルールを使用して、A/AAAA/CNAMEレコード、またはDMARC、SPFレコードである、ゾーンのすべてのDNSアセットと設定をスキャンします。

インサイトのライフサイクルは次のようになります：

メッセージを受信するとチェッカーが起動します。
チェッカーは、ゾーンまたはアカウントに関する関連アセット（DNSレコードなど）を収集します。
チェッカーは、CNAMEレコードがサーバーを指しているかどうかなど、アセットのステータスを確認するために、いくつかのチェックを実行します。
状態または設定が必要なしきい値を満たしていない場合、インサイトにフラグが立てられます。
次のチェック時に、インサイトが続くと、タイムスタンプが更新されます。
次回のチェック時にインサイトが修正された場合は、データベースから削除されます。

2. イベントハンドラー: チェッカーはスケジュールに沿って動作しますが、イベントハンドラーはリアルタイムで機能します。コントロールプレーンからの信号やイベントを受信します。

リアルタイムのルールセットインサイトのライフサイクルは次のようになります：

WAFルールの設定が変更されています。
変更の詳細を含むイベントはすぐにトリガーされます。
アクティブにリッスンしているルールセットハンドラーがアクションを開始します。
ハンドラは異常を検出します。たとえば、Cloudflareマネージドルールセットを有効にしているが、「ログのみ」モードのままになっている必要があります。
ハンドラーは、攻撃が記録されているがブロックされていないと推測します。
ハンドラーはインサイトを登録し、ダッシュボードで利用できるようにします。
設定が安全な設定に更新された場合、ハンドラーはインサイトをクリアにします。

ルールセットハンドラはリアルタイム性を備えているため、設定ミスにフラグを立てたり、即座に修正を確認することができます。

セキュリティの可視性とコンテキストに基づくインサイトを統合

お客様は一貫して、可視性以上のものを求めてきました。コンテキストも求めてきました。レコードが誤って設定されているという通知は便利ですが、話の半分にすぎません。即座に自信を持って行動をとるためには、防御者は「つまり、何なのか」を理解する必要があるのです。ビジネスへの影響と技術的な根本原因を含めこれに対処するために、検出エンジン用のコンテキストインサイトを開発しました。壊れたAレコードのトラフィック量などのデータを表面化することで、すべてのインサイトが行動への招待となるようにします。

コンテキストインサイトの旅は、DNSインサイトの深さをさらに深めることから始まります。単に壊れたレコードにフラグを立てるのではなく、追加のコンテキストやリアルタイムのトラフィックデータと交信的信号を相関させ、「理由」と「方法」を提供します。

ターゲットコンテキスト：レコードがどの削除されたリソース（古いS3バケットやクラウドインスタンスなど）を正確に識別します。
インパクトコンテキスト：壊れたレコードにアクセスしようとしているユーザー数が正確に表示されます。

「Dangling A/AAAA/CNAME record」インサイトを例として見てみましょう。

これらのインサイトを提供するには、ネットワークを通過する毎秒大量のデータを分析する必要があります。舞台裏で行われている作業を把握していただくために、次のことを行います：

当社のエンジンは毎週1億件以上のDNSレコードをスキャンしています。先週、当社のエンジンは100万件以上の滞留中のDNSレコードを特定しました。大半（97%）はDangling A/AAAAレコードで、残りの3%はDangling CNAMEレコードです。

31,000件の重複するCNAMEレコードのうち：

95%がMicrosoft Azureサービスを指します。
3% はAWS Elastic Cookies。

これは、サブドメイン乗っ取りの優先度の高い標的であることを示しています。攻撃者は、これらの放棄されたクラウドリソースを要求し、サブドメインを即座に制御して、フィッシング攻撃を仕掛けたり、信頼されているブランド名で誤った情報を拡散させたりする可能性があります。何千ものヒットが発生するレコードは、サブドメイン乗っ取りの優先度が高いリスクであり、脅威を即座に計測し、軽減するための即時修正が必要です。

当社のDNSチェッカーは、2段階のプロセスでインサイトを生成しています。

ステップ1：アクティブインサイト検出
- チェッカーは、スキャン開始のメッセージを受け取るとすぐに検証を開始します。このプロセスは、以前のセクションで説明されています。
ステップ2：コンテキストの強化
- インサイトが生成されると、チェッカーは、顧客がセキュリティインサイトの影響を理解するのに役立つ、インサイトに関連するコンテキストデータを収集します。

宙ぶらりんのDNSレコードインサイトがどのように生成されるのか、関係する2つのフェーズのプロセスに焦点を当てて、詳しく見ていきましょう。

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

IPアドレスを指すDNSレコードは、背後にあるサーバーが数か月前に破棄されていたとしても、紙上は完全に有効に見えることがよくあります。リスクが現実的なものであるかどうかを確認するために、エンジンはネットワークの外に出て、リアルタイムでその先を探る必要があります。実行されるチェックは、次のように分類できます：

停止中のサーバーチェック（A/AAAAレコード）：IPアドレスを直接指すレコードの場合、宛先がまだアクティブであるかどうかを確認します。Cloudflareのエンジンは、専用のエグレスプロキシをスピンアップして、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つの重要な側面に焦点を当てています：

トラフィック量（影響）CloudflareのグローバルClickHouseクラスターは、情報の宝庫です。レコードが実際に使用されているかどうかを確認するために、チェッカーはグローバルClickHouseクラスターにクエリーを実行し、過去7日間のそのレコードに対するDNSクエリーの合計を集計します。この貴重なコンテキストにより、修復の優先順位付けが可能になります。クエリーが0のレコードも、時間がある時に修正することができます。 10,000件のクエリを持つレコードは、アクティブな脆弱性であり、すぐにパッチを適用する必要があります。

Clickhouseへのクエリは次のようになります：

SELECT query_name,
       sum(_sample_interval) as total
  FROM <dnslogs_table_name>
 WHERE account_id = {{account_id}}
   AND zone_id = {{zone_id}}
   AND timestamp >= subtractDays(today(), 7)
   AND timestamp < today()
   AND query_name in ('{{record1}}', '{{record2}}', ...)
 GROUP BY query_name

クエリーは、「この特定の破損したレコードが、過去7日間にリアルユーザーによってリクエストされたのは何回ですか？」と尋ねます。

インフラストラクチャ所有者（標的） 宛先となるインフラストラクチャの所有者を把握することは、修復と重大度評価の両方に不可欠です。

IPレコード（A/AAAA）の場合：Cloudflare R2バケットからの最新のジオロケーションデータを使用し、メモリ内の高速ルックアップを実行することで、ネットワーク所有者（ASN）を特定します。機能しなくなったリソースがどこにあるか（例：「Google Cloud」と「DigitalOcean」など）が正確にわかるため、調査が迅速化されます。

CNAMEレコードの場合：特定のホスティングプロバイダー（AWS S3、Shopifyなど）を識別します。これによって、リスクレベルが決まります。レコードが、簡単に乗っ取られるプロバイダー（S3など）を指している場合、クリティカルとマークします。そうでない場合は、モデレートとします。

DNS TTL また、レコード構成から直接TTL（Time To Live）値も抽出します。

これは、修正の「遅れ」を示しています。高い有効期限（TTL）（例：24時間）で滞留しているレコードを削除すると、丸一日にわたって世界中のリゾルバーにキャッシュされたままになります。つまり、パッチを適用しても脆弱性は残ります。このことを知っておくことで、インシデント対応時の期待事項を管理することができます。

これからのこと

このエクスペリエンスはドメインレベルで開始されていますが、企業のお客様にとっては、一度に1つのドメインだけを管理するわけではないことは承知しています。当社のロードマップは、このインテリジェンスを次のアカウントレベルにもたらすことに重点を置いています。まもなくセキュリティチームは、全Cloudflareドメイン全体でセキュリティアクションアイテムを集約し、最も重大なリスクを優先順位付けして削除します。

セキュリティが追いつくゲームのように感じられるべきではありません。あまりにも長い間、アプリケーションセキュリティ管理の複雑さが、攻撃者に有利な立場にありました。特化型チェッカーとリアルタイムイベントハンドラーのアーキテクチャを通じて、潜在的リスクを検出し、重要なコンテキストで内容を豊かにすることで、防御者が迅速かつ正確に対応できるようにします。

新たな「セキュリティ概要」は、リスクデータを優先順位付けした戦略に変換する場所として、1日の出発点となります。今日、Cloudflareダッシュボードにログインして、新しいアプリケーションセキュリティ概要ページをご確認ください！