Questo documento descrive le implementazioni a livello di accesso e fornisce per avviare l'applicazione forzata del perimetro di servizio in base 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 inoltre scopri che alcuni carichi di lavoro necessitano di una lista consentita basata sui dispositivi. Per concedere l'accesso alle risorse Google Cloud protette, puoi utilizzare Livelli di accesso ai Controlli di servizio VPC. 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 le API protette da questo intervallo IP, l'ambiente dietro questi IP deve essere affidabile 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:
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 quando provengono dall'azienda dagli indirizzi IP pubblici.
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. Devi inoltre assicurati di evitare di minare chiavi per gli account di servizio che hai aggiunto a una lista consentita. È raro aggiungere identità utente a una lista consentita (i gruppi non possono essere aggiunte a una lista consentita) su un perimetro.
Le risorse all'interno del perimetro sono accessibili tramite le VM all'interno da reti on-premise attendibili o da dispositivi attendibili. Me consiglia di utilizzare Cloud Workstations per accedere di risorse all'interno dei perimetri, poiché Controlli di servizio VPC non supporta 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, una diversa sessione di un utente Windows sulla stessa macchina non può chiamare sulle API del perimetro protetto.
Le seguenti condizioni dei dispositivi sono utili per stabilire l'attendibilità dei dispositivi:
ChromeOS verificato è una condizione molto sicura e verificata tramite crittografia che indica che un utente dell'organizzazione valido abbia eseguito l'accesso a un Chromebook avviato in modo sicuro. Questo è 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 l'accesso è stato concesso. 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 dispositivo di proprietà dell'azienda si basa sull'agente Chrome che recupera i dati numero di serie del sistema operativo, che solitamente proviene dal BIOS. Questo numero deve corrispondere ai numeri di serie esistenti inserito in Cloud Identity.
Poiché il numero di serie non è autorevole sui dispositivi non ChromeOS, utente con privilegi di amministratore elevati potrebbe essere in grado di eseguire lo spoofing il 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 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 carichi di lavoro senza violazioni, puoi avviare i 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.
- Assicurarsi che i team addetti alle operazioni di sicurezza e alla risposta agli incidenti siano a conoscenza per il 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.
- Creare o modificare i livelli perimetrali e di accesso utilizzando strumenti di automazione come Terraform. Consigliamo di non eseguire queste attività manualmente.
Quando avvii l'applicazione forzata, sposta innanzitutto i progetti associati con un singolo carico di lavoro, dal perimetro in modalità di prova a quello attivo. Marca lascia che l'applicazione venga eseguita correttamente mentre osservi le 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 a BigQuery gli audit log per tutti i progetti nel perimetro. Quindi, esegui questa 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
- Scopri come consentire l'accesso alle risorse protette dall'esterno del perimetro.
- Scopri come elencare, aggiornare ed eliminare i perimetri di servizio.