境界線の向こう側を制御せよ：SASE/CASBで実現する「テナント制限」の深淵
ネットワークエンジニアとして現場に立っていると、「社用PCから個人のOffice 365にファイルをアップロードされたらどうする？」という問いは、避けて通れない悪夢のような命題だ。オンプレミス時代ならプロキシでURLをブラックリスト化すれば済んだかもしれない。だが、クラウドネイティブな現代において、そんな泥縄式のアプローチは通用しない。
そこで登場するのが、SASE（Secure Access Service Edge）やCASB（Cloud Access Security Broker）による「テナント制限（Tenant Restrictions）」だ。今回は、ただの機能説明ではない。パケットがどう書き換えられ、Microsoftの認証サーバーとどう対話するのか、その「現場のリアル」を掘り下げていこう。
—
1. なぜ「ヘッダー」を書き換えるのか？その背後にあるロジック
通常、ブラウザやOfficeクライアントが login.microsoftonline.com へアクセスすると、認証フローが始まる。このとき、SASEプロキシは透過的（あるいはPACファイル経由）に通信を横取りし、HTTPリクエストヘッダーに特定のフラグを埋め込む。
Microsoftの認証基盤は、この特定のヘッダーを検知すると、「お、このリクエストには制限がかかっているな」と判断し、許可されたテナント（許可リスト）に含まれないIDでのログインを自動的に拒絶する仕組みだ。これが「テナント制限」の正体である。
重要なHTTPヘッダーの構造
CASBが挿入するヘッダーは、大きく分けて以下の2つだ。
Restrict-Access-To-Tenants-List: 許可するテナントID（ディレクトリID）のリスト。セミコロンで区切る。Restrict-Access-Context: 誰がこの制限をかけたのかを示す識別子。基本的にはtenant-id-guidを入れるのが作法だ。
—
2. 認証シーケンスの現場的視点
通信フローは非常にシンプルだが、ここを理解していないと「なぜかログインできる」というトラブルシュートで迷子になる。
1. クライアント：login.microsoftonline.com へリクエストを送出。
2. CASB/SASEプロキシ：リクエストをキャッチ。ここでパケットを分解し、ヘッダーを挿入。
3. Microsoft認証サーバー：受け取ったリクエストに上記のヘッダーが含まれているか確認。
4. 認証処理：ヘッダー内のリストに含まれないテナントへのログイン試行なら、サーバー側が403エラーを返すか、ID/PW入力後に「この組織はアクセスを制限されています」と弾き出す。
注意点： この仕組みはあくまでHTTPS通信の「ヘッダー」を利用する。つまり、プロキシがTLSインスペクション（復号）を行えて初めて機能する点に注意してほしい。SSLオフロードをサボっている環境では、このヘッダー挿入は物理的に不可能だ。
—
3. 実装の現場：コードと設定のサンプル
理屈は分かった。では、どう設定し、どう検証するか。現場で使える実践的なコードを提示する。
Pythonによるリクエストヘッダーのシミュレーション
トラブルシューティング時、特定のヘッダーを付与して疎通確認を行うためのPythonコードだ。
import requests
# 制限をかけるテナントID（例）
allowed_tenants = "12345678-abcd-efgh-ijkl-9876543210ab"
context_id = "your-company-tenant-id"
headers = {
# 許可するテナントのリスト
"Restrict-Access-To-Tenants-List": allowed_tenants,
# 制限を適用している組織のID
"Restrict-Access-Context": context_id,
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
}
url = "https://login.microsoftonline.com/common/oauth2/authorize"
# 検証用リクエスト
response = requests.get(url, headers=headers)
print(f"Status Code: {response.status_code}")curlによるデバッグコマンド
プロキシを経由した際、実際にヘッダーが挿入されているかを curl で叩いて確認する。
# プロキシサーバー経由でヘッダーを確認
curl -v -x http://proxy.example.com:8080 \
-H "Restrict-Access-To-Tenants-List: 12345678-abcd-efgh-ijkl-9876543210ab" \
-H "Restrict-Access-Context: your-company-tenant-id" \
https://login.microsoftonline.com/—
4. 現場のシニアからのアドバイス：ハマりポイント
この技術を導入する際、必ず遭遇する「壁」がある。
- HTTPS復号の除外設定：全ての通信を復号すると、銀行系サイトやプライバシーに関わるサイトで問題が起きる。
login.microsoftonline.comやaadcdn.msauth.netといったMicrosoft関連のFQDNだけを確実に復号し、かつヘッダーを注入する設定が必要だ。 - テナントIDの取り違え：
Restrict-Access-To-Tenants-Listに入れるのは「ドメイン名」ではなく「GUID形式のディレクトリID」だ。これを間違えると、全ユーザーがログイン不可になるという「自爆テロ」が起きる。必ず検証環境で一度テストしてから本番に投入すること。 - ブラウザキャッシュの罠：一度認証が成功すると、ブラウザはセッションを維持する。ポリシーを変更した直後に「反映されない！」と慌てないこと。ブラウザをシークレットモードにするか、キャッシュをクリアして再試行するのが鉄則だ。
終わりに
ゼロトラストの時代においても、こうしたHTTPヘッダーレベルの制御は、防御の最前線となる。泥臭いパケットの書き換え作業だが、これ一つで「野良テナントへのデータ漏洩」という大きなリスクを封じ込めることができる。
技術は常に進化するが、結局のところ、制御の肝は「誰が、どのデータに、どんな条件下でアクセスするのか」をどれだけ正確に可視化し、制御できるかという一点に尽きる。現場のネットワークを守る同志諸君、ぜひこの「ヘッダー制御」の力を使いこなしてほしい。
コメント