Google

HOME
office
Google
Google Workspaceで高度なアクセス制限を実現する

2023年7月7日 / 最終更新日時 : 2023年12月3日 officeの杜 Google

Google Workspaceで高度なアクセス制限を実現する

Google Workspaceを企業で利用してるケースで、ログインに関して特になんの手立ても講じないままノーマルのID/PWでのログインのままにしている企業は多いと思われます。しかし現代に於いて、単純なID/PWでの運用は限界に来ているのも事実で、先日もGoogle I/OでGoogle Workspaceへのログインにパスキーがサポートされたり、ログイン管理はより厳格により簡単にという二律背反を求められています。

そこで今回その手段の1つであるGoogle Workspace Enterprise Standard以上で利用可能なコンテキストアウェアアクセスを検証する機会があったので、まとめてみたいと思います（よって、規模300名以上の組織での利用手段になると思います）。

1 今回利用するサービス
2 事前準備
3 コンテキストアウェアアクセスの設定
4 関連動画
5 関連リンク

今回利用するサービス

コンテキストアウェアアクセス

利用できる条件がGoogle Workspace Enterprise Standard以上という事で、300名以下のBusiness StarterやStandardを利用してるような企業ではハードルが高い。しかし無償で利用が出来るという利点とこれそのものはシンプルであるという点は評価できます。

小規模組織の場合はアドオンサービスとなりますが、サテライトオフィスのシングルサインオン for Google Workspaceが同じようなことを実現出来、また高度な管理機能を取り込むことが可能です。

※自分のケースではこのサテライトオフィスの仕組みを現在利用していますが、これを解除してコンテキストアウェアアクセスで統合しようと考えて今回の検証を行っています。他に追加の契約等は不要です。

※2022年1月14日、デバイスポリシーやIPアドレス等での制限だけじゃなく、証明書を用いた手法も追加されました。

事前準備

サテライトオフィスSSOが入ってる場合

いざ、コンテキストアウェアアクセスを使いたいと思っても、自分のケースでは既にサテライトオフィスのSSOがGoogle Workspaceに設定されてしまっています。この設定は、以下の場所に入っており、組織部門単位ではなく現時点でテナント単位で適用されている状態でした。

Admin Consoleにログインする
左サイドバーからセキュリティ=>認証=>サードパーティの IdP による SSOを開く
組織向けのSSOプロファイルが入っており、サテライトオフィスの設定が入ってる状態。

ここで、すぐにコレをオフにしてコンテキストアウェアアクセスの設定にというわけにはいかないので、一時的に専用の組織部門を作成し、そこに検証用ユーザを所属させておき、同じページの下の方にある「SSOプロファイルの割当の管理」では、この組織部門だけはSSOプロファイルの割当については、「なし」に設定して通常のログイン処理にしておきました。

図：ここが設定箇所になる

図：特定組織部門だけ組織SSOを外しておく

Google Workspaceで安全に外部とファイルを共有する方法

iOSデバイスを管理したい場合

概要

Google Workspaceでのこれまでのコンテキストアウェアアクセスでは、以下の要件の組み合わせでアクセス制限を制御出来ていました。

IPサブネット
場所（国を指定する）
デバイス（会社のデバイスなどを指定）
デバイスのOS（OSのバージョンまで指定できる）

最もポピュラーなのが会社所有のデバイスのシリアルナンバーリストで制限するのが利用されており、macOS, Windows, Linux, Chrome OS, Androidが基本の対象で、一応iOSも管理対象に加えられるようになっています。しかし、iOSの場合別のMDMで管理している場合、デバイスリストを使ったアクセス制御はGoogle WorkspaceがMDMとなるためバッティングしてしまう為、この機能が使えなくなります。

また使える状態であっても、デバイス登録はGoogle Workspace上ではなくApple Business Manager上でデバイス登録をした上で、Google Workspace側でその情報を取得する設定を施す必要がありかなり面倒な仕組みです。Androidの場合はPC同様にデバイス登録が出来るのでここまで面倒なことはありません。

モバイルの詳細管理

iOSデバイスに於いて、MDM管理されてるわけじゃないということであるならば、モバイル詳細管理に於いては以下の作業も必要になります。これはMDM証明書と呼べるものなので、この登録は非常に面倒で1年毎に同じApple IDでの更新作業が必要（でないと、全端末初期化という大変なことになる）

モバイル詳細管理にて「詳細」に変更する必要がある
前述の詳細を有効化するには、iOS設定のAppleプッシュ通知サービスにて、Appleのプッシュ証明書をApple Push Certificate Portalにて登録が必要になる
結局はiOSの場合、Safariが証明書にアクセスできず、Chromeで証明書にアクセスさせるにはMDM管理が必要であるため、レンタルiPhoneのようなケースの場合現状この機能でコンテキストアウェアアクセスは使えない。

考えられる策は、iOSの場合だけは特定のクラウドプロキシを通過させるようにポリシーを設定し、そのクラウドプロキシのIPアドレスをもってして、コンテキストアウェアアクセスを利用するか？あきらめてiOSだけ別のソリューションに頼るか？になります。Androidだとこんな苦労しなくて済むのですが。

※また上記のクラウドプロキシを通過させた時には、iOSで接続させた場合、IPアドレスとOS情報でコンテキストアウェアアクセスで絞れば良い。テザリングさせてもリファラ情報はiOSにはならず使ってるPCの情報となるので、会社のPC以外からの接続は弾くことが可能。

※出口IP固定化できるクラウドプロキシとしては、IIJクラウドプロキシやMenlo Securityなどが対応しています(IPアドレス持ち込みもできるみたい）。

図：証明書で制御する方法が2022年に出てる

図：モバイル詳細管理画面

図：Appleプッシュ証明書

外部MDMへの対応

これまでのコンテキストアウェアアクセスはとりわけ、iPhoneなどのスマートデバイスの場合、MDMについてはGoogle Workspaceを利用しない場合管理できないという非常に不便な状態でした（そんな企業殆ど存在しないでしょうし、そもそもMDMは複数共存できない）。これはGoogleも結構苦労してるようなのですが、現在はJamfProには対応してるので、自社でiPhoneを購入し自社でJamfProでMDM管理してる場合、iPhoneに対してコンテキストアウェアアクセスが可能になっています。

ただ、これは人的リソースが必要となるので大企業以外ではちょっと現実的ではない（中小でも扱う数がわずかならば可能）。ある程度の規模になってる中小企業の場合、情シスでJamfProでiPhoneキッティングしてコンテキストアウェアアクセスも設定しては現実的ではないです。例えばソフトバンクのようなiPhoneを提供し、MDMまで一括でサービス提供してるものを利用してる企業は多いでしょうが、これが現在対象外になってるため、ソフトバンクユーザでビズコンシェルを使ってる場合には、まだコンテキストアウェアアクセスが使えません。

2024年以降、外部MDMへの対応を広げていくという噂があるので、その１つにソフトバンクのビズコンシェルが含まれるのを現在自分は待っている状態です。ぜひお願いしたい。

モニターモード

2023年10月17日、いきなりコンテキストアウェアアクセスを導入するのではなく、設定したらどのような弾き方をするのか？といったことをCAAの監査ログで確認できるモニターモードというものが導入されました。

デバッグというかいきなり本番に導入するには勇気と検証するのに時間的制限が生まれてしまっていたのでこれは地味に管理者にとっては嬉しい機能。

アクセスレベルの設定時のポリシー画面で、モニターモードにチェックを入れて保存するだけです。

コンテキストアウェアアクセスの設定

共通項目

Chome Enterprise化

Chromeからのログイン制御は、Google Workspaceの管理対象ブラウザとして追加することが必須です。ポリシー設定も追加で必要となるため、以下のエントリーを参考に事前にChromeを管理対象として制御できるようにしておく必要があります。

Google Chromeを組織管理下に置く方法

Chrome拡張機能の配信と追加

PCの場合、各ユーザのChromeに対して「Endpoint Verification」の拡張機能をインストールする必要があります。常時インベントリでデバイスの情報を送る為の拡張機能で、これをインストールしていない場合、そのChromeではGoogle Workspaceにログインする事が出来ません。

ユーザまかせだと従わない者が出てくるので、Google WorkspaceからChromeを管理下に置き、拡張機能を強制インストールするように配布するようにしましょう。拡張機能はクリックするとSyncというボタンがあるのでクリックするだけでオッケー。

前述のChrome Enterprise化でEndpoint Verificationを強制配信するように追加し、詳細設定に於いて以下の設定を有効化します

鍵へのアクセスを許可する
企業向けアプリの真正性確認を許可する

iOSやAndroidでは入れようがないので不要です。

図：拡張機能の強制配信設定

iOS端末の制限

コンテキストアウェアアクセスについて、非常に情報が少ないのですが、デバイスポリシーの制限（会社所有のデバイスで行う場合）に於いては、Google Workspace自身がMDM機能を持ってしまっている為、例えば他のMDM（ソフトバンクのビジネスコンシェル等）と共存が出来ません。よって、この場合iOSはデバイスポリシーでの制限で制御する事が出来ない為、PCのみとなってしまい、iOSからのログインを制御出来ません。

IPアドレスであったり、アクセス元地域での制限はこの限りではないのですが、この制御方法では大雑把すぎる。よって、前述のiOSデバイスを管理したいの項目にある「クラウドプロキシで出口のIPを固定化し、IPアドレスとiOSであることを条件にコンテキストアウェアアクセスで制限する」といった手法を取ることになるでしょう。

APIアクセスも制御可能に

これまでのコンテキストアウェアアクセスは、ログイン制御ではなく特定のアプリケーションへのアクセス制御を行う為の仕組みということでリリースされてきました。その為利用目的は各種Googleアプリケーションへのアクセスをどうするか？であって、APIでのアクセスについては制御対象外でした。これでは穴になってしまう。ということで、2023年8月11日より、APIアクセスに関してもコンテキストアウェアアクセスの制御対象になりました。

設定に関する詳細なドキュメントはこちら。

会社所有のデバイスで行う場合

デバイスの制限方法

コンテキストアウェアアクセスの肝になる部分の設定からまず行っていきます。組織部門単位で有効化できるので、まずは実験的な組織部門を用意してそちらに対して、適用するようにしましょう。

Admin Consoleへログインする
左サイドバーからセキュリティ=>アクセスとデータ管理=>コンテキストウェアアクセスを開く（アクセスレベルを開く）
アクセスレベルの作成をクリック
適当な名前を付ける（今回は会社端末だけ許可と命名）
下の基本にある条件を追加をクリックする
全ての属性と一致するにチェックを入れて「デバイス」=> 「会社所有」とする
作成をクリック
ルール作成が出る
組織部門を選択して続行をクリックする
アプリでは全部にチェックをいれて続行する
条件は空っぽのまま続行をクリックする
操作では監査および外部共有をブロックのみとして続行をクリック
作成をクリックすると、左サイドバーのルールに作成される

図：会社所有デバイスを条件にする

図：適用する組織部門を選択する

会社所有端末の登録

会社所有のデバイスは現在空になってるハズです。そこで、CSVデータを持って、以下の手順でデバイスを登録します。このダイアログで登録出来るのは

macOS
Android
Windows
Chrome OS
Linux

の5種類です。iOSデバイスは登録出来ません。前述にあるように、ABMからの連携で取得できるようになっています。手順的には

会社所有のインベントリにアクセスする
右上の＋アイコン（会社所有デバイスのインポート）をクリックする
デバイスはWindowsを選択インポート用テンプレートをダウンロードすると現在、このリストにいないデバイスを登録する事が出来ます。よって既に承認済みとなってるデバイスは登録済みということになります。
4.シリアルナンバーとasset tagという２列しかないので、シリアルナンバーとデバイス名だけを入れてCSVとしてアップするだけです。
画面をリロードすると登録したデバイスが出てくる

※デバイスから開くと現在承認済みのデバイス一覧が出てくるのでダウンロードすると楽。実はGoogle Workspaceは普段からデバイスの詳細なインベントリを取得してるので、インベントリ取得ソリューション等不要だったりします。ここにはiPhoneのインベントリも特に設定なく収集されています。

図：CSVでデバイスのシリアル登録

アクセスレベルの割当

コンテキストアウェアアクセスはログイン制限というよりも、アクセス制限の為の仕組みで、制限する項目はアプリ単位で行います。基本は全部のアプリに対して制限を掛けるのが定石です。ここまで準備が整ったら以下の作業を行い、アプリ毎の制限を行います。

アクセスレベルの割り当てを開く
組織部門を選択する
制限を掛けたアプリにチェックを入れて、上部にある「割り当て」をクリックする
会社端末たけ許可にチェックをいれて続行する（これが出てこない場合、前述のどこかが間違ってると思われます）
「アクセスレベルの要件を満たしていない場合、ユーザーが Google のデスクトップアプリやモバイルアプリにアクセスできないようブロックする」にチェックが入ってるままにして、続行をクリックする
割当をクリックする
基本この設定を使用してる全アプリに適用していく
「アクセスレベル」が「1 個をローカルに適用しました」に変更されたら成功

図：アプリ毎に適用する

図：会社端末だけ許可にチェック

コンテキストアウェアアクセスを有効化

ここまでで準備が整いました。最後に、以下の作業を行ってコンテキストアウェアアクセスを有効化する事で制限が適用されます。指定の組織部門に所属してるユーザに対してだけ有効化するので、適用する部門やテストを入念に行いましょう（でないと、全員規制されて管理者ですらログインできなくなってしまいます）。

会社所有端末にリストがあり、インベントリが取得できてる端末以外の端末からログインしようとすると以下のような画像が表示されて、アクセスを制限されます。この時表示されるメッセージ等はこちらから変更することが可能です。

※Google Driveアプリなどのデスクトップアプリも問題なく動作しました（これはOAuth2認証であるため、コンテキストアウェアアクセスの対象外なのです。但し、SAML認証はコンテキストウェアアクセスの対象になります）

図：指定端末以外からアクセスすると表示されなくなる

証明書を使って行う場合

2022年1月から、デバイスに対して配布した証明書を用いてのコンテキストアウェアアクセス制御が出来るようになりました。こちらの場合デバイスのシリアル管理をせずに済む点と、MDMで管理するわけではない為、iOSデバイスもPCも同じ手法でアクセス制御を掛けられる為、現在調査中。会社所有デバイスリストとは全く違った手順となる点と、証明書および中間証明書が別途必要、Chrome Enterprise化で管理下に置く必要という点で、より高度なテクニックが必要です。

※サテライトオフィスにも証明書ログインの仕組みがあるにはあるのですが、証明書は個別に発行が必要であり、ユーザがリクエストしてユーザが証明書をインストールする作業が必要であるため煩雑です（故に使いたくない）。

証明書の準備

ルートCAおよび中間CAの２つの証明書が必要になります。公式の手順によるとこれらをアップロードしておきます。今回は社内にあるプライベートなCAを発行できるWindows Server2台からルートCAと中間CAから証明書をエクスポートして発行しました。通常は外部の証明書発行サービス（CyberTrustなど）にお金を払って購入する事になるかと思います。証明書は期限があるので、期限切れとなるとログインが出来なくなる為、管理者のアドレスはコンテキストアウェアアクセスの対象から外したほうが良いかと思います。

エクスポートされた拡張子がcerの証明書ファイルを以下の手順でアップロードします。

Admin Consoleにログインする
左サイドバーからデバイス=>ネットワークを開きます。
証明書をクリックする
組織部門を選択します。テストの時には最小限の組織部門だけを選んで設定すべきでしょう。
証明書を追加をクリックする
名前とダウンロードしておいたcerファイルを指定します。
認証局は「エンドポイントの確認」にチェックを入れて追加をクリックします。

この時、中間CAのcerファイルのコモンネームを控えておく必要があります。cerファイルをダブルクリック=>発行先の情報がコモンネームになります。また、こちらのサイトで中身を貼り付けて解析しても知ることが可能です。

図：無事にアップロードされました。

図：エンドポイントの確認にチェックを入れる

図：コモンネームを調べておく

Chrome Policyの配信

以下の手順で証明書の参照を行うChrome Policyを設定する必要があります。以下の手順でセットします。

Admin Consoleへログインする
左サイドバーからデバイス=>Chrome=>設定=>ユーザとブラウザを開く
検索で「クライアント証明書」で検索すると、コンテンツにクライアント証明書という項目があるのでクリックする
適用する組織部門を選択する
設定欄に以下のような構文を記述する

{"pattern":"https://[*.]clients6.google.com","filter":{"ISSUER":{"CN":"中間CAのコモンネーム"}}}

1

{"pattern":"https://[*.]clients6.google.com","filter":{"ISSUER":{"CN":"中間CAのコモンネーム"}}}

控えておいた中間CAのコモンネームを含めて記述します。
保存をクリックする

この設定値がChrome PolicyのAutoSelectCertificateForUrlsとしてセットされます。

図：クライアント証明のポイント

Policy適用状況を確認する

Chromeを一旦閉じて、再度起動し、chrome://policyを開いたら、AutoSelectCertificateForUrlsが適用先として「マシン」でセットされていればポリシーがきちんと適用されています。

図：無事にポリシーが適用された

デバイスの制限方法

さて、ここまで準備が出来たらいよいよ、コンテキストアウェアアクセスで、証明書を使った制御をアクセスレベルを使って構築します。

Admin Consoleへログインする
左サイドバーからセキュリティ=>アクセスとデータ管理=>コンテキストウェアアクセスを開く（アクセスレベルを開く）
アクセスレベルの作成をクリック
適当な名前を付ける（今回は証明書で制限と命名）
今回は「詳細」をクリックして、「Common Expression Language」で記述を行います

device.certificates.exists(cert, cert.is_valid && cert.issuer == "CN=中間CAのコモンネーム")

1

device.certificates.exists(cert, cert.is_valid && cert.issuer == "CN=中間CAのコモンネーム")

ここでも、前述で利用していた中間CAの証明書のコモンネームを記述する必要があります。
作成をクリック
ルールを作成をクリックする
組織部門を選択して続行をクリックする
アプリでは全部にチェックをいれて続行する
条件は空っぽのまま続行をクリックする
操作では監査および外部共有をブロックのみとして続行をクリック
作成をクリックすると、左サイドバーのルールに作成される

図：複数の条件をCEL言語で記述する

アクセスレベルの割り当て

デバイスリストを使ったケースと同様に、前述のコンテキストウェアアクセスの設定を持ってアクセスレベルの設定を行います。但し今回はデバイスリストではないので、途中異なる部分があるので注意。

アクセスレベルの割り当てを開く
組織部門を選択する
制限を掛けたアプリにチェックを入れて、上部にある「割り当て」をクリックする
証明書で制限が出てくるのでチェックを入れる
「アクセスレベルの要件を満たしていない場合、ユーザーが Google のデスクトップアプリやモバイルアプリにアクセスできないようブロックする」にチェックが入ってるままにして、続行をクリックする
割当をクリックする
基本この設定を使用してる全アプリに適用していく
「アクセスレベル」が「1 個をローカルに適用しました」に変更されたら成功

図：証明書で制限をクリック

Google Workspaceで高度なアクセス制限を実現する

今回利用するサービス