Chrome Enterprise Premium の重要な原則は、「サービスへのアクセス権限は、ユーザーとそのデバイスについてサービス提供側が知っている情報に基づき付与される」ことです。単一のユーザーまたは単一のデバイスに付与されるアクセスレベルは、複数のデータソースを照会することで動的に推定されます。この信頼レベルは、意思決定プロセスの一部として使用できます。
信頼性評価プロセスにおける重要な要素は、ユーザーのログイン認証情報の安全度です。この場合、特定の種類のアプリケーションへのアクセスは、ユーザーがシステムに認証された方法によって決まります。たとえば、パスワードだけでログインしたユーザーは機密情報を含まないアプリケーションにのみアクセスできるのに対し、第 2 要素としてハードウェア セキュリティ キーを使用してログインしたユーザーは、最も機密性の高いエンタープライズ アプリケーションにアクセスできます。
認証情報の安全度に基づくポリシーは、認証プロセス中に使用される認証情報の安全度に基づいて、企業によるアクセス制御を可能にする機能です。アクセス制御ポリシーの別の条件として認証情報の安全度を利用することで、企業はハードウェア セキュリティ キー、2 段階認証プロセス、その他の形式の強固な認証情報に基づいてアクセス制御を実施できます。
認証情報の安全度に関するポリシーの概要
Access Context Manager を使用すると、Google Cloud 組織管理者は、Google Cloud のプロジェクトとリソースに対するきめ細かい属性ベースのアクセス制御を定義できます。
アクセスレベルは、リクエストのコンテキスト情報に基づいてリソースへのアクセスを許可するために使用されます。アクセスレベルを使用すると、信頼階層の編成を開始できます。たとえば、High_Level というアクセスレベルを作成して、高い権限を持つユーザーの少人数のグループからのリクエストを許可できます。 リクエストを許可する IP 範囲など、信頼できるより一般的なグループを特定することもできます。その場合、Medium_Level というアクセスレベルを作成して、これらのリクエストを許可します。
Access Context Manager では、ベーシックとカスタムの 2 種類のアクセスレベルを定義できます。現在、認証情報の安全度の確認には、カスタム アクセスレベルを使用しています。 ユーザー認証で使用される認証情報の安全度に関する情報は、Google のログイン プロセスで取得されます。この情報はキャプチャされ Google のセッション ストレージ サービスに保存されます。
認証情報の安全度チェックは現在、Identity-Aware Proxy、TCP 用 Identity-Aware Proxy、Google Workspace でサポートされています。
認証情報の安全度のポリシーを構成する
Access Context Manager のカスタム アクセスレベル定義を使用して、適切なポリシーを設定できます。カスタム アクセスレベルでは、Common Expression Language（CEL）のサブセットで作成されたブール式を使用して、リクエストを発行するクライアントの属性をテストします。
Google Cloud コンソールでは、アクセスレベルを作成するときに、詳細モードでカスタム アクセスレベルを構成できます。カスタム アクセスレベルを作成するには、次の手順を行います。
- Google Cloud コンソールで、[Access Context Manager] ページを開きます。
- プロンプトが表示されたら、組織を選択します。
- [Access Context Manager] ページの上部にある [新規] をクリックします。
- [新しいアクセスレベル] ペインで、次の操作を行います。
- [アクセスレベルのタイトル] ボックスに、アクセスレベルのタイトルを入力します。タイトルは最大 50 文字です。先頭は英字にしてください。その後には、数字、英字、アンダースコア、スペースのみ使用できます。
- [条件の作成] で、[詳細モード] を選択します。
- [条件] セクションで、カスタム アクセスレベルの式を入力します。条件は、1 つのブール値に解決される必要があります。Common Expression Language（CEL）のサポートとカスタム アクセスレベルの例と詳細については、カスタム アクセスレベルの仕様をご覧ください。
- [保存] をクリックします。
サポートされている認証情報の安全度の値
| 値 | Google の定義 | カスタム アクセスレベルの例 |
|---|---|---|
pwd |
ユーザーはパスワードで認証されます。 | request.auth.claims.crd_str.pwd == true |
push |
モバイル デバイスへのプッシュ通知でユーザーは認証されます。 | request.auth.claims.crd_str.push == true |
sms |
ユーザーは、SMS または通話で送信されたコードを使用して認証されます。 | request.auth.claims.crd_str.sms == true |
swk |
2 段階認証プロセスには、スマートフォンなどのソフトウェア キーをセキュリティ キーとして使用します。 | request.auth.claims.crd_str.swk == true |
hwk |
2SV には、Google Titan Key などのハードウェア キーを使用します。 | request.auth.claims.crd_str.hwk == true |
otp |
ユーザーは、ワンタイム パスワード方式（Google 認証システムとバックアップ コード）で認証されます。 | request.auth.claims.crd_str.otp == true |
mfa |
ユーザーは、このテーブル（pwd を除く）のメソッドのいずれかで認証されます。 |
request.auth.claims.crd_str.mfa == true |
2 段階認証プロセスに関するその他の情報
Google の 2 段階認証プロセスには、デバイスを信頼できるものとしてマークすることで、同じデバイスで再度ログインする際に追加で 2 段階認証プロセスを行う必要性をなくす機能があります。この機能を有効にすると、ユーザーがログアウトして再度ログインするときに 2 回目のログインで 2 段階認証プロセスが行われなくなります。2 段階認証は 2 回目のログインで使用されていないため、Google は 2 回目のログインでの認証情報の安全度を多様性認証でなくパスワードのみとして正しく報告します。
常に強力な認証情報の使用を必須とするアプリケーションやワークフローがある場合は、信頼できるデバイスの機能を無効にすることをおすすめします。信頼できるデバイスの機能を有効または無効にする方法については、信頼できるコンピュータを追加または削除するをご覧ください。この機能を無効にすると、使用頻度の高いデバイスであっても、ログインのたびに第 2 要素を提供するよう求められます。多要素認証のアサーションを行うには、ユーザーがログアウトして、最新のログインに再度ログインする必要がある場合があります。