TLS証明書透明性ログの監査

TLS証明書透明性ログの監査 は何をしますか？

使用するタイミング

• 所有ドメインに対する未知の認証局による不正または予期しない証明書発行を監視する場合
• 公開CTログに記録された証明書を通じてサブドメインや隠れサービスを発見する場合
• 似たようなドメイン証明書（タイポスクワッティング、ホモグラフ攻撃）を使用するフィッシング基盤を検出する場合
• ブラウザポリシーで要求される通り、発行されたすべての証明書がCTログに表示されているかを検証することで、認証局のコンプライアンスを監査する場合
• 新しい発行に対するアラートを含む、セキュリティ運用パイプラインに継続的な証明書監視を組み込む場合

使用しないでください：認証局への攻撃や妨害、レート制限や利用規約に違反するCTログのスクレイピング、DNS検証による結果の裏付けなしでのサブドメイン列挙の唯一の方法としての使用。

前提条件

• Python 3.10以上、requests、cryptography、pyOpenSSLライブラリがインストールされていること
• crt.sh（HTTPS）および公開CTログサーバーへのネットワークアクセス
• 監視するドメインのリスト（所有ドメイン、ブランドのバリエーション、タイポスクワット候補）
• 新しい証明書発見時のアラート通知用のSMTP認証情報またはWebhook URL
• X.509証明書構造とTLS証明書チェーン検証の基本的な理解

ワークフロー

ステップ1：ドメインインベントリとベースライン

監視対象ドメインの初期証明書インベントリを構築します：

• 監視範囲の定義：所有するすべてのルートドメイン、登録ブランド名、既知の子会社をリストアップします。包括的なサブドメインカバレッジのためにワイルドカードパターン（%.example.com）を含めます。
• crt.shへの履歴証明書クエリ：crt.sh JSON APIを使用して、各ドメインの既知のすべての証明書を取得します。APIエンドポイントhttps://crt.sh/?q=%.example.com&output=jsonは、ワイルドカードパターンに一致する証明書を返し、issuer_ca_id、issuer_name、common_name、name_value、not_before、not_after、serial_numberなどのフィールドを含みます。
• ベースラインデータベースの構築：初期の証明書セットをローカルのSQLiteデータベースに保存します。カラムには証明書ID、ドメイン、発行者、有効期間、SAN（サブジェクト代替名）、初回検出タイムスタンプを含めます。このベースラインにより、既知の証明書に対するアラートを防止します。
• 許可された認証局の特定：ベースラインから、ドメインに対して正当に証明書を発行した認証局のセットを抽出します。このセットに含まれないCAからの将来の発行は、高優先度アラートをトリガーします。
• サブドメインのマッピング：すべての証明書のname_valueフィールドからすべての一意のサブドメインを抽出し、初期サブドメインインベントリを構築します。

ステップ2：継続的なCTログ監視

新しい証明書発行のための継続的な監視を設定します：

• crt.shへの定期的なポーリング：一定間隔（15〜60分ごと）でcrt.sh APIにクエリを実行し、新しい証明書を取得します。exclude=expiredパラメータを使用して、現在有効な証明書に焦点を当てます。結果をベースラインデータベースと比較して新しいエントリを特定します。
• 証明書詳細の解析：新しい証明書ごとに、完全なSANリスト、発行者チェーン、有効期間、鍵タイプとサイズ、CTログSCT（署名付き証明書タイムスタンプ）詳細、証明書フィンガープリント（SHA-256）を抽出します。
• 事前証明書の検出：CTログには事前証明書（最終発行前に提出された毒入り証明書）が含まれます。これらは証明書が発行されようとしているがまだアクティブでない可能性があることを示す早期警告として追跡します。
• CTログ署名付きツリーヘッド（STH）の監視：高度な監視のために、CTログサーバーに直接クエリを実行して最新のSTHを取得し、連続するツリーヘッド間の一貫性証明を検証します。不整合はログの不正行為（分割ビュー攻撃）を示します。
• レート制限への配慮：クエリ間隔を空け、レスポンスをキャッシュすることでcrt.shのレート制限を尊重します。HTTP 429レスポンスには指数バックオフを実装します。大量監視の場合は、crt.sh:5432でcrt.shのPostgreSQLインターフェースに直接クエリすることを検討します。
• Atom/RSSフィードの代替：軽量な監視のためにcrt.shのAtomフィードを購読します：https://crt.sh/atom?q=%25.example.comは新しいログエントリのリアルタイム通知を提供します。

ステップ3：CTデータを介したサブドメイン発見

証明書透明性データで見つかったサブドメインを抽出して検証します：

• ワイルドカード展開：ワイルドカードSAN（*.dev.example.com）を持つ証明書は、DNSゾーンファイルに存在しない可能性のあるサブドメインの存在を明らかにします。親ドメインをさらなる列挙のターゲットとして記録します。
• 履歴証明書マイニング：exclude=expiredパラメータなしでcrt.shにクエリを実行し、DNSでまだ解決する可能性のある期限切れ証明書からサブドメインを見つけます。これらはサブドメイン乗っ取りに対して脆弱な可能性のある過去のインフラストラクチャを表します。
• DNS検証：発見されたサブドメインごとに、DNS解決（A、AAAA、CNAMEレコード）を実行してサブドメインが現在アクティブかどうかを判断します。既知のIP範囲と相互参照してシャドーITや不正なサービスを特定します。
• タイポスクワット検出：監視対象ドメインの順列（ビットスクワッティング、ホモグラフ、挿入、省略、転置、キーボード隣接置換）を生成し、これらのバリエーションに対して発行された証明書をCTログにクエリします。タイポスクワットドメインの証明書は、フィッシングインフラストラクチャを強く示します。
• 重複排除とエンリッチメント：発見されたサブドメインを正規化（小文字化、末尾のドット削除）し、重複を排除し、WHOISデータ、IP地理位置情報、HTTPレスポンスヘッダーでエンリッチメントして調査の優先順位付けを行います。

ステップ4：証明書発行アラート

セキュリティ関連の証明書イベントに対するアラートルールを設定します：

• 未承認CAアラート：許可されたCAリストに含まれないCAによって証明書が発行された場合にトリガーされます。これは最も優先度の高いアラートであり、ドメインハイジャック、ドメイン検証のためのBGPハイジャック、または侵害されたCAを示す可能性があります。
• 新しいサブドメインアラート：証明書にこれまで見られなかったサブドメインのSANが含まれている場合にトリガーされます。これはシャドーITの展開や不正なサービスを捕捉します。
• ワイルドカード証明書アラート：新しいワイルドカード証明書の発行時にトリガーされます。ワイルドカード証明書は侵害された場合の影響範囲が広く、その発行は厳重に管理されるべきです。
• 短命証明書異常アラート：証明書の有効期間が異常に短い場合（24時間未満）にアラートします。これは組織の通常の証明書ライフサイクルから逸脱しており、Let's Encryptの悪用や自動化されたフィッシングインフラストラクチャを示す可能性があります。
• 有効期限警告：CTログデータのnot_afterフィールドに基づいて、重要なサービスの証明書が期限切れに近づいている場合（30日、14日、7日前）にアラートします。
• アラート配信：メール（SMTP）、Slack Webhook、PagerDutyを介してアラートを送信するか、既存のセキュリティ監視との統合用にSIEM互換のJSONログ形式に書き込みます。

ステップ5：CTログ整合性検証とレポート作成

ログの整合性を検証し、コンプライアンス証拠を作成します：

• 署名付きツリーヘッド（STH）監視：get-sth APIエンドポイントを介して、監視対象の各CTログから最新のSTHを取得します。STHにはツリーサイズと署名付きタイムスタンプが含まれます。ログの公開鍵を使用して署名を検証します。
• 一貫性証明の検証：連続するSTH取得の間に、get-sth-consistencyを介して一貫性証明を要求し、ログが追加専用のままであること、およびエントリが変更または削除されていないことを検証します。
• 証明書インベントリレポート：監視対象ドメインに対して発行されたすべての証明書の完全なインベントリを作成し、発行者ごとにグループ化し、有効性ステータスと鍵強度メトリクスを含めます。
• CA多様性分析：組織に対して証明書を発行するCAの数を報告し、統合の機会と単一障害点を特定します。
• コンプライアンス証拠：PCI-DSS、SOC 2、または同様のフレームワークの対象となる組織の場合、CT監視ログは証明書ライフサイクル管理と不正発行検出機能の証拠を提供します。

主要な概念

用語	定義
証明書透明性（CT）	認証局が発行したすべての証明書を公開監査可能な追加専用ログに記録することを要求するオープンフレームワーク（RFC 6962）。ドメイン所有者は不正な発行を検出できます
署名付き証明書タイムスタンプ（SCT）	証明書が最大マージ遅延（通常24時間）以内にCTログに含まれるという約束。ブラウザは証明書を信頼する前に複数のログからのSCTを要求します
マークルツリー	CTログで使用される暗号化データ構造。リーフノードは証明書ハッシュ、親ノードはその子のハッシュであり、効率的な一貫性証明と包含証明を可能にします
事前証明書	最終発行前にCTログに提出される証明書。毒入り拡張（OID 1.3.6.1.4.1.11129.2.4.3）を含み、TLSには使用できませんが、ログ内での位置を確保します
crt.sh	Sectigoが運営する無料のWebサービス。すべての主要なCTログからの証明書を検索可能なPostgreSQLデータベースに集約し、WebとAPIの両方のアクセスを提供します
サブドメイン乗っ取り	サブドメインのDNSレコードが廃止されたサービス（クラウドプロバイダー、CDN）を指しており、攻撃者がそれを乗っ取ることができる脆弱性。期限切れのCT証明書を通じて発見可能になります
最大マージ遅延（MMD）	CTログがSCTを返した後、提出された証明書をマークルツリーに組み込むための最大時間（通常24時間）
CAAレコード	ドメインに対して証明書を発行することを許可されたCAを指定するDNS認証局認可レコード。CT監視はCAAポリシーの違反を検出します

ツールとシステム

• crt.sh：プライマリCTログアグリゲーター。https://crt.sh/?q=<query>&output=jsonでJSON APIアクセスを提供し、ワイルドカードクエリ、IDフィルタリング、証明書詳細の取得をサポートします
• ct-woodpecker：Let's EncryptのオープンソースCTログ監視ツール。PrometheusおよびGrafanaと統合して、ログの健全性と一貫性の運用監視を行います
• certspotter：SSLMateのCTログ監視ツール。新しく発行された証明書を監視し、通知を送信します。ホスティングサービスまたはセルフホスト型ツールとして利用可能です
• Google Argon / Xenon / Icarus：Googleが運営するCTログ。最も広く使用されているものの一つで、それぞれのログURLでRFC 6962 APIを介してクエリ可能です
• OpenSSL：証明書詳細の解析、チェーンの検証、CT監視を通じて取得した証明書からのSANリストの抽出のためのコマンドラインツール

一般的なシナリオ

シナリオ：金融サービス会社の不正証明書発行の検出

コンテキスト：銀行がプライマリドメイン（bank.example.com）を監視しており、CTログを介して、使用したことのないCAによってsecure-login.bank.example.comをカバーする証明書が発行されたことを発見します。このサブドメインはDNSに存在しません。

アプローチ：

1. CT監視エージェントが、crt.shの結果でsecure-login.bank.example.comに対する「FreeSSL CA」からの新しい証明書を検出します。これは許可されたCAリスト（DigiCert、Sectigo）に含まれていません
2. 未承認CA + 新しいサブドメインとしてアラートが発火し、CTログエントリから15分以内にセキュリティチームにエスカレーションされます
3. 証明書を調査：公開鍵を抽出し、HTTP-01またはDNS-01チャレンジを介してドメインが検証されたかを確認し、発行組織のWHOISを照会します
4. secure-login.bank.example.comのDNSルックアップにより、銀行が使用していないホスティングプロバイダーのIPアドレスに解決されることが判明します。これは攻撃者のインフラストラクチャであることを確認します
5. インシデント対応を開始：FreeSSL CAに証明書の失効を要求し、ドメイン悪用報告を提出し、IPをブロックリストに追加し、フィッシング対策チームに通知します
6. CAA DNSレコードを実装します（`bank.example.com. CAA 0 issue