「クラウドの海」で情報漏洩を防ぐ：CASBのDLPエンジンと泥臭いチューニングの現場
ネットワークエンジニアとして数々の現場を渡り歩いてきたが、最近のトレンドである「境界防御の消失」は、かつてのファイアウォール全盛期を知る人間にとっては、ある種の心地よい緊張感がある。
社内ネットワークという「聖域」が消え、ユーザーはカフェのWi-Fiから直接SaaSにアクセスする。この世界で、機密データが誤送信されるのを防ぐ最後の砦が CASB (Cloud Access Security Broker) だ。特にその心臓部である DLP (Data Loss Prevention) エンジンは、ただの「フィルタリング」ではなく、データの中身を理解しようとする執念の塊と言える。
今回は、このCASBのDLPが裏側でどう動いているのか、正規表現（Regex）とフィンガープリンティングという二つの武器に焦点を当てて解説しよう。
—
1. CASBにおけるDLPの通信フロー：パケットはどこで止まるのか？
まず、技術的な勘所として「どこで検査が走っているか」を理解しておく必要がある。CASBがインラインモード（APIではなくプロキシ型）で稼働している場合、ユーザーのアップロードリクエストは一度CASBを経由する。
シーケンス概略
1. Client: POST /upload リクエストを発行。
2. CASB (Proxy): Content-Type: multipart/form-data を受領し、バッファリングを開始。
3. DLP Engine: バッファ上のペイロードをスキャン（正規表現マッチング ＋ ハッシュ照合）。
4. Decision:
- Allow: 検査通過後、SaaSへ転送。
- Block:
403 Forbiddenをクライアントへ返し、ログをSIEMへ送信。
この「バッファリング」こそが、実務上のボトルネックだ。巨大なファイルをアップロードしようとすれば、当然レイテンシが発生する。ここを考慮せずに「何でもかんでもDLPで舐める」設定をすると、現場のエンジニアは「クラウドが遅い！」というユーザーからのクレームに頭を抱えることになる。
—
2. 正規表現：クレジットカード番号を「仕留める」技術
DLPの基本は正規表現だ。しかし、ただ文字列を探すだけでは誤検知（False Positive）の山に埋もれる。
例えば、クレジットカード番号（PAN）を検出する場合。単純に \d{16} と書けば、ただの乱数も引っかかってしまう。現場で求められるのは、Luhnアルゴリズムのチェックや、周囲の単語（Visa, Card, Exp 等）との距離を考慮した「近接性ルール」の組み合わせだ。
Pythonによる検証ロジック例
CASBの設定ファイルで正規表現を書く前、まずはローカルで挙動を検証するのがプロの鉄則だ。
import re
# クレジットカード番号（単純な16桁）のサンプルRegex
# 実際にはLuhnチェック用のライブラリを併用するのが賢い
cc_pattern = re.compile(r'\b(?:\d[ -]*?){13,16}\b')
def scan_text(data):
matches = cc_pattern.findall(data)
# ここに「前後にクレジットカードに関連する単語があるか？」という判定を加える
if matches:
print(f"警告: 機密情報が含まれています: {matches}")
return False # ブロック処理へ
return True
# テストデータ
sample_data = "私のカード番号は 1234-5678-9012-3456 です。"
scan_text(sample_data)—
3. フィンガープリンティング：ドキュメントの「指紋」で防ぐ
正規表現が「パターン」なら、フィンガープリンティングは「特定のファイルそのもの」を監視する技術だ。
機密性の高い設計図や契約書をハッシュ化（SHA-256等）し、CASBに登録しておく。ユーザーがアップロードしようとしたファイルのハッシュ値が登録済みリストと一致すれば、たとえファイル名を変えていても即座にブロックする。
cURLを使ったアップロードテスト
CASBのデバッグ時、実際にファイルアップロードを模倣して挙動を確認する際は、curl が最も信頼できる。
# 検査対象のファイルをCASBを通る経路でアップロードするシミュレーション
curl -v -X POST https://proxy.your-casb.com/api/v1/upload \
-H "Authorization: Bearer <TOKEN>" \
-F "file=@sensitive_document.pdf" \
-o result.json
# 戻り値が 403 であれば、DLPポリシーが正しく動作している証拠だ。
# ログには 'DLP_Violation_ID: 12345' のようなヘッダーが含まれるはず。—
4. 現場のエンジニアへのアドバイス：運用を成功させるためのTips
DLPの導入で最も避けるべきは「厳しすぎて業務を止めること」と「緩すぎて漏洩すること」のバランスを崩すことだ。
1. 監査モードから始める:
いきなりブロック設定を入れるのではなく、まずは「検知のみ（Audit）」モードで数週間ログを回せ。現場でどのような正規表現が誤検知を起こしているか、実際のデータを見てチューニングする期間が不可欠だ。
2. 例外設定の設計:
特定のSaaS（例：経理用ツール）だけは、特定のデータ形式を許可するなど、粒度の細かいポリシー設計をAPI経由で自動化しておくこと。手作業の設定変更は、必ず設定ミスという名の爆弾を埋め込む。
3. パフォーマンスの監視:
Fetch API 等を用いたフロントエンドのタイムアウト値も意識しよう。DLPエンジンが重い処理を行っている間、ブラウザ側で Timeout が発生するような設計は避けるべきだ。
まとめ
CASBのDLPは、魔法の杖ではない。正規表現の精度とフィンガープリンティングの管理、そして何より「ユーザーの利便性とセキュリティのトレードオフ」を泥臭く調整し続けるエンジニアの努力によって初めて機能するものだ。
次回の記事では、このDLPのログをSIEMへ流し込み、SOCチームがいかにしてインシデントを自動トリアージするか、その実践編をお届けする予定だ。現場のエンジニア諸君、今日もお互いパケットの海をうまく渡っていこう。
コメント