「境界」は死んだ。ならば、どう戦う？：コンテキストベースアクセス制御のリアル
「社内ネットワークにいれば安全」という神話は、数年前に葬り去られたはずだ。しかし、現場を歩いていると、いまだに「VPNを張れば万事解決」と考えている古参のネットワーク担当者に遭遇する。正直に言おう。VPNは、侵入者に社内ネットワークという「広大な遊び場」を提供するだけの脆弱な入り口になり得る。
今、我々が実装すべきは、アクセスが試みられるその瞬間に、あらゆる変数（コンテキスト）を計算し、「信じていいのか？」を問い続ける「ゼロトラスト」の思想だ。今回は、SASEとCASBが織りなす「コンテキストベースアクセス制御」の深淵に切り込む。
—
1. コンテキストベースアクセス制御の「計算式」
従来型のACL（Access Control List）は静的だ。IPアドレスが許可リストにあれば通す。これでは、盗まれた認証情報や、マルウェアに感染したデバイスからのアクセスを止められない。
現代のアクセス制御は、以下の変数を組み合わせてリアルタイムに「信頼スコア」を算出する。
- User Identity: 誰か？（MFAの状況は？）
- Device Posture: デバイスの状態は健全か？（パッチは最新か？ EDRは稼働しているか？）
- Location/Network: どこからか？（異常な地理的跳躍はないか？）
- Time/Behavior: いつもと違う時間帯ではないか？
これらが、SASEのゲートウェイでパケットを待ち受ける「判定エンジン」の材料となる。
—
2. 通信フロー：認証の裏で何が起きているか
ユーザーがWeb APIを叩くとき、裏側ではどのようなやり取りが発生しているのか。実は、この裏側にはOIDC（OpenID Connect）とCASBの判定ロジックが複雑に絡み合っている。
1. Request: ユーザーが api.production.internal へリクエストを送信。
2. Intercept: SASEゲートウェイがリクエストを傍受し、CASBへコンテキスト評価を依頼。
3. Challenge: デバイス証明書やブラウザのフィンガープリント、位置情報がトークンとともに検証される。
4. Evaluate: CASBがポリシーエンジンを呼び出し、「このユーザーが、香港から、未パッチのWindows端末で、深夜2時に本番DBに触る」という行為を拒絶。
5. Deny/Challenge: 403 Forbiddenを返すか、あるいはステップアップ認証（MFA）を要求する。
—
3. 実践：アクセス制御をコードで叩く
SASE環境下でのAPIアクセスをシミュレートしてみよう。ここでは、標準的なヘッダー付与の概念を理解するために curl と Python を用いる。
curlによる検証（ヘッダー注入の概念）
実務では、デバイスの健全性ステータスやセッションIDをヘッダーに含めるのが一般的だ。
# SASEゲートウェイ経由でAPIにアクセスする想定
# X-Device-Posture-Token: CASBが発行したデバイス評価トークン
# X-Client-Location: ゲートウェイが検知した接続元情報
curl -v -X GET "https://api.example.com/v1/data" \
-H "Authorization: Bearer <JWT_TOKEN>" \
-H "X-Device-Posture-Token: eyJhbGciOiJIUzI1Ni..." \
-H "X-Requested-With: XMLHttpRequest"Pythonによるアクセス制御のロジック（擬似コード）
バックエンド側で、SASEから送られてくるコンテキスト情報を検証する際のロジック例だ。
def check_access_context(request):
"""
SASE/CASBがインジェクションしたヘッダー情報を基に判定を行う
"""
device_status = request.headers.get("X-Device-Posture-Status")
geo_location = request.headers.get("X-Geo-Location")
# ポリシー判定: デバイスが準拠していて、かつ地理的異常がない場合のみ許可
if device_status == "compliant" and geo_location == "JP":
return True
# 異常検知時のログ出力（SIEMへの連携用）
log.warning(f"Unauthorized access attempt: {device_status}, {geo_location}")
return False—
4. トラブルシューティングの勘所：ここが現場の泣き所
「なぜかAPIが叩けない」という問い合わせを受けたとき、どこを見るべきか。私の経験則では、以下の3点が9割を占める。
1. EDRのパッチ適用ラグ: 「社内では繋がるのにリモートだと弾かれる」場合、デバイス管理エージェントの同期遅延で compliant 状態になっていないことが多い。
2. プロキシ越えのIP偽装: SASEを通過する際、X-Forwarded-For が適切に変換されておらず、地理情報が誤判定されているケース。
3. トークンの有効期限: CASBのセッションは非常に短く設定されることがある。トークンの exp クレームを必ず確認せよ。
最後に：防御は「静」から「動」へ
ゼロトラストは、決して「厳しい制限をかけること」ではない。「状況を正確に把握し、その場のリスクに応じた適切な信頼を与えること」だ。
インフラエンジニア諸君、設定ファイルと睨めっこするだけでなく、その裏で走っているユーザーの「コンテキスト」を想像してほしい。技術は常に進化するが、泥臭くパケットを追いかけ、仕様の隙間を埋めていく作業こそが、最強のセキュリティを構築する唯一の道である。
さあ、次は君の環境で、どのコンテキストが「信頼」を阻害しているか、ログを掘り起こしてみようじゃないか。
コメント