Progettare i livelli di accesso

Questo documento descrive le implementazioni a livello di accesso e fornisce consigli per avviare l'applicazione del perimetro del servizio in base alle liste consentite.

Quando completi un'esecuzione di prova dei carichi di lavoro, identifichi un elenco di IP gli indirizzi e le identità da aggiungere a una lista consentita. Potresti anche scoprire che alcuni carichi di lavoro richiedono una lista consentita basata sul dispositivo. Per concedere accesso controllato alle risorse Google Cloud protette, puoi utilizzare i livelli di accesso di VPC Service Controls. Alcuni modi pratici per I livelli di accesso implementati si basano sull'indirizzo IP, sull'identità o sul dispositivo.

Per maggiori informazioni, consulta 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 dietro questi IP deve essere attendibile e controllato. Uno scenario di utilizzo tipico per questa lista consentita è consentire l'accesso perimetrale dalle reti on-premise. Il seguente diagramma mostra come La lista consentita basata su IP blocca e consente l'accesso al perimetro:

Il perimetro della rete e del servizio di VPC Service Controls impedisce l'accesso da un'identità valida su una rete non attendibile.

Nel diagramma precedente, un'identità valida tenta di accedere al perimetro. I tentativi di accesso vengono rifiutati quando provengono da qualsiasi IP internet. indirizzi IP esterni. Tuttavia, l'accesso è consentito se proviene dagli indirizzi IP pubblici aziendali.

Una variante di questo scenario si verifica quando consenti l'accesso al perimetro da risorse private di cui è stato eseguito il deployment in un progetto o un'organizzazione diversa. In questo caso, è necessario un gateway Cloud NAT nel progetto di origine. Cloud NAT ha un'integrazione con l'accesso privato Google che abilita automaticamente l'accesso privato Google sulla subnet della risorsa e mantiene interno il traffico verso le API e i servizi Google, anziché indirizzarlo a internet utilizzando l'indirizzo IP esterno del gateway Cloud NAT. Quando il traffico viene instradato all'interno della rete Google interna, Il campo RequestMetadata.caller_ip dell'oggetto AuditLog è oscurato in gce-internal-ip. In questo caso, per consentire l'accesso al perimetro, devi configurare una regola di ingresso per consentire l'accesso in base ad altri attributi, come il progetto o l'account di servizio, anziché configurare un livello di accesso in base all'indirizzo IP dell'origine esterna.

Concessione dell'accesso in base all'identità del chiamante

Per implementare una lista consentita basata su identità, aggiungi account di servizio e super amministratori dell'organizzazione a una lista consentita. Il perimetro è aperto per queste identità da qualsiasi indirizzo IP, devi assicurarti che le identità siano ben protette. Inoltre, devi assicurarti di evitare di coniare chiavi per gli account di servizio che hai aggiunto a una lista consentita. Non è comune aggiungere le 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 tramite 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.

Accesso idoneo in base agli attributi del dispositivo del chiamante

L'attendibilità del dispositivo, chiamata anche endpoint attendibile, è basata sul fatto di avere un valido utente dell'organizzazione che ha eseguito l'accesso a un browser Chrome o a un Chromebook. Il trust si applica alla sessione a cui è stato eseguito l'accesso dal sistema operativo. Ad esempio, un utente Windows che ha eseguito l'accesso eseguire una sessione Chrome (non è necessario che il browser sia aperto) correttamente i comandi della gcloud CLI sulle API del perimetro protetto. Tuttavia, un'altra sessione di un utente Windows sulla stessa macchina non può chiamare sulle API del perimetro protetto.

Le seguenti condizioni del dispositivo sono utili per stabilire la fiducia del dispositivo:

  • ChromeOS verificato è una condizione altamente sicura e verificata tramite crittografia che indica che un utente valido dell'organizzazione ha eseguito l'accesso a un Chromebook avviato in modo sicuro. Questa è una condizione di attendibilità di primo livello consigliata.

    Il criterio del sistema operativo con l'opzione ChromeOS verificato attivata.

  • L'opzione Richiedi l'approvazione dell'amministratore per l'accesso al dispositivo consente agli amministratori di Cloud Identity di approvare ogni dispositivo prima che venga concesso l'accesso. Per impostazione predefinita, i dispositivi vengono approvati automaticamente se dispongono di un è stato effettuato l'accesso da un utente dell'organizzazione valido. Tuttavia, ti consigliamo di disattivare l'opzione di approvazione automatica.

  • L'opzione Richiedi un 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 inserita in Cloud Identity.

    Poiché il numero di serie non è attendibile nei dispositivi non ChromeOS, un utente con privilegi amministrativi elevati potrebbe essere in grado di falsificarlo. 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 discussi nell'elenco precedente, vedi Modello di onboarding per i Controlli di servizio VPC - Lista consentita (PDF).

Avvia applicazione

Dopo aver progettato la lista consentita e aggiornato i livelli di accesso, ti consigliamo di: eseguire nuovamente i carichi di lavoro per confermare che non siano presenti violazioni. Se i carichi di lavoro vengono eseguiti senza violazioni, puoi avviare l'applicazione dei Controlli di servizio VPC senza influire sulle applicazioni.

Quando prevedi l'applicazione forzata, includi quanto segue:

  • Scegli una data di applicazione e comunica tale data a tutti i team correlati.
  • Assicurati che i team di operazioni di sicurezza e di risposta agli incidenti siano a conoscenza del deployment. Inoltre, assicurati che le persone con i requisiti ispezionare i log e approvare ulteriori liste consentite, se necessario.
  • Assicurati che il team di risposta alla situazione possa aprire un Google Cloud una richiesta di assistenza in caso di domande o problemi.
  • Crea o modifica i livelli di perimetro e 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 carico di lavoro dal perimetro di prova al perimetro di produzione. Assicurati di lasciare il tempo necessario all'applicazione per funzionare correttamente mentre osservi i log delle violazioni. Ripeti il processo per i carichi di lavoro rimanenti uno alla volta.

Per visualizzare le violazioni bloccate, configura un sink di log aggregato che invii i log di controllo per tutti i progetti nel perimetro a BigQuery. Quindi, esegui la seguente query:

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