詳細モードでのコンテキストアウェア アクセスの例

機密データを含むアプリケーションへのアクセスのセキュリティを高めるため、管理者はシステムに対するユーザーの認証方法に応じて、アプリケーションへのアクセスを許可するかどうかを決定できます。

たとえば、パスワードだけを使ってログインしたユーザーには機密情報を含まないアプリケーションのみへのアクセスを許可する一方で、二要素認証でハードウェア セキュリティ キーを使ってログインしたユーザーには特に機密性の高いエンタープライズ アプリケーションへのアクセスを許可できます。

後者のアクセスレベルでは、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
)
)
)

デスクトップ ウェブアプリに限定され、モバイルアプリや API には適用されません

Device Bound Session Credentials（DBSC）を必須にすることで、機密データを含むアプリへのアクセスのセキュリティを強化できます。DBSC は、Windows で Chrome ブラウザを使用しているときにユーザーのセッションをデバイスにバインドします。これにより、セッション ハイジャックのリスクを大幅に軽減できます。

このアクセスレベルでは、request.auth 属性を使用して、ユーザーのセッションが特定のデバイスにバインドされていることを確認します。バインドされている場合、アプリにアクセス権が付与されます。バインドされていない場合（DBSC セッションでない場合）、アクセスは拒否されます。

エラーを回避するには、このアクセスレベルの対象となるすべてのユーザー アカウントに対して DBSC を有効にします。詳しくは、DBSC を有効にするをご覧ください。

アクティブ モードを有効にする前に、アクセスレベルを [モニターモード] に設定します。モニターモードでは、ユーザーのアクセスを中断することなく、アクセスレベルの適用による影響をテストできます。

次の CEL 式を使用して、カスタム アクセスレベルを作成します。

request.auth.sessionBoundToDevice(origin) == true

この CEL 式を使用して、Chrome ブラウザ バージョン 136 以降の Windows デバイスでのみ DBSC を適用します。

!(device.os_type == OsType.DESKTOP_WINDOWS && device.chrome.versionAtLeast("136.0.0")) || request.auth.sessionBoundToDevice(origin) == true

管理者は BeyondCorp Alliance パートナーから報告されたデバイス シグナルを使用できます。この例では、アプリケーションに Lookout Software を使用しています。

このアクセスレベルでは、device 属性を使用して、Google Workspace へのアクセスに使用するデバイスがポリシーに沿っており、健全性スコアが「とても良い」と Lookout で報告されていることを確認します。

このアクセスレベルでは、device 属性を使用して、ユーザーが最新バージョンの管理対象 Chrome ブラウザを使用していることが確認され、そのようなブラウザからのアクセスだけが許可されます。

カスタム アクセスレベルのデバイスに対して企業向け証明書を使用すると、デバイスが企業所有のアセットかどうかを判断できます。このアクセスレベルでは、アセットを確認するのに device 属性を使用します。詳細と例については、エンタープライズ証明書の条件の構成をご覧ください。

1 台のデバイスに複数の証明書を含めることができます。企業向け証明書は、exists() マクロを使用してカスタム アクセスレベルで使用されます。次に例を示します。

device.certificates.exists(cert, 述語)

この例の cert は、変更可能な述語でデバイスの企業向け証明書にバインドするシンプルな識別子です。マクロ exists() は、要素ごとの述語結果を OR（||）演算子で結合します。少なくとも 1 つの証明書が述語式を満たす場合、マクロは true を返します。

次の表に、カスタム アクセスレベルで使用する CEL 表現の設定に使用できる属性を示します。文字列の比較では大文字と小文字が区別されます。

よく使用されるポリシーの例:

会社のルート証明書で署名された有効な企業証明書がデバイスにあることを確認する

device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT")

デバイス上の企業向け証明書の発行元を検証する

device.certificates.exists(cert, cert.is_valid && cert.issuer == "EMAILADDRESS=test_inter1@beyondcorp.in, 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 ダイジェスト（バイナリ形式）です。文字列は、次の 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）

アクセスレベルでは、device 属性を使用して、CrowdStrike のデータが最新であることを必須としています。Chrome Enterprise Premium が Falcon ZTA からの新しい評価を使用する際には 90 分の固有の遅延があるため、1 時間未満の長さにすることはおすすめできません。

// Crowdstrike からのデータについて次のいずれかの条件が true であることを確認する:
// 次のいずれかの条件を満たしている必要がある
// 1. デバイスが過去 1 日以内に評価された
// 2. 評価の有効期限が切れていない（前回の iat から 2 週間以内）
device.vendors に「CrowdStrike」が含まれており、かつ（
request.time - timestamp(device.vendors["CrowdStrike"].data["iat"]) < duration("1d") または
timestamp(device.vendors["CrowdStrike"].data["exp"]) - request.time > duration("0m")
）

Chrome Enterprise Premium は、多数の BeyondCorp Alliance エコシステム パートナーと連携して、デバイスのシグナルとコンテキストを Chrome Enterprise Premium ソリューション内に統合しています。パートナーは Chrome Enterprise Premium と属性をいくつでも共有できます。そのうちの 1 つが is_compliant_device 属性です。次の例は、device 属性を使用して、BeyondCorp Alliance パートナーのいずれかが Chrome Enterprise Premium と連携しているかどうかと、デバイスを準拠デバイスと見なしているかどうかを確認する方法を示しています。

exists マクロは、||（or）演算子を使用して、各 BeyondCorp Alliance パートナーの式を展開します。

// BCA パートナーがデバイスを準拠していると見なしているかどうかを確認します
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)

この例では、device 属性を使用して、デバイスに安全なバージョンの Android が搭載されていることを確認します。

確認付きブートは、実行されたコードが攻撃者や破損からではなく、信頼できるソース（通常はデバイスの OEM）から取得されたかどうかを確認します。詳しくは、確認付きブートをご覧ください。

// Android の確認済みブートのステータスが緑色であることを必須とする
device.android_device_security.verified_boot == true

この例では、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 時～深夜までリソースへの一時的なアクセスを許可する
// このアクセス元は米国リージョンである必要がある
レベル。Require_Secure_Device &&
request.time.between('2022-03-01T23:00:00+08:00', '2022-03-02T23:59:59+08:00') &&
origin.region_code == "US"
// 終了時刻は排他的であるため、上記のコードでは、ユーザーがアクセスできない 2 秒間が発生する可能性があります。
// もう 1 つの方法として次のように指定できる
// !between('00:00:01','16:00:00')

このアクセスレベルでは、levels 属性を使用して、ユーザーが 2 つのアクセスレベルの組み合わせ条件を満たしていることを必須としています。この例では、access_level_name_1 と access_level_name_2 は内部名を参照しています。

levels.access_level_name_1 && levels.access_level_name_2