Beispiele für den kontextsensitiven Zugriff im erweiterten Modus

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 == true

Hä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.

// Require basic MFA (not SMS) on corporate devices and security key (hardware or software) if not
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
)
)
)

Beschränkt auf Desktop-Webanwendungen und nicht für mobile Apps oder APIs anwendbar

Sie können die Sicherheit des Zugriffs auf Apps mit sensiblen Daten erhöhen, indem Sie DBSC (Device Bound Session Credentials) voraussetzen. DBSC bindet die Sitzung eines Nutzers an sein Gerät, wenn er den Chrome-Browser unter Windows verwendet. Dadurch kann das Risiko von Session Hijacking erheblich verringert werden.

Bei dieser Zugriffsebene wird anhand des Attributs request.auth geprüft, ob die Sitzungen des Nutzers an ein bestimmtes Gerät gebunden sind. Wenn das der Fall ist, wird der App der Zugriff gewährt. Andernfalls (wenn die Sitzung nicht DBSC-gebunden ist) wird der Zugriff verweigert.

Aktivieren Sie DBSC für alle Nutzerkonten mit dieser Zugriffsebene, um Fehler zu vermeiden. Weitere Informationen finden Sie unter DBSC aktivieren.

Legen Sie die Zugriffsebene auf Monitormodus fest, bevor Sie den Aktivmodus aktivieren. Im Monitormodus können Sie die Auswirkungen der Erzwingung von Zugriffsebenen testen, ohne den Nutzerzugriff zu unterbrechen.

Verwenden Sie diesen CEL-Ausdruck, um Ihre benutzerdefinierte Zugriffsebene zu erstellen:

request.auth.sessionBoundToDevice(origin) == true

Mit diesem CEL-Ausdruck wird DBSC nur auf Windows-Geräten mit Chrome-Browserversion 136 oder höher erzwungen:

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

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.

Bei dieser Zugriffsebene wird anhand des device-Attributs überprüft, ob Nutzer die neueste Version eines verwalteten Chrome-Browsers verwenden. Der Zugriff ist nur über einen solchen Browser möglich.

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.

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.

// Require disk encryption and screen lock enabled
// This is applicable across all major platforms (Windows, Mac, Linux, CrOS, iOS, Android)
// This foundational and should be depended upon by all other access levels
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.

// Require Chrome to be managed at profile or browser level, must have
// security event reporting enabled and must be version 97 or greater
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.

// Require managed chrome (dependent on "Require_Managed_Chrome" access level)
// and require content inspection for downloads as well as URL check enabled
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.

// Das Gerät 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. Wenn das Gerät ein gültiges Unternehmenszertifikat hat
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

• Zeitstempel für „Ausgestellt am“ (iat)
• Zeitstempel des Ablaufs (exp)

Bei dieser Zugriffsebene wird das device-Attribut verwendet, um dafür zu sorgen, dass CrowdStrike-Daten aktuell sind. Hinweis: Bei Chrome Enterprise Premium 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")
)

Chrome Enterprise Premium arbeitet mit vielen BeyondCorp Alliance-Partnerunternehmen zusammen, um Gerätesignale und ‑kontext in die Chrome Enterprise Premium-Lösung einzubinden. Partner können beliebig viele Attribute für Chrome Enterprise Premium 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 Chrome Enterprise Premium 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).

// Check to see if any of the BCA partners consider the device to be compliant
["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 Bootmodus mit Verifikation.

// 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 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 mit potenziell schädlichen Apps zu verweigern. Diese Apps werden auch Malware genannt. 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

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.

// Shift 1 - Monday to Friday, midnight to 8am
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')

// Shift 2 - Monday to Friday, 8am to 4pm
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')

// Shift 3 - Monday to Friday, 4pm to midnight
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:30: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 sie 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-01T23:00:00+08:00', '2022-03-02T23:59:59+08:00') &&
origin.region_code == "US"
// Note that the end time is exclusive, so the above potentially has 2 seconds that
// the users may not have access. Alternativ ist folgende Verwendung möglich:
// !between('00:00:01','16:00:00')

Bei 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