【テクニカル・上級編】Datadog Sensitive Data Scannerによる個人情報・機密情報の自動マスクとコンプライアンス対応 – 運用監視・オブザーバビリティ活用バイブル

ログは「汚染」されるもの――Datadog Sensitive Data Scannerによる境界防衛の極意

オブザーバビリティの世界において、最も恐ろしいのは「見えない障害」ではない。「見えてはいけないものが見えてしまう」というコンプライアンスの死だ。

開発者がいかに注意深くログ設計を行っても、予期せぬ例外スタックトレースや、外部ライブラリのデバッグ出力の中にクレジットカード番号(PAN)やAPIキーが混入するリスクをゼロにすることは不可能だ。人間を信じるな、システムを信じろ。これが大規模分散システムの鉄則である。

今回は、Datadogの「Sensitive Data Scanner(SDS)」を単なるコンプライアンスツールではなく、「データ・パイプラインの検閲官」として機能させるための、アーキテクト視点の深淵を解説する。

—

1. SDSのアーキテクチャ:なぜ「事前」検閲が必要なのか

SDSは、データがインデックスされる前のIngestionパイプラインで動作する。後付けのマスク処理とは次元が違う。一旦インデックスされたログを後からマスキングするのは、一度流出した情報を回収するようなものだ。

  • Ingestion-Time Filtering: パフォーマンスへの影響を最小限に抑えるには、Agent側の `scrub_sensitive_data` 設定と、Datadog側でのSDSの役割分担を明確にする必要がある。
  • 計算量との戦い: 正規表現(Regex)は強力だが、複雑なパターンはCPUを食う。SDSのルールは「優先度の高い順」に、かつ「短絡評価」されることを念頭に置け。

2. 実践:IaCによる完全自動化とライフサイクル管理

ポチポチとGUIで設定する? それは運用ではない、ただの作業だ。すべてのスキャンルールはTerraformで管理し、CI/CDのガバナンス下に置け。

Sensitive Data ScannerのルールをTerraformで定義する
resource “datadog_sensitive_data_scanner_group” “compliance_group” {
name = “Global Security Policy”
is_enabled = true
description = “全サービス共通のPII/機密情報マスクルール”
}

resource “datadog_sensitive_data_scanner_rule” “mask_api_keys” {
group_id = datadog_sensitive_data_scanner_group.compliance_group.id
name = “Mask AWS Secret Keys”
is_enabled = true
pattern = “(AKIA[0-9A-Z]{16})” # AWSアクセスキーのパターン
text_replacement {
type = “replacement_string”
value = “”
}
# パフォーマンス向上のため、特定のログストリームに絞る
included_keywords = [“AWS”, “SECRET”, “KEY”]
}

極意: `included_keywords` を活用せよ。全ログをスキャン対象にするとコストとレイテンシが跳ね上がる。機密情報が出現しそうなキーワードをトリガーにすることで、計算負荷を桁違いに下げられる。

3. 現場で震えるほど役立つ「ハック」

A. カスタム正規表現による「境界値」の守り方

単純なカード番号だけでなく、自社独自のID体系やトークンフォーマットをRegexで記述する際は、必ずLookahead/Lookbehind(先読み・後読み)を駆使し、文脈(周辺のキー名など)を含めて検知せよ。誤検知(False Positive)による業務ログの破壊は、障害対応時に致命傷となる。

B. APIによる動的ルールの投入

緊急時のAPIキー漏洩発覚時、管理画面を操作している暇はない。以下のスクリプトをCI/CDのトリガーに組み込み、数秒で全環境に「緊急マスキングルール」を適用できるようにしておくべきだ。

!/bin/bash
緊急事態発生時、特定の文字列パターンを即座に無効化するスクリプト
curl -X POST “https://api.datadoghq.com/api/v2/sensitive-data-scanner/rule” \
-H “DD-API-KEY: ${DD_API_KEY}” \
-H “DD-APPLICATION-KEY: ${DD_APP_KEY}” \
-H “Content-Type: application/json” \
-d @- <4. コンプライアンスの先にあるもの

PCI DSSやGDPRの監査担当者は、「ログに個人情報が含まれていないこと」を証明しろと言ってくる。その際、SDSのログメトリクスを見せればいい。「インデックスされたデータは常に監査され、マスクされている」という履歴そのものが、最高のエビデンスになる。

パフォーマンスを最適化する最後の問い

  • ログ量: `DD_SCRUB_PATTERNS` でAgent側で捨てられるものは捨てているか?
  • スキャン効率: ルールの数は多すぎないか?(100個以上のルールは設計を見直せ)
  • コスト: SDSは課金対象だ。無意味なスキャンを減らすことこそが、真のアーキテクトの仕事である。

ログは「システムの呼吸」だ。そこに不純物が混ざればシステムは病む。SDSを使いこなし、クリーンなオブザーバビリティ環境を構築せよ。それは単なるセキュリティ対策ではなく、運用エンジニアとしての誇りを守る行為に他ならない。

タイトルとURLをコピーしました