【入門編】 HTTPヘッダー書き換え仕様:CASBによるX-Google-Apps-Allowed-Domainsヘッダーの挿入 – ゼロトラスト&エンタープライズセキュリティ実践ガイド

こんにちは!インフラやネットワークの世界へようこそ。ゼロトラストやクラウドセキュリティの最前線で日夜奮闘しているセキュリティスペシャリストの私です。

「SASE」や「CASB(キャスビー)」といった言葉、最近よく耳にしますよね。「なんだか難しそうな英語の略語ばかりで、頭がクラクラする……」なんて感じる方も多いのではないでしょうか。一歩ずつ、身近な例えから紐解いていけば決して怖くありませんよ。

今回は、数あるCASBの機能の中でも、現場で本当によく使われる「HTTPヘッダー書き換え仕様:X-Google-Apps-Allowed-Domainsヘッダーの挿入」というテーマを取り上げます。

「会社のPCから個人のプライベートなGmailにログインされたくない!」そんな企業の悩みを、ネットワークの裏側でどうやってスマートに解決しているのか、一緒に覗いてみましょう!

—

1. 会社員が個人のGmailを見ちゃう?「シャドーIT」の恐怖

皆さんは普段、会社から支給されたパソコンやスマートフォンで仕事をしていますよね。その端末を使って、Google Workspace(旧G Suite。GmailやGoogleドライブなど)にアクセスするシーンを想像してみてください。

ここで、ちょっと意地悪な想像をしてみましょう。
あなたが会社のパソコンを開き、魔が差して(あるいはうっかり)、自分のプライベートで使っているGmailのアカウントでログインしようとしたとします。

企業の情報システム部門の視点からすると、これは冷や汗モノの一大事です。なぜなら、会社の機密データを個人のGoogleドライブにこっそり保存されてしまうかもしれないし、私用のメールと会社のメールが混ざって情報漏洩のリスクが跳ね上がるからです。いわゆる「シャドーIT」の典型例ですね。

「じゃあ、社内のネットワークからGoogleへのアクセスを全部禁止しちゃえばいいじゃない!」……と言いたいところですが、今の時代、業務でGoogle Workspaceをバリバリ使っている会社もたくさんありますよね。「仕事のGoogleは使いたいけれど、個人のGoogleは使わせたくない」という、何ともわがまま(でも現場にとっては切実!)な要望を叶える必要があるのです。

そこで登場するのが、今回の主役であるCASB(Secure Access Service Edgeを構成する重要なピースの一つ)と、魔法の合言葉であるX-Google-Apps-Allowed-DomainsというHTTPヘッダーになります。

—

2. 郵便配達員に例えてみよう!CASBとHTTPヘッダーの仕組み

「HTTPヘッダー」とか「ドメイン制御」とか言われると、急に拒否反応が出てしまうかもしれません。でも、身近な「郵便配達」に例えてみると、驚くほどすんなり理解できますよ。

手紙(HTTPリクエスト)の封筒の裏書き

私たちが会社のパソコンからウェブサイト(Google)にアクセスするとき、ブラウザは裏側で「リクエスト」という名の「手紙」を相手のサーバーに向けて送っています。

この手紙には、本文(見たいページの情報など)のほかに、「封筒の宛名や差出人の情報」が書かれています。これがHTTPヘッダーと呼ばれるものです。

途中の検問所(CASB)で封筒を書き換える

ここで、会社のネットワークの出口(あるいはクラウド上のCASBサービス)に、厳格な「郵便の検問所」が設置されていると想像してください。

社員がGoogle宛てに手紙を出そうとポストに投函すると、その手紙は必ずこのCASBという検問所を通過します。
CASBは、その手紙の封筒の宛名や中身をチラッと見て、こうつぶやきます。

> 「おっ、この手紙の差出人は会社の社員だな。Google宛ての手紙だから、『我が社の指定したドメインのアカウント以外はお断り!』という特別なスタンプ(HTTPヘッダー)を封筒にポンと押してやろう」

このCASBが勝手に(あるいは代行して)押し込んでくれる魔法のスタンプこそが、今回学ぶX-Google-Apps-Allowed-Domainsというヘッダーなんです!

—

3. 実際のHTTPヘッダーの仕様を覗いてみよう

一歩進んで、技術的な中身を少しだけ覗いてみましょう。難しくありませんよ。

Googleのサーバーは、世界中から届く手紙(HTTPリクエスト)を受け取ったとき、その封筒に特定のヘッダーが含まれているかどうかをチェックする仕組みを持っています。それが X-Google-Apps-Allowed-Domains です。

例えば、あなたの会社のドメインが example.co.jp だとしましょう。
CASBがインライン(通信の経路上)で、Google宛てのHTTPリクエストに対して、次のようなヘッダーを自動的に挿入(追加)します。

GET / HTTP/1.1
Host: accounts.google.com
X-Google-Apps-Allowed-Domains: example.co.jp

たったこれだけです!
このヘッダーが付与された状態でリクエストがGoogleのログイン画面に届くと、Googleのサーバーはこう判断します。

> 「なるほど、この会社(example.co.jp)からのアクセスなのだな。よし、ではログイン画面において、example.co.jp 以外のドメイン(例えば gmail.com など)のアカウントでのログインや新規追加をブロックしてあげよう」

もし、社員が私用の xxx@gmail.com でログインしようとしても、Google側が「この組織では許可されていません」とピシャリと跳ね返してくれるようになります。これが、CASBによるインライン制御の鮮やかなカラクリです。

—

4. 現場での設定イメージと注意点

実際のインフラ構築の現場では、このヘッダー挿入をどのように設定するのでしょうか。具体的なコードや設定ファイルのイメージを見てみましょう。

多くの主要なCASB製品(NetSkope、Palo Alto Prisma Access、Microsoft Defender for Cloud Appsなど)や、リバースプロキシ・次世代ファイアウォールでは、GUIの管理画面でポチポチと設定することが多いですが、概念的には次のようなルール(ポリシー)を定義します。

CASB / プロキシのポリシー設定例(概念コード)

{
  "rule_name": "Google_Workspace_Domain_Restriction",
  "target_application": "Google Workspace",
  "action": "Insert HTTP Header",
  "conditions": {
    "source_network": "Corporate_Managed_Devices",
    "destination_domain": "*.google.com"
  },
  "header_to_insert": {
    "name": "X-Google-Apps-Allowed-Domains",
    "value": "example.co.jp, partner-company.jp"
  }
}

> 【実務のワンポイント解説】
> 上記の設定例では、自社のドメインである example.co.jp に加えて、ビジネスパートナーのドメインである partner-company.jp もあわせて許可(複数指定する場合はカンマ区切り)しています。現場の要件に合わせて柔軟に調整できるのがこの方式の強みです。

⚠️ 現場でハマりがちな注意点(SSL/TLS復号の壁)

ここで、ネットワークエンジニアとして絶対に知っておかなければならない重要なポイントがあります。

現代のWeb通信は、すべて HTTPS(暗号化)されていますよね。つまり、ブラウザとGoogleの間を行き交う手紙は、すべて分厚い鍵のかかったカバンに入れられている状態です。
そのままでは、途中のCASB(検問所)が手紙の封筒を開けて X-Google-Apps-Allowed-Domains ヘッダーを書き換えることができません。

そのため、CASBやプロキシ装置でこの制御を行うためには、社内ネットワークの出口で一度通信の暗号化を解き(SSL/TLSインスペクション / 復号)、ヘッダーを書き換えてから再び暗号化して送り出すという、少し高度な処理が必要になります。

「最近、特定のクラウドサービスだけ変な挙動をするな……」というトラブルに直面したときは、大体このSSL復号の証明書エラーやパケットの改ざんが原因であることが多いので、現場に出たときはぜひ思い出してくださいね!

—

5. おわりに:ゼロトラストの基本は「信じない、だが賢く制御する」こと

今回は、CASBによる X-Google-Apps-Allowed-Domains ヘッダーの挿入という、ちょっと専門的なテーマを優しく紐解いてみました。

一見すると難解な英単語の羅列も、
1. 「シャドーITを防ぎたい」という現場の切実なセキュリティの目的があり、
2. 「郵便の検問所(CASB)」が、
3. 「封筒のスタンプ(HTTPヘッダー)」を書き換えることでGoogleに意思を伝えている、

というストーリーで捉えれば、ぐっと身近に感じられたのではないでしょうか。

ゼロトラストアーキテクチャの基本は、「ユーザーやデバイスを無条件に信用せず、しかし業務の利便性を損なわずに賢く安全な道を整えること」にあります。CASBを味方につければ、クラウドの便利さを安全に享受する強力な武器になりますよ。

それでは、また次回の技術解説でお会いしましょう!インフラの現場を一緒に楽しんでいきましょうね!

コメント

タイトルとURLをコピーしました