Best practice per l'abilitazione dei Controlli di servizio VPC

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

L'attivazione sconsiderata di Controlli di servizio VPC può causare problemi con le applicazioni esistenti e potrebbe potenzialmente causare un'interruzione del servizio. Ti consigliamo di pianificare attentamente l'attivazione e di concederti tempo sufficiente per raccogliere dati, eseguire test e analizzare i log delle violazioni. Assicurati che gli stakeholder del team operativo e del team delle applicazioni di Controlli di servizio VPC siano disponibili per l'attività.

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

Coordinare la comunicazione

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 avere una persona dedicata che crei e monitori riunioni interfunzionali e documenti gli elementi di azione. I tuoi team collaborano su quanto segue:

  • Pattern di accesso alle API Google Cloud
  • Identificazione delle violazioni del perimetro di servizio
  • Consentire l'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 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 all'esterno e all'interno del perimetro. Di seguito sono riportati alcuni pattern di accesso comuni:

  • Pattern di accesso ai dati: i servizi esterni al perimetro archiviano o recuperano i dati al suo interno.
  • Modelli di accesso alle risorse:
    • Gli utenti accedono ai progetti nel perimetro tramite la 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.
  • Modelli 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 classificali in 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.
  • I servizi di Automation come Terraform, Jenkins e Microsoft Azure DevOps che si trovano all'esterno del perimetro gestiscono il deployment delle risorse all'interno del perimetro.
  • I servizi di gestione della configurazione come Ansible, Chef o Puppet che si trovano al di fuori del perimetro gestiscono il deployment e la configurazione del software sulle risorse 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
  • Gli attori 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
  • Eventuali ipotesi relative al caso d'uso

Per un tracker di pattern di accesso e casi d'uso di esempio, consulta Modello di onboarding di VPC Service Controls - Casi d'uso (PDF).

Condurre interviste

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

  • I tuoi casi d'uso sono una priorità da considerare per l'attivazione di Controlli di servizio VPC? Ti consigliamo di prendere in considerazione solo i carichi di lavoro di prima priorità per l'attivazione iniziale e di integrare altri carichi di lavoro meno critici dopo aver protetto le risorse fondamentali per l'attività.

  • Puoi completare un'esecuzione completa di tutti i casi d'uso? Questo viene fatto per attivare tutti i possibili scenari di perimetro in modo da poter analizzare completamente e confermare che l'applicazione funzionerà correttamente dopo l'applicazione del perimetro.

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

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

Preparare una prova

La modalità di prova riduce la complessità del test dell'applicazione dei Controlli di servizio VPC identificando le violazioni senza interruzioni delle applicazioni. Configura un simulacro come perimetro separato che registra tutte le violazioni, ma non esegue alcun blocco. Puoi eseguire i 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 completa la procedura di colloquio e del caso d'uso per questi progetti.
  2. Crea un perimetro di prova 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 log aggregato che invii tutti i log a BigQuery oppure un sink di log per ogni progetto che invii i log di prova a un set di dati BigQuery comune. Per eseguire query su questi messaggi di log e identificare le violazioni di Controlli di servizio VPC, puoi utilizzare una query SQL.

    Per creare un sink di log che includa tutti i messaggi di 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 ai servizi non supportati. Configura il perimetro in modo che funzionino solo i servizi con limitazioni. A questo scopo, configura l'elenco dei servizi accessibili su 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. Consentire flussi legittimi noti contribuisce a ridurre il numero di log delle violazioni e consente ai revisori di concentrarsi su eventi che possono essere sottoposti a intervento.

  7. Verifica che nessuna delle VPC nei progetti abbia un percorso di uscita per internet o per 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 i casi d'uso

All'ora concordata, chiedi al team delle applicazioni di eseguire il proprio carico di lavoro sul progetto nel perimetro in modalità di prova. Assicurati di avere una copertura completa di tutto il codice che potrebbe chiamare le API di Google. Al termine della simulazione, il team di revisione designato può eseguire l'analisi dei log delle violazioni.

Analizza le violazioni

I log delle violazioni del 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 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'indirizzo email dell'identità che chiama l'API protetta.
  • L'indirizzo IP della persona che chiama.
  • Il tipo di violazione.

L'esempio seguente è una query BigQuery che restituisce tutti i dettagli delle violazioni:

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

Le seguenti strategie possono aiutarti a identificare le violazioni pertinenti:

  • Aggiungi un qualificatore del timestamp per la finestra temporale in cui ogni applicazione univoca 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à o dei progetti di carico 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 avere il permesso di richiamare l'API dall'esterno del perimetro?

In base ai criteri precedenti, 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 di private. Ciò indica che la chiamata proviene dalla rete di Google, dai servizi di Google o da un VPC in un progetto esterno al perimetro. Per i servizi Google come i scrittori di destinazioni log, devi aggiungere l'account di servizio Google a una lista consentita.

Le voci senza email sono dovute alla oscuramento dei log di controllo di Cloud per le operazioni di sola lettura che sono state rifiutate per mancanza di autorizzazioni IAM. 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 potrebbe essere un accesso accidentale da parte di un utente esterno alla tua organizzazione. Ad esempio, un utente che digita erroneamente un bucket con un nome simile.

Se viene visualizzato un tipo di violazione SERVICE_NOT_ALLOWED_FROM_VPC, il carico di lavoro potrebbe utilizzare un servizio 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 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 precedentemente noto come Data Studio.

Passaggi successivi