In diesem Artikel werden Anwendungsfälle für den kontextsensitiven Zugriff beschrieben, die auch Richtlinien mit benutzerdefinierten Zugriffsebenen umfassen. In diesen Beispielen erstellen Sie mit Common Expression Language (CEL) benutzerdefinierte Zugriffsebenen im erweiterten Modus.
Beachten Sie, dass Sie auch Funktionen und Makros verwenden können, wenn Sie benutzerdefinierte Zugriffsebenen mit CEL-Ausdrücken erstellen.
Beispiele für Zugriffsebenen im einfachen Modus (über die Oberfläche für den kontextsensitiven Zugriff erstellt) finden Sie unter Beispiele für den kontextsensitiven Zugriff im einfachen Modus.
Authentifizierungsbeispiele
Abschnitt öffnen | Alle minimieren
Um die Sicherheit des Zugriffs auf Anwendungen mit sensiblen Daten zu erhöhen, können Sie ermitteln, wie sich der Nutzer beim System authentifiziert hat, und basierend darauf entscheiden, ob er Zugriff auf die Anwendung erhält.
Nutzer, die lediglich mit einem Passwort angemeldet sind, können beispielsweise nur auf Anwendungen zugreifen, die keine vertraulichen Informationen enthalten. Einem Nutzer, der mit einem Hardware-Sicherheitsschlüssel als zweitem Faktor angemeldet ist, könnte dagegen Zugriff auf besonders vertrauliche Unternehmensanwendungen gewährt werden.
Bei dieser Zugriffsebene wird anhand der request.auth-Attribute geprüft, ob Nutzer für die Anmeldung sowohl ein Passwort als auch einen Hardwareschlüssel für die Bestätigung in zwei Schritten verwenden und entsprechend auf vertrauliche Anwendungen zugreifen dürfen.
request.auth.claims.crd_str.pwd == true && request.auth.claims.crd_str.hwk == trueHäufig möchten Administratoren nur dann Zugriff auf Unternehmensressourcen gewähren, wenn sich der Nutzer mit starken Anmeldedaten authentifiziert hat. Im folgenden Beispiel werden die Attribute levels und request.auth so verwendet:
- Wenn ein Nutzer ein Unternehmensgerät verwendet, ist eine beliebige Multi-Faktor-Authentifizierung (MFA) außer SMS ausreichend (z. B. Push-Benachrichtigungen, Hardware- oder Software-Sicherheitsschlüssel oder Einmalpasswörter).
- Verwendet der Nutzer kein Unternehmensgerät, ist ein Hardware- oder Software-Sicherheitsschlüssel erforderlich.
// Grundlegende MFA (außer SMS) für Unternehmensgeräte und Sicherheitsschlüssel (Hardware oder Software) für private Geräte erforderlich
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
)
)
)
Gerätebeispiele
Abschnitt öffnen | Alle minimieren und nach oben
Sie können Gerätesignale verwenden, die von einem BeyondCorp Alliance-Partner erfasst wurden. In diesem Beispiel wird als Anwendung „Lookout“ verwendet.
Bei dieser Zugriffsebene wird anhand des Attributs device geprüft, ob das für den Zugriff auf Google Workspace verwendete Gerät von Lookout als richtlinienkonform erfasst wurde und die Integritätsbewertung „Very Good“ lautet.
device.vendors["Lookout"].is_compliant_device == true && device.vendors["Lookout"].device_health_score == DeviceHealthScore.VERY_GOODBei dieser Zugriffsebene wird anhand des Attributs device überprüft, ob Nutzer die neueste Version eines verwalteten Chrome-Browsers verwenden. Der Zugriff ist nur über einen solchen Browser möglich.
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED && device.chrome.versionAtLeast("94.0.4606.81") Sie können Unternehmenszertifikate für Geräte in benutzerdefinierten Zugriffsebenen verwenden, um zu bestimmen, ob es sich bei einem Gerät um ein unternehmenseigenes Asset handelt. Bei dieser Zugriffsebene wird das Attribut device für die Asset-Überprüfung verwendet. Weitere Informationen und Beispiele finden Sie unter Bedingungen für Unternehmenszertifikate konfigurieren.
Ein Gerät kann mehrere Zertifikate haben. Unternehmenszertifikate werden in einer benutzerdefinierten Zugriffsebene mit dem Makro exists() verwendet. Beispiel:
device.certificates.exists(cert, predicate)
In diesem Beispiel ist cert eine einfache Kennung, die in der Variable predicate verwendet wird, um eine Bindung an das Unternehmenszertifikat des Geräts zu erstellen. Das Makro exists() kombiniert die Prädikatsergebnisse pro Element mit dem Operator or (||). Makros geben den Wert true zurück, wenn mindestens ein Zertifikat den Prädikatsausdruck erfüllt.
In der folgenden Tabelle sind Attribute aufgeführt, die Sie zum Erstellen von CEL-Ausdrücken für benutzerdefinierte Zugriffsebenen verwenden können. Bei Stringvergleichen wird die Groß-/Kleinschreibung beachtet.
| Attribut | Beschreibung | Beispiel für einen Prädikatsausdruck (wobei cert eine Kennung von Makros ist) |
|---|---|---|
| is_valid |
„true“, wenn das Zertifikat gültig und nicht abgelaufen ist. |
cert.is_valid |
| cert_fingerprint | Fingerabdruck des Zertifikats (base64-codiertes, nicht aufgefülltes SHA256) |
cert.cert_fingerprint == origin. |
| root_ca_fingerprint | Fingerabdruck des CA-Root-Zertifikats, das zum Signieren dieses Zertifikats verwendet wird (base64-codiertes, nicht aufgefülltes SHA256) |
cert.root_ca_fingerprint == "the_fingerprint" |
| issuer |
Ausstellername Führen Sie den folgenden Befehl für das Zertifikat aus, um den Ausstellernamen zu ermitteln:
Der in der Zugriffsebene verwendete Ausstellerstring ist die Umkehrung der Ausgabe und das Zeichen „/“ wird durch ein Komma ersetzt. Beispiel:
|
cert.issuer == "EMAILADDRESS=test_inter1 |
| subject | Name des Zertifikats (vollständig erweiterte Namen) |
cert.subject == "CA_SUB" |
| serial_number |
Seriennummer des Zertifikats |
cert.serial_number == “123456789” |
| template_id | ID der Zertifikatsvorlage der X.509-Erweiterung für das Zertifikat (String) |
cert.template_id == "1.3.6.1.4.1.311.21. |
Beispiele für häufig verwendete Richtlinien:
Prüfen, ob das Gerät ein gültiges Unternehmenszertifikat hat, das vom Root-Zertifikat des Unternehmens signiert wurde
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT")
Aussteller des Unternehmenszertifikats auf dem Gerät validieren
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”)
In diesem Beispiel sorgen die device-Attribute dafür, dass die Laufwerksverschlüsselung und Displaysperre aktiviert sein müssen. Außerdem muss das Gerät von Administratoren genehmigt werden.
Standardmäßig werden alle über die Erweiterung „Endpoint Verification“ erstellten Geräte genehmigt. In einigen Fällen empfiehlt es sich jedoch, ein Gerät zu sperren, etwa, wenn dieses verloren geht. Dann sollte es nicht mehr möglich sein, über dieses Gerät auf Unternehmensressourcen zuzugreifen.
Bei anderen Beispielen für Zugriffsebenen in diesem Dokument wird davon ausgegangen, dass diese Zugriffsebene den Namen Require_Secure_Device hat.
// Laufwerksverschlüsselung und Displaysperre müssen aktiviert sein
// Das gilt für alle größeren Plattformen (Windows, Mac, Linux, CrOS, iOS, Android)
// Das ist die Grundlage, von der alle anderen Zugriffsebenen abhängig sind
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device
In diesem Beispiel wird für die Zugriffsebene das Attribut device verwendet, um die Nutzung des Chrome-Browsers mit grundlegenden Sicherheitsmaßnahmen zu erzwingen.
// Chrome muss auf Profil- oder Browserebene verwaltet werden,
// Berichte zu Sicherheitsereignissen müssen aktiviert sein und Chrome muss mindestens in Version 97 vorliegen
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")
In diesem Beispiel wird das Attribut device verwendet, um die Nutzung eines verwalteten Chrome-Browsers oder eines verwalteten Chrome-Profils zu erzwingen und dafür zu sorgen, dass die Connectors für den Schutz vor Bedrohungen und den Datenschutz in Chrome aktiviert sind. Mit dem Attribut levels wird auf die zuvor beschriebene Zugriffsebene verwiesen, die eine verwaltete Chrome-Version erforderlich macht. Im Beispiel wird davon ausgegangen, dass die abhängige Zugriffsebene den Namen Require_Managed_Chrome hat.
// Verwalteter Chrome-Browser erforderlich (abhängig von der Zugriffsebene „Require_Managed_Chrome“)
// und es müssen eine Inhaltsprüfung für Downloads sowie URL-Prüfungen aktiviert sein
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled
Eine der Voraussetzungen für die Zugriffssteuerung ist es, Zugriff nur dann zuzulassen, wenn das Gerät vom Unternehmen verwaltet wird oder dem Unternehmen gehört. Es gibt viele Möglichkeiten festzustellen, ob ein Gerät dem Unternehmen gehört oder von diesem verwaltet wird. Beispiel:
- Wenn die Seriennummer eines Geräts mit einer Seriennummer im Asset-Managementsystem des Unternehmens übereinstimmt
- Wenn ein Gerät über ein gültiges Unternehmenszertifikat verfügt, das vom Unternehmen ausgestellt wurde
Diese beiden Ansätze können in der folgenden benutzerdefinierten Zugriffsebene verwendet werden, bei der anhand der Attribute levels und device bestimmt wird, ob das Gerät dem Unternehmen gehört oder von diesem verwaltet wird.
// Es ist ein unternehmenseigenes Gerät, wenn eine der folgenden Bedingungen erfüllt ist:
// 1. Die Seriennummer stimmt mit einer der vom Administrator hochgeladenen Seriennummern überein
// 2. Das Gerät verfügt über ein gültiges, vom Unternehmen ausgestelltes Zertifikat
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 Fingerabdruck ist der nicht aufgefüllte base64-codierte sha256-Digest (im Binärformat) des DER-verschlüsselten Zertifikats. Der String kann, wie nachfolgend gezeigt, mit openssl aus dem Zertifikat im PEM-Format generiert werden:
$ openssl x509 -in cert.pem -out cert.der -outform DER
$ openssl dgst -sha256 -binary cert.der > digest.sha
$ openssl base64 -in digest.sha
- iat (Issued at, ausgestellt am)
- exp (Expiry, Ablauf); in der aktuellen Version gültig bis zwei Wochen nach dem iat-Zeitstempel
Bei dieser Zugriffsebene wird das Attribut device verwendet, um dafür zu sorgen, dass CrowdStrike-Daten aktuell sind. Hinweis: Bei BeyondCorp Enterprise werden Falcon ZTA mit einer Verzögerung von 90 Minuten verarbeitet. Daher sollten sie als Dauer mindestens eine Stunde angeben.
// Prüfen, ob eine der folgenden Bedingungen für Daten von CrowdStrike zutrifft:
// Es muss eine dieser Bedingungen erfüllt sein
// 1. Das Gerät wurde innerhalb des letzten Tages bewertet.
// 2. Die Bewertung ist nicht abgelaufen (2 Wochen seit dem letzten iat).
“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 arbeitet mit vielen BeyondCorp Alliance-Partnerunternehmen zusammen, um Gerätesignale und ‑kontext in die BeyondCorp Enterprise-Lösung einzubinden. Partner können beliebig viele Attribute für BeyondCorp freigeben. Eines davon ist das Attribut is_compliant_device. Im folgenden Beispiel wird anhand des Attributs device veranschaulicht, wie festgestellt werden kann, ob eines der BeyondCorp Alliance-Partnerunternehmen mit BeyondCorp Enterprise verknüpft wurde und das Gerät als konform einstuft.
Das Makro exists erweitert den Ausdruck für jedes BeyondCorp Alliance-Partnerunternehmen mit dem Operator || (oder).
// Prüfen, ob einer der BCA-Partner das Gerät als konform einstuft
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)
In diesem Beispiel sorgen device-Attribute dafür, dass auf den Geräten eine sichere Version von Android ausgeführt wird.
Der verifizierte Bootmodus prüft, ob der ausgeführte Code von einer vertrauenswürdigen Quelle stammt (normalerweise Geräte-OEMs), und nicht von einem Angreifer oder einer Korruption. Weitere Informationen finden Sie unter Verifizierter Bootmodus.
// Der Status des verifizierten Bootmodus von Android muss grün sein
device.android_device_security.verified_boot == true
In diesem Beispiel wird mit device-Attributen erzwungen, dass Geräte die CTS-Complianceprüfungen (Compatibility Test Suite) bestehen. Weitere Informationen finden Sie in der Compatibility Test Suite.
// Geräte müssen CTS-Complianceprüfungen bestehen
device.android_device_security.cts_profile_match == true
In diesem Beispiel werden device-Attribute verwendet, um die Aktivierung von „Apps überprüfen“ von Google Play Protect Apps zu erzwingen.
Bei Aktivierung dieser Einstellung werden Apps, die nicht über Google Play installiert werden, auf mögliche Bedrohungen überprüft. Außerdem werden Geräte regelmäßig auf potenziell schädliche Apps überprüft. Die App-Überprüfung ist standardmäßig aktiviert. Für Geräte mit erweiterter Verwaltung können Sie festlegen, ob Nutzer sie deaktivieren können. Weitere Informationen finden Sie unter Einstellungen für Android-Mobilgeräte anwenden.
// Geräte müssen durch „Apps überprüfen“ von Google Play Protect Apps überprüft werden
device.android_device_security.verify_apps_enabled == true
In diesem Beispiel werden device-Attribute verwendet, um den Zugriff auf Geräte zu verweigern, die potenziell schädliche Apps enthalten. Solche Apps werden häufig als Malware bezeichnet. Weitere Informationen finden Sie unter Potenziell schädliche Apps.
// Zugriff auf Geräte mit potenziell schädlichen Apps verweigern appsandroid_device_security.has_potentially_harmful_apps != true
Beispiele für zeitbasierten Zugriff
Abschnitt öffnen | Alle minimieren und nach oben
Unternehmen möchten dafür sorgen, dass ihre Schichtarbeiter nur während der Arbeitszeit auf Unternehmensressourcen zugreifen können. Bei den folgenden Zugriffsebenen wird das Attribut levels verwendet, um drei Schichten von Montag bis Freitag zu definieren.
// Schicht 1 – Montag bis Freitag, Mitternacht bis 8:00 Uhr
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')
// Schicht 2 – Montag bis Freitag, 8:00 bis 16:00 Uhr
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')
// Schicht 3 – Montag bis Freitag, 16:00 Uhr bis Mitternacht
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')
// Schichtarbeitern von Montag bis Freitag zwischen 9:00 Uhr und 17:00 Uhr Zugriff auf Ressourcen erlauben, jedoch nicht am 4. Juli.
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:00:00', '17:00:00')
Manchmal möchten Unternehmen Ausnahmezugriff bei Notfällen zulassen, wenn der Administrator keinen Zugriff auf ein sicheres Gerät hat, aber für einen kurzen Zeitraum Notfallzugriff benötigt.
Erstellen Sie in diesem Fall eine zeit- und ortsgebundene Zugriffsebene mit dem Attribut levels und weisen Sie es dem entsprechenden Administrator zu. Wenn diese Zugriffsebene zugewiesen wird, ist sie nur während der angegebenen Zeit gültig. Nach Ablauf dieses Zeitraums wird der Administratorzugriff wieder durch die bestehenden Anforderungen bestimmt.
// Vorübergehenden Zugriff auf Ressourcen am 1. März 2022 zwischen 22:00 Uhr und Mitternacht zulassen
// und diesen Zugriff auf die Region „USA“ beschränken.
levels.Require_Secure_Device &&
request.time.between('2022-03-01T22:00:00+08:00', '2022-03-01T23:59:59+08:00') &&
origin.region_code == “US”
// Die Endzeit ist exklusiv, sodass Nutzer bei obigem Code möglicherweise 2 Sekunden vor Mitternacht schon
// keinen Zugriff mehr haben. Alternativ ist folgende Verwendung möglich:
// !between(‘00:00:01’,’16:00:00’)
Beispiel für die Kombination von Bedingungen aus zwei Ebenen
Neue Zugriffsebene aus einer Kombination von Bedingungen aus zwei Zugriffsebenen festlegenBei dieser Zugriffsebene werden Attribute des Typs levels verwendet. Nutzer müssen dabei die kombinierten Bedingungen von zwei Zugriffsebenen erfüllen. In diesem Beispiel beziehen sich access_level_name_1 und access_level_name_2 auf Interner Name.
levels.access_level_name_1 && levels.access_level_name_2