Best practice per l'abilitazione dei Controlli di servizio VPC

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

L'abilitazione senza riguardo dei Controlli di servizio VPC può causare problemi con applicazioni e ciò potrebbe 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 il team operativo Controlli di servizio VPC e il team delle applicazioni sono disponibili per l'attività.

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

Coordina le comunicazioni

Spesso, il team di sicurezza di rete o di abilitazione del cloud Operazione di abilitazione dei 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 sui seguenti argomenti:

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

Proprio come con i firewall di rete convenzionali, lo scopo è identificare e consentire i flussi necessari per il funzionamento efficiente di attività commerciali legittime carichi di lavoro con scale out impegnativi.

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 di interazioni ripetibili tra all'esterno e all'interno del perimetro. Di seguito sono riportati alcuni pattern di accesso comuni:

  • 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 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.
  • 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 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 automazione 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.
  • Monitoraggio della sicurezza e applicazione di servizi come Forseti o SIEM che risiedono al di fuori del perimetro consumano dati o applicano di sicurezza su una risorsa che si trova 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
  • Eventuali ipotesi relative 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).

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 VPC Service Controls? Ti consigliamo di prendere in considerazione solo i carichi di lavoro di prima priorità per l'attivazione iniziale e di eseguire l'onboarding di altri carichi di lavoro meno critici dopo aver protetto le risorse fondamentali per l'attività.

  • Sei in grado di 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 ci vuole per esaminare l'esecuzione del caso d'uso?

  • Stai pianificando modifiche sostanziali per questo carico di lavoro che potrebbero entrare in conflitto con l'attivazione di Controlli di servizio VPC? Le funzionalità del carico di lavoro devono trovarsi in un 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. Configuri un come perimetro separato che registra tutte le violazioni, ma non esegue bloccare qualsiasi tipo di 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 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 di VPC Service Controls, 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 i Controlli di servizio VPC violazioni, puoi usare una query SQL.

    Per creare un sink dei log che includa tutti i messaggi di log di VPC Service Controls 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 RESTRICTED-SERVICES.

  6. Se hai già un elenco di IP pubblici, identità, dispositivi, progetti o reti VPC, aggiungili a una regola in entrata o a un accesso come applicabile nel perimetro di prova. 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 punta a restricted.googleapis.com.

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

Esegui i 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 tutto il codice 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 sono archiviati nella tabella BigQuery cloudaudit_googleapis_com_policy. Di seguito sono riportati gli elementi principali per analizzare la violazione:

  • Il metodo dell'API e del servizio protetto chiamato.
  • 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 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 timestamp per la finestra temporale quando ogni applicazione univoca 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 di carico di lavoro:

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

Esamina i log delle violazioni

Quando esamini i log delle violazioni, verifica se quanto segue è vero:

  • È previsto che l'identità (email) richiami le API protette?
  • Il chiamante deve avere il permesso di invocare 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 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 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 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 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