Controlli per limitare l'accesso alle API approvate singolarmente

Last reviewed 2024-02-06 UTC

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

Questo documento descrive come limitare l'accesso alle API di Google approvate singolarmente utilizzando il servizio Organization Policy Service e altri controlli di rete, nonché le sfide legate all'applicazione dell'approccio basato su proxy on-premise ai servizi Google Cloud. Questo documento è destinato agli amministratori di rete o ai team di sicurezza che vogliono limitare le API Google Cloud raggiungibili dai propri endpoint di rete VPC.

sfide relative ai 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 verso servizi e domini approvati. Questo requisito può essere applicato filtrando il traffico in uscita attraverso un proxy web o un gateway di accesso sicuro. Questo proxy intercetta tutto il traffico in uscita e consente il traffico in uscita solo verso API approvate esplicitamente.

In modo simile, in alcune aziende potrebbe esistere un requisito di conformità che prevede di limitare l'accesso dalla rete VPC alle API Google Cloud approvate. Questo controllo di conformità viene spesso illustrato nei seguenti scenari:

  • Un'azienda sta adottando Assured Workloads per carichi di lavoro sensibili e controlli di conformità.
  • Un'azienda ha requisiti di conformità interni in base ai quali agli endpoint di rete su Google Cloud è consentito accedere soltanto alle API Google Cloud approvate tramite un processo interno.
  • 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 dell'ambiente on-premise.

Anche se la tua azienda potrebbe utilizzare un proxy web per controllare il traffico in uscita dalla rete on-premise ai servizi web, sconsigliamo questo approccio per controllare l'accesso dalla rete VPC alle API Google Cloud. L'utilizzo di questo approccio basato su proxy introduce problemi di scalabilità, crea un single point of failure e non risolve i rischi di esfiltrazione di dati utilizzando le API Google Cloud.

Per consentire selettivamente l'accesso alle singole API Google Cloud, consigliamo di utilizzare il criterio dell'organizzazione Limita l'utilizzo del servizio risorse anziché i proxy. Nelle sezioni seguenti sono descritte le sfide relative alla creazione e al mantenimento di un proxy web per controllo dell'accesso dell'accesso alle singole API di Google.

Intervalli di indirizzi IP condivisi utilizzati da più API di Google

Non è possibile controllare l'accesso a una singola API di Google tramite una regola firewall o proxy che applica un filtro in base 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 una relazione one-to-one 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 nei domini. La maggior parte delle API di Google è raggiungibile su endpoint che differenziano le API specifiche in base al percorso e iniziano con un URI che inizia con www.googleapis.com. Anche alcune API di Google utilizzano un endpoint con un sottodominio dedicato. Ad esempio, il riferimento dell'API Cloud Storage documenta 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 API.

Quando utilizzi più API che hanno solo endpoint nel dominio www.googleapis.com, il proxy in uscita non può distinguere tra le API solo in base al dominio. Ad esempio, alcune API Google Cloud come Deployment Manager e altre API di 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 deve decriptare la richiesta di filtro sul percorso dell'URI, aumentando la complessità.

Colli di bottiglia causati dai proxy

Se tutto il traffico dalla rete VPC alle API di Google deve passare attraverso un proxy in uscita, il proxy potrebbe diventare un collo di bottiglia. Se utilizzi un proxy in uscita per il traffico dalla rete VPC alle API di Google, ti consigliamo di creare un proxy per l'alta disponibilità al fine di evitare interruzioni del servizio. Gestire e scalare il proxy può diventare complesso perché, man mano che l'organizzazione cresce, il proxy potrebbe introdurre un single point of failure, una latenza e una velocità effettiva ridotta. Potrebbe esserci un impatto particolare sulle operazioni che trasferiscono grandi volumi di dati.

Rischio di esfiltrazione da servizio a servizio

Un proxy web può limitare se un'API di Google è raggiungibile dalla tua rete VPC, ma non indirizza altri percorsi di esfiltrazione che utilizzano l'API di Google. Ad esempio, un dipendente della tua azienda potrebbe avere privilegi IAM legittimi per leggere i bucket Cloud Storage interni. Con questo privilegio, possono leggere i dati interni e poi copiarli in un bucket pubblico. Il proxy in uscita non può limitare il traffico API-API che non ha origine nel tuo VPC, né controllare in che modo il traffico internet raggiunge gli endpoint pubblici per le API Google Cloud.

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

Configurare i controlli di rete per limitare i servizi non approvati

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

Configurazione dei Controlli di servizio VPC

Quando utilizzi il criterio dell'organizzazione per il limite di utilizzo delle risorse, ti consigliamo di configurare anche i Controlli di servizio VPC. Se applichi il criterio dell'organizzazione in un progetto, limiti i servizi che possono essere utilizzati in quel progetto, ma il criterio dell'organizzazione non impedisce ai servizi del progetto di comunicare con i servizi di altri progetti. In confronto, Controlli di servizio VPC consente di definire un perimetro per impedire la comunicazione con i servizi al di fuori di quel 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 potrebbe creare o comunicare con un bucket Cloud Storage nel tuo progetto. Tuttavia, la VM può effettuare 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 all'esterno del perimetro, devi configurare un perimetro dei Controlli di servizio VPC.

Utilizza questi controlli insieme per consentire selettivamente i servizi approvati nel tuo ambiente e bloccare una serie di percorsi di esfiltrazione a servizi non approvati.

Rimuovi i percorsi verso internet

Se le risorse nella tua rete VPC possono comunicare direttamente con internet, potrebbe esserci un percorso alternativo alle API di Google non approvate e ad altri servizi che vuoi bloccare. Pertanto, consigliamo di utilizzare solo gli indirizzi IP interni sulle VM e di non consentire route in uscita tramite una soluzione NAT o proxy. Il criterio dell'organizzazione per l'utilizzo limitato dell'utilizzo delle risorse non riduce i percorsi di esfiltrazione sulla rete internet pubblica, di conseguenza è comunque possibile accedere indirettamente ai servizi non approvati da un server esterno al tuo ambiente.

Configura un endpoint privato per l'accesso all'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 dai Controlli di servizio VPC o dal criterio dell'organizzazione Limita l'utilizzo del servizio delle risorse. Puoi limitare l'accesso privato Google solo alle API supportate configurando Private Service Connect con il bundle vpc-sc.

Ad esempio, l'abilitazione dell'accesso privato Google consente un percorso di rete privata a tutte le API di Google, come Google Drive o Google Maps Platform. Un dipendente potrebbe copiare dati nel proprio 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 l'accesso allo stesso insieme di servizi supportati dall'IP virtuale limitato (VIP) nell'endpoint restricted.googleapis.com. In confronto, è possibile raggiungere un set più ampio di API di Google 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 route a restricted.googleapis.com. Potresti preferire l'utilizzo del VIP con restrizioni se non vuoi creare un endpoint Private Service Connect per ogni regione e ogni rete VPC nel tuo ambiente. Tuttavia, ti consigliamo l'approccio Private Service Connect perché puoi creare un endpoint interno alla tua rete VPC, rispetto all'approccio VIP limitato che richiede una route verso un endpoint annunciato pubblicamente.

Passaggi successivi