Best practice per l'abilitazione dei Controlli di servizio VPC

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

L'abilitazione non intenzionale dei Controlli di servizio VPC può causare problemi alle applicazioni esistenti e potenzialmente causare un'interruzione. Ti consigliamo di pianificare con attenzione l'abilitazione e lasciare tempo sufficiente per raccogliere i dati, eseguire test e analizzare i log delle violazioni. Assicurati che gli stakeholder del team operativo Controlli di servizio VPC e del team delle applicazioni siano disponibili per l'attività.

Per ogni carico di lavoro o applicazione che accetti nei Controlli di servizio VPC, devi ripetere il processo di abilitazione.

Coordina la comunicazione

Spesso, il team di sicurezza della rete o di abilitazione del cloud è a capo delle attività di abilitazione dei Controlli di servizio VPC. Ti consigliamo di affidarti a una persona dedicata che crei e tenga traccia delle attività per riunioni e documenti interfunzionali. I tuoi team collaborano sugli aspetti seguenti:

Pattern di accesso alle API Google Cloud
Identificazione delle violazioni del 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 carichi di lavoro aziendali legittimi.

Modelli di accesso ai documenti e casi d'uso

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

Pattern di accesso ai dati: i servizi che si trovano all'esterno del perimetro archiviano o recuperano i dati che risiedono nel perimetro.
Pattern di accesso alle risorse:
- Gli utenti accedono ai progetti nel perimetro tramite la console Google Cloud.
- Gli strumenti o i 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 di Cloud gestiscono i progetti che fanno parte di un perimetro.
I servizi di Automation come Terraform, Jenkins e DevOps di Microsoft Azure che risiedono al di fuori del perimetro gestiscono il deployment delle risorse all'interno del perimetro.
I servizi di gestione della configurazione, come Ansible, Chef o Puppet, che risiedono al di fuori del perimetro, gestiscono il deployment e la configurazione del software sulle risorse che si trovano all'interno del perimetro.
Il monitoraggio della sicurezza e l'applicazione di servizi come Forseti o SIEM che risiedono al di fuori del perimetro consumano dati o applicano i criteri di sicurezza su una risorsa che si trova all'interno del perimetro.

Per ogni caso d'uso, documenta quanto segue:

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 pattern di accesso di esempio e un tracker dei casi d'uso, consulta Modello di onboarding dei Controlli di servizio VPC - casi d'uso (PDF).

Condurre interviste

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

I tuoi casi d'uso sono una priorità assoluta da prendere in considerazione per l'abilitazione di Controlli di servizio VPC? Ti consigliamo di prendere in considerazione solo i carichi di lavoro prioritari per l'abilitazione iniziale e l'onboarding di altri carichi di lavoro meno critici dopo aver protetto le risorse business-critical.
Sei in grado di completare l'esecuzione completa di tutti i casi d'uso? In questo modo puoi attivare tutti i possibili scenari di perimetro in modo da poter analizzare completamente il perimetro e confermare che l'applicazione funzionerà correttamente dopo l'applicazione forzata del perimetro.
Quanto tempo è necessario per eseguire l'esecuzione del caso d'uso?
Stai pianificando modifiche importanti per questo carico di lavoro che potrebbero essere in conflitto con l'abilitazione dei Controlli di servizio VPC? Le funzionalità dei carichi di lavoro devono essere in stato stabile prima di abilitare i Controlli di servizio VPC.

Preparare una prova

La modalità di prova riduce la complessità di test dell'applicazione dei Controlli di servizio VPC identificando le violazioni senza interruzioni delle applicazioni. Puoi configurare una prova 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:

Identifica tutti i progetti idonei per far parte del perimetro e completa il caso d'uso e la procedura di colloquio per tali progetti.
Crea un perimetro di prova e aggiungi tutti i progetti.
Nel perimetro di servizio dei Controlli di servizio VPC, in Servizi limitati > Servizi da proteggere, aggiungi tutti i servizi supportati.
Crea un sink di logging aggregato che invii tutti i log a BigQuery oppure crea un sink di log per ogni progetto che invia i log di prova a un set di dati BigQuery comune. Per eseguire una 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 il seguente filtro:
```
logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"
```
Per la massima sicurezza, non consentire l'accesso ai servizi non supportati. Configura il tuo perimetro in modo che solo i servizi limitati funzionino al suo interno. A questo scopo, configura l'elenco dei servizi accessibili in RESTRICTED-SERVICES.
Se disponi già di 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 in base ai casi nel perimetro di prova. L'autorizzazione di flussi legittimi noti contribuisce a ridurre il numero di log delle violazioni e consente ai revisori di concentrarsi sugli eventi eseguibili.
Verifica che nessuno dei VPC nei progetti abbia un percorso in uscita verso internet o al VIP privato.
Verifica che tutti i VPC abbiano il DNS *.googleapis.com che punta a restricted.googleapis.com.

Esegui casi d'uso

Al momento concordato, chiedi al team dedicato all'applicazione di eseguire il proprio carico di lavoro sul progetto nel perimetro in modalità di prova. Assicurati di avere la copertura completa di tutto il codice che potrebbe chiamare API di Google. Al termine della prova, il team di controllo designato può eseguire l'analisi del log delle violazioni.

Analizza le violazioni

I log delle violazioni di prova 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 protetto e il metodo API 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 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 su violazioni pertinenti

Le seguenti strategie possono aiutarti a identificare le violazioni pertinenti:

Aggiungi un qualificatore 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 dei carichi di lavoro:
```
WHERE where resource.labels.project_id like '%APPLICATION_NAME%'
```

Esaminare i log delle violazioni

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

L'identità (email) deve richiamare le API protette?
Il chiamante deve essere autorizzato a richiamare l'API dall'esterno del perimetro?

In base ai criteri precedenti, determina se è necessario 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. Questo indica che la chiamata proviene dalla rete Google, dai servizi Google o da un VPC in un progetto esterno al perimetro. Per servizi Google come gli autori dei sink di log, devi aggiungere l'account di servizio 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 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 in modo errato un bucket con nome simile.

Se vedi un tipo di violazione SERVICE_NOT_ALLOWED_FROM_VPC, è possibile che il carico di lavoro utilizzi un servizio supportato dai Controlli di servizio VPC, ma che non sia stato aggiunto all'elenco delle API protette. Ad esempio, se IAM ha causato questa violazione, 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

Scopri di più sui perimetri di servizio.
Scopri come creare un perimetro di servizio.