Esempi di accesso sensibile al contesto per la modalità avanzata

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

Spesso 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

// 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
)
)
)

Limitato alle app web desktop e non applicabile ad API o app mobile

Puoi migliorare la sicurezza dell'accesso alle app che contengono dati sensibili richiedendo le credenziali di sessione vincolate al dispositivo (DBSC). DBSC lega la sessione di un utente al suo dispositivo quando utilizza il browser Chrome su Windows, il che può ridurre notevolmente il rischio di compromissione della sessione.

Questo livello di accesso utilizza l'attributo request.auth per verificare che le sessioni dell'utente siano associate a un dispositivo specifico. In questo caso, l'accesso viene concesso all'app. In caso contrario (ovvero se la sessione non è associata a DBSC), l'accesso viene negato.

Per evitare errori, attiva DBSC per tutti gli account utente soggetti a questo livello di accesso. Per maggiori dettagli, vedi Attiva DBSC.

Imposta il livello di accesso in modalità di monitoraggio prima di attivare la modalità attiva. In modalità di monitoraggio, puoi verificare l'impatto dell'applicazione forzata dei livelli di accesso senza interrompere l'accesso degli utenti.

Utilizza questa espressione CEL per creare il tuo livello di accesso personalizzato:

request.auth.sessionBoundToDevice(origin) == true

Utilizza questa espressione CEL per applicare il controllo dei dati sensibili solo sui dispositivi Windows con il browser Chrome versione 136 o successive:

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

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.

Questo livello di accesso utilizza l'attributo device per verificare che gli utenti utilizzino l'ultima versione di un browser Chrome gestito e consente l'accesso solo tramite questo browser.

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

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.

// 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 questo esempio, il livello di accesso utilizza l'attributo device per richiedere il browser Chrome con requisiti di sicurezza di base.

// 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 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.

// 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

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.

// The device is a corporate if one of the following conditions is true:
// 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_owned_device ||
device.certificates.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)

Il livello di accesso utilizza l'attributo device per garantire che i dati di CrowdStrike siano aggiornati. Tieni presente che Chrome Enterprise Premium 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")
)

Chrome Enterprise Premium collabora con molti partner dell'ecosistema BeyondCorp Alliance per integrare gli indicatori e il contesto dei dispositivi nella soluzione Chrome Enterprise Premium. I partner possono condividere qualsiasi numero di attributi con Chrome Enterprise Premium, tra cui l'attributo is_compliant_device. Nel seguente esempio viene utilizzato l'attributo device per mostrare come possiamo verificare se uno qualsiasi dei partner BeyondCorp Alliance ha integrato Chrome Enterprise Premium e considerare il dispositivo conforme.

La macro existsestende l'espressione per ciascuno dei partner BeyondCorp Alliance con un operatore || (or).

// 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 questo esempio vengono utilizzati gli attributi device per garantire che sui dispositivi sia installata una versione sicura di Android.

Avvio verificato controlla se il codice eseguito proviene da una fonte attendibile (di solito gli OEM del dispositivo), anziché da un malintenzionato o da dati corrotti. Per maggiori dettagli, consulta Avvio verificato.

// Richiede uno stato di avvio verificato di Android verde
device.android_device_security.verified_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 vengono spesso chiamate malware. Per maggiori dettagli, vedi Applicazioni potenzialmente dannose.

// Nega l'accesso ai dispositivi che hanno app potenzialmente dannoseandroid_device_security.has_potentially_harmful_apps != true

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ì.

// 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')

// Allow shift workers to access resources from Monday to Friday between 9 AM to 5 PM, except for July fourth.
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"
// Note that the end time is exclusive, so the above potentially has 2 seconds that
// the users may not have access. Un'altra opzione è usare questa opzione
// !between('00:00:01','16:00:00')

Questo 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