G-gen の武井です。当記事では Context-Aware Access の request.auth 属性を使ったアクセス制御でハマった際の顛末について解説します。

はじめに

背景

今回、以下の要件を満した場合に Google ドライブへのアクセスを許可するというアクセス制御を検証していました。

特定の IP アドレスからのアクセスであること
Google アカウントがMFA (Multi-Factor Authentication) を有効にしていること
2段階目の認証要素にハードウェアセキュリティキー (以降、セキュリティキー) を使用していること

実際の検証では適切なアクセスレベルを定義し、かつ、送信元の IP アドレスや MFA 要件をすべて満たしているにもかかわらず、Google ドライブへのアクセスが拒否される事象が発生しました。

Context-Aware Access

Context-Aware Access（以降、CAA）とは、デバイス情報、アカウント情報、接続状況などの背景情報（コンテキスト）にもとづきアクセスを制御する、Google Workspace の一機能です。Frontline Standard、Enterprise Standard、Enterprise Plus、Cloud Identity Premium などのエディションで利用可能です。

CAA を設定することで、Google ドライブ、Gmail、Google カレンダー、Looker Studio などに条件付きのアクセス制御を適用できます。

参考：コンテキストアウェアアクセスの概要

カスタムアクセスレベル

今回のように、セキュリティキーによる認証をアクセス制御の条件とする場合、標準アクセスレベルではなく、カスタムアクセスレベルを使用します。

カスタムアクセスレベルは Common Expression Language (CEL) と呼ばれる式言語で定義します。

参考：カスタムアクセスレベル
参考：CEL 言語の定義

request.auth 属性

カスタムアクセスレベルで認証要素を用いたルールを定義する場合、request.auth 属性を使用します。

この属性は、アクセス元のプリンシパル情報や MFA における各種認証要素を指定することができます。

参考：request.auth の属性

事象の詳細

構成

今回の検証構成を図示したものが以下となります。

前述の要件を満たすユーザーのアクセスだけを許可する想定です。

セキュリティキーによる MFA は、組織部門の設定を利用して強制的に適用しています。

2段階目の認証要素はセキュリティキーを強制する組織部門を用意し、対象ユーザーを紐づけ

カスタムアクセスレベルの定義と紐づけ

カスタムアクセスレベルは以下のように定義しています。

# セキュリティキーによる MFA 認証と許可 IP アドレスをまとめたアクセスレベルを AND 条件で結合  

request.auth.claims.crd_str.hwk == true && levels.source_ip_allow_list_test_sq7nlybc

上記のカスタムアクセスレベルで、対象の組織部門からのアクセスを制御するため、以下のように紐づけ設定をしています。

実際のエラー

上記の設定を行い、実際にアクセス確認をしたところ、セキュリティキーによる MFA が有効なアクセスであってもアクセス拒否と判定されてしまいました。

まず、Google ドライブにアクセスするユーザーの MFA 設定は以下の通りで、セキュリティキーの登録が完了しています。

解説のため一度ログアウトした状態から Google ドライブにアクセスすると、パスワード認証と2段階目のセキュリティキー認証が要求されるため、指示に従い認証を実施します。

セキュリティキーによる認証を行っているにもかかわらず、Google ドライブへのアクセスが拒否されました。

原因については後述しますが、今回のハマりどころは、セキュリティキーによる MFA 認証を判定するプロセスにありました。

原因と解決策

原因

エラーの原因は、以前にログインした際のログイン情報（ブラウザの Cookie や Google Workspace 側で持っているログイン情報）でした。

今回アクセス制御をテストしたユーザーは、組織部門移行前も MFA 自体は有効でしたが、認証要素には ソフトウェアキー を使用していました。

その際の Cookie やログイン情報が残っていたため、カスタムアクセスレベルによる MFA 設定を判定する過程で既存のログイン情報が干渉した結果、想定外のアクセス拒否を引き起こしていました。

解決策

以下を実施することでエラーは解消されました。

Google Chrome の場合、以下の画面遷移で Cookie を削除します。

3点アイコン > 閲覧履歴データを削除 > 全期間でCookieと他のサイトデータ (全チェックにはなっているものの、対象は Cookie) を削除

Admin コンソールから当該ユーザーのログイン情報をリセット

以下の画面遷移でログイン Cookie を無効化（リセット）します。

ディレクトリ > ユーザー > 対象ユーザー > セキュリティタブ > ログイン Cookie の [リセット] を押下

動作確認

上記の操作を行い再度アクセスすると Google ドライブが表示されました。

"Cookie をすべて削除して再度アクセスすると Google ドライブが表示された

アクセス拒否だった際の認証プロセスに着目すると、以前は2段階目の認証プロセスのポップアップで別の方法を試すを選択できる状態でした。

しかし、アクセス許可となった際の2段階目の認証プロセスでは、認証方法を選択するポップアップは表示されず、すぐにセキュリティーによる認証が開始されました。

Cookie を削除し、ログイン情報をリセットしたことにより、2段階目の認証にセキュリティキーを用いていると正しく判定されました。

ログイン情報の削除により、パスワード認証成功後すぐにセキュリティキーによる認証が開始