Best practice per l'abilitazione dei Controlli di servizio VPC

Questo documento descrive la procedura consigliata per configurare e applicare Protezione dei Controlli di servizio VPC nella tua organizzazione Google Cloud.

L'abilitazione senza riguardo dei Controlli di servizio VPC può causare problemi applicazioni e ciò potrebbe causare un'interruzione del servizio. Ti consigliamo di pianificare garantire la massima attenzione e concedere tempo sufficiente per raccogliere dati, eseguire test e analizzare i log delle violazioni. Assicurati che gli stakeholder il team operativo Controlli di servizio VPC e il team delle applicazioni sono disponibili per l'attività.

Per ogni carico di lavoro o applicazione di cui esegui l'onboarding in Controlli di servizio VPC, devi ripetere la procedura di abilitazione.

Coordina le comunicazioni

Spesso, il team di abilitazione della sicurezza di rete o del cloud gestisce l'attività di abilitazione di Controlli di servizio VPC. Ti consigliamo di aggiungere una scheda persona che crea e monitora azioni per riunioni e documenti interfunzionali elementi. I tuoi team collaborano su quanto segue:

  • Pattern di accesso alle API Google Cloud
  • Identificazione delle violazioni del perimetro di servizio
  • Autorizzazione dell'accesso al perimetro

Come per i firewall di rete convenzionali, l'obiettivo è identificare e consentire i flussi necessari per il funzionamento efficiente dei carichi di lavoro aziendali legittimi.

Pattern di accesso ai documenti e casi d'uso

Per iniziare il processo di abilitazione, identifica e documenta chiaramente tutti gli accessi validi pattern. I pattern di accesso sono tipi di interazioni ripetibili tra all'interno e all'esterno del perimetro. Di seguito sono riportati alcuni accessi comuni pattern:

  • Pattern di accesso ai dati: servizi esterni all'archivio o al recupero del perimetro che risiedono nel perimetro.
  • Pattern di accesso alle risorse:
    • Gli utenti accedono ai progetti nel perimetro tramite nella console Google Cloud.
    • Strumenti o servizi di terze parti gestiscono e accedono alle risorse all'interno del perimetro.
    • I servizi o le risorse all'interno del perimetro accedono alle API di Google.
  • Pattern di accesso agli endpoint:
    • Gli utenti accedono alle risorse all'interno del perimetro da un dispositivo gestito dalla tua organizzazione.
    • Le risorse on-premise comunicano con le risorse all'interno del perimetro.

Dopo aver identificato i pattern di accesso per un carico di lavoro, identifica i casi d'uso e classificarle in base a uno dei pattern di accesso nell'elenco precedente. Di seguito sono riportati alcuni casi d'uso comuni:

  • Gli amministratori cloud gestiscono i progetti che fanno parte di un perimetro.
  • Servizi di Automation come Terraform, Jenkins e Microsoft Azure DevOps che risiedono al di fuori del perimetro, gestire il deployment delle risorse all'interno perimetrale.
  • servizi di gestione delle configurazioni, come Ansible, Chef o Puppet, che che risiedono al di fuori del perimetro, per gestire il deployment su risorse che si trovano all'interno del perimetro.
  • I servizi di monitoraggio e applicazione della sicurezza come Forseti o SIEM che si trovano all'esterno del perimetro consumano dati o applicano i criteri di sicurezza a una risorsa all'interno del perimetro.

Per ogni caso d'uso, documenta quanto segue:

  • Il pattern di accesso
  • I soggetti che possono attivare il caso d'uso
  • Condizioni che attivano il caso d'uso
  • Indica se il caso d'uso è un pattern di accesso valido e deve essere consentito
  • Qualsiasi ipotesi attinente al caso d'uso

Per un esempio di pattern di accesso e tracker dei casi d'uso, vedi Modello di onboarding per i Controlli di servizio VPC - casi d'uso (PDF).

Effettua interviste

Conduci interviste con i team dei carichi di lavoro per discutere dei modelli di accesso e i casi d'uso raccolti dai modelli di comunicazione precedenti. Di seguito sono riportati alcuni esempi di domande che potresti porre durante interviste:

  • Considerare la priorità dei tuoi casi d'uso? Abilitazione dei Controlli di servizio VPC? Ti consigliamo di considerare solo carichi di lavoro prioritari per l'abilitazione iniziale e di carichi di lavoro meno critici dopo aver protetto le risorse business-critical.

  • Sei in grado di completare un'esecuzione completa di tutti i casi d'uso? Sei tu a fare per attivare tutti i possibili scenari perimetrali in modo da poter analizzare e verificare che l'applicazione funzioni correttamente dopo l'applicazione lungo il perimetro.

  • Quanto tempo è necessario per eseguire l'esecuzione del caso d'uso?

  • Stai pianificando modifiche significative a questo carico di lavoro che potrebbero entrare in conflitto con l'abilitazione dei Controlli di servizio VPC? Le funzionalità del carico di lavoro devono trovarsi in un stato stabile prima di abilitare Controlli di servizio VPC.

Prepara una prova

La modalità di prova riduce la complessità del test dell'applicazione dei Controlli di servizio VPC identificando le violazioni senza interrompere le applicazioni. Configura un simulacro come perimetro separato che registra tutte le violazioni, ma non esegue alcun blocco. Puoi eseguire carichi di lavoro mentre si trovano nel perimetro in modalità di prova e generare log delle violazioni da analizzare.

Per preparare l'ambiente di prova:

  1. Identifica tutti i progetti idonei a far parte del perimetro. e completare il caso d'uso e il processo di colloquio per questi progetti.
  2. Crea un perimetro di prova e aggiungere tutti i progetti.
  3. Nella sezione Controlli di servizio VPC perimetro di servizio, in Servizi limitati > Servizi da proteggere, aggiungi tutti quelli supportati i servizi di machine learning.

  4. Crea un sink di logging aggregato che invia tutti i log a BigQuery oppure sink di log per ogni progetto che invia log di prova a un server BigQuery comune del set di dati. Per eseguire query su questi messaggi di log e identificare i Controlli di servizio VPC violazioni, puoi usare una query SQL.

    Per creare un sink di log che includa tutti i log di Controlli di servizio VPC pertinenti utilizza il seguente filtro:

    logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"

  5. Per la massima sicurezza, non consentire l'accesso a servizi non supportati. Configura del perimetro, in modo che vengano utilizzati solo i servizi con restrizioni. A questo scopo, configura l'elenco dei servizi accessibili RESTRICTED-SERVICES.

  6. Se disponi già di un elenco di IP pubblici, identità, dispositivi attendibili, progetti o reti VPC consentiti, aggiungili a una regola di ingresso o a un livello di accesso, a seconda dei casi, nel perimetro della prova simulata. Autorizzazione delle informazioni legittime aiuta a ridurre il numero di log delle violazioni e consente ai revisori eventi strategici.

  7. Verifica che nessuno dei VPC nei progetti abbia un percorso in uscita verso internet o il VIP privato.

  8. Verifica che tutti i VPC abbiano il DNS *.googleapis.com che rimandi a restricted.googleapis.com.

    In Dettagli zona, il nome DNS *.googleapis.com ha restricted.googleapis.com nel campo Dati

Esegui casi d'uso

A un orario concordato, chiedi al team dell'applicazione di eseguire il proprio carico di lavoro progetto nel perimetro in modalità di prova. Assicurati di avere una copertura completa di tutti che potrebbe chiamare le API di Google. Quando la modalità di prova è completata, viene il team di revisione può eseguire l'analisi del log delle violazioni.

Analizza le violazioni

I log delle violazioni del dry run contengono la maggior parte delle informazioni necessarie determinare se una violazione dell'applicazione richiede una qualsiasi azione, come l'aggiunta di identità o indirizzi IP nella lista consentita del perimetro. I dati sulle violazioni vengono archiviati nella tabella BigQuery cloudaudit_googleapis_com_policy. Di seguito sono riportati gli elementi principali per analizzare la violazione:

  • Il servizio e il metodo dell'API protetti chiamati.
  • Il progetto all'interno del perimetro che avrebbe bloccato la richiesta.
  • L'email dell'identità che chiama l'API protetta.
  • L'indirizzo IP del chiamante.
  • Il tipo di violazione.

L'esempio seguente è una query BigQuery che restituisce tutti dettagli della violazione:

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') = "true" #ensure these are dry-run logs

Invia query su violazioni pertinenti

Le seguenti strategie possono aiutarti a identificare le violazioni pertinenti:

  • Aggiungi un qualificatore timestamp per la finestra temporale quando ogni applicazione unica ha implementato il proprio caso d'uso:

    WHERE receiveTimestamp >'2020-07-23 19:53:48.241317 UTC'

  • Aggiungi un filtro per la convenzione di denominazione delle identità o dei progetti dei carichi di lavoro:

    WHERE where resource.labels.project_id like '%APPLICATION_NAME%'

Esamina i log delle violazioni

Quando esamini i log delle violazioni, determina se le seguenti condizioni sono vere:

  • L'identità (email) dovrebbe richiamare le API protette?
  • Il chiamante deve poter richiamare l'API dall'esterno del perimetro?

In base ai criteri precedenti, determina se devi consentire l'identità, dispositivo, indirizzo IP, intervallo CIDR, progetto o rete da cui accedere al perimetro all'esterno.

Alcune voci potrebbero avere un indirizzo IP private. Ciò indica che proviene dalla rete Google, dai servizi Google o da un VPC in un progetto all'esterno del perimetro. Per servizi Google come writer sink di log, devi aggiungere l'account di servizio Google a una lista consentita.

Le voci senza indirizzi email sono dovute a Oscuramento di Cloud Audit Logs per le operazioni di sola lettura negate per mancanza di IAM autorizzazioni aggiuntive. In questi casi, puoi utilizzare l'indirizzo IP e i nomi delle risorse per comprendere l'origine del tentativo di accesso. Questo tipo di tentativo di accesso essere un accesso accidentale da parte di un utente esterno all'organizzazione. Ad esempio: un utente che digita in modo errato un bucket con nome simile.

Se visualizzi un tipo di violazione SERVICE_NOT_ALLOWED_FROM_VPC, il carico di lavoro potrebbe utilizzare un servizio supportato dai Controlli di servizio VPC, ma che non aggiunta all'elenco delle API protette. Ad esempio, se IAM causa una violazione di questo tipo, l'amministratore deve aggiungere IAM dei servizi accessibili eseguendo questo comando di Google Cloud CLI:

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

Puoi creare una dashboard di Looker Studio per esaminare le violazioni. Per ulteriori informazioni, consulta Monitorare le violazioni dei Controlli di servizio VPC nella tua organizzazione Google Cloud con Looker Studio. Looker Studio era noto in precedenza come Data Studio.

Passaggi successivi