Questo documento descrive le implementazioni a livello di accesso e fornisce suggerimenti per avviare l'applicazione del perimetro di servizio sulla base di liste consentite.
Quando completi un'esecuzione dry run dei workload, identifichi un elenco di indirizzi IP e identità che dovrai aggiungere a una lista consentita. Potresti anche scoprire che alcuni workload richiedono una lista consentita basata sul dispositivo. Per concedere l'accesso controllato alle risorse Google Cloud protette, puoi utilizzare i livelli di accesso dei Controlli di servizio VPC. Alcuni metodi pratici per implementare i livelli di accesso sono in base all'indirizzo IP, all'identità o al dispositivo.
Per saperne di più, consulta Accesso sensibile al contesto con regole in entrata.
Concessione dell'accesso in base all'IP di origine
Nei livelli di accesso per le liste consentite basate su IP puoi utilizzare solo intervalli CIDR di IP pubblici. Poiché questo metodo consente tutte le API protette da questo intervallo IP, l'ambiente di provenienza di questi IP deve essere attendibile e controllato. Un tipico scenario di utilizzo di questa lista consentita è quello di consentire l'accesso al perimetro dalle reti on-premise. Il seguente diagramma mostra come una lista consentita basata su IP blocca e consente l'accesso al perimetro:
Nel diagramma precedente, un'identità valida tenta di accedere al perimetro. I tentativi di accesso vengono rifiutati quando hanno origine da indirizzi IP internet. L'accesso viene però consentito quando il tentativo ha origine dagli indirizzi IP pubblici aziendali.
Una variante di questo scenario si ha quando si consente l'accesso al perimetro da risorse private di cui è stato eseguito il deployment in un progetto o un'organizzazione diversi. In questo caso d'uso, è necessario un gateway Cloud NAT nel progetto di origine.
Cloud NAT
ha un'integrazione con l'accesso privato Google che attiva automaticamente l'accesso privato Google sulla subnet della risorsa e mantiene interno il traffico verso i servizi e le API di Google, anziché instradarlo a internet utilizzando l'indirizzo IP esterno del gateway Cloud NAT.
Poiché il traffico viene instradato entro la rete Google interna, il campo RequestMetadata.caller_ip dell'oggetto AuditLog viene modificato in gce-internal-ip. In questo caso, per consentire l'accesso al perimetro devi configurare una regola in entrata che consenta l'accesso in base ad altri attributi, come il progetto o il service account, anziché configurare un livello di accesso basato sull'indirizzo IP di origine esterno.
Concessione dell'accesso in base all'identità del chiamante
Per implementare una lista consentita basata sull'identità, devi aggiungere service account e super amministratori dell'organizzazione a una lista consentita. Per queste identità il perimetro è aperto da qualsiasi indirizzo IP, quindi devi assicurarti che siano ben protette. Devi anche assicurarti di evitare la generazione di chiavi per i service account che hai aggiunto a una lista consentita. È insolito aggiungere identità utente a una lista consentita (i gruppi non possono essere aggiunti a una lista consentita) in un perimetro.
È possibile accedere alle risorse all'interno del perimetro da 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é i Controlli di servizio VPC non supportano Cloud Shell.
Qualificazione dell'accesso in base agli attributi del dispositivo chiamante
L'attendibilità del dispositivo, o anche endpoint attendibile, si basa sull'accesso di un utente valido dell'organizzazione a un browser Chrome o a un Chromebook. L'attendibilità si applica alla sessione del sistema operativo in cui l'utente ha eseguito l'accesso. Ad esempio, un utente Windows che ha effettuato l'accesso e sta eseguendo una sessione di Chrome (non occorre che il browser sia aperto) può chiamare correttamente i comandi gcloud CLI sulle API protette dal perimetro. Tuttavia, una sessione di un utente Windows diverso sulla stesso computer non può chiamare comandi sulle API protette dal perimetro.
Le seguenti condizioni del dispositivo sono utili per stabilire l'attendibilità del dispositivo:
ChromeOS verificato è una condizione altamente sicura e verificata crittograficamente che indica che un utente dell'organizzazione valido ha eseguito l'accesso a un Chromebook con avvio protetto. Questa è una condizione di attendibilità di livello 1 consigliata.
Richiedere l'approvazione dell'amministratore per l'accesso al dispositivo consente agli amministratori di Cloud Identity di approvare ogni dispositivo prima di concedere l'accesso. Per impostazione predefinita, i dispositivi vengono approvati automaticamente se ha eseguito l'accesso un utente dell'organizzazione valido. Tuttavia, ti consigliamo di disattivare l'opzione di approvazione automatica.
L'opzione Richiede un dispositivo di proprietà dell'azienda si basa sul recupero del numero di serie dal sistema operativo, che di solito proviene dal BIOS, da parte dell'agente Chrome. Questo numero deve corrispondere ai numeri di serie esistenti che hai inserito 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 la concessione dell'accesso controllato in base alle condizioni descritte nell'elenco precedente, consulta Modello di onboarding dei Controlli di servizio VPC - lista consentita (PDF).
Avvia l'applicazione
Dopo aver progettato la lista consentita e aggiornato i livelli di accesso, ti consigliamo di eseguire nuovamente i workload per verificare che non ci siano violazioni. Se i workload vengono eseguiti senza violazioni, puoi avviare l'applicazione dei Controlli di servizio VPC senza influire sulle applicazioni.
Quando pianifichi l'applicazione, includi quanto segue:
- Scegli una data di applicazione e comunicala a tutti i team interessati.
- Assicurati che i team delle operazioni di sicurezza e di risposta agli incidenti siano a conoscenza del deployment. Assicurati inoltre che persone con le autorizzazioni appropriate ispezionino i log e approvino ulteriori liste consentite, se necessario.
- Assicurati che il team di risposta agli incidenti possa aprire una richiesta di assistenza Google Cloudin caso di domande o problemi.
- Crea o modifica il perimetro e i livelli di accesso utilizzando strumenti di automazione come Terraform. Ti sconsigliamo di eseguire queste attività manualmente.
Quando avvii l'applicazione, inizia spostando i progetti associati a un singolo workload dal perimetro in modalità dry run al perimetro attivo. Assicurati di lasciare il tempo necessario per l'applicazione mentre esamini i log delle violazioni. Ripeti la procedura per i workload rimanenti uno alla volta.
Per visualizzare le violazioni bloccate, configura un sink di log aggregato che invii gli audit log per tutti i progetti nel 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.