シャドーITの深淵を覗く：CASBで制御不能な「クラウドの闇」を可視化・遮断する実務作法
ネットワークの最前線で戦うエンジニア諸君、今日もパケットの海を泳いでいるか？
境界防御という概念が過去のものとなり、トラフィックがオンプレミスからクラウドへ、そして個人のデバイスへと分散した今、「社内ネットワークを守れば安泰」という時代は完全に終わった。特に頭の痛いのが、情シスが関知しない「シャドーIT」だ。従業員が独断で契約したSaaSに、機密情報やマルウェアを無造作にアップロードする。この穴を塞がない限り、どれだけ堅牢なファイアウォールを積んでも意味がない。
今回は、この混沌を制御するための鍵となる「CASB（Cloud Access Security Broker）」について、現場の視点から深掘りしていこう。
—
CASBが介入する「見えない境界線」の仕組み
CASBは、ユーザーとクラウドサービス（SaaS）の間に立ち、プロキシとして振る舞うことで通信を制御する。特に「インライン型」と呼ばれる構成では、ユーザーがSaaSへ送信するHTTPリクエストを横取りし、リアルタイムで検査を行う。
通信シーケンスのリアルな挙動
ユーザーが PUT メソッドでファイルをアップロードする際、CASBは以下の挙動をとる。
1. セッションの奪取: クライアントは本来のSaaS宛ではなく、CASBのプロキシへ TLS 接続を行う。
2. TLS終端と復号: CASBはサーバー証明書を偽装（あるいは信頼されたルート証明書を利用）し、通信を復号する。ここで初めてペイロードの中身が露わになる。
3. ポリシー検査: Content-Type や Content-Disposition、そしてファイルハッシュを検査。
4. アクション実行: 不正なファイルであれば 403 Forbidden を返し、通信を強制遮断する。
—
現場で役立つ：API経由の不正アップロードを検知するPython実装
多くのCASBはログをJSON形式でSIEMに飛ばしてくれるが、独自に挙動を検証したい場合や、特定SaaSへのアップロードをシミュレートする際は、Pythonでパケットを投げることが多い。
以下は、CASBを通した際に「不正なファイル拡張子」や「スキャン対象外の通信」をどう再現するかを示すサンプルコードだ。
import requests
# CASBのプロキシ経由でSaaSへファイルをアップロードする想定のデバッグスクリプト
proxy_url = "http://casb-proxy.corporate.internal:8080"
target_saas = "https://api.cloud-storage.example.com/v1/upload"
proxies = {
"http": proxy_url,
"https": proxy_url,
}
# 悪意あるファイルを装ったテストペイロード
payload = {'file': ('malware.exe', 'This is not a real virus', 'application/x-msdownload')}
try:
# CASBがこのリクエストを捕捉し、ポリシー違反であれば403を返すはず
response = requests.post(target_saas, files=payload, proxies=proxies, verify='/path/to/casb-root-ca.pem')
if response.status_code == 403:
print("【成功】CASBにより通信がブロックされました。")
else:
print(f"【注意】ブロックされませんでした。ステータスコード: {response.status_code}")
except requests.exceptions.ProxyError:
print("【障害】プロキシとの接続に失敗しました。CASBの稼働状況を確認してください。")—
トラブルシューティング：現場でハマる「CASBの罠」
エンジニアがCASBを導入して必ず直面するのが「SSL/TLS復号によるトラブル」だ。
1. 証明書エラーの泥沼
クライアント端末にCASBのルート証明書がインポートされていない場合、全てのSaaS通信で ERR_CERT_AUTHORITY_INVALID が発生する。ブラウザなら警告で済むが、APIクライアントやコマンドラインツール（curl など）は容赦なく接続を断つ。
デバッグのヒント:
curl を使う際は -k（insecure）オプションで一時的に回避できるが、本番環境では必ずCA証明書を指定すること。
# 証明書エラーを回避してCASBを通した通信テスト
curl -v -x http://casb-proxy.corporate.internal:8080 \
--cacert ./casb-ca.pem \
-F "file=@malware.exe" \
https://api.cloud-storage.example.com/v1/upload2. パフォーマンスのボトルネック
巨大なファイルをアップロードする際、CASBが全てのパケットをメモリ上でスキャンすると、ネットワークが激しく遅延する。これを避けるには、CASB側で「ファイルサイズによるスキャン除外ポリシー」を設定する必要がある。すべての通信を丸裸にするのではなく、「リスクの高い通信」にリソースを集中させるのが、凄腕エンジニアのチューニング術だ。
—
最後に：防御は技術だが、運用は文化である
CASBは魔法の杖ではない。どれだけ強力なツールを入れても、現場のエンジニアがポリシーを理解していなければ、設定は形骸化する。
「なぜこのファイルをアップロードしてはいけないのか？」
「この通信がなぜブロックされたのか？」
こうしたログを可視化し、開発チームと対話することこそが、真のセキュリティインフラを構築する第一歩だ。ツールに依存するのではなく、パケットが流れる先にある「リスク」を想像する力を養ってほしい。
次回の記事では、CASBログをSplunkやELKスタックで解析し、ランサムウェアの兆候を検知するダッシュボード構築術について解説する予定だ。現場からは以上だ。質問があればコメント欄まで。
コメント