Context-Aware Access でデバイス証明書を使ってみた
Goolge Workspace / Context-Aware Access のアクセスレベルに「デバイス証明書を条件とした設定」を適用することが可能になりました。
実際に自組織の PKI (検証中) で発行・配布したデバイス証明書を使ったコントロールが可能であることが確認できたので、内容をシェアしようと思います。
※ Google のドキュメントで「企業証明書」「エンタープライズ証明書」「クライアント証明書」といった表記の揺れがありますが、本記事では「デバイス証明書」で統一します。
Context-Aware Access とは
アクセス元のエンティティの属性情報をチェックし、Google Workspace のアプリケーション単位、SAML アプリケーション単位でアクセコントロールのポリシーを設定できる機能です。
コンテキストアウェア アクセスを使用すると、ユーザー ID、アクセス元の地域、デバイスのセキュリティ状況、IP アドレスなどの属性に基づいて、アプリに対する詳細なアクセス制御ポリシーを作成できます。
この機能により、ユーザーのデバイスが組織の IT ポリシーに準拠しているかどうかなどの状況に基づいて、そのユーザーがどのアプリにアクセスできるかを制御することが可能です。
類似のアプローチとして ”サードパーティの IdP - Google Workspace を SP とする SAML を構成し、IdP 側でアクセス元の属性情報をチェックして Google Workspace への SSO 可否をコントロールする” ものがあります。(ex. Azure AD のリスクベースの条件付きアクセス)
この場合は「Google Workspace 全体へのアクセス可否 (ユーザ認証そのもの)」がコントロールされるため、例えば「Google Drive は会社支給デバイスでの利用に制限するが、カレンダーは個人スマホでの利用を許可したい」といったアプリケーションレベルでのコントロールができない認識です。(違っていたら教えていただければと思います。)
一方 Context-Aware Access だと個々のアプリケーション単位でアクセスポリシーを設定できるため、
特定のサービスは会社支給 PC (デバイス証明書が配布されたデバイス) でのみアクセス可能
その他のサービスは利用デバイスを制限をしない
といった柔軟な設計が実現できそうです。
必要なプラン
Google Workspace Enterprise Standard 以上のエディション
Google Workspace Education Standard 以上のエディション
Cloud Identity Premium
のいずれかの契約が必要とのこと。
この機能に対応しているエディション: Enterprise、Education Standard、Education Plus、Cloud Identity Premium
(余談) BeyondCorp Enterprise の契約は必要？
リリースページからリンクされている設定手順を辿っていくと、以下の説明が見つかります。
エンタープライズ証明書を構成する前に、カスタム アクセスレベルの作成でカスタム アクセスレベルを構成していることを確認してください。
注: この機能は、有料のエンタープライズ セキュリティ サブスクリプションの一部としてのみご利用いただけます。ご希望の場合は、こちら から登録できます。
リンク先は BeyondCorp Enterprise (BCE) の問い合わせフォームです。
Context-Aware Access でデバイス証明書を条件として扱う場合にも BCE の契約が必要なのか問い合わせてみたところ「不要」という回答でした。
ざっくりとした分類ですが以下の考え方のようです。
Access Context Manager でカスタムアクセスレベルを設定する場合は (Google Cloud 上のリソースへのアクセス条件でデバイス証明書を扱う場合は)、BCE の契約が必要
Google Workspace の Context-Aware Access でカスタムアクセスレベルを設定する場合、BCE の契約は不要
検証環境
以下の組み合わせで、デバイス証明書を利用した Google Drive へのアクセスコントロールを試しました。
Google Workspace Enterprise Standard
macOS Monterey (12.5) / M1
Chrome (ver.104)
設定の流れ
デバイス証明書を条件として利用するための設定を、Access Context Manager のヘルプページを参考にして検証しました。
※ Google Workspace のヘルプページには条件式の構文の情報しか記載されておらず、この設定だけしても期待している動作とならないので注意です。
概要は以下の通りです。
Google Workspace での設定
Context-Aware Access の設定
Root CA 証明書、中間 CA 証明書のファイルを Google Workspace へ登録
Chrome Enterprise 化の設定
Endpoint Verification (Chrome Extension) のインストール設定
Chrome policy の設定 (Context-Aware Access で使用するデバイス証明書の指定)
デバイス側の設定
Chrome が対象のデバイス証明書へアクセスすることを許可
詳細な操作内容は上記のヘルプページを参照いただく形として、検証時にハマったところや補足情報、学びになったことを書いていきます。
Context-Aware Access の設定
サンプルのポリシーを参考に「組織で管理している認証局から発行された、有効なデバイス証明書が存在すること」を条件とするアクセスレベルを作成しました。
device.certificates.exists(cert, cert.is_valid && cert.issuer == "[ 中間 CA の情報]")作成したアクセスレベルを Google Drive (ドライブとドキュメント) に割り当てます。適用対象の組織部門が選択可能です。
この時点で、検証用 Mac 含む使用中の全デバイスで Google Drive へのアクセスがブロックされるようになりました。
ルート CA 証明書, 中間 CA 証明書のアップロード
デバイス証明書を発行する認証局 (ルート CA, 中間 CA) の証明書を Google Workspace へ登録します。このときに「エンドポイントの確認」を有効化します。
Chrome Enterprise 化
検証機の Chrome を Chrome Enterprise 化します。
当初は「ブラウザ管理機能を利用するため (後述する Endpoint Verification, AutoSelectCertificateForUrls を構成するため)」 だけに必要なのだと勘違いしたので(※)、いったん Chrome Enterprise 化せず検証を進めたのですが期待した動作とならず、この手順に戻ってきました。詳細は後述します。
※ ブラウザ管理機能であれば、Google Workspace の標準機能で対応可能です
設定に必要なテキストファイルをダウンロードし、検証用 Mac で /Library/Google/Chrome ディレクトリを作成・直下に同ファイルを保存した後、Chrome を再起動することで Chrome Enterprise に移行できました。
Jamf Pro を使って一括展開する方法はこちらの note が詳しいのでご紹介させていただきます。
Endpoint Verification (Chrome Extension) のインストール
Chrome にデバイスの情報を収集させるため Endpoint Verification をインストールします。これはデバイス証明書の利用有無にかかわらず、Context-Aware Access そのものを使うため必要な機能です。
Google Workspace の管理コンソールで自動インストール・以下 2 つを有効化するよう設定しました。
鍵へのアクセスを許可する
企業向けアプリの真正性確認を許可する
Chrome policy の設定 (AutoSelectCertificateForUrls)
Chrome policy の AutoSelectCertificateForUrls で、Context-Aware Access で利用するデバイス証明書を指定します。正確には「デバイス証明書を発行する認証局 (中間 CA)」を指定します。
このポリシーでは、Chrome でクライアント証明書を自動的に選択できるサイトを指定する URL パターンのリストを作成できます。値は文字列変換した JSON 辞書の配列で、それぞれ { "pattern": "$URL_PATTERN", "filter" : $FILTER } の形式で指定します。$URL_PATTERN は、コンテンツを設定するパターンです。$FILTER は、ブラウザで自動的に選択されるクライアント証明書の発行元を限定するフィルタです。なお、フィルタの設定にかかわらず、サーバーの証明書リクエストに一致する証明書のみが選択されます。
Google Workspace 管理コンソールで設定・適用しました。
{"pattern":"https://[*.][clients6.google.com]","filter":{"ISSUER":{"CN":"[クライアント証明書を発行する中間 CA]"}}}
(https://[*.]clients6.google.com なんだ〜 へぇ〜〜 と思うなど 👀)
(トラブルシューティング) デバイス証明書の情報が渡せない
ここで上述した「Chrome Enterprise 化が必要」な件に触れます。
Chrome Enterprise 化を除いて一通り設定したうえで Google Drive へアクセスしたところ、引き続きブロックされてしまいました。原因調査のため、Endpoint Verification のログを確認します。
Endpoint Verification のアイコンを右クリック - [ options ] をクリックします。
Troubleshooting 画面が表示されるので、Log Level を All に変更して SHOW LOG をクリックします。
(詳細は割愛しますが、Endpoint Verification のログを見ているとどんな情報がどの程度の頻度で送信されているのかわかっておもしろいです。)
ログを眺めていると ”[WARNING] No policy set to fetch device certificate." というメッセージを見つけました。どうやらデバイス証明書 の情報を取得するポリシーがうまく適用されていないようです。
結論ですが、AutoSelectCertificateForUrls ポリシーの構成 (ポリシーの適用レベル) に不備がありました。
ポリシー構成を確認するには、次の手順を実行します。
1. ブラウザで chrome://policy に移動します。
2. AutoSelectCertificateForUrls の構成値を確認します。
3. ポリシー[対象] の値が [マシン] に設定されていることを確認します。Chrome オペレーティング システムの場合、値は[Current User] に適用されます。
4. ポリシーの [ステータス] に [競合] がないことを確認します。
検証用 Mac で chrome://policy を確認すると、同ポリシーの適用対象が "Current user" となっていました。
試しに Chrome Enterprise 化してみると、適用先が "Machine" へ変更され、"[WARNING] No policy set to fetch device certificate." のログも出力されなくなりました。
※ もともと Current user レベルに適用されていたため、Status に Superseding (置換) と表示されていますが、後の動作確認上は問題ありませんでした。
というわけで「Chrome Enterprise は必要そう」という結論です。
Chrome が デバイス証明書へアクセスすることを許可
検証用 Mac で、Chrome がデバイス証明書へアクセスする許可を求められたので "Always Allow" をクリックします。
Google Drive にアクセスしてみる
一連の設定後、Chrome で Google Drive へのアクセスが可能となったことを確認できました。
あわせて、以下のケースでは Google Drive へのアクセスがブロックされることを確認しました。
別の Web ブラウザでの Google Workspace へログイン・Google Drive にアクセス (Safari, Firefox)
デバイス証明書の有効期限が切れた後は、 Chrome でアクセスしてもブロック
配布したデバイス証明書を削除すると、同様にブロックされる
2, 3 について補足ですが、既に Google Workspace へログイン中の状態でもデバイス証明書の失効・削除をトリガとしてアクセスがブロックされました。
最後に
限定したユースケースではありますが、Context-Aware Access でデバイス証明書を利用したアクセスレベルが機能することを確認できました。
設定に関するドキュメントが分散していることもあり試行錯誤しながらの検証でしたが、全体感がつかめれば 15 分程度で実現できてしまうのも魅力です。
実運用にのせるにはまだまだ検証が必要ですが、セキュリティと利便性の両立に活用できることを期待しています。
参考情報
既出もありますが、自分用にメモです。
Google 公式情報
いただいたサポートは記事を書くためのエネルギー(珈琲、甘いもの)に変えさせていただきます！