SASEの「守護神」CASBを出し抜くデータたち：難読化・エンコードと戦うDLPの舞台裏
現場でインフラを叩いていると、「CASBのDLP（Data Loss Prevention）がなぜかカード番号を検知してくれない」「逆に、ただのログファイルを個人情報と誤認してアラートの嵐になる」という壁にぶつかることはないだろうか。
ゼロトラストアーキテクチャの要であるSASE（Secure Access Service Edge）において、CASB（Cloud Access Security Broker）はクラウドへのアクセスのゲートキーパーだ。しかし、攻撃者や悪意ある内部者は、DLPのシグネチャをすり抜けるために様々な「隠れ蓑」を用意している。今回は、CASBのDLPエンジンが直面する、少し泥臭いエッジケースの話をしよう。
CASBのDLPエンジンが「見ている」もの、見ていないもの
CASBのDLPエンジンは、基本的に正規表現（Regex）をベースに機密情報をスキャンする。しかし、Web API経由の通信において、データは往々にしてそのままの姿では流れてこない。
例えば、Content-Type: application/json の中にBase64でエンコードされたバイナリが含まれていたり、JSONのキー名や値を細工して難読化されていたりする場合だ。CASBは万能ではない。すべてのリクエストに対して再帰的なデコード処理を無限に行えば、レイテンシでネットワークは麻痺するからだ。
通信フローにおけるデコードの限界
典型的な通信フローを見てみよう。
1. Client -> POST /api/upload (Base64 data) -> CASB
2. CASB -> DLPエンジンによるスキャン
3. CASB -> Cloud Storage
ここで問題になるのは、CASBが「どこまで深追いするか」という点だ。多くのCASBは、HTTPヘッダーの Content-Transfer-Encoding や Content-Encoding を確認し、標準的な gzip や base64 は解凍・デコードする。しかし、アプリケーション層で独自の難読化（例えば、文字の置換や、JSONのネストを極限まで深くする等）を行われると、DLPエンジンは正規表現にマッチさせることができず、スルーしてしまう。
実践：Base64と難読化を仕掛けられた時の挙動
例えば、クレジットカード番号（PAN）をBase64で包んで送るケースを考えてみる。
import base64
# クレジットカード番号（テスト用）をBase64化
pan = "4111-1111-1111-1111"
encoded_pan = base64.b64encode(pan.encode('utf-8')).decode('utf-8')
# 攻撃者の意図：そのまま流すとCASBに引っかかるのでエンコードする
payload = {"data": encoded_pan}
print(payload)
# 出力: {'data': 'NDExMS0xMTExLTExMTEtMTExMQ=='}このデータを curl で投げる場合、CASBがBase64のデコードをサポートしていなければ、正規表現によるパターンマッチングは空振りに終わる。
# CASB配下で実行
curl -X POST https://cloud-storage.example.com/upload \
-H "Content-Type: application/json" \
-d '{"data": "NDExMS0xMTExLTExMTEtMTExMQ=="}'もし君が管理するCASBが、Base64のデコードに対応していない、あるいは設定が不十分であれば、この通信は「安全」として通過してしまう。これが「難読化による検知回避」の正体だ。
誤検知（False Positive）を抑制するための「チューニング」の極意
一方で、過剰な検知も現場の運用を疲弊させる。特に、ログの出力やデバッグ情報の断片が、偶然クレジットカードのフォーマット（Luhnアルゴリズムのチェック等）に合致してしまうケースは後を絶たない。
ここで重要になるのは、「コンテキストの絞り込み」だ。
1. 正規表現の「境界」を厳密にする
単なる数字の羅列を探すのではなく、前後の文字列を考慮したLookaround（肯定先読み・後読み）を駆使する。
- 甘い正規表現:
\d{4}-\d{4}-\d{4}-\d{4}（これだとシリアル番号も拾ってしまう） - 硬い正規表現:
(?i)(?:card|cc|number|pan)\s*[:=]\s*(\d{4}-\d{4}-\d{4}-\d{4})（キー名を含めることで誤検知を激減させる）
2. コンテキスト・アウェアネスを活用する
多くのCASB設定画面では、DLPルールに対して「適用するファイル拡張子」や「送信元IPアドレス」、「特定のユーザグループ」を設定できる。
# CASBのDLPポリシー設定（擬似的な設定例）
rule:
name: "Strict_Credit_Card_Detection"
regex: "(?i)(?:card|cc|number|pan)\s*[:=]\s*\d{4}-\d{4}-\d{4}-\d{4}"
# 誤検知対策：社内の特定の管理用サーバーからの通信は除外する
exception:
source_ip_range: "10.0.50.0/24"
file_type: ["log", "txt"]
action: "block_and_alert"凄腕エンジニアからのアドバイス：デバッグの視点
もし君がこの問題に直面したら、まずやるべきは「CASBのログ出力詳細レベルを上げる」ことだ。
多くの商用CASBでは、DLPで検知した際、どの正規表現に引っかかったのか、どの部分が「機密情報」と判定されたのかをログに残すオプションがある。それを見れば、自社のアプリケーションがどのようなフォーマットでデータを送っているのか、CASBがどこまで深読みできているのかが一目瞭然だ。
「技術は魔法ではない」といつも自分に言い聞かせてほしい。パケットの中身を覗き、エンコードの層を一枚ずつ剥がしていく。そうした地道な確認の繰り返しこそが、強固なゼロトラスト環境を作る唯一の近道だ。
現場の君たちの健闘を祈る。また、技術の深淵で会おう。
コメント