Controlli per limitare l'accesso alle API approvate singolarmente

Last reviewed 2024-02-06 UTC

Molte organizzazioni hanno un requisito di conformità che prevede di limitare l'accesso alla rete a un elenco di API approvate esplicitamente, in base a requisiti interni o nell'ambito dell'adozione di Assured Workloads. On-premise, questo requisito viene spesso soddisfatto con i controlli proxy, ma in Google Virtual Private Cloud (VPC) puoi soddisfare questo requisito con il criterio dell'organizzazione Limita l'utilizzo dei servizi delle risorse. Questo criterio consente a un amministratore di definire le risorse Google Cloud che possono essere create all'interno della gerarchia delle risorse, ma per utilizzare efficacemente questo criterio dell'organizzazione, devi allineare vari controlli di rete nel tuo ambiente.

Questo documento descrive come limitare l'accesso alle API Google approvate singolarmente utilizzando il servizio di norme dell'organizzazione e altri controlli di rete, nonché le difficoltà di applicazione dell'approccio basato su proxy on-premise ai servizi Google Cloud. Questo documento è rivolto agli amministratori di rete o ai team di sicurezza che vogliono limitare le API Google Cloud che possono essere raggiunte dagli endpoint di rete VPC.

Problemi con i proxy per controllo dell'accesso alle API di Google

In una rete on-premise, la tua azienda potrebbe avere un requisito di conformità per consentire il traffico in uscita solo per servizi e domini approvati. Questo requisito puoi essere applicato filtrando il traffico in uscita tramite un proxy web o un gateway di accesso sicuro. Questo proxy intercetta tutto il traffico in uscita e consente l'esportazione solo per le API approvate esplicitamente.

In alcune aziende, potresti avere un requisito di conformità simile per limitare l'accesso dalla tua rete VPC alle API Google Cloud approvate. Questo controllo della conformità si verifica spesso nei seguenti scenari:

  • Un'azienda sta adottando Assured Workloads per i carichi di lavoro sensibili e i controlli di conformità.
  • Un'azienda ha requisiti di conformità interni che richiedono che gli endpoint di rete su Google Cloud possano accedere solo alle API Google Cloud approvate tramite una procedura interna.
  • Un'azienda vuole eseguire la migrazione dei carichi di lavoro Infrastructure as a Service (IaaS) su Google Cloud con un refactoring minimo.
  • Un'azienda non ha ancora sviluppato controlli per il cloud e preferisce estendere i controlli esistenti dall'ambiente on-premise.

Sebbene la tua azienda possa utilizzare un proxy web per controllare il traffico in uscita dalla sua rete on-premise ai servizi web, sconsigliamo questo approccio per controllare l'accesso dalla tua rete VPC alle API di Google Cloud. L'utilizzo di questo approccio proxy presenta problemi di scalabilità, crea un singolo punto di errore e non risolve i rischi di esfiltrazione di dati utilizzando le API Google Cloud.

Consigliamo di utilizzare i criteri dell'organizzazione Limita l'utilizzo dei servizi delle risorse anziché i proxy per consentire in modo selettivo l'accesso alle singole API Google Cloud. Le sfide legate alla creazione e alla gestione di un proxy web per controllo dell'accesso alle singole API di Google sono discusse nelle sezioni seguenti.

Intervalli di indirizzi IP condivisi utilizzati da più API Google

Non puoi controllare l'accesso a una singola API Google tramite una regola proxy o firewall che filtra a un singolo indirizzo IP. Google utilizza un intervallo dinamico di indirizzi IP per i domini predefiniti. All'interno di questi indirizzi IP non esiste un rapporto uno a uno tra un indirizzo IP dedicato e un'API specifica.

Domini condivisi utilizzati dalle API di Google

Per alcune API di Google, non puoi controllare l'accesso alla rete filtrando il traffico sui domini. La maggior parte delle API Google è raggiungibile su endpoint che distinguono API specifiche in base al percorso e iniziano con un URI che inizia con www.googleapis.com. Alcune API di Google utilizzano anche un endpoint con un sottodominio dedicato. Ad esempio, la documentazione di riferimento dell'API Cloud Storage descrive gli URI in relazione all'endpoint storage.googleapis.com/storage/v1, ma puoi anche utilizzare un URI che inizia con www.googleapis.com/storage/v1 per chiamare gli stessi metodi dell'API.

Quando utilizzi più API che hanno endpoint solo nel dominiowww.googleapis.com, il proxy di uscita non è in grado di distinguere le API in base al dominio. Ad esempio, alcune API Google Cloud come Deployment Manager e altre API Google come Tag Manager o Google Play Giochi sono accessibili solo nel dominio www.googleapis.com. Inoltre, tutte le API Google Cloud utilizzano la crittografia TLS per impostazione predefinita. Se vuoi consentire una di queste API, ma bloccare le altre, il proxy dovrà decriptare la richiesta per filtrare in base al percorso dell'URI, aumentando la complessità.

Colli di bottiglia causati dai proxy

Se tutto il traffico dalla rete VPC agli API di Google deve passare attraverso un proxy di uscita, il proxy potrebbe diventare un collo di bottiglia. Se utilizzi un proxy in uscita per il traffico dalla tua rete VPC alle API Google, ti consigliamo di creare il proxy per l'alta disponibilità per evitare interruzioni del servizio. La gestione e il ridimensionamento del proxy possono diventare complessi perché, con la crescita dell'organizzazione, il proxy potrebbe introdurre un singolo punto di errore, latenza e un throughput ridotto. Potrebbe esserci un impatto particolare sulle operazioni che trasferiscono grandi volumi di dati.

Rischio di esfiltrazione service-to-service

Un proxy web può limitare la raggiungibilità di un'API Google dalla rete VPC, ma non risolve altri percorsi di esfiltrazione che utilizzano l'API Google. Ad esempio, un dipendente della tua azienda potrebbe disporre di privilegi IAM legittimi per leggere i bucket Cloud Storage interni. Con questo privilegio, l'utente può leggere i dati interni e poi copiarli in un bucket pubblico. Il proxy in uscita non può limitare il traffico da API ad API che non ha origine nella tua VPC o controllare come il traffico internet raggiunge gli endpoint pubblici per le API Google Cloud.

Per i dati sensibili, un perimetro di Controlli di servizio VPC contribuisce a mitigare questo tipo di esfiltrazione. L'applicazione di un perimetro dei Controlli di servizio VPC consente di proteggere le risorse all'interno del perimetro da criteri IAM configurati in modo errato, esfiltrazione e credenziali compromesse.

Configura i controlli di rete per limitare i servizi non approvati

Quando utilizzi il criterio dell'organizzazione Limita l'utilizzo dei servizi delle risorse, per limitare in modo efficace l'accesso ai servizi, devi considerare in che modo la tua rete VPC limita il traffico in uscita e i percorsi di esfiltrazione. Le sezioni seguenti descrivono le best practice per la progettazione di reti per utilizzare in modo efficace il criterio di organizzazione Limita l'utilizzo dei servizi delle risorse.

Configurazione dei Controlli di servizio VPC

Quando utilizzi il criterio dell'organizzazione Limita l'utilizzo dei servizi delle risorse, ti consigliamo di configurare anche Controlli di servizio VPC. Se applichi il criterio dell'organizzazione a un progetto, limiti i servizi che possono essere utilizzati in quel progetto, ma il criterio dell'organizzazione non impedisce ai servizi di questo progetto di comunicare con i servizi di altri progetti. I Controlli di servizio VPC, invece, ti consentono di definire un perimetro per impedire la comunicazione con i servizi esterni al perimetro.

Ad esempio, se definisci un criterio dell'organizzazione per consentire Compute Engine e negare Cloud Storage nel tuo progetto, una VM in questo progetto non potrà creare o comunicare con un bucket Cloud Storage nel tuo progetto. Tuttavia, la VM può inviare richieste a un bucket Cloud Storage in un altro progetto, quindi l'esfiltrazione con il servizio Cloud Storage è ancora possibile. Per bloccare la comunicazione con Cloud Storage o altri servizi Google esterni al perimetro, devi configurare un perimetro Controlli di servizio VPC.

Utilizza questi controlli insieme per consentire in modo selettivo i servizi approvati nel tuo ambiente e bloccare una serie di percorsi di esfiltrazione verso servizi non approvati.

Rimuovi i percorsi per internet

Se le risorse della tua rete VPC possono comunicare direttamente con internet, potrebbe esserci un percorso alternativo per le API di Google non approvate e per altri servizi che vuoi bloccare. Pertanto, ti consigliamo di utilizzare solo indirizzi IP interni sulle VM e di non consentire route di uscita tramite una soluzione NAT o proxy. Il criterio dell'organizzazione che limita l'utilizzo dei servizi delle risorse non attenua i percorsi di esfiltrazione verso la rete internet pubblica, pertanto potrebbe essere ancora possibile accedere indirettamente ai servizi non approvati da un server esterno al tuo ambiente.

Configurare un endpoint privato per l'accesso API

Per controllare gli endpoint API nella tua rete, ti consigliamo di accedere alle API di Google utilizzando Private Service Connect. Quando configuri l'accesso privato Google per consentire alle VM con solo IP interno di accedere alle API di Google, viene incluso l'accesso a tutte le API di Google, incluse quelle non supportate da Controlli di servizio VPC o dal criterio di organizzazione Limita l'utilizzo dei servizi delle risorse. Puoi limitare l'accesso privato Google solo alle API supportate configurando inoltre Private Service Connect con il bundle vpc-sc.

Ad esempio, l'attivazione dell'accesso privato Google consente un percorso di rete privato a tutte le API Google, come Google Drive o Google Maps Platform. Un dipendente potrebbe copiare i dati sul suo Google Drive personale da un'istanza Compute Engine utilizzando l'API Google Drive. Puoi impedire questo percorso di esfiltrazione configurando Private Service Connect con il bundle vpc-sc per fornire accesso allo stesso insieme di servizi supportati dall'IP virtuale (VIP) con limitazioni all'endpoint restricted.googleapis.com. In confronto, un insieme più ampio di API di Google può essere raggiunto utilizzando l'accesso privato Google quando utilizzi i domini predefiniti di Google, un endpoint Private Service Connect configurato con il bundle all-apis o il VIP privato (private.googleapis.com).

In alternativa, puoi configurare le route per restricted.googleapis.com. Potresti preferire utilizzare l'IP virtuale limitato se non vuoi creare un endpoint Private Service Connect per ogni regione e ogni rete VPC nel tuo ambiente. Tuttavia, consigliamo l'approccio Private Service Connect perché puoi creare un endpoint interno alla tua rete VPC, rispetto all'approccio VIP limitato che richiede un route a un endpoint annunciato pubblicamente.

Passaggi successivi