こんにちは！技術メディアの主筆ライターです。日々、ネットワークの奥深くを流れるパケットと格闘していると、「セキュリティって、本当に奥が深くて面白いな」と実感します。
今回は、最近のクラウド全盛期に欠かせない「CASB（キャスビー）」、そしてその中でも一番シビアで泥臭い「データ損失防止（DLP）」の裏側について、とことん優しく紐解いていきたいと思います。
「正規表現マッチング」「Base64」「エッジケース」……。なんだか文字面だけでコーヒーを飲みたくなるような難しそうなワードが並んでいますが、大丈夫です！ 一歩ずつ、身近な例えを交えながら一緒に理解していきましょうね。
—
1. そもそもCASBのDLPって、どんな「お仕事」をしているの？
皆さんは、会社で使っているクラウドストレージ（Microsoft 365やGoogle Workspace、Boxなど）に、うっかり重要なファイル（顧客のクレジットカード番号やマイナンバーなど）をアップロードしそうになった経験はありませんか？ あるいは「そんなミス、絶対に許されない！」と冷や汗をかいたことがあるかもしれません。
ここで登場するのが CASB です。CASBは、社内ネットワークとクラウドサービスの間にすっくと立ちふさがり、いわゆる「企業の門番」として通信を監視してくれます。
このCASBの中核機能の一つが DLP（データ損失防止） です。
DLPの働きを、身近な例えで考えてみましょう。あなたは国際郵便の巨大な仕分けセンターで働くベテランの検品スタッフです。ベルトコンベアを流れていく無数のダンボール箱を一つひとつチェックし、「中にクレジットカード番号などの機密情報が書かれた紙が入っていないか」を鋭い目でスキャンする役割を担っています。
このスキャンのときに大活躍するのが、「正規表現（Regular Expression）」というパターンのようなものです。
例えば、「数字が4桁ずつハイフンで区切られて4つ並んでいたら、それはクレジットカード番号かもしれないぞ！」といったルール（パターン）をあらかじめ決めておき、そのルールに一致する文字列がないかを高速で見つけ出すわけですね。
—
2. 悪知恵を働かせる「難読化」と、CASBの苦悩
しかし、世の中はそう単純ではありません。中には、意図的に（あるいはシステムの仕様で勝手に）その機密情報を隠そうとする「ちょっと困ったちゃん」たちがいます。
例えば、クレジットカード番号の数字をそのままダンボールに入れるのではなく、
- 「わざわざ文字と文字の間にスペースや特殊記号を挟んで、パッと見で分からないようにする（難読化）」
- 「文字データを全く別の意味不明な文字列に変換してしまう（Base64エンコードなどの技術）」
郵便配達の例えで言えば、宛先をわざと「鏡文字（裏返し）」で書いたり、完全に暗号化された古代文字で書いたりして、仕分けスタッフの目をくらまそうとするイタズラのようなものです。
素朴なDLP機能だと、「うーん、これはただの乱雑な文字列だな。問題なし！」とスルーしてしまい、結果的に大切な機密データがクラウドの海へ流出してしまう……。これが、セキュリティ事故につながる「エッジケース（想定外の隅っこで起きるトラブル）」の正体です。
—
3. CASBはどうやってこの「イタズラ」を見破るのか？
では、優秀なCASBのDLPは、この難読化やBase64エンコードされたペイロード（中身のデータ）に対してどう立ち向かっているのでしょうか？
答えはシンプルです。「怪しいダンボールを見つけたら、ベルトコンベアの途中で一旦ストップさせて、中身をキレイにほどいて（デコードして）からもう一度チェックする」のです。
特にBase64という仕組みは、Webの世界では非常によく使われる「バイナリデータをテキストとして安全に運ぶための梱包方法」にすぎません。CASBは、「おっ、この文字列はもしかしてBase64で包まれているな？」と勘繰り、自動的に元のテキストに解凍（デコード）してから、改めて先ほどの正規表現ルールを適用します。
ここで、実務でよく使われる「Base64デコードを行ってから正規表現でマイナンバーやクレジットカード番号を探し出す」簡単なPythonスクリプトのイメージを見てみましょう。コードの中のコメントもぜひ参考にしてくださいね。
import base64
import re
# 【設定】検知したいクレジットカード番号の正規表現パターン
# (4桁の数字 - 4桁の数字 - 4桁の数字 - 4桁の数字) の形式を狙う
CREDIT_CARD_PATTERN = r'\b\d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}\b'
def inspect_payload(payload_str):
"""
クラウドへ送信されるペイロード（データ）を受け取り、
通常テキストとBase64エンコードされた部分の両方を検査する関数です。
"""
print(f"[*] 検査を開始します: {payload_str}")
# 1. まずは通常のテキストのまま正規表現でチェック
if re.search(CREDIT_CARD_PATTERN, payload_str):
print("[!] 警告: 通常テキストからクレジットカード番号を検出しました！")
return True
# 2. 次に、もしかしてBase64で包まれているかもしれないのでデコードを試みる
try:
# 文字列をバイト列に変換してBase64デコード
decoded_bytes = base64.b64decode(payload_str.encode('utf-8'))
decoded_str = decoded_bytes.decode('utf-8', errors='ignore')
print(f"[*] デコード結果: {decoded_str}")
# デコードした文字列に対して、もう一度正規表現チェック！
if re.search(CREDIT_CARD_PATTERN, decoded_str):
print("[!] 警告: Base64エンコードされたペイロード内からクレジットカード番号を検出しました！")
return True
except Exception as e:
# Base64の形式になっていない等のエラーは無視してスルーする
pass
print("[+] 問題なし: 機密データは検出されませんでした。\n")
.return False
# --- テスト実行 ---
# パターンA: 通常のテキスト（一発で検知できる）
inspect_payload("私のカード番号は 1234-5678-9012-3456 です。")
# パターンB: Base64でエンコードされた機密データ ("MTIzNC01Njc4LTkwMTItMzQ1Ng==" は "1234-5678-9012-3456" のBase64)
# 普通のDLPなら見逃してしまうところを、CASBはデコードして暴き出します！
inspect_payload("MTIzNC01Njc4LTkwMTItMzQ1Ng==")このように、高度なCASB製品は、単に送られてきたデータを上からなぞるだけでなく、「必要に応じて一手間かけて中身をほどいてから吟味する」という賢いアプローチを取っています。
—
4. 誤検知（フォールポジティブ）との戦い
ここで終わらないのが、インフラ・セキュリティエンジニアの苦悩のしどころです。
「じゃあ、片っ端から何重にもデコードして、少しでも似た数字があればすべてブロックしちゃえば完璧じゃん！」と思われるかもしれませんが、それをやると今度は「誤検知（フォールポジティブ）」の嵐が巻き起こります。
例えば、開発者がソースコードの中でテスト用に使っている単なる「ダミーのUUID」や、3桁の数字が偶然4つ並んだだけの製品型番、あるいはログファイルのタイムスタンプの一部などを、DLPが「おっと、マイナンバー発見！ブロック！」と勘違いして止めてしまうのです。
これでは、現場の開発チームから「仕事ができないんだけど！」とクレームの嵐になってしまいますよね。セキュリティを厳しくしすぎると業務が止まり、緩くすると情報漏洩のリスクが高まる――この絶妙なバランスを取るのが、私たちエンジニアの腕の見せ所です。
誤検知を減らすための実務的なアプローチ
1. 文脈評価（コンテキスト分析）の導入
単に数字のパターンだけでなく、「その周辺に『カード』『有効期限』『CVV』といったキーワード（関連ワード）が同居しているか」をセットで判定します。
2. 除外リスト（ホワイトリスト）の活用
あらかじめ安全だと分かっている社内システムのドメインや、テスト用の特定フォーマットはスキャン対象外から除外する設定を丁寧にチューニングします。
—
まとめ
今回は、CASBのDLPにおける正規表現マッチングと、難読化・Base64エンコードされたペイロードに対するエッジケースの裏側についてお話ししました。
- CASBのDLPは単なる文字合わせだけでなく、裏で「デコード（解読）」という一手間をかけて巧妙なすり抜けを防いでいること
- しかし、厳しくしすぎると今度は「誤検知」という別のモンスターが現れること
セキュリティの現場は、こうした「イタチごっこ」の連続ですが、仕組みの本質を知っていれば怖くありません。「一歩ずつ理解していけば、どんな複雑なパケットの動きも必ずクリアに見えてくる」――この感覚を、ぜひ今後の実務や学習の中でも大切にしてみてくださいね。
それでは、また次回の技術コラムでお会いしましょう！
コメント