In questo articolo vengono descritti i casi d'uso per l'accesso sensibile al contesto che includono criteri che utilizzano livelli di accesso personalizzati. In questi esempi i livelli di accesso personalizzati sono creati in modalità avanzata utilizzando il linguaggio CEL (Common Expressions Language).
Tieni presente che, se preferisci, puoi utilizzare anche funzioni e macro durante la creazione di livelli di accesso personalizzati utilizzando le espressioni CEL.
Per esempi di livelli di accesso sviluppati nella modalità di base (utilizzando l'interfaccia di accesso sensibile al contesto), vedi Esempi di accesso sensibile al contesto per la modalità di base.
Esempi di autenticazione
Per migliorare la sicurezza dell'accesso alle applicazioni che contengono dati sensibili, puoi determinare in che modo l'utente ha eseguito l'autenticazione nel sistema per stabilire se può accedere all'applicazione.
Ad esempio, è possibile permettere agli utenti che effettuano l'accesso solo con password di accedere solo ad applicazioni che non contengono informazioni sensibili, mentre gli utenti che effettuano l'accesso con un token di sicurezza hardware come secondo fattore possono essere autorizzati ad accedere alle applicazioni aziendali più sensibili.
Questo livello di accesso utilizza gli attributi request.auth per verificare che gli utenti accedano utilizzando sia una password che un token hardware per la verifica in due passaggi e abbiano quindi accesso alle applicazioni sensibili.
request.auth.claims.crd_str.pwd == true && request.auth.claims.crd_str.hwk == trueSpesso gli amministratori vogliono applicare l'accesso alle risorse aziendali solo dopo che l'utente si è autenticato con credenziali efficaci. L'esempio seguente utilizza gli attributi levels e request.auth come segue:
- Se un utente utilizza un dispositivo aziendale, sarà sufficiente usare qualsiasi metodo MFA, ad eccezione degli SMS (i metodi possono essere notifiche push, token di sicurezza hardware o software, o password unica)
- Se un utente utilizza un dispositivo non aziendale, è necessario utilizzare un token di sicurezza hardware o software
// Richiede una MFA di base (non SMS) sui dispositivi aziendali e un token di sicurezza (hardware o software) in caso contrario
levels.Request_Secure_Device &&
(
(
levels.Require_Corporate_Device &&
request.auth.claims.crd_str.mfa &&
!request.auth.claims.crd_str.sms
) ||
(
!levels.Request_Corporate_Device &&
(
request.auth.claims.crd_str.hwk || request.auth.claims.crd_str.swk
)
)
)
Esempi di dispositivi
Apri sezione | Comprimi tutto e torna all'inizio della pagina
Puoi utilizzare gli indicatori dei dispositivi segnalati da un partner BeyondCorp Alliance. In questo esempio, l'applicazione è il software Lookout.
Questo livello di accesso utilizza l'attributo device per verificare che il dispositivo utilizzato per accedere a Google Workspace sia segnalato da Lookout come conforme ai criteri e che il punteggio di integrità sia Molto buono.
device.vendors["Lookout"].is_compliant_device == true && device.vendors["Lookout"].device_health_score == DeviceHealthScore.VERY_GOODQuesto livello di accesso utilizza l'attributo device per verificare che gli utenti utilizzino la versione più recente di un browser Chrome gestito e consente l'accesso solo tramite tale browser.
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED && device.chrome.versionAtLeast("94.0.4606.81") Puoi utilizzare i certificati aziendali per i dispositivi con livelli di accesso personalizzati per determinare se il dispositivo è una risorsa di proprietà dell'azienda. Questo livello di accesso utilizza l'attributo device per la verifica degli asset. Per ulteriori informazioni ed esempi, consulta Configurazione delle condizioni dei certificati aziendali.
Un dispositivo può avere più di un certificato. I certificati aziendali vengono utilizzati in un livello di accesso personalizzato mediante la macro exists(). Ad esempio:
device.certificates.exists(cert, predicate)
In questo esempio, cert è un identificatore semplice da utilizzare nella variabile predicate per l'associazione al certificato aziendale del dispositivo. La macro exists() combina i risultati del predicato per ciascun elemento con l'operatore or (||). Le macro restituiscono vero se almeno un certificato soddisfa l'espressione del predicato.
Nella tabella seguente sono elencati gli attributi che puoi utilizzare per creare espressioni CEL da usare con livelli di accesso personalizzati. Tieni presente che i confronti delle stringhe sono sensibili alle maiuscole.
| Attributo | Descrizione | Esempio di espressione del predicato (dove cert è un identificatore di macro) |
|---|---|---|
| is_valid |
Vero se il certificato è valido e non è scaduto |
cert.is_valid |
| cert_fingerprint | Impronta del certificato (SHA256 base64 senza padding) |
cert.cert_fingerprint == origin. |
| root_ca_fingerprint | Impronta del certificato CA radice utilizzato per firmare questo certificato (SHA256 base64 senza padding) |
cert.root_ca_fingerprint == "the_fingerprint" |
| issuer |
Nome dell'autorità di certificazione Per trovare il nome dell'autorità di certificazione, esegui il comando seguente sul certificato:
La stringa dell'autorità di certificazione usata nel livello di accesso è l'inverso dell'output e il carattere "/" viene sostituito da una virgola, ad esempio:
|
cert.issuer == "EMAILADDRESS=test_inter1 |
| subject | Nome del soggetto del certificato (nomi completamente espansi) |
cert.subject == "CA_SUB" |
| serial_number |
Numero di serie del certificato |
cert.serial_number == "123456789" |
| template_id | ID modello dell'estensione X.509 CertificateTemplate del certificato (stringa) |
cert.template_id == "1.3.6.1.4.1.311.21. |
Esempi di criteri di uso comune:
Convalida che il dispositivo abbia un certificato aziendale valido firmato dal certificato radice aziendale
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT")
Convalida l'autorità di certificazione del certificato aziendale sul dispositivo
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 questo esempio l'attributo device viene utilizzato per richiedere l'attivazione sia della crittografia del disco sia del blocco schermo. Inoltre, il dispositivo deve essere approvato dagli amministratori.
Per impostazione predefinita, tutti i dispositivi creati mediante Endpoint Verification sono approvati. Tuttavia, in alcuni casi potrebbe essere opportuno bloccare un dispositivo, ad esempio quando viene smarrito. In questi casi, non vuoi che questi dispositivi siano in grado di accedere alle risorse aziendali.
Per altri esempi di livelli di accesso contenuti in questo documento, supponiamo che il nome del livello di accesso sia Require_Secure_Device.
// Richiede la crittografia del disco e il blocco schermo attivati
// Applicabile a tutte le principali piattaforme (Windows, Mac, Linux, CrOS, iOS, Android)
// In quanto livello di accesso di base, tutti gli altri dovrebbero dipendere da questo
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approval_device
In questo esempio, il livello di accesso utilizza l'attributo device per richiedere il browser Chrome con requisiti di sicurezza di base.
// Richiede che Chrome sia gestito a livello di profilo o browser, deve avere
// attivato il reporting sugli eventi di sicurezza e deve eseguire la versione 97 o successive
levels.Request_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 questo esempio l'attributo device viene utilizzato per richiedere che l'utente provenga da un browser o un profilo Chrome gestito e che Chrome abbia attivato i connettori di protezione dei dati e dalle minacce. In questo esempio viene utilizzato l'attributo levels per fare riferimento al livello di accesso "Richiede Chrome gestito" descritto in precedenza. L'esempio seguente presuppone che il livello di accesso dipendente sia denominato Require_Managed_Chrome.
// Richiede Chrome gestito (che dipende dal livello di accesso "Require_Managed_Chrome")
// e richiede sia l'ispezione dei contenuti per i download sia il controllo degli URL abilitati
levels.Request_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_Real_url_check_enabled
Un requisito per controllare l'accesso è consentire quest'ultimo solo quando il dispositivo è gestito o è di proprietà dell'azienda. Esistono molti modi per stabilire se un dispositivo è di proprietà dell'azienda o gestito, ad esempio:
- Se il dispositivo ha un numero di serie corrispondente a quello presente nel sistema di gestione delle risorse dell'azienda
- Se il dispositivo ha un certificato aziendale valido emesso dall'azienda
Questi due approcci possono essere utilizzati nel seguente livello di accesso personalizzato che usa gli attributi levels e device per determinare se il dispositivo è di proprietà dell'azienda o è gestito.
// Il dispositivo è aziendale se è soddisfatta una delle seguenti condizioni:
// 1. Se il numero di serie corrisponde a quello caricato dall'amministratore
// 2. Se il dispositivo ha un certificato valido emesso dall'azienda
levels.Require_Secure_Device &&
(
device.is_corp_owner_device ||
device.certificate.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)
L'impronta è il digest sha256 (in formato binario) con codifica base64 senza padding del certificato con codifica DER. La stringa può essere generata dal certificato in formato PEM utilizzando la procedura seguente con openssl:
$ openssl x509 -in cert.pem -out cert.der -outform DER
$ openssl dgst -sha256 -binary cert.der > digest.sha
$ openssl base64 -in digest.sha
- Emesso al momento del timestamp (iat)
- Timestamp di scadenza (exp) (che nella release corrente sembra cadere due settimane dopo l'emissione al momento del timestamp)
Il livello di accesso utilizza l'attributo device per garantire che i dati di CrowdStrike siano aggiornati. Tieni presente che BeyondCorp Enterprise ha un ritardo innato di 90 minuti per la ricezione di qualsiasi nuova valutazione di Falcon ZTA, pertanto l'utilizzo di durate inferiori a un'ora è sconsigliato.
// Assicurati che una di queste condizioni sia vera per i dati di Crowdstrike:
// Deve soddisfare una di queste condizioni
// 1. Il dispositivo è stato valutato nell'ultimo giorno
// 2. La valutazione non è scaduta (2 settimane dall'ultimo 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 collabora con molti partner dell'ecosistema BeyondCorp Alliance per integrare gli indicatori e il contesto dei dispositivi nella soluzione BeyondCorp Enterprise. I partner possono condividere qualsiasi numero di attributi con BeyondCorp, tra cui l'attributo is_compliance_device. Nel seguente esempio viene utilizzato l'attributo device per mostrare come possiamo verificare se uno qualsiasi dei partner BeyondCorp Alliance ha integrato BeyondCorp Enterprise e considerare il dispositivo conforme.
La macro existsestende l'espressione per ciascuno dei partner BeyondCorp Alliance con un operatore || (or).
// Verifica se uno dei partner BCA considera il dispositivo conforme
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)
In questo esempio vengono utilizzati gli attributi device per garantire che sui dispositivi sia installata una versione sicura di Android.
L'avvio verificato controlla se il codice eseguito proviene da una fonte attendibile (di solito gli OEM dei dispositivi), anziché da un utente malintenzionato o da un danneggiamento. Per maggiori dettagli, vedi Avvio verificato.
// Richiede uno stato di avvio verificato di Android verde
device.android_device_security.verify_boot == true
In questo esempio vengono utilizzati gli attributi device per richiedere che i dispositivi superino i controlli di conformità del Compatibility Test Suite (CTS). Per maggiori dettagli, vai a Compatibility Test Suite.
// Richiede che i dispositivi superino i controlli di conformità CTS
device.android_device_security.cts_profile_match == true
In questo esempio vengono utilizzati gli attributi device per richiedere che sui dispositivi sia attivata Verifica app di Google Play Protect.
Verifica app esegue la scansione delle app installate da origini diverse da Google Play per rilevare eventuali minacce. Inoltre, esegue periodicamente la scansione dei dispositivi per rilevare app potenzialmente dannose. Verifica app è attiva per impostazione predefinita. Per i dispositivi con gestione avanzata, puoi specificare se gli utenti possono disattivarla. Per saperne di più, vedi Applicare impostazioni per i dispositivi mobili Android.
// Richiede che sui dispositivi sia attivata Verifica app di Google Play Protect
device.android_device_security.verify_apps_enabled == true
In questo esempio vengono utilizzati gli attributi device per negare l'accesso ai dispositivi con app potenzialmente dannose. Queste app sono spesso chiamate malware. Per maggiori dettagli, vedi Applicazioni potenzialmente dannose.
// Nega l'accesso ai dispositivi che hanno app potenzialmente dannose android_device_security.has_potentially_harmful_apps != true
Esempi di accesso in base al tempo
Apri sezione | Comprimi tutto e torna all'inizio della pagina
Le aziende vogliono assicurarsi che i lavoratori che fanno i turni possano accedere alle risorse aziendali solo durante le ore del turno. I seguenti livelli di accesso utilizzano l'attributo levels per definire tre turni dal lunedì al venerdì.
// Turno 1 - Dal lunedì al venerdì, da mezzanotte alle 08:00
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')
// Turno 2 - Dal lunedì al venerdì, dalle 08:00 alle 16:00
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')
// Turno 3 - Dal lunedì al venerdì, dalle 16:00 a mezzanotte
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')
// Consenti ai lavoratori che fanno i turni di accedere alle risorse dal lunedì al venerdì dalle 9:00 alle 17:00, ad eccezione del 4 luglio.
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')
A volte le aziende vogliono consentire l'accesso di emergenza durante le emergenze quando l'amministratore non ha accesso a un dispositivo sicuro, ma ha bisogno dell'accesso di emergenza per un breve periodo di tempo.
In questo caso, crea un livello di accesso vincolato a ora e sede utilizzando l'attributo levels e assegnalo all'amministratore specifico. L'assegnazione di questo livello di accesso è valida solo durante l'orario specificato. Allo scadere di questo periodo di tempo, l'accesso dell'amministratore verrà di nuovo controllato dai requisiti esistenti.
// Consenti l'accesso temporaneo alle risorse il 1° marzo 2022, dalle 22:00 a mezzanotte,
// e questo accesso deve provenire dall'interno della regione degli Stati Uniti.
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”
// Tieni presente che l'ora di fine è esclusa, pertanto il periodo di cui sopra potrebbe includere due secondi in cui
// gli utenti potrebbero non avere accesso. Un'altra opzione è usare questa opzione
// !between('00:00:01','16:00:00')
Esempio di combinazione delle condizioni di due livelli
Definire un nuovo livello di accesso combinando le condizioni di due livelli di accessoQuesto livello di accesso utilizza gli attributi levels e richiede che gli utenti soddisfino le condizioni combinate di due livelli di accesso. In questo esempio, access_level_name_1 e access_level_name_2 fanno riferimento a un nome interno.
levels.access_level_name_1 && levels.access_level_name_2
