境界防御の終焉と「ゼロトラスト」の泥臭い現実：Entra ID条件付きアクセスで防ぐ侵入の連鎖
「VPNに入れば安全」「社内LANだから信頼できる」――そんな神話は、数年前に死んだ。
今の攻撃者は、フィッシングで奪ったセッションクッキーや、ダークウェブで流出したID/PWを使い、いとも簡単にクラウドのゲートウェイを突破してくる。私がこれまで見てきたインシデントの多くは、実は「高度な技術」ではなく「設定の不備」や「認証の隙」を突いたものだ。
今日は、Azure AD（現Microsoft Entra ID）を用いた条件付きアクセス（Conditional Access）について、教科書には載っていない「現場のリアリティ」を叩き込む。
—
攻撃者の視点：彼らはどこを狙っているのか？
攻撃者が狙うのは、「 MFA（多要素認証）が強制されていない古いAPIエンドポイント」や「特定のIPアドレス以外からのアクセスに対する防御が甘いクラウドサービス」だ。
彼らの常套手段はこうだ。
1. セッションハイジャック: MFAを突破してログインした後の「セッションID」を盗み出し、自身のブラウザに注入する。
2. 地理的バイパス: 信頼されたIPリストにVPNサーバーを混ぜ込み、地理的制限を無効化する。
これらを防ぐには、単に「MFAをオンにする」だけでは足りない。「デバイスが管理下にあるか」「リスクレベルは正常か」「想定外の場所ではないか」というコンテキスト（文脈）を評価し続けなければならない。
—
実践：条件付きアクセスで「侵入コスト」を最大化する
Entra IDの条件付きアクセスは、ただのアクセス制限ツールではない。攻撃者が「この標的はコストに合わない」と諦めるための防壁だ。
推奨するポリシー構成（ベストプラクティス）
現場で私が必ず設定させるのは以下の組み合わせだ。
- ユーザーのリスク: 高・中リスクのユーザーは即座にパスワードリセットを要求。
- サインインのリスク: 「ありえない移動（Impossible Travel）」検知時にはMFAを再要求、またはアクセス拒否。
- デバイス状態: Intune等で「準拠」と判定されたデバイス以外からのアクセスは不可。
【実務コード】Pythonによる条件付きアクセス判定（Microsoft Graph API）
APIのバックエンド側でも、ユーザーの認証状態を確認する際は、「条件付きアクセスが正しく適用されているか」をトークンのクレームから検証する必要がある。以下は、トークンの検証を行う際のサンプルコードだ。
import jwt # PyJWTを使用
def verify_conditional_access_claims(token):
“””
トークン内のクレームを確認し、MFAが適切に実施されたか検証する
“””
try:
decoded_token = jwt.decode(token, options={“verify_signature”: False})
# ‘amr’ (Authentication Methods References) クレームを確認
# ‘mfa’ が含まれていることを必須とする
auth_methods = decoded_token.get(‘amr’, [])
if ‘mfa’ not in auth_methods:
raise Exception(“警告: MFAが実施されていません。アクセスを拒否します。”)
print(“認証状態: MFA検証済み。アクセスを許可します。”)
return True
except Exception as e:
# 本来はログに詳細なセキュリティイベントを記録し、SIEMへ飛ばす
print(f”セキュリティエラー: {e}”)
return False
利用例
token = request.headers.get(“Authorization”)
if verify_conditional_access_claims(token):
run_business_logic()
—
WAFで守る最後の砦：HTTPヘッダーの検証
条件付きアクセスで制御できない「境界の隙間」は、WAF（Web Application Firewall）で物理的に遮断する。特に、許可されたEntra IDテナントからのアクセスのみを許可する設定は、不正なトークン持ち込みを防ぐ強力な手段だ。
Nginx/CloudFront等の設定例（イメージ）
許可する特定のAzureテナントIDのみを許可する（カスタムヘッダー等の活用）
※ Entra IDのエンタープライズアプリケーション設定で「テナント制限」を有効にしている前提
map $http_x_tenant_id $is_trusted_tenant {
default 0;
“your-tenant-guid-here” 1;
}
server {
if ($is_trusted_tenant = 0) {
return 403; # 許可されていないテナントからのトークンは即座に拒否
}
}
—
現場のエンジニアへ送るアドバイス
最後に、一つだけ覚えておいてほしい。「完璧なセキュリティ」は存在しない。
条件付きアクセスをどれだけ強固にしても、デバイス自体がマルウェアに感染していれば、セッションは奪われる。だからこそ、我々は「ゼロトラスト」を「継続的な検証」として捉えなければならない。
- MFAはFIDO2/WebAuthnへ: SMS認証はフィッシングに脆弱だ。可能な限りハードウェアキーや生体認証への移行を急げ。
- ログを疑え: ログイン成功ログだけでなく、条件付きアクセスの「不合格ログ（Report-only）」を定期的に分析せよ。そこにこそ、攻撃者の偵察の跡が残っている。
セキュリティは「作業」ではなく「規律」だ。今日紹介した設定を、今すぐあなたの環境の「条件付きアクセス」ポリシーと照らし合わせてみてほしい。もし一つでも穴があれば、そこがあなたのシステムの「出口」になる。
現場からは以上だ。また次のインシデント分析で会おう。
コメント