Modalità di prova per i perimetri di servizio

Quando utilizzi i Controlli di servizio VPC, può essere difficile determinare l'impatto sul tuo ambiente quando viene creato o modificato un perimetro di servizio. Con la modalità di prova, puoi comprendere meglio l'effetto dell'abilitazione dei Controlli di servizio VPC e delle modifiche ai perimetri negli ambienti esistenti.

In modalità di prova, le richieste che violano il criterio del perimetro non vengono negate, ma solo registrate. Puoi utilizzare la modalità di prova per testare la configurazione del perimetro e monitorare l'utilizzo dei servizi senza impedire l'accesso alle risorse. I casi d'uso comuni includono:

  • La determinazione dell'impatto delle modifiche ai perimetri di servizio esistenti.

  • Anteprima dell'impatto dei nuovi perimetri di servizio.

  • Richieste di monitoraggio a servizi protetti che provengono dall'esterno di un perimetro di servizio. ad esempio per vedere da dove provengono le richieste a un determinato servizio o per identificare un utilizzo imprevisto del servizio nella tua organizzazione.

  • nei tuoi ambienti di sviluppo, creando un'architettura perimetrale analoga all'ambiente di produzione. Ciò ti consente di identificare e mitigare eventuali problemi causati dai perimetri di servizio prima di apportare modifiche all'ambiente di produzione.

I perimetri di servizio possono esistere utilizzando esclusivamente la modalità di prova. Puoi anche avere perimetri di servizio che utilizzano un ibrido di modalità di esecuzione e di prova.

Vantaggi della modalità di prova

Utilizzando la modalità di prova, puoi creare nuovi perimetri di servizio o modificare più perimetri esistenti senza alcun impatto su un ambiente esistente. Le richieste che violano la nuova configurazione del perimetro non vengono bloccate. Puoi anche comprendere l'impatto del perimetro in un ambiente in cui non tutti i servizi utilizzati sono integrati con i Controlli di servizio VPC.

Puoi analizzare i log di Controlli di servizio VPC per individuare eventuali rifiuti, modificare la configurazione per risolvere potenziali problemi e applicare la nuova strategia di sicurezza.

Se i problemi relativi alla configurazione del perimetro non possono essere risolti, puoi scegliere di mantenere la configurazione di prova del perimetro e monitorare i log per rilevare eventuali rifiuti imprevisti che potrebbero indicare un tentativo di esfiltrazione. Tuttavia, le richieste al perimetro non vengono negate.

Concetti della modalità di prova

La modalità di prova opera come secondo passaggio di valutazione della configurazione del perimetro. Per impostazione predefinita, la configurazione in modalità applicata per tutti i perimetri di servizio viene ereditata nella configurazione in modalità di prova, dove la configurazione può essere modificata o eliminata senza influire sul funzionamento del perimetro di servizio.

Poiché la modalità di prova eredita la configurazione della modalità di applicazione forzata, a ogni passaggio entrambe le configurazioni devono essere valide. In particolare, un progetto può trovarsi solo in un perimetro nella configurazione applicata e in un solo perimetro nella configurazione di prova. Di conseguenza, le modifiche che interessano più perimetri, come lo spostamento di un progetto tra i perimetri, devono essere sequenziate nell'ordine corretto.

La modalità di prova registra una richiesta solo se soddisfa entrambi i seguenti criteri:

  • La richiesta non è già rifiutata dalla configurazione applicata del perimetro.

  • La richiesta viola la configurazione di prova del perimetro.

Ad esempio, se configurazioni identiche di prova e modalità di applicazione limitano un bucket Cloud Storage, la modalità applicata blocca e registra qualsiasi richiesta nel bucket Cloud Storage. La modalità di prova registra solo le differenze di violazioni rispetto alla modalità di applicazione forzata.

Puoi anche creare perimetri che hanno solo una configurazione di prova. In questo modo puoi simulare l'impatto di un nuovo perimetro in modalità di applicazione forzata nel tuo ambiente.

Semantica dei criteri

La seguente sezione descrive la relazione dei criteri tra le modalità di esecuzione forzata e quelle di prova e il tipo di risoluzione dell'applicazione.

Vincolo di appartenenza univoco

Un progetto Google Cloud può essere incluso solo in una configurazione applicata e in una configurazione di prova. Tuttavia, le configurazioni applicate e di prova non devono necessariamente essere applicate allo stesso perimetro. In questo modo puoi testare l'impatto dello spostamento di un progetto da un perimetro all'altro senza compromettere la sicurezza attualmente applicata al progetto.

Esempio

Il progetto corp-storage è attualmente protetto dalla configurazione applicata del perimetro PA. Vuoi testare l'impatto dello spostamento di corp-storage al perimetro PB.

La configurazione di prova per PA non è stata ancora modificata. Poiché la configurazione di prova non è stata modificata, eredita corp-storage dalla configurazione applicata.

Per testare l'impatto, rimuovi prima corp-storage dalla configurazione di prova per PA e aggiungi il progetto alla configurazione di prova per PB. Devi prima rimuovere corp-storage dalla configurazione di prova per PA perché i progetti possono esistere in una sola configurazione di prova alla volta.

Se ritieni che la migrazione di corp-storage da PA a PB non abbia effetti negativi sulla tua strategia di sicurezza, decidi di applicare le modifiche.

Esistono due modi per applicare le modifiche ai perimetri PA e PB:

  • Puoi rimuovere manualmente corp-storage dalla configurazione applicata per l'AP e aggiungere il progetto alla configurazione applicata per PB. Poiché corp-storage può trovarsi in un'unica configurazione applicata alla volta, devi eseguire i passaggi in questo ordine.

    -oppure-

  • Puoi utilizzare lo strumento a riga di comando gcloud o l'API Access Context Manager per applicare tutte le configurazioni di prova. Questa operazione si applica a tutte le configurazioni di prova modificate dei perimetri, pertanto ti consigliamo di coordinare l'operazione con chiunque nell'organizzazione che abbia modificato le configurazioni di prova per i perimetri. Poiché la configurazione di prova per PA esclude già corp-storage, non sono necessari passaggi aggiuntivi.

La configurazione applicata di un perimetro viene eseguita per prima

Solo le richieste consentite dalla configurazione applicata di un perimetro ma negate dalla configurazione di prova vengono registrate come violazioni dei criteri di prova. Le richieste rifiutate dalla configurazione applicata, ma che sarebbero consentite dalla configurazione di prova non vengono registrate.

I livelli di accesso non hanno un equivalente in modalità di prova

Sebbene sia possibile creare una configurazione di prova per un perimetro, i livelli di accesso non prevedono una configurazione di prova. In pratica, questo significa che se vuoi verificare in che modo una modifica a un livello di accesso influirebbe sulla configurazione di prova, devi:

  1. Crea un livello di accesso che rifletta le modifiche che vuoi apportare a un livello di accesso esistente.

  2. Applica il nuovo livello di accesso alla configurazione di prova per il perimetro.

La modalità di prova non ha un impatto negativo sulla sicurezza

Le modifiche alla configurazione di prova per un perimetro, ad esempio l'aggiunta di nuovi progetti o livelli di accesso a un perimetro oppure la modifica dei servizi protetti o accessibili alle reti all'interno del perimetro, non influiscono sull'effettiva applicazione di un perimetro.

Ad esempio, supponiamo che tu abbia un progetto che appartiene al perimetro di servizio PA. Se il progetto viene aggiunto alla configurazione di prova di un altro perimetro, la sicurezza effettiva applicata al progetto non cambia. Il progetto continua a essere protetto dalla configurazione applicata del perimetro PA, come previsto.

Azioni di prova e stati di configurazione

Con la funzionalità di prova, puoi:

  • Crea un perimetro solo con una configurazione di prova

  • Aggiorna la configurazione di prova di un perimetro esistente

  • Spostare un nuovo progetto in un perimetro esistente

  • Spostare un progetto da un perimetro a un altro

  • Elimina la configurazione di prova di un perimetro

In base all'azione eseguita in modalità di prova, un perimetro può trovarsi in uno dei seguenti stati di configurazione:

Ereditato dall'applicazione: stato predefinito per i perimetri applicati. In questo stato, qualsiasi modifica alla configurazione applicata del perimetro viene applicata anche alla configurazione di prova.

Modificata: la configurazione di prova per un perimetro è stata visualizzata o modificata e poi salvata. In questo stato, le modifiche alla configurazione applicata di un perimetro non vengono applicate alla configurazione di prova.

Nuovo: il perimetro ha solo una configurazione di prova. Anche se vengono apportate modifiche alla configurazione di prova, finché non viene applicata una configurazione su questo perimetro, lo stato rimane Nuovo.

Eliminato: la configurazione di prova per il perimetro è stata eliminata. Questo stato rimane finché non crei una nuova configurazione di prova per il perimetro o non annulli l'azione. In questo stato, le modifiche alla configurazione applicata di un perimetro non vengono applicate alla configurazione di prova.

Limitazioni della modalità di prova

La modalità di prova si applica solo ai perimetri. Non è utile per comprendere l'impatto della limitazione dell'accesso all'API Google Cloud al VIP privato o con restrizioni. Prima di configurare il dominio restricted.googleapis.com, ti consigliamo di assicurarti che tutti i servizi che vuoi utilizzare siano disponibili sul VIP con restrizioni.

Se non hai la certezza che le API che utilizzi in un ambiente esistente siano supportate dal VIP con restrizioni, ti consigliamo di utilizzare il VIP privato. Puoi comunque applicare la sicurezza perimetrale per i servizi supportati. Tuttavia, se utilizzi il VIP privato, le entità all'interno della tua rete avranno accesso a servizi non protetti (servizi non supportati dai Controlli di servizio VPC), ad esempio le versioni consumer di Gmail e Drive. Poiché il VIP privato consente ai servizi non supportati dai Controlli di servizio VPC, è possibile che codice compromesso, malware o un utente malintenzionato all'interno della tua rete esfiltrando i dati utilizzando tali servizi non sicuri.

Che cosa succede dopo?