こんにちは！ネットワークやセキュリティの世界へようこそ。
日々、会社から支給されたパソコンでメールやチャットを開き、当たり前のようにクラウド上のファイル共有サービスを使っていますよね。でも、ふとこんな心配をしたことはありませんか？
「社員が個人のプライベートで作ったMicrosoft 365のアカウントにログインして、会社の機密データをこっそり持ち出してしまうかもしれない……」
エンタープライズの現場でインフラやセキュリティを守る私たちにとって、この「シャドーIT（管理外のクラウド利用）」は頭の痛い問題の筆頭です。
今回は、そんなセキュリティの悩みを鮮やかに解決してくれる、SASE（Secure Access Service Edge）やCASB（Cloud Access Security Broker）の強力な武器「HTTPヘッダー書き換えによるOffice 365テナント制限」について、難しい専門用語の壁をすんなり越えていけるよう、一緒に紐解いていきましょう！
—
1. 例え話でスッキリ理解！「会社の郵便受け」と「特製の宛先スタンプ」
まずは、パケットの動きやHTTPヘッダーという見慣れない言葉を、身近な世界に置き換えて考えてみましょう。
想像してみてください。あなたは巨大なオフィスの「総務部の郵便係」です。
社員たちが外に向かって手紙（リクエスト）を出すとき、必ずあなたのデスクの前を通っていきますよね。
- 通常のインターネット： 社員が「どこ宛ての手紙でも、自分の好きな私書箱に出していいよ」という状態です。これでは、会社の極秘データを個人のプライベートな私書箱に送られても誰も気づけません。
- CASBプロキシの登場： ここに、優秀な郵便係（CASBプロキシ）を配置します。この郵便係は、社員が会社の外へ手紙を出すときに、封筒の裏に「我が社の公式な宛先リスト」という特別なスタンプをギュッと押してから送り出すのです。
この「特製の宛先スタンプ」こそが、今回主役となるHTTPヘッダーの書き換えの正体です。
—
2. なぜHTTPヘッダーの書き換えが必要なの？
Microsoft 365（旧Office 365）は非常に便利ですが、ひとつのテナント（企業ごとの専用スペース）だけでなく、個人が持っている無料のアカウントや、他社のテナントにも簡単にログインできてしまいます。
企業としては、「うちの社員なんだから、アクセスしていいのはうちの会社のテナントだけ！ 他所のテナントのドアをノックすることは許さない！」と制限したいわけです。
ここで、ネットワークの経路の途中にいるCASBやセキュアWebゲートウェイ（SWG）が、社員のブラウザからMicrosoftのサーバーへ向かう通信（HTTPリクエスト）のすきマにサッと割り込み、通信の「お札（HTTPヘッダー）」に、次のような特別な合言葉（制限リスト）を書き加えます。
1. Restrict-Access-To-Tenants-List （許可する会社のテナントIDのリスト）
2. Restrict-Access-Context （どの会社からアクセスしているかの証明）
この書き換えが行われた通信を受け取ったMicrosoftのサーバー側は、こう判断します。
「おっ、この通信にはちゃんと自社の許可証（ヘッダー）が貼ってあるな。じゃあログインを許可しよう。……おや？ この通信には許可証がない、あるいは別の会社の名前が書かれているぞ。アクセス拒否（シャットアウト）！」
こうして、社員がうっかり（あるいは故意に）管理外のテナントへログインしようとしても、途中でピシャリと門前払いできるというわけです。
—
3. 実装の裏側：実際どんなヘッダーが書き換えられているの？
それでは、一歩進んで技術的な中身を覗いてみましょう。一見難しそうに見えますが、ルールさえ分かれば怖くありません。
ブラウザがMicrosoftのログイン画面（login.microsoftonline.com など）へ向かう際、CASBやプロキシサーバーは、通過するHTTPリクエストの中に次のようなヘッダーを「追加または上書き」します。
# CASBやプロキシがMicrosoft 365宛ての通信に付与するHTTPヘッダーの例
# 1. アクセスを許可するテナントのリスト（テナントIDやドメイン名を並べる）
Restrict-Access-To-Tenants-List: contoso.com, fabrikam.com, 11111111-2222-3333-4444-555555555555
# 2. 制限をかけている組織の証明（Azure ADで生成したテナントGUIDなど）
Restrict-Access-Context: 99999999-8888-7777-6666-555555555555パラメータの優しい解説
Restrict-Access-To-Tenants-List- ここに書かれているテナント（会社）にしかアクセスを許しません。複数の会社をカンマ区切りで指定できます。自社のテナントIDや独自ドメインをここに登録します。
Restrict-Access-Context- 「どの企業がこの制限ルールを適用しているか」をMicrosoft側に伝えるためのIDです。これにより、不正にヘッダーを偽造されないような信頼性の担保（テナントの乗っ取り防止）が行われます。
—
4. 現場で役立つ！CASB/SWG設定のポイントと注意点
実際のプロジェクトでこのテナント制限を実装する際、インフラエンジニアとして絶対に押さえておかなければならないポイントがいくつかあります。
① SSL/TLS復号（インスペクション）は必須！
現代のWebトラフィックのほとんどはHTTPS（暗号化）されています。つまり、パケットの中身（HTTPヘッダー）はカプセル化されていて、そのままでは外から書き換えることができません。
CASBやSASE製品でテナント制限を行うためには、プロキシサーバーで一度通信の暗号化を解いて中身を検査・書き換え（SSL Decryption）、再び暗号化して送り出す仕組みを必ず有効にする必要があります。
② すべてのMicrosoft 365のエンドポイントを網羅する
テナント制限の対象となる宛先ドメインは、Microsoftによって厳密に定義されています。一般的には以下のドメイン宛てのトラフィックに対してヘッダーインジェクション（挿入）を行います。
login.microsoftonline.comlogin.microsoft.comlogin.windows.net
③ 予期せぬ「社外ゲスト」への配慮を忘れずに
自社の社員が他社のテナントに「ゲストユーザー」として招待されて仕事をするケースはよくありますよね。
このテナント制限を厳しくしすぎると、他社テナントへの正当なゲストアクセスまでブロックされてしまい、「仕事ができない！」とヘルプデスクに問い合わせが殺到する原因になります。導入前には必ず、自社としてどの範囲のアクセスを許容すべきか、関係部署としっかりとすり合わせを行いましょう。
—
まとめ
今回は、SASEやCASBにおける重要な機能のひとつである「HTTPヘッダー書き換えによるOffice 365テナント制限」について、郵便配達の例えを交えながら解説しました。
一見すると難解な英単語やパケットの仕組みも、「誰が・どこで・何の目的で手を加えているのか」を順序立てて見ていくと、すごくシンプルで理にかなった仕組みであることが分かりますよね。
インフラやセキュリティの世界は、こうした小さな「ひと手間（ヘッダーの書き換え）」の積み重ねによって、企業の巨大な安全性が守られています。
「難しそう」と身構えず、ぜひ実際の検証環境やログを見ながら、パケットたちのドラマに思いを馳せてみてください。あなたのネットワークエンジニアとしての引き出しが、また一つ確実に深くなりますよ！
コメント