この記事では、カスタム アクセスレベルを使用するポリシーを含む、コンテキストアウェア アクセスのユースケースについて説明します。以下に示す例では、Common Expressions Language（CEL）を使用して、詳細モードでカスタム アクセスレベルを作成します。
CEL 式を使用してカスタム アクセスレベルを作成する場合は、必要に応じて関数とマクロを使用することもできます。
（コンテキストアウェア アクセス インターフェースを使用して）基本モードで開発されたアクセスレベルの例については、基本モードでのコンテキストアウェア アクセスの例をご覧ください。
認証の例
機密データを含むアプリケーションへのアクセスのセキュリティを高めるため、管理者はシステムに対するユーザーの認証方法に応じて、アプリケーションへのアクセスを許可するかどうかを決定できます。
たとえば、パスワードだけを使ってログインしたユーザーには機密情報を含まないアプリケーションのみへのアクセスを許可する一方で、二要素認証でハードウェア セキュリティ キーを使ってログインしたユーザーには特に機密性の高いエンタープライズ アプリケーションへのアクセスを許可できます。
後者のアクセスレベルでは、request.auth 属性を使用して、ユーザーが 2 段階認証プロセスでパスワードとハードウェア キーの両方を使ってログインして、機密性の高いアプリケーションにアクセスできることが確認されます。
request.auth.claims.crd_str.pwd == true && request.auth.claims.crd_str.hwk == true安全度の高い認証情報で認証されたユーザーに対してのみ企業リソースへのアクセスを許可したいケースはよくあります。以下に示す例では、levels 属性と request.auth 属性を次のように使用しています。
- ユーザーが会社のデバイスからアクセスする場合は、プッシュ通知、ハードウェアまたはソフトウェアのセキュリティ キー、ワンタイム パスワードなどの MFA 方式（SMS を除く）で十分
- ユーザーが会社以外のデバイスからアクセスする場合は、ハードウェアまたはソフトウェアのセキュリティ キーの仕様が必要
// 会社のデバイスでは基本的な MFA（SMS を除く）を必須とし、それ以外のデバイスではセキュリティ キー（ハードウェアまたはソフトウェア）を必須とする
levels.Require_Secure_Device &&
(
(
levels.Require_Corporate_Device &&
request.auth.claims.crd_str.mfa &&
!request.auth.claims.crd_str.sms
) ||
(
!levels.Require_Corporate_Device &&
(
request.auth.claims.crd_str.hwk || request.auth.claims.crd_str.swk
)
)
)
デバイスの例
管理者は BeyondCorp Alliance パートナーから報告されたデバイス シグナルを使用できます。この例では、アプリケーションに Lookout Software を使用しています。
このアクセスレベルでは device 属性を使用して、Google Workspace へのアクセスに使用するデバイスがポリシーに沿っており、健全性スコアが「とても良い」と Lookout で報告されていることを確認します。
device.vendors["Lookout"].is_compliant_device == true && device.vendors["Lookout"].device_health_score == DeviceHealthScore.VERY_GOODこのアクセスレベルでは、device 属性を使用して、ユーザーが最新バージョンの管理対象 Chrome ブラウザを使用していることが確認され、そのようなブラウザからのアクセスだけが許可されます。
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED && device.chrome.versionAtLeast("94.0.4606.81") カスタム アクセスレベルのデバイスに対して企業向け証明書を使用すると、デバイスが企業所有のアセットかどうかを判断できます。このアクセスレベルでは、アセットを確認するのに device 属性を使用します。詳細と例については、エンタープライズ証明書の条件の構成をご覧ください。
1 台のデバイスに複数の証明書を含めることができます。企業向け証明書は、exists() マクロを使用してカスタム アクセスレベルで使用されます。例:
device.certificates.exists(cert, 述語)
この例の cert は、変更可能な述語でデバイスの企業向け証明書にバインドするシンプルな識別子です。マクロ exists() は、要素ごとの述語結果を OR（||）演算子で結合します。少なくとも 1 つの証明書が述語式を満たす場合、マクロは true を返します。
次の表に、カスタム アクセスレベルで使用する CEL 表現の設定に使用できる属性を示します。文字列の比較では大文字と小文字が区別されます。
| 属性 | 説明 | 述語式の例（cert はマクロの識別子） |
|---|---|---|
| is_valid |
証明書が有効で、期限切れでない場合は true。 |
cert.is_valid |
| cert_fingerprint | 証明書のフィンガープリント （base64 のパディングなしの SHA256） |
cert.cert_fingerprint == origin. |
| root_ca_fingerprint | この証明書の署名に使用されるルート CA 証明書のフィンガープリント （base64 のパディングなしの SHA256） |
cert.root_ca_fingerprint == "the_fingerprint" |
| issuer |
発行元の名前 発行元の名前を確認するには、証明書に対して次のコマンドを実行します。
アクセスレベルで使用する発行元の文字列は、出力の逆で、「/」をカンマで置き換えます。たとえば、次のようになります。
|
cert.issuer == "EMAILADDRESS=test_inter1 |
| subject | 証明書のサブジェクト名 （完全に展開された名前） |
cert.subject == "CA_SUB" |
| serial_number |
証明書のシリアル番号 |
cert.serial_number == “123456789” |
| template_id | 証明書の X.509 拡張機能の Certificate Template のテンプレート ID （文字列） |
cert.template_id == "1.3.6.1.4.1.311.21. |
よく使用されるポリシーの例:
会社のルート証明書で署名された有効な企業証明書がデバイスにあることを確認する
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT")
デバイス上の企業向け証明書の発行元を検証する
device.certificates.exists(cert, cert.is_valid && cert.issuer == "[email protected], CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN”)
この例では、device 属性を使用して、デバイスでディスク暗号化と画面ロックの両方を有効にすることを必須としています。また、デバイスは管理者によって承認される必要があります。
デフォルトでは、Endpoint Verification で作成されたすべてのデバイスが承認されます。ただし、デバイスを紛失したときなどは、デバイスをブロックしたほうがよい場合もあります。こういった場合は、該当のデバイスから企業リソースにアクセスできないようにします。
このドキュメントで説明する他のアクセスレベルの例では、このアクセスレベルを Require_Secure_Device と呼ぶものとします。
// ディスク暗号化と画面ロックが有効になっていることを必須とする
// すべての主要プラットフォーム（Windows、Mac、Linux、CrOS、iOS、Android）に該当
// このアクセスレベルは他のすべてのアクセスレベルの基盤となる必要がある
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device
この例では、アクセスレベルで device 属性を使用して、基本的なセキュリティ要件を満たす Chrome ブラウザを必須としています。
// Chrome について、プロファイルまたはブラウザレベルで管理されていること、
// セキュリティ イベント レポートが有効になっていること、バージョン 97 以降であることを必須とする
levels.Require_Secure_Device &&
(
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED ||
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_PROFILE_MANAGED
) &&
device.chrome.is_security_event_analysis_enabled &&
device.chrome.versionAtLeast("97")
この例では、device 属性を使用して、ユーザーが管理対象の Chrome ブラウザまたはプロファイルを使用することと、Chrome で脅威対策とデータ保護のコネクタが有効であることを必須としています。また、levels 属性を使用して、前述の管理対象 Chrome のアクセスレベルを参照しています。次の例では、基盤となるアクセスレベルを Require_Managed_Chrome と呼ぶものとします。
// 管理対象 Chrome であることと（「Require_Managed_Chrome」アクセスレベルに依存）、
// ダウンロード時のコンテンツ検査と URL チェックが有効になっていることを必須とする
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled
デバイスが会社によって管理または所有されている場合にのみアクセスを許可することが、アクセスを制御するための要件です。デバイスが会社所有のものであるかどうか、または会社の管理対象であるかどうかを判断する方法はたくさんあります。次に例を示します。
- デバイスのシリアル番号が、会社のアセット管理システムに登録されている番号と一致しているかどうか
- 会社から発行された有効な企業証明書がデバイスにあるかどうか
この 2 つの方法を levels 属性と device 属性を使用する次のカスタム アクセスレベルで使用して、デバイスが会社所有のものであるかどうか、または会社の管理対象であるかどうかを判断できます。
// 次のいずれかの条件が true の場合、デバイスは会社所有デバイスである:
// 1. シリアル番号が管理者がアップロードした番号と一致している
// 2. デバイスに企業発行の有効な証明書がある
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)
フィンガープリントは、DER エンコード形式の証明書の、base64 でエンコードされたパディングなしの sha256 digest（バイナリ形式）です。文字列は、次の openssl の手順を使用して PEM 形式の証明書から生成できます。
$ openssl x509 -in cert.pem -out cert.der -outform DER
$ openssl dgst -sha256 -binary cert.der > digest.sha
$ openssl base64 -in digest.sha
- 発行時タイムスタンプ（iat）
- 有効期限タイムスタンプ（exp）（現在のリリースでは発行時タイムスタンプから 2 週間後と思われる）
アクセスレベルでは、device 属性を使用して、CrowdStrike のデータが最新であることを必須としています。BeyondCorp Enterprise が Falcon ZTA からの新しい評価を使用する際には 90 分の固有の遅延があるため、1 時間未満の長さにすることはおすすめできません。
// Crowdstrike からのデータについて次のいずれかの条件が true であることを確認する:
// 次のいずれかの条件を満たしている必要がある
// 1. デバイスが過去 1 日以内に評価された
// 2. 評価の有効期限が切れていない（前回の iat から 2 週間以内）
“CrowdStrike” in device.vendors && (
request.time - timestamp(device.vendors["CrowdStrike"].data["iat"]) < duration("1d") ||
timestamp(device.vendors["CrowdStrike"].data["exp"]) - request.time > duration("0m")
)
BeyondCorp Enterprise は、多数の BeyondCorp Alliance エコシステム パートナーと連携して、デバイスのシグナルとコンテキストを BeyondCorp Enterprise ソリューション内に統合しています。パートナーは BeyondCorp と属性をいくつでも共有できます。そのうちの 1 つが is_compliance_device 属性です。次の例は、device 属性を使用して、BeyondCorp Alliance パートナーのいずれかが BeyondCorp Enterprise と連携しているかどうかと、デバイスを BeyondCorp 準拠デバイスと見なしているかどうかを確認する方法を示しています。
exists マクロは、||（or）演算子を使用して、各 BeyondCorp Alliance パートナーの式を展開します。
// いずれかの BCA パートナーがデバイスを BeyondCorp 準拠デバイスと見なしているかどうかを確認する
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v、v（device.vendors && device.vendors[v].is_compliance_device
）
この例では、device 属性を使用して、デバイスが互換性テストスイート（CTS）コンプライアンス チェックに合格することを必須にします。詳しくは、互換性テストスイートをご覧ください。
// デバイスが CTS コンプライアンス チェックに合格することを必須にする
device.android_device_security.cts_profile_match == true
この例では、device 属性を使用して、デバイスで Google Play プロテクト検証アプリを有効にすることを必須としています。
[アプリの確認] を使用すると、Google Play 以外の提供元からアプリをインストールした場合の危険性を調べることができます。有害な可能性があるアプリがないかどうかの確認も定期的に行います。[アプリの確認] はデフォルトで有効になっています。詳細管理の対象になっているデバイスでは、ユーザーがこれを無効化できるようにするかを指定できます。詳しくは、Android モバイル デバイスに設定を適用するをご覧ください。
// デバイスに対して Google Play プロテクトの [アプリの確認] を有効にすることを必須とする
device.android_device_security.verify_apps_enabled == true
この例では、device 属性を使用して、有害な可能性があるアプリのあるデバイスへのアクセスを拒否します。このようなアプリは多くの場合、マルウェアと呼ばれます。詳しくは、有害な可能性があるアプリ（PHA）をご覧ください。
// 有害な可能性（android_device_security.has_Potentially_harmful_apps != true）のあるデバイスへのアクセスを拒否する
時間に基づくアクセスの例
企業において、シフト従業員がシフト時間内にのみ企業リソースにアクセスできるようにすることを基本とするケースがあります。次に示すアクセスレベルでは、levels 属性を使用して、月曜日から金曜日までの 3 つのシフトを定義しています。
// シフト 1 - 月曜日から金曜日の午前 0 時～午前 8 時
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('00:00:00', '08:00:00')
// シフト 2 - 月曜日から金曜日の午前 8 時～午後 4 時
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('08:00:00', '16:00:00')
// シフト 3 - 月曜日から金曜日の午後 4 時～午前 0 時
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('16:00:00', '00:00:00')
// シフト勤務者に対して、月曜日から金曜日の午前 9 時～午後 5 時の間はリソースへのアクセスを許可する（7 月 4 日を除く）
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
!(
request.time.getMonth("America/Los_Angeles") == 6 &&
request.time.getDayOfMonth("America/Los_Angeles") == 3
) &&
request.time.timeOfDay("America/Los_Angeles").between('09:30:00', '17:00:00')
企業においてはときに、安全なデバイスへのアクセス権を持っていない管理者が短時間だけ緊急でデバイスにアクセスしなければならないとき、ブレークグラス アクセス（非常時用アクセス権限）を許可したい場合があります。
そのような場合は、levels 属性を使用して、時間と場所が制約されたアクセスレベルを作成して、特定の管理者に割り当てます。このアクセスレベルは、割り当てられると、指定された時間内のみ有効となります。この時間を過ぎると、管理者のアクセス権は再び既存の要件で制御されるようになります。
// 2022 年 3 月 1 日午後 10 時～深夜までリソースへの一時的なアクセスを許可する
// このアクセス元は米国リージョンである必要がある
levels.Require_Secure_Device &&
request.time.between('2022-03-01T23:00:00+08:00', '2022-03-02T23:59:59+08:00') &&
origin.region_code == “US”
// 終了時刻の 23:59:59 は含まれないため、上記の指定ではユーザーがアクセスできない時間が
// 2 秒間発生する可能性がある。もう 1 つの方法として次のように指定できる
// !between('00:00:01','16:00:00')
2 つのレベルの条件を組み合わせた例
2 つのアクセスレベルの条件を組み合わせて新しいアクセスレベルを定義するこのアクセスレベルでは、levels 属性を使用して、ユーザーが 2 つのアクセスレベルの組み合わせ条件を満たしていることを必須としています。この例では、access_level_name_1 と access_level_name_2 は内部名を参照しています。
levels.access_level_name_1 && levels.access_level_name_2
