Questo documento descrive le implementazioni a livello di accesso e fornisce suggerimenti per avviare l'applicazione del perimetro di servizio in base alle liste consentite.
Quando completi un'esecuzione di prova dei carichi di lavoro, devi identificare un elenco di indirizzi IP e identità che devi aggiungere a una lista consentita. Potresti anche notare che alcuni carichi di lavoro richiedono una lista consentita basata sui dispositivi. Per concedere l'accesso controllato alle risorse Google Cloud protette, puoi utilizzare i livelli di accesso di Controlli di servizio VPC. Alcuni modi pratici per implementare i livelli di accesso si basano su indirizzo IP, identità o dispositivo.
Per saperne di più, vedi Accesso sensibile al contesto con le regole in entrata.
Concessione dell'accesso in base all'IP di origine
Puoi utilizzare solo intervalli CIDR IP pubblici nei livelli di accesso per le liste consentite basate su IP. Poiché questo metodo consente tutte le API protette da questo intervallo IP, l'ambiente protetto da questi IP deve essere considerato attendibile e controllato. Uno scenario di utilizzo tipico per questa lista consentita è consentire l'accesso perimetro dalle reti on-premise. Il seguente diagramma mostra in che modo una lista consentita basata su IP blocca e consente l'accesso perimetrale:
Nel diagramma precedente, un'identità valida tenta di accedere al perimetro. I tentativi di accesso vengono rifiutati quando provengono da qualsiasi indirizzo IP internet. Tuttavia, l'accesso è consentito quando proviene dagli indirizzi IP pubblici aziendali.
Concessione dell'accesso in base all'identità del chiamante
Per implementare una lista consentita basata sull'identità, devi aggiungere account di servizio e super amministratori dell'organizzazione a una lista consentita. Il perimetro è aperto per queste identità provenienti da qualsiasi indirizzo IP, quindi devi assicurarti che le identità siano ben protette. Devi inoltre assicurarti di evitare il minting di chiavi per gli account di servizio che hai aggiunto a una lista consentita. Non è raro aggiungere identità utente a una lista consentita (i gruppi non possono essere aggiunti a una lista consentita) su un perimetro.
È possibile accedere alle risorse all'interno del perimetro tramite le VM all'interno del perimetro, da reti on-premise attendibili o da dispositivi attendibili. Ti consigliamo di utilizzare Cloud Workstations per accedere alle risorse all'interno dei perimetri perché Controlli di servizio VPC non supporta Cloud Shell.
Qualifica dell'accesso in base agli attributi del dispositivo del chiamante
L'attendibilità del dispositivo, nota anche come endpoint attendibile, si basa sul fatto che un utente dell'organizzazione valido abbia eseguito l'accesso a un browser Chrome o a un Chromebook. L'attendibilità si applica alla sessione di accesso al sistema operativo. Ad esempio, un utente Windows che ha eseguito l'accesso ed esegue una sessione di Chrome (non è necessario aprire il browser) può chiamare correttamente i comandi dell'interfaccia a riga di gcloud CLI sulle API perimetrali protette. Tuttavia, una sessione utente Windows diversa sulla stessa macchina non può chiamare i comandi sulle API perimetrali protette.
Le seguenti condizioni relative ai dispositivi sono utili per stabilire l'attendibilità dei dispositivi:
Chrome OS verificato è una condizione di sicurezza elevata e crittografata che indica che un utente dell'organizzazione valido ha eseguito l'accesso a un Chromebook avviato in modo sicuro. Questa è una condizione di attendibilità di livello 1 consigliata.
Richiedi l'approvazione dell'amministratore per l'accesso ai dispositivi consente agli amministratori di Cloud Identity di approvare ogni dispositivo prima di concedere qualsiasi accesso. Per impostazione predefinita, i dispositivi vengono approvati automaticamente se ha eseguito l'accesso a un utente dell'organizzazione valido. Tuttavia, consigliamo di disattivare l'opzione di approvazione automatica.
Richiedi dispositivo di proprietà dell'azienda si basa sull'agente Chrome che recupera il numero di serie dal sistema operativo, che in genere proviene dal BIOS. Questo numero deve corrispondere ai numeri di serie esistenti inseriti in Cloud Identity.
Poiché il numero di serie non è autorevole nei dispositivi non ChromeOS, un utente con privilegi amministrativi elevati potrebbe essere in grado di eseguire lo spoofing del numero di serie. Ti consigliamo di utilizzare questa condizione solo come controllo di livello 2.
Per un tracker di esempio per concedere l'accesso controllato in base alle condizioni discusse nell'elenco precedente, vedi Modello di onboarding dei Controlli di servizio VPC - lista consentita (PDF).
Avvia applicazione forzata
Dopo aver progettato la lista consentita e aggiornato i livelli di accesso, ti consigliamo di eseguire di nuovo i carichi di lavoro per verificare che non siano presenti violazioni. Se i carichi di lavoro vengono eseguiti senza violazioni, puoi avviare l'applicazione forzata dei Controlli di servizio VPC senza influire sulle applicazioni.
Quando prevedi l'applicazione forzata, includi quanto segue:
- Scegliere una data di applicazione delle norme e comunicarla a tutti i team correlati.
- Assicurati che i team delle operazioni di sicurezza e di risposta agli incidenti siano a conoscenza del deployment. Inoltre, assicurati che le persone con le autorizzazioni appropriate esaminino i log e approvino ulteriori liste consentite, se necessario.
- Assicurati che il team di risposta alla situazione possa aprire una richiesta di assistenza Google Cloud in caso di domande o problemi.
- Crea o modifica il perimetro e i livelli di accesso utilizzando strumenti di automazione come Terraform. Sconsigliamo di eseguire queste attività manualmente.
Quando avvii l'applicazione, inizia spostando i progetti associati a un singolo carico di lavoro dal perimetro in modalità di prova al perimetro attivo. Assicurati di lasciare tempo per l'esecuzione corretta dell'applicazione mentre osservi i log delle violazioni. Ripeti il processo per i carichi di lavoro rimanenti uno alla volta.
Per individuare le violazioni bloccate, configura un sink di logging aggregato che invii gli audit log per tutti i progetti all'interno del perimetro a BigQuery. Quindi, esegui la query seguente:
SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter
Passaggi successivi
- Scopri come consentire l'accesso alle risorse protette dall'esterno del perimetro.
- Scopri come elencare, aggiornare ed eliminare i perimetri di servizio.