Google Workspaceで高度なアクセス制限を実現する
Google Workspaceを企業で利用してるケースで、ログインに関して特になんの手立ても講じないままノーマルのID/PWでのログインのままにしている企業は多いと思われます。しかし現代に於いて、単純なID/PWでの運用は限界に来ているのも事実で、先日もGoogle I/OでGoogle Workspaceへのログインにパスキーがサポートされたり、ログイン管理はより厳格により簡単にという二律背反を求められています。
そこで今回その手段の1つであるGoogle Workspace Enterprise Standard/Cloud Identity Premium以上で利用可能なコンテキストアウェアアクセスを検証する機会があったので、まとめてみたいと思います(よって、規模300名以上の組織での利用手段になると思います)。
目次
今回利用するサービス
利用できる条件がGoogle Workspace Enterprise Standard以上という事で、300名以下のBusiness StarterやStandardを利用してるような企業ではハードルが高い。しかし無償で利用が出来るという利点とこれそのものはシンプルであるという点は評価できます。
小規模組織の場合はアドオンサービスとなりますが、サテライトオフィスのシングルサインオン for Google Workspaceが同じようなことを実現出来、また高度な管理機能を取り込むことが可能です。
※自分のケースではこのサテライトオフィスの仕組みを現在利用していますが、これを解除してコンテキストアウェアアクセスで統合しようと考えて今回の検証を行っています。他に追加の契約等は不要です。
※2022年1月14日、デバイスポリシーやIPアドレス等での制限だけじゃなく、証明書を用いた手法も追加されました。
※Enterprise Standard / Cloud Identity Premium以上が必要になりますが、Enterprise Standardが導入済みテナントであればCloud Identity Freeのアカウントに対してもコンテキストアウェアアクセスは有効に出来ます。
事前準備
サテライトオフィスSSOが入ってる場合
いざ、コンテキストアウェアアクセスを使いたいと思っても、自分のケースでは既にサテライトオフィスのSSOがGoogle Workspaceに設定されてしまっています。この設定は、以下の場所に入っており、組織部門単位ではなく現時点でテナント単位で適用されている状態でした。
- Admin Consoleにログインする
- 左サイドバーからセキュリティ=>認証=>サードパーティの IdP による SSOを開く
- 組織向けのSSOプロファイルが入っており、サテライトオフィスの設定が入ってる状態。
ここで、すぐにコレをオフにしてコンテキストアウェアアクセスの設定にというわけにはいかないので、一時的に専用の組織部門を作成し、そこに検証用ユーザを所属させておき、同じページの下の方にある「SSOプロファイルの割当の管理」では、この組織部門だけはSSOプロファイルの割当については、「なし」に設定して通常のログイン処理にしておきました。
図:ここが設定箇所になる
図:特定組織部門だけ組織SSOを外しておく
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への対応を広げていくという噂があるので、その1つにソフトバンクのビズコンシェルが含まれるのを現在自分は待っている状態です。ぜひお願いしたい。
モニターモード
2023年10月17日、いきなりコンテキストアウェアアクセスを導入するのではなく、設定したらどのような弾き方をするのか?といったことをCAAの監査ログで確認できるモニターモードというものが導入されました。
デバッグというかいきなり本番に導入するには勇気と検証するのに時間的制限が生まれてしまっていたのでこれは地味に管理者にとっては嬉しい機能。
アクセスレベルの設定時のポリシー画面で、モニターモードにチェックを入れて保存するだけです。
コンテキストアウェアアクセスの設定
共通項目
Chome Enterprise化
Chromeからのログイン制御は、Google Workspaceの管理対象ブラウザとして追加することが必須です。ポリシー設定も追加で必要となるため、以下のエントリーを参考に事前に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であることを条件にコンテキストアウェアアクセスで制限する」といった手法を取ることになるでしょう。
制限できるアプリ
コンテキストアウェアアクセスはログイン制御ではなくアプリへのアクセス制御なのですが、アクセス禁止に出来るアプリは「コアサービスの14種類」となっています。GmailやDriveなど(Gemini AppやLooker Studioも対象です)。AppSheetやNotebook LMなどは対象外となっています。
よって、ノンコアサービスであるその他のGoogleサービスについてはアクセス制御が出来ません。これら含めての制御をしたいとなった場合にはコンテキストアウェアアクセスの上位版であるChrome Enterprise Premium(旧Beyond Corp)を利用したアクセス制御でなければ出来ないのではないかと思います。
図:制御できるのはWorkspaceアプリに限られる
APIアクセスも制御可能に
これまでのコンテキストアウェアアクセスは、ログイン制御ではなく特定のアプリケーションへのアクセス制御を行う為の仕組みということでリリースされてきました。その為利用目的は各種Googleアプリケーションへのアクセスをどうするか?であって、APIでのアクセスについては制御対象外でした。これでは穴になってしまう。ということで、2023年8月11日より、APIアクセスに関してもコンテキストアウェアアクセスの制御対象になりました。
設定に関する詳細なドキュメントはこちら。
SAMLアプリについて
カスタムSAMLアプリについてもコンテキストアウェアアクセスの制限対象になっています。しかし注意しなければならない点がいくつかあります。
- Google AnalyticsなどはSAMLではなく内部のノンコアサービスなのでSAMLアプリではない
- コアサービスのアプリについては常に評価が実行されてる(少しでも条件と違う場所になったらアクセス拒否されます)
- SAMLアプリはログオン時にだけ評価が実行される(Googleのセッションが切れるまでは場所を移動してもアクセス拒否されません)
評価タイミングと基準が異なる為、注意が必要です。また例えばノンコアサービスのGoogle Analyticsをコンテキストアウェアアクセスで制御したくても出来ません。Looker Studioについてはコアサービスになってるため制御が可能。
Google AnalyticsをIP制限かけたいといった場合には、Analyticsの対象テナントに対して個別にユーザの追加をすることだけで、IPアドレスで制限等は出来ません(Chrome Enterprise Premiumだったら出来るかもですが)
Admin Consoleアプリ
いつの間にやらですが、コンテキストウェアアクセスにて「管理コンソール」も規制対象に入れることが出来るようになっています。故に管理コンソールに入る場合には、コンテキストアウェアアクセスの要件を満たしていないと入ることが出来ないようにすることが可能です。
しかし、他のアプリの規制と異なり、管理コンソールに入って作業をする人は特権管理者やユーザ管理者といった限定された人間である点や、もし誤った規制をセットしてしまうとどうなってしまうのか?調査してみました。尚、公式では複数管理者が存在していて、他の管理者を規制する場合を除き設定しないでねと書いてあります。
- IPアドレスを現在のIPとは違うものをセットしようとすると、「要件を満たしていない」としてアクセスレベルの編集続行を拒否されます。
- すでに割り当て済みとなってしまってる場合、全部解除しないとアクセスレベルの編集は出来ません。
- 仮にもIP制限にて設定時はOKなIPであっても、後にそのIPでは駄目という環境になってしまうと「ロックアウト」されてしまい管理コンソールに入れません
さて、ロックアウトされた場合どうするのか?といったら2パターンあり
- Google カスタマーケア ポータルにアクセスして、Googleに解除をしてもらう(但し対象ユーザにこのポータルへのアクセス権限が必要です)
- 販売パートナー経由であれば、パートナー側から対象の管理コンソールに「コンテキストアウェアアクセスが有効」になっていたとしても入れるので、そちらで解除してもらう
管理コンソールへのログイン規制に関してはこのようにリスクがありますので、よく設定を見直してから有効にする必要があります。IPアドレス制限は単純なのでまだ良いですが、デバイスのシリアル番号や証明書などで規制となると厄介なので、有効にする場合はよーく確認してから実行しましょう。
図:設定時にアクセスできないIPは指定出来ない
図:割当中はアクセスレベルは編集出来ない
IPアドレスとOSで制限を行う場合
コンテキストアウェアアクセスでもっとも手軽で簡単な設定パターンとしては「会社の出口IPアドレス + 端末のOS」で制限することです。このパターンの場合、IP制限だけであれば後述の方法のようにEndpoint Verification拡張機能の配布(またChrome Enterprise化)が必要ありません。OSが条件に加わるとEndpoint Verificationが必要になります。
出口アドレスは例えばプロキシーサーバのアドレスなどが該当します(確認くんなどで検証できます)。出口IPアドレスが固定であるならば会社内部からのアクセスということで絞ることが出来、またスマートフォンなどからはアクセスさせないということでOSで縛ることも可能です。
-
Admin Consoleへログインする
-
左サイドバーからセキュリティ=>アクセスとデータ管理=>コン
テキストウェアアクセスを開く(アクセスレベルを開く) -
アクセスレベルの作成をクリック
-
適当な名前を付ける(今回は会社端末だけ許可と命名)
-
下の基本にある条件を追加をクリックする
- 全ての属性と一致するにチェックを入れて「デバイスのOS」=> 「Windows」とする(バージョンを指定も可能)
- 属性を追加をクリック
- IPサブネットを選択して、次に一致にてIPアドレスもしくはCIDR形式のIPレンジを入れる
-
作成をクリック
-
ルール作成が出る
-
組織部門を選択して続行をクリックする
-
アプリでは全部にチェックをいれて続行する
- 割当をクリックする
- 左側でアクセスレベルを選択する
- 右側でアクティブにチェックをいれる
- 続行をクリック
- その他の適用設定は全部チェックを入れて続行をクリックする
- 最後に割当をクリックする
但し、注意点としてIPで制限を掛ける場合には、設定時にそのIPレンジ内に設定者がいないと「設定して有効化」することが出来ません。よって、事前に設定しておいて・・といったことが出来ません。
また、IPレンジで縛って有効化をいざ実行した場合、のちにネットワークがそのIPレンジを外れるような設定変更をしてしまうと全員がロックアウトされる恐れがあります。ロックアウトしてしまった場合はパートナー等で解除することは可能ですので、設定時は連絡先などを事前に把握した状態で行うようにしましょう。
パートナー契約ではなくGoogle直契約時の場合にはカスタマーケアポータルから申請が出来ますが、ここに対するアクセス権の事前設定が必要になる為、抜かりなく把握した上で設定を行うようにしてください。
図:IPとOSで制限する
図:アクセスレベルの割当
会社所有のデバイスで行う場合
デバイスの制限方法
コンテキストアウェアアクセスの肝になる部分の設定からまず行っていきます。組織部門単位で有効化できるので、まずは実験的な組織部門を用意してそちらに対して、適用するようにしましょう。
-
Admin Consoleへログインする
-
左サイドバーからセキュリティ=>アクセスとデータ管理=>コン
テキストウェアアクセスを開く(アクセスレベルを開く) -
アクセスレベルの作成をクリック
-
適当な名前を付ける(今回は会社端末だけ許可と命名)
-
下の基本にある条件を追加をクリックする
-
全ての属性と一致するにチェックを入れて「デバイス」=> 「会社所有」とする
-
作成をクリック
-
ルール作成が出る
-
組織部門を選択して続行をクリックする
-
アプリでは全部にチェックをいれて続行する
-
条件は空っぽのまま続行をクリックする
-
操作では監査および外部共有をブロックのみとして続行をクリック
-
作成をクリックすると、左サイドバーのルールに作成される
図:会社所有デバイスを条件にする
図:適用する組織部門を選択する
会社所有端末の登録
会社所有のデバイスは現在空になってるハズです。そこで、CSVデータを持って、以下の手順でデバイスを登録します。このダイアログで登録出来るのは
- macOS
- Android
- Windows
- Chrome OS
- Linux
の5種類です。iOSデバイスは登録出来ません。前述にあるように、ABMからの連携で取得できるようになっています。手順的には
-
会社所有のインベントリにアクセスする
-
右上の+アイコン(会社所有デバイスのインポート)
をクリックする -
デバイスはWindowsを選択インポート用テンプレートをダウンロードすると現在、
このリストにいないデバイスを登録する事が出来ます。 よって既に承認済みとなってるデバイスは登録済みということにな ります。 -
4.シリアルナンバーとasset tagという2列しかないので、
シリアルナンバーとデバイス名だけを入れてCSVとしてアップす るだけです。 -
画面をリロードすると登録したデバイスが出てくる
※デバイスから開くと現在承認済みのデバイス一覧が出てくるので
図:CSVでデバイスのシリアル登録
アクセスレベルの割当
コンテキストアウェアアクセスはログイン制限というよりも、アクセス制限の為の仕組みで、制限する項目はアプリ単位で行います。基本は全部のアプリに対して制限を掛けるのが定石です。ここまで準備が整ったら以下の作業を行い、アプリ毎の制限を行います。
-
アクセスレベルの割り当てを開く
-
組織部門を選択する
-
制限を掛けたアプリにチェックを入れて、上部にある「割り当て」をクリックする
-
会社端末たけ許可にチェックをいれて続行する(これが出てこない場合、前述のどこかが間違ってると思われます)
-
「アクセスレベルの要件を満たしていない場合、ユーザーが Google のデスクトップ アプリやモバイルアプリにアクセスできないようブロックする」にチェックが入ってるままにして、続行をクリックする
-
割当をクリックする
-
基本この設定を使用してる全アプリに適用していく
-
「アクセスレベル」が「1 個をローカルに適用しました」に変更されたら成功
図:アプリ毎に適用する
図:会社端末だけ許可にチェック
コンテキストアウェアアクセスを有効化
ここまでで準備が整いました。最後に、以下の作業を行ってコンテキストアウェアアクセスを有効化する事で制限が適用されます。指定の組織部門に所属してるユーザに対してだけ有効化するので、適用する部門やテストを入念に行いましょう(でないと、全員規制されて管理者ですらログインできなくなってしまいます)。
会社所有端末にリストがあり、インベントリが取得できてる端末以外の端末からログインしようとすると以下のような画像が表示されて、アクセスを制限されます。この時表示されるメッセージ等はこちらから変更することが可能です。
※Google Driveアプリなどのデスクトップアプリも問題なく動作しました(これはOAuth2認証であるため、コンテキストアウェアアクセスの対象外なのです。但し、SAML認証はコンテキストウェアアクセスの対象になります)
図:指定端末以外からアクセスすると表示されなくなる
証明書を使って行う場合
2022年1月から、デバイスに対して配布した証明書を用いてのコンテキストアウェアアクセス制御が出来るようになりました。こちらの場合デバイスのシリアル管理をせずに済む点と、MDMで管理するわけではない為、iOSデバイスもPCも同じ手法でアクセス制御を掛けられる為、現在調査中。会社所有デバイスリストとは全く違った手順となる点と、証明書および中間証明書が別途必要、Chrome Enterprise化で管理下に置く必要という点で、より高度なテクニックが必要です。
※サテライトオフィスにも証明書ログインの仕組みがあるにはあるのですが、証明書は個別に発行が必要であり、ユーザがリクエストしてユーザが証明書をインストールする作業が必要であるため煩雑です(故に使いたくない)。
証明書の準備
ルートCAおよび中間CAの2つの証明書が必要になります。公式の手順によるとこれらをアップロードしておきます。今回は社内にあるプライベートなCAを発行できるWindows Server2台からルートCAと中間CAから証明書をエクスポートして発行しました。通常は外部の証明書発行サービス(CyberTrustなど)にお金を払って購入する事になるかと思います。証明書は期限があるので、期限切れとなるとログインが出来なくなる為、管理者のアドレスはコンテキストアウェアアクセスの対象から外したほうが良いかと思います。
エクスポートされた拡張子がcerの証明書ファイルを以下の手順でアップロードします。
- Admin Consoleにログインする
- 左サイドバーからデバイス=>ネットワークを開きます。
- 証明書をクリックする
- 組織部門を選択します。テストの時には最小限の組織部門だけを選んで設定すべきでしょう。
- 証明書を追加をクリックする
- 名前とダウンロードしておいたcerファイルを指定します。
- 認証局は「エンドポイントの確認」にチェックを入れて追加をクリックします。
この時、中間CAのcerファイルのコモンネームを控えておく必要があります。cerファイルをダブルクリック=>発行先の情報がコモンネームになります。また、こちらのサイトで中身を貼り付けて解析しても知ることが可能です。
図:無事にアップロードされました。
図:エンドポイントの確認にチェックを入れる
図:コモンネームを調べておく
Chrome Policyの配信
以下の手順で証明書の参照を行うChrome Policyを設定する必要があります。以下の手順でセットします。
- Admin Consoleへログインする
- 左サイドバーからデバイス=>Chrome=>設定=>ユーザとブラウザを開く
- 検索で「クライアント証明書」で検索すると、コンテンツにクライアント証明書という項目があるのでクリックする
- 適用する組織部門を選択する
- 設定欄に以下のような構文を記述する
1{"pattern":"https://[*.]clients6.google.com","filter":{"ISSUER":{"CN":"中間CAのコモンネーム"}}}
控えておいた中間CAのコモンネームを含めて記述します。 - 保存をクリックする
この設定値がChrome PolicyのAutoSelectCertificateForUrlsとしてセットされます。
図:クライアント証明のポイント
Policy適用状況を確認する
Chromeを一旦閉じて、再度起動し、chrome://policyを開いたら、AutoSelectCertificateForUrlsが適用先として「マシン」でセットされていればポリシーがきちんと適用されています。
図:無事にポリシーが適用された
デバイスの制限方法
さて、ここまで準備が出来たらいよいよ、コンテキストアウェアアクセスで、証明書を使った制御をアクセスレベルを使って構築します。
-
Admin Consoleへログインする
-
左サイドバーからセキュリティ=>アクセスとデータ管理=>コン
テキストウェアアクセスを開く(アクセスレベルを開く) -
アクセスレベルの作成をクリック
-
適当な名前を付ける(今回は証明書で制限と命名)
- 今回は「詳細」をクリックして、「Common Expression Language」で記述を行います
1device.certificates.exists(cert, cert.is_valid && cert.issuer == "CN=中間CAのコモンネーム")
ここでも、前述で利用していた中間CAの証明書のコモンネームを記述する必要があります。 -
作成をクリック
- ルールを作成をクリックする
-
組織部門を選択して続行をクリックする
-
アプリでは全部にチェックをいれて続行する
-
条件は空っぽのまま続行をクリックする
-
操作では監査および外部共有をブロックのみとして続行をクリック
-
作成をクリックすると、左サイドバーのルールに作成される
図:複数の条件をCEL言語で記述する
アクセスレベルの割り当て
デバイスリストを使ったケースと同様に、前述のコンテキストウェアアクセスの設定を持ってアクセスレベルの設定を行います。但し今回はデバイスリストではないので、途中異なる部分があるので注意。
-
アクセスレベルの割り当てを開く
-
組織部門を選択する
-
制限を掛けたアプリにチェックを入れて、上部にある「割り当て」をクリックする
-
証明書で制限が出てくるのでチェックを入れる
-
「アクセスレベルの要件を満たしていない場合、ユーザーが Google のデスクトップ アプリやモバイルアプリにアクセスできないようブロックする」にチェックが入ってるままにして、続行をクリックする
-
割当をクリックする
-
基本この設定を使用してる全アプリに適用していく
-
「アクセスレベル」が「1 個をローカルに適用しました」に変更されたら成功
図:証明書で制限をクリック
関連動画
関連リンク
- G Suite で使用するコンテキストアウェア アクセスをグループ別に管理
- [やってみた]BCDMシングルサインオン機能と連携させてGoogleWorkspaceのパスワードレス(デバイス証明書)認証環境を構築してみた
- Apple プッシュ証明書を設定する
- ユースケース: 管理対象の Chrome ブラウザの適用
- これらのサイトのクライアント証明書を自動的に選択する
- Chrome - クライアント証明書を自動選択する
- Apple Business ManagerとGoogle Workspaceを連携する
- モバイルの詳細管理を設定する
- デバイス毎のデフォルトMDMサーバー設定
- 会社所有の iOS デバイスの管理を設定する
- エンタープライズ証明書の条件の構成
- 管理対象デバイスのデジタル証明書を追加して割り当てる
- エンタープライズ CA テスト証明書
- Chrome デバイスで TLS(SSL)インスペクションを設定する 証明書を設定する
- カスタム アクセスレベルの仕様(CEL言語で判定)
- CEL言語 - Language Definition
- 【AD CS基礎】エンタープライズCAでの証明書の発行の仕組み
- Active Directory証明書サービス(AD CS)でオレオレ認証局(エンタープライズCA)を構築する
- Windows Server に中間認証局の証明機関を構成する (Windows Server Tips)
- Windows Serverのワークフォルダー機能で証明書を自動的に更新する
- MDM(モバイルデバイス管理)とは?管理者が知っておくべきポイントと Google Workspace のデバイス管理を解説
- スマホに「5年間のセキュリティアップデート」と「3年間のOSアップデート」を義務付ける法案がEUで検討中