Context-Aware Access で全SaaSは統制できない — モバイルアプリは素通り、モバイルブラウザは遮断

はじめに

社内のゼロトラスト移行で、業務SaaSをGoogle認証に寄せて Context-Aware Access（以下CAA）で統制する構成を考えていました。認証を一箇所に集めれば、端末条件やIPの判定もそこで済む。SaaSが増えても同じ仕組みが使える。設計としてきれいでした。

Slackにこれをかけようとして、成立しないことが分かりました。

以下はその過程です。CAAの設定手順を書いた記事はすでにあるので、どこまで守れてどこから守れないかに絞ります。

Slackが一覧に出てこない

管理コンソールのCAAの割り当て画面を開いて、対象アプリの一覧にSlackを探しました。ありません。

CAAの割り当て対象に並ぶのは、Googleのサービスと、SAMLアプリとして登録したアプリだけです。SlackはOAuthの「Googleでサインイン」で連携していたので、そもそも対象になりません。SAMLで登録し直さない限り、どんな設定をしてもCAAは届きません。

一覧を眺めていて、もうひとつ気付いたことがありました。アプリごとに「評価ポイント」という列があり、Googleアプリは「継続」、SAMLで登録したアプリは「ログイン」と表示されています。

公式ヘルプにも書かれていました。

For SAML apps, policy evaluation occurs on sign-in to the app.

同じページに、ユーザーが場所を変えてもSAMLアプリのCAAポリシーは再評価されないと明記されています。再評価はセッションが切れて再ログインしたときだけです。

Gmail や Drive のようなGoogleのサービスは継続的に評価されるので、条件を満たさなくなればその時点で止まります。SAMLアプリは入口で一度見るだけです。長いセッションを張るアプリなら、条件から外れたあともずっと通ります。

この違いを意識していませんでした。SAML化すればGoogleアプリと同じ強度で守れると思っていたのですが、入口のチェックにすぎません。

公式ヘルプだけでは決められなかった

SAML化すれば端末条件はかけられる。そう考えてモバイルの挙動を調べました。ここで手が止まりました。

関係する記述が、同じページの離れたセクションに分かれて置かれています。まず「Apps」の "Mobile apps support notes" に2つ、隣り合った箇条書きとして。

You can't enforce Context-Aware Access policies for mobile on third-party built-in apps (for example, Salesforce).

You can enforce Context-Aware Access policies on SAML apps accessed using Chrome browser.

そして少し下の「SAML apps」に、また2つ。

If a device policy is applied at an access level, a user can be approved only by a third-party SAML app through the Chrome browser with endpoint verification enabled.

If a device policy is applied, web browser access on mobile (including mobile apps that use a web browser for sign-in) is blocked.

最初は「Apps」側の1文目だけを見て、スマホのアプリは評価対象外なので通る、と読みました。それだと、実際に使われるアプリが素通りして、ほとんど使われないブラウザだけが止まることになります。狙いと逆です。

その後「SAML apps」側を読んで、この読みが怪しくなりました。2文目の括弧に「サインインにウェブブラウザを使うモバイルアプリを含めて」とあります。スマホのSaaSアプリがGoogleでサインインするとき、多くはシステムブラウザかアプリ内ブラウザを開きます。その経路がブラウザアクセスとして扱われるなら、デバイス条件を当てた時点でサインインそのものが通りません。アプリは評価されないまま、新しいセッションを取れなくなります。

厄介なのは、この2つがどちらも成り立つことです。「Apps」側はアプリそのものに強制できないという話で、「SAML apps」側はサインインの経路がブラウザなら塞がるという話です。対象が違うので矛盾していません。そして両方を認めると、結論はアプリの実装次第で変わります。サインインにブラウザを開くアプリなら落ち、ブラウザを経由しない実装なら評価されず通る。公式はそこをアプリごとに書いていません。

つまりこの4文を読んだだけでは、素通りするともサインインが落ちるとも決められません。自分の環境でも測っていないので、この記事ではどちらとも断定しません。最初の「アプリは素通りする」という読みは、根拠として1文しか見ていなかったという点で単純に足りていませんでした。

分かるのは範囲の話だけです。制御できないと書かれているのはモバイルのサードパーティ製組み込みアプリで、SaaS全般ではありません。PCのChromeからのSaaSアクセスは制御できます。そしてこれはエディションを上げても変わりません。Googleがサードパーティのアプリの中に手を伸ばせないという構造の話なので、プランでは動きません。

どちらの読みでも残るもの

モバイルの挙動が決まらなくても、確実に残る抜け道がひとつあります。すでに張られているセッションです。

CAAがSAMLアプリを見るのはサインインの瞬間だけでした。OAuth連携のアプリについてもヘルプに明記されていて、サインインを通したあとはサードパーティ側がセッションを持ち、アクセス条件が後から変わってもCAAは進行中のセッションを止めません。再評価は次のサインインまで走りません。

なので、すでにスマホでサインイン済みの端末は、デバイス条件を当てたあとも、そのセッションが切れるまで使い続けられます。ここは素通り説でもサインイン遮断説でも同じです。切り替えた直後、新しいサインインの扱いがどちらに転んでも、既存のセッションは残ります。

セッションの寿命自体は測っていません。ヘルプにあるとおり、サインインを通したあとのセッションを持っているのはサードパーティ側なので、どれくらい保つかはSaaSごとの仕様です。数日から数十日そのままというものもあります。デバイス条件を当てた効果が実際に出るのは、その期限が切れて入り直すときで、切り替えた当日ではありません。

検証で決めること

以上を踏まえて、次に測るものが決まりました。既存のSAMLアプリに、デバイス条件を含むアクセスレベルを監視モードで割り当て、自分だけを対象にします。そのうえでスマホのアプリからサインアウトして入り直し、CAAのログに現れるかを見ます。

ログに現れなければ評価の対象外で、素通り説が残ります。現れて拒否側で記録されるなら、デバイス条件がサインインを止めることになります。PCのChromeからの経路と、モバイルブラウザからの経路も同じ手順で比べます。

ひとつ制約があります。実施者のアカウントが特権管理者で、CAAのアクティブ強制の対象外です。監視モードのログで評価対象かどうかは分かりますが、実際に弾かれるかは自分のアカウントでは確かめられません。実ブロックの確認は検証テナントの一般ユーザーで別に取ります。

結果が出たら追記します。

Chromeでないと通らない

デバイスポリシーには、もうひとつ範囲を狭める仕様があります。アクセスレベルにデバイスポリシーを含めた場合、サードパーティのSAMLアプリで承認されるのは、Endpoint Verification が有効なChromeからのアクセスだけです。

「SAMLアプリならデバイス条件をかけられる」は、実際には「Chrome かつ Endpoint Verification が入った端末に限定する」という意味でした。Safari、Edge、Firefox は弾かれます。

標準ブラウザがChromeで統一されていれば影響はありません。統一されていない場合は、有効化した時点で業務が止まります。SAML化して端末条件をかけるなら、そのアプリを誰がどのブラウザで開いているかを先に見るところからになります。

Endpoint Verification の展開に要るものは、プラットフォームで少し違います。ヘルパーアプリは公式ヘルプに Install the helper app (Linux, Mac & Windows only) と書かれているとおり Linux / Mac / Windows 限定で、ChromeOSでは要りません。ただし拡張のほうはChromeOSにも強制インストールの対象として並ぶので、ChromeOSだから何も配らなくてよいという話ではありませんでした。ここは最初、管理端末なら勝手にシグナルが立つものだと思い込んでいました。

監視モードで自分を実験台にした

ヘルプを読んだだけでは、自分の環境で何が起きるかは分かりません。本番環境で自分1人だけのグループを作り、Driveに対して監視モードでアクセスレベルを割り当てました。監視モードは実アクセスを止めずログだけ残すので、影響を出さずに挙動を見られます。

割り当てから2分で評価が始まりました。

最初のブラウザアクセスは、デバイスIDが不明のまま拒否側で記録されました。Endpoint Verification の拡張を入れるとデバイスIDが付いて状態が変わり、さらに端末を会社所有としてインベントリに登録した時点で条件が満たされました。識別できるだけでは足りず、会社所有として登録されて初めて通ります。順番が分かっていれば当たり前ですが、拡張を入れた時点で通ると思っていたので少し待ちました。

想定していなかったのはパソコン版Google Driveです。

デスクトップに常駐している同期クライアントのアクセスが毎時ログに残り、会社所有として登録したあとも拒否のままでした。Endpoint Verification がデバイスシグナルを付けられるのはChromeブラウザのリクエストで、ネイティブアプリのAPIアクセスには端末を証明する手段がありません。

つまりデバイス条件のCAAをアクティブにすると、ブラウザは通るのにデスクトップの同期が止まります。割り当ての「デスクトップ / モバイルアプリに適用」を切ってブラウザだけ縛るか、同期クライアントの利用をやめるかになります。ChromeOSに寄せた環境なら同期クライアントを使わないので関係ありませんが、Mac や Windows に広げるときは、ここを決めてからになります。

社内のレビューで、Google のデバイス管理側で管理対象端末として登録し、アクセスレベルの条件に管理対象状態を含めれば、Chrome 以外のAPI通信も識別できるのではないかという案が出ました。手元のログとは合いません。会社所有としてインベントリに登録した後も、同期クライアントからのアクセスは No Device Signals のまま拒否でした。別の登録経路なら結果が変わるのかは確かめていないので、未検証として置いておきます。

ログを見る限り、デバイスシグナルが取れないアクセスは拒否側に倒れていました。公式に明記された挙動ではないので断定はしません。ただしこれはCAAが評価している経路の話で、評価対象外のモバイルネイティブアプリには当てはまりません。

5月にデフォルトポリシーが入っていた

調べているうちに、2026年5月14日に全SAMLアプリへ既定のCAAポリシーを一括で当てられる機能が入っていたことに気付きました。個別のポリシーが割り当てられていないSAMLアプリのバックアップとして働き、個別ポリシーがあればそちらが優先されます。既定はオフで、OUまたはグループ単位で有効にします。対象は Enterprise Standard / Plus、Education Standard / Plus、Frontline Standard / Plus、Enterprise Essentials Plus、Cloud Identity Premium です。

割り当て漏れが埋まるのは助かります。SAMLアプリを追加して設定を忘れても、ベースラインが掛かります。

ただ守れる範囲は広がっていません。評価がサインイン時である点も、モバイルのサードパーティアプリに届かない点も同じです。しかも既定ポリシーにデバイス条件を含めると、さきほど決められなかったモバイルの挙動が、一部のアプリではなく全SAMLアプリに一斉に及びます。読みが定まっていない条件を全体に当てる形なので、有効化するOUやグループの範囲は、検証の結果を見てから決めることにしました。

統制を1枚でやるのをやめた

前提が崩れたので、単一の面で統制する構成をやめました。守る対象ごとに担当を分ける形に組み替えています。

守る対象	統制の担当	モバイルでの有効性
Googleアプリ（業務データの本体）	CAA（継続評価）	効く
PCからのSaaSアクセス	SAML + CAA（サインイン時）	該当なし
内部システムへの到達	ゼロトラストアクセス製品のポリシーとデバイスポスチャ	クライアント必須化で効く
サードパーティSaaSのモバイルアプリ	各SaaSの管理機能	SaaSごとに差がある
端末そのもの	会社支給 + MDM	私物には効かない

崩れなかった部分のほうが多かったのは救いでした。業務データの本体がDriveにあるなら、私物スマホからのDriveアクセスを止める構成は成立します。Googleアプリはモバイルでも継続評価されるからです。管理対象のChromeOSからGoogleアプリへのアクセスを端末条件で縛る構成も、実ブロックまで確認できています。

CAAに任せきれないのは、サードパーティSaaSのモバイル利用です。デバイス条件を当てたときに新規サインインが落ちるのか素通りするのかが未確定で、どちらであっても既存セッションは残ります。落ちるなら統制ではなく遮断になり、素通りするなら統制になりません。どちらに転んでもSaaS側の管理機能が要るので、そこで個別に対処する前提にしました。Slackならモバイルからのファイルダウンロード禁止や脱獄端末のブロックが該当します。ただし設定できる項目はSaaSごとにばらつきます。

結果として、どのSaaSに何のデータが入っているかを棚卸しして優先順位を決めるところからやり直しになりました。認証を寄せれば統制も寄る、という発想が雑でした。

おわりに

CAAは対象と経路を選べばよく効きます。管理端末からGoogleアプリへのアクセスを縛る用途では、実際にブロックまで確認できました。

引っかかったのは、SAMLアプリに端末条件を足したときの影響を、統制の強さの問題としてだけ見ていたことです。ヘルプを読むと、先に出てくるのは可用性の側でした。モバイルから業務SaaSに入れなくなる可能性があり、そうなると止まるのは攻撃者ではなく自分たちの業務です。統制が緩いかどうかを気にして、業務が落ちる側を見ていませんでした。

この記事のうち、Googleアプリ側の挙動とパソコン版Driveの件は自分の環境で測ったものです。SAMLアプリのモバイルの挙動は公式ヘルプの読み取りにとどまっていて、しかもヘルプだけでは結論が出ませんでした。測ってから書く順序が逆になったので、結果が出たら追記します。

先に調べておけばよかったと思うのは2つです。SaaSごとの連携方式がSAMLかOAuthか。そのアプリを実際にどの経路で開いているか。どちらもCAAを触る前に分かることでした。

参考

• Protect your business with Context-Aware Access — 適用対象、SAMLアプリのサインイン時評価、モバイルの制約
• Apply a default Context-Aware Access policy for all SAML apps
• Improving security posture with default context-aware access for all SAML applications — 2026年5月14日
• Deploy Context-Aware Access
• Create Context-Aware access levels