Best practice per l'abilitazione dei Controlli di servizio VPC

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

L'attivazione incauta dei Controlli di servizio VPC può causare problemi alle applicazioni esistenti e potenzialmente provocare un'interruzione del servizio. Ti consigliamo di pianificare attentamente l'attivazione e di dedicare tempo sufficiente alla raccolta dei dati, all'esecuzione dei test e all'analisi dei log delle violazioni. Assicurati che gli stakeholder del team operativo e del tuo team delle applicazioni dei Controlli di servizio VPC siano disponibili per l'attività.

Per ogni workload o applicazione di cui esegui l'onboarding nei Controlli di servizio VPC, dovrai ripetere la procedura di attivazione.

Coordina le comunicazioni

Spesso, il team responsabile della sicurezza di rete o dell'abilitazione del cloud dirige l'attività di attivazione dei Controlli di servizio VPC. Ti consigliamo di designare una persona dedicata che crei e monitori le riunioni interfunzionali e documenti le attività. I tuoi team collaborano alle seguenti attività:

  • Google Cloud Pattern di accesso alle API
  • Identificazione delle violazioni del perimetro di servizio
  • Impostazione delle autorizzazioni di accesso al perimetro

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

Documenta i pattern di accesso e i casi d'uso

Per iniziare la procedura di attivazione, identifica e documenta chiaramente tutti i pattern di accesso validi. I pattern di accesso sono tipi ripetibili di interazioni tra elementi esterni e interni al perimetro. Di seguito sono descritti alcuni pattern di accesso comuni:

  • Pattern di accesso ai dati: i servizi esterni al perimetro archiviano o recuperano i dati che si trovano nel perimetro.
  • Pattern di accesso alle risorse:
    • Gli utenti accedono ai progetti nel perimetro tramite la consoleGoogle Cloud .
    • Strumenti o servizi di terze parti gestiscono e accedono alle risorse all'interno del perimetro.
    • Servizi o 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 workload, identifica i casi d'uso e classificali in uno dei pattern di accesso descritti nell'elenco precedente. Ecco alcuni casi d'uso comuni:

  • Gli amministratori cloud gestiscono i progetti che fanno parte di un perimetro.
  • I servizi di automazione come Terraform, Jenkins e Microsoft Azure DevOps che si trovano al di fuori del perimetro gestiscono il deployment delle risorse all'interno del perimetro.
  • I servizi di gestione delle configurazioni come Ansible, Chef o Puppet che si trovano al di fuori del perimetro gestiscono il deployment e la configurazione del software in risorse che si trovano all'interno del perimetro.
  • I servizi di monitoraggio e applicazione della sicurezza come Forseti o SIEM che si trovano al di fuori del perimetro utilizzano i dati o applicano le policy di sicurezza a una risorsa che si trova all'interno del perimetro.

Per ogni caso d'uso, documenta quanto segue:

  • Il pattern di accesso
  • Gli attori che possono attivare il caso d'uso
  • Le condizioni che attivano il caso d'uso
  • Se il caso d'uso è un pattern di accesso valido e deve essere consentito
  • Eventuali ipotesi relative al caso d'uso

Per un esempio di pattern di accesso e di monitoraggio dei casi d'uso, consulta Modello di onboarding dei Controlli di servizio VPC - casi d'uso (PDF).

Conduci interviste

Conduci interviste con i team responsabili dei workload per discutere i pattern di accesso e i casi d'uso che raccogli dai template di comunicazione precedenti. Di seguito sono riportati alcuni esempi di domande che potresti porre durante questi colloqui:

  • I tuoi casi d'uso sono una priorità assoluta da prendere in considerazione per l'attivazione dei Controlli di servizio VPC? Ti consigliamo di considerare solo i workload di massima priorità per l'attivazione iniziale e di eseguire l'onboarding di altri workload meno critici dopo aver protetto le risorse business-critical.

  • Sei in grado di portare a termine un'esecuzione completa di tutti i casi d'uso? Questo serve ad attivare tutti i possibili scenari perimetrali in modo da poter analizzare e confermare completamente che l'applicazione funzionerà correttamente dopo aver applicato il perimetro.

  • Quanto tempo ci vuole per completare l'esecuzione del caso d'uso?

  • Stai pianificando modifiche importanti per questo workload che potrebbero entrare in conflitto con l'attivazione dei Controlli di servizio VPC? Le funzionalità del workload devono essere in uno stato stabile prima di attivare i Controlli di servizio VPC.

Prepara un dry run

La modalità dry run riduce la complessità dei test di applicazione forzata dei Controlli di servizio VPC identificando le violazioni senza interrompere l'esecuzione delle applicazioni. Puoi configurare un dry run come perimetro separato che registra tutte le violazioni ma non esegue alcun blocco. Puoi eseguire i workload mentre si trovano nel perimetro in modalità dry run e generare log di violazione da analizzare.

Per preparare l'ambiente di dry run, segui questa procedura:

  1. Identifica tutti i progetti idonei a far parte del perimetro e completa il caso d'uso e i colloqui per questi progetti.
  2. Crea un perimetro in modalità dry run e aggiungi tutti i progetti.
  3. Nel perimetro di servizio dei Controlli di servizio VPC, in Servizi limitati > Servizi da proteggere, aggiungi tutti i servizi supportati.

  4. Crea un sink di logging aggregato che invia tutti i log a BigQuery oppure crea un sink di log per ogni progetto che invia i log di dry run a un set di dati BigQuery comune. Per eseguire query su questi messaggi di log e identificare le violazioni dei Controlli di servizio VPC, puoi utilizzare una query SQL.

    Per creare un sink di log che includa tutti i messaggi di log dei Controlli di servizio VPC pertinenti, utilizza questo filtro:

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

  5. Per garantire la massima sicurezza, non consentire l'accesso a servizi non supportati. Configura il perimetro in modo che solo i servizi limitati funzionino al suo interno. Per farlo, configura l'elenco dei servizi accessibili su RESTRICTED-SERVICES.

  6. Se hai già un elenco di IP pubblici, identità, dispositivi attendibili, progetti o reti VPC consentiti, aggiungili a una regola in entrata o a un livello di accesso, a seconda dei casi, nel perimetro in modalità dry run. Consentire flussi legittimi noti aiuta a ridurre il numero di log di violazione e consente ai revisori di concentrarsi su eventi su cui è possibile intervenire.

  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 punta a restricted.googleapis.com.

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

Esegui i casi d'uso

All'ora concordata, il team dell'applicazione esegue il workload sul progetto nel perimetro in modalità dry run. Assicurati di avere una copertura completa di tutto il codice che potrebbe chiamare API di Google. Al termine del dry run, il team di revisione designato può eseguire l'analisi dei log delle violazioni.

Analizza le violazioni

I log delle violazioni dry run contengono la maggior parte delle informazioni necessarie per determinare se una violazione dell'applicazione richiede un'azione, ad esempio l'aggiunta di identità o indirizzi IP alla lista consentita per il perimetro. I dati sulle violazioni vengono archiviati nella tabella BigQuery cloudaudit_googleapis_com_policy. Gli elementi principali da analizzare in caso di violazione sono i seguenti:

  • Il servizio protetto e il metodo API chiamato.
  • Il progetto all'interno del perimetro che avrebbe bloccato la richiesta.
  • L'indirizzo 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 i dettagli di una 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

Esegui query sulle violazioni pertinenti

Ecco alcune strategie che possono aiutarti a identificare le violazioni pertinenti:

  • Aggiungi un qualificatore di timestamp per la finestra temporale in cui ogni applicazione specifica ha eseguito 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à dei workload o dei progetti:

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

Esamina i log delle violazioni

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

  • È previsto che l'identità (email) richiami le API protette?
  • Al chiamante deve essere consentito di richiamare l'API dall'esterno del perimetro?

In base a questi criteri, determina se devi consentire all'identità, al dispositivo, all'indirizzo IP, all'intervallo CIDR, al progetto o alla rete di accedere al perimetro dall'esterno.

Alcune voci potrebbero avere un indirizzo IP private. Ciò indica che la chiamata ha avuto origine dalla rete Google, ossia dai servizi Google stessi o da un VPC in un progetto esterno al perimetro. Per i servizi Google come i writer sink di log devi aggiungere il service account Google a una lista consentita.

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

Se vedi una violazione di tipo SERVICE_NOT_ALLOWED_FROM_VPC, il workload potrebbe utilizzare un servizio che è supportato dai Controlli di servizio VPC ma non è stato aggiunto all'elenco delle API protette. Ad esempio, se IAM ha causato una violazione di questo tipo, l'amministratore deve aggiungere IAM all'elenco dei servizi accessibili eseguendo il seguente comando di Google Cloud CLI:

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

Per esaminare le violazioni, puoi creare una dashboard di Looker Studio. Per saperne di più, consulta Monitora le violazioni di Controlli di servizio VPC nella tua organizzazione Google Cloud con Looker Studio. Looker Studio era precedentemente noto come Data Studio.

Passaggi successivi