OktaとGWSで実現！「Chrome Device Trust」でデバイス認証

ごきげんよう、IDチームのわかなです！

「Chrome Device Trust」の機能自体はリリースされて少し経ちますが、先日お客様からお問い合わせがあり改めて検証してみたところ、「これ、多くの方のお悩みを解決できるのでは？」と感じたので記事にすることにしました。

「MDMは導入していないけど、許可したPCからしかアクセスさせたくない…」 「証明書の配布や更新の運用が正直つらい…」 「セキュリティは強化したいけど、ユーザーの利便性は下げたくない！」

そんなお悩みを持つID管理担当者様は、ぜひ最後までご覧ください。

３行まとめ

• MDMや証明書なしで、会社が管理するChromeブラウザをOktaが認識。

• ブラウザが持つセキュリティ情報（暗号化、セキュアブート等）を認証条件に利用可能。

• 運用負荷を下げつつ、適切な信頼レベルのデバイスだけアクセスを許可する制御を実現。

こんな環境におすすめ！

• Oktaに加え、Google Workspaceを主要なコラボレーションツールとして深く活用している環境

• クライアント証明書を配布するような高度なMDM運用はしていないが、アクセスできる端末を制限したい

• 全社的にChromeブラウザの利用を標準としている

• BYOD（私物端末）を許可しつつ、業務アクセスはセキュアに行わせたい

必要なもの

• Okta側
  • Okta Identity Engine が有効であること
  • Adaptive SSOもしくはAdaptive MFA ライセンスを利用していること

• Google側
  • ユーザーに Cloud Identity Free または Cloud Identity Premium のライセンスが付与されていること

• その他
  • PCの初期セットアップ（キッティング）時や資産管理ツール経由などから、管理PCに設定ファイル（.reg/.mobileconfig）を配布・適用できる状態であること
  • 事前にOktaとGoogle Workspace間でSSO連携が構成されていること

セットアップ手順

ここからは、実際の管理画面のスクリーンショットを想定しながら、「Chrome Device Trust」を有効化する手順を解説していきます。全体の流れは「①Googleで設定 → ②PCに設定 → ③Oktaで設定」の3ステップです。

Step 1. OktaとGoogleをコネクタで接続する

まずはじめに、OktaとGoogle、双方の管理コンソールを操作して2つのサービスを接続します。Oktaで接続情報を作成し、それをGoogleに設定する、という流れです。

Okta側で接続情報を取得する

1. Okta管理コンソールにログインし、 [Security] > [Device Integrations] に移動します。
2. [Add endpoint integration] をクリックし、 [Chrome Device Trust] を選択します。
   
3. 連携を有効にしたいプラットフォーム（macOS, Windows）を選択し、[Add] をクリックします。
   
4. ポップアップウィンドウに 「Login URL pattern」 と 「Service account」 が表示されます。この2つの情報はGoogle側の設定で必要になるため、ウィンドウを開いたままにするか、テキストエディタなどにコピーしておきましょう。
5. 

Google管理コンソールでコネクタを設定する

次に、Google側の画面に切り替えて、先ほどOktaで取得した情報を設定します。

1. Google管理コンソールにログインし、 [デバイス] > [Chrome] > [コネクタ] に移動します。
2. [+ 新しいプロバイダの設定] をクリックします。
   
3. プロバイダのリストから [Okta] を探し、[設定] をクリックします。
   
4. 右側に設定パネルが開きます。
   • 設定名: 任意の分かりやすい名前（例: Okta）を入力します。
   • 許可するURLパターン: Oktaの画面でコピーした 「Login URL pattern」 を貼り付けます。
   • サービス アカウント: 同じく 「Service account」 の値を貼り付けます。
   • 入力が完了したら、[設定を保存] をクリックします。
     
5. コネクタのトップページに戻ります。最後に、画面右上の [保存] をクリックして、組織部門への設定変更を確定させます。
   

これで、OktaとGoogleの間の信頼関係が結ばれました！次のステップでは、ユーザーのPCを設定していきます。

Step 2. クライアントPCを「管理対象ブラウザ」にする

次に、ユーザーが利用するPCのChromeブラウザに「私は貴社（Google Workspace）の管理下にあるブラウザです」と認識させるための設定を行います。

この設定により、Chromeブラウザは自身のセキュリティ状態（ディスクが暗号化されているか、など）をGoogleに送信し始め、Oktaがそれを認証に利用できるようになります。

登録トークンを取得する

まずは、各PCに設定するための「登録トークン」をGoogle管理コンソールから取得します。

1. Google管理コンソールで [デバイス] > [Chrome] > [管理対象ブラウザ] に移動します。
2. 画面上部の [登録] ボタンをクリックします。
   
3. ポップアップウィンドウが表示されます。ここからWindows用の設定ファイルをダウンロードしたり、macOS用のトークンをコピーしたりします。
   
   

Windowsの場合

1. 先ほどのポップアップ画面で、[REGファイル (WINDOWS)] をクリックして設定ファイルをダウンロードします。
2. ダウンロードした.regファイルを、対象のPCで実行（ダブルクリック）してレジストリに登録します。

macOSの場合

1. 先ほどのポップアップ画面で、表示されている「トークン」の文字列をコピーします。
2. 以下のサンプルコードを参考に、.mobileconfig という拡張子で保存し、実行します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CloudManagementEnrollmentToken</key>
    <string>ここにGoogle管理コンソールでコピーしたトークンを貼り付け</string>
</dict>
</plist>

Step 3. OktaでDevice Assuranceポリシーを設定する

最後に、Okta側で「管理対象ブラウザからのアクセス」を信頼するルールを作成し、認証ポリシーに適用します。

1. Okta管理コンソールで [Security] > [Device Assurance] に移動し、ポリシーを新規作成します。
2. プラットフォーム（Windows/macOS）を選択し、“Chrome Device Trust” を条件に追加します。
   
3. 作成したDevice Assuranceポリシーを、認証ポリシー（Authentication Policy）のルールに組み込みます。
   

これで設定は完了です！

補足：本機能とOkta Device Assuranceの関係

「Chrome Device Trust」は、以前ブログで紹介されたOktaの Device Assurance機能 の中で利用できる、新しいシグナルソース（情報源）です。

Okta Device Assuranceでデバイスの状態を条件にアクセス制御を行なってみた

こんにちは！たつみんです。 みなさんはOktaのリリースノートって読んでますか？ 2022.08のリリースノー…

blog.cloudnative.co.jp

現時点で、OktaのDevice Assuranceは、デバイスの信頼性を評価するために、主に以下の2つのソースから情報（シグナル）を受け取ることができます。

1. Okta Verify Oktaの認証アプリ自体が収集する情報です。（以前の記事で解説した、もともとのDevice Assuranceの機能）
2. Chrome Device Trust 管理対象のChromeブラウザから収集する情報です。

この2つは同等の機能として共存させることが可能ですが、Oktaの仕様として、両方のシグナルが同時に存在する場合はOkta Verifyからのシグナルが優先して評価されます。

OktaでDevice Assuranceポリシーを強化し、認証に組み込む

ここまでの設定で、OktaのSystem LogにはChromeブラウザからの様々な情報（シグナル）が届くようになっているはずです。最後のステップでは、この豊富な情報を活用して、自社のセキュリティポリシーに合わせた強力なアクセス制御を構築していきます。

シグナルを元に、デバイスの信頼性を定義する

System Logに記録されるCHROME_DTCの情報を元に、「どのような状態のデバイスを信頼するか」を定義します。

OktaのDevice Assuranceポリシー作成画面では、これらのシグナルをGUIで簡単に条件として設定できます。

【ポリシーで設定できる条件の例】

• 基本的なPCのセキュリティ:
  • Lock screen secured: 画面ロックがパスワードやWindows Helloで保護されているか
  • Disk encryption: ディスクが暗号化されているか
  • Firewall: OSのファイアウォールが有効か
• バージョン管理:
  • Minimum Windows version / Minimum Chrome browser version: OSやブラウザが指定したバージョン以上であるか
• Entra ID / AD参加状態の確認:
  • Entra Joinedデバイス: Device enrollment domain に自社のテナントドメインを指定
  • Hybrid Entra Joinedデバイス: 上記に加え、Windows machine domain や Windows user domain にオンプレADのドメインを指定
• サードパーティ製品との連携:
  • CrowdStrike: CrowdStrike - Agent ID などを条件に追加し、EDRが導入されていることを必須とする

このように、様々な条件を組み合わせることで、「Entra IDに参加していて、ディスクが暗号化され、CrowdStrikeが稼働しているPCの最新版Chromeから」といった、非常にきめ細やかなルールを作成できます。

【ユーザーにも親切に】不適合時の修復メッセージ

ポリシーの条件を満たせなかったユーザーに対して、ただ「アクセス拒否」と表示するだけでは不親切です。この機能では、なぜアクセスできなかったのか、どうすれば解決できるのかをユーザーに案内するメッセージを表示できます。

[Security] > [Device Assurance] の上部にある [User help] 設定から、[Display device error remediation in the browser when access is denied] を有効化するだけでOKです。

これにより、「Chromeのバージョンが古いためアクセスできません。最新版にアップデートしてください。」といった具体的なメッセージが表示され、ユーザーの自己解決を促し、ヘルプデスクの負荷を軽減できます。

【重要ポイント】認証ポリシーの順番と「キャッチオール」の罠

最後に、この機能を実装する上で最も重要な注意点です。 Oktaの認証ポリシーは、設定されたルールのリストを上から順に評価していきます。

ここで注意が必要なのは、特定のルールの条件を満たさなくても、即座にアクセスが拒否されるわけではない点です。そのルールは「条件不一致」としてスルー（スキップ）され、もし下位に「全ユーザーを許可する」のような緩いキャッチオールルールが存在すると、意図せずアクセスが許可されてしまいます。

上の画像は、上が「Chrome Device Trust」のルールに一致して成功したログ、下がそれに一致せず、より下位の「Catch-all Rule」に拾われて成功してしまったログです。 私も検証中、この動作によって、本来であればアクセスが拒否されるべき端末が下位のルールに拾われてログインに成功してしまう現象を確認しました。

まとめ

本記事では、Oktaの新機能「Chrome Device Trust」について、以下の点をご紹介しました。

• MDMやクライアント証明書がなくても、多くの企業で標準となっているChromeブラウザ自体を信頼のアンカーとして利用できること。
• Entra ID/ADへの参加状態やディスク暗号化といったデバイスのセキュリティ状態（ポスチャ）をリアルタイムに評価し、アクセス制御の条件に組み込めること。
• 認証ポリシーの評価順序を正しく設定しないと、意図せずアクセスを許可してしまう危険性があること、そしてその対策。

ID管理におけるデバイス認証は、セキュリティの要でありながら、導入や運用のコストが課題でした。「Chrome Device Trust」は、多くの企業で標準的に利用されているChromeブラウザを活用することで、その課題をスマートに解決できるのではと思います。

この記事が、皆様のID管理業務のヒントになれば幸いです！