Questa pagina è stata tradotta dall'API Cloud Translation.

Regole per il traffico in entrata e in uscita

Questa pagina spiega le regole di traffico in entrata e in uscita per i controlli di servizio VPC. Controlli di servizio VPC utilizza regole di traffico in entrata e in uscita per consentire l'accesso alle risorse e ai client protetti dai perimetri di servizio e viceversa.

I blocchi di regole ingress e egress specificano la direzione dell'accesso consentito a e da diverse identità e risorse. Le regole di ingresso e di uscita possono sostituire e semplificare i casi d'uso che in precedenza richiedevano uno o più ponti di perimetro.

Per scoprire come applicare i criteri per il traffico in entrata e in uscita al perimetro di servizio, consulta Configurare i criteri per il traffico in entrata e in uscita.

Puoi configurare gruppi di identità e identità di terze parti (anteprima) nelle regole di entrata e di uscita. Per un esempio di caso d'uso, consulta Esempio di utilizzo di gruppi di identità e identità di terze parti nelle regole di entrata e di uscita.

Per un elenco di casi d'uso e esempi di scambio di dati protetti, vedi Protezione dello scambio di dati con le regole per il traffico in entrata e in uscita.

Per un elenco di casi d'uso ed esempi di accesso sensibile al contesto, vedi Accesso sensibile al contesto con regole per il traffico in entrata.

Vantaggi delle regole per il traffico in entrata e in uscita

Le regole di ingresso e di uscita ti consentono di scambiare dati in modo privato ed efficiente all'interno e tra le organizzazioni utilizzando le API di servizio Google Cloud.
Le regole di ingresso e di uscita ti consentono di concedere l'accesso alle risorse Google Cloud in un perimetro in base al contesto della richiesta dell'API:
1. Limita i tipi di identità o le identità che possono essere utilizzate in base a una rete, un indirizzo IP o un dispositivo di origine.
2. Limita le API e i metodi di Google Cloud a cui è possibile accedere in base alla rete di origine, all'indirizzo IP, al dispositivo e al tipo di identità.
Riduci al minimo il rischio di esfiltrazione limitando i servizi, i metodi, i progetti Google Cloud, le reti VPC e le identità esatti utilizzati per eseguire lo scambio di dati.
Concedi l'accesso di sola lettura a set di dati e immagini esterni non gestiti da te.
Assicurati che i client in segmenti con meno privilegi non abbiano accesso alle risorse Google Cloud in segmenti con più privilegi, consentendo al contempo l'accesso nell'altra direzione.
Semplifica le configurazioni che in precedenza richiedevano uno o più ponti di perimetro.

Definizione di traffico in entrata e in uscita

Le definizioni di in entrata e in uscita sono indipendenti dall'operazione invocata sulla risorsa. Pertanto, le definizioni si riferiscono alla direzione della richiesta e non alla direzione dello spostamento dei dati.

Ingresso:si riferisce a qualsiasi accesso da parte di un client API dall'esterno del perimetro di un servizio alle risorse all'interno di un perimetro di servizio. Esempio:
- Un client Cloud Storage esterno a un perimetro di servizio che chiama operazioni di lettura, scrittura o copia di Cloud Storage su una risorsa Cloud Storage all'interno del perimetro.
Egress Si riferisce a qualsiasi accesso che coinvolge un client API o risorse all'interno del perimetro di servizio e risorse al di fuori di un perimetro di servizio. Esempi:
- Un client Compute Engine all'interno di un perimetro di servizio che chiama un'operazione create di Compute Engine in cui la risorsa immagine è esterna al perimetro.
- Un client Cloud Storage, all'interno o all'esterno del perimetro, che chiama un comando copy in cui un bucket si trova all'interno del perimetro e l'altro al di fuori.

Modello di criteri

Una regola per il traffico in entrata o in uscita è costituita da blocchi from e to in cui:

from fa riferimento agli attributi del client API.
to fa riferimento agli attributi dei servizi e delle risorse Google Cloud.

A un perimetro di servizio possono essere associate più regole per il traffico in entrata e in uscita. Una chiamata al servizio Google Cloud è consentita o negata in base alla seguente semantica:

Una richiesta da un client esterno al perimetro a una risorsa Google Cloud all'interno del perimetro è consentita se le condizioni della regola di ingresso necessaria sono soddisfatte.
Una richiesta da un client all'interno del perimetro a una risorsa Google Cloud al di fuori del perimetro è consentita se le condizioni della regola di uscita necessaria sono soddisfatte.
Una chiamata API che coinvolge una risorsa Google Cloud all'interno del perimetro e una risorsa Google Cloud all'esterno del perimetro è consentita se esiste una regola di ingresso soddisfatta dal client (se il client non si trova all'interno del perimetro) e una regola di uscita soddisfatta dalla risorsa esterna.

Esempi di richieste API consentite dalle regole di ingresso

Un client Cloud Storage esterno al perimetro che scarica oggetti da un bucket Cloud Storage all'interno del perimetro nella macchina locale (ad esempio mediante il comando gcloud storage cp).
Un client BigQuery esterno al perimetro che utilizza un job BigQuery in un progetto all'interno del perimetro per eseguire query su un set di dati BigQuery all'interno del perimetro (ad esempio utilizzando il comando bq query).
Una VM Compute Engine in una rete VPC esterna al perimetro scrive in un bucket Cloud Storage all'interno del perimetro.

Esempi di richieste API consentite dalle regole di uscita

Un client Cloud Storage all'interno del perimetro che copia oggetti tra un bucket Cloud Storage all'esterno del perimetro e un bucket all'interno del perimetro (ad esempio utilizzando il comando gcloud storage cp).

Un client BigQuery all'interno del perimetro che utilizza un job BigQuery in un progetto esterno al perimetro per eseguire query su un set di dati BigQuery all'interno del perimetro (ad esempio utilizzando il comando bq query).

Esempi di richieste API consentite dalla combinazione di regole di ingresso e di uscita

Un client Cloud Storage all'esterno del perimetro che copia oggetti tra un bucket Cloud Storage all'esterno del perimetro e un bucket all'interno del perimetro (ad esempio utilizzando il comando gcloud storage cp).
Un client BigQuery esterno al perimetro che utilizza un job BigQuery in un progetto esterno al perimetro per eseguire query su un set di dati BigQuery all'interno del perimetro (ad esempio utilizzando il comando bq query).
Un client Compute Engine esterno al perimetro che crea un disco Compute Engine esterno al perimetro utilizzando una chiave Cloud KMS all'interno del perimetro.

Negli esempi di BigQuery e Compute Engine, una regola di ingresso non è sufficiente, perché il job BigQuery o il disco Compute Engine si trova al di fuori del perimetro. È necessaria una regola di uscita per consentire una richiesta API che coinvolge una risorsa Google Cloud all'interno del perimetro (il set di dati BigQuery o la chiave Cloud KMS) e una risorsa al di fuori del perimetro (il job BigQuery o il disco Compute Engine).

Richieste API che coinvolgono più perimetri di servizio

Quando le risorse a cui si accede e/o il client API appartengono a perimetri di servizio diversi, i criteri di tutti i perimetri coinvolti devono consentire la richiesta dell'API. Ad esempio, prendi in considerazione un client e un bucket Cloud Storage a all'interno di un perimetro di servizio A e un bucket b all'interno di un perimetro di servizio B. In questo esempio, affinché il client Cloud Storage possa copiare gli oggetti dal bucket a al bucket b e dal bucket b al bucket a, sono necessarie le seguenti regole di ingresso e uscita:

una regola in uscita nel perimetro A per consentire l'accesso al bucket Cloud Storage b ,
una regola di uscita nel perimetro B per consentire l'accesso al a,
una regola di ingresso nel perimetro B per consentire l'accesso al client Cloud Storage esterno al perimetro B.

Riferimento alle regole in entrata

Le regole di ingresso possono essere configurate utilizzando la console Google Cloud, un file JSON o un file YAML. L'esempio seguente utilizza il formato .yaml:

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
  ingressTo:
    operations:
    - serviceName: SERVICE
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    resources:
    - projects/PROJECT

- ingressFrom: - (obbligatorio) Avvia il blocco from che elenca le origini e le identità consentite al di fuori del perimetro.
identityType:: (è necessario utilizzare questo attributo o l'attributo identities) Questo attributo definisce i tipi di identità che possono essere utilizzati dall'sources specificato (origine della rete). Valori accettati: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY consente tutte le identità. ANY_USER_ACCOUNT consente tutti gli utenti umani. ANY_SERVICE_ACCOUNT consente tutti gli account di servizio.

Questo attributo non limita le identità in base all'organizzazione. Ad esempio, ANY_SERVICE_ACCOUNT consente un account di servizio di qualsiasi organizzazione.
identities:: (è necessario utilizzare questo attributo o l'attributo identityType) questo attributo inizia un elenco di account di servizio, account utente, gruppi Google o identità di terze parti che possono accedere alle risorse nel perimetro.
PRINCIPAL_IDENTIFIER: specifica un account utente, un account di servizio, un gruppo Google o un'identità di terze parti a cui vuoi fornire l'accesso alle risorse nel perimetro. Utilizza il formato specificato in Identificatori principali dell'API v1 IAM. Ad esempio, utilizza il formato group:GROUP_NAME@googlegroups.com per specificare un gruppo Google.

Controlli di servizio VPC supporta solo le identità v1 che iniziano con i prefissi user, serviceAccount, group (anteprima), principal (anteprima) e principalSet (anteprima) negli identificatori principali dell'API IAMv1.
sources: - (Obbligatorio) Questo attributo fa riferimento a un elenco di origini di rete. Ogni valore nell'elenco è un livello di accesso o un progetto Google Cloud. Se imposti l'attributo accessLevel su "*", il criterio di ingresso consente l'accesso da qualsiasi origine di rete. Se imposti questo attributo su un progetto Google Cloud, il criterio di ingresso consente l'accesso da una rete VPC appartenente al progetto.

Questo valore potrebbe essere rimosso quando il progetto associato viene eliminato definitivamente. Tuttavia, la rimozione di questo valore non causa un errore. Controlla sempre se questo valore esiste durante la risoluzione dei problemi.
- resource: - (utilizza questo attributo o l'attributo accessLevel) Specifica un progetto o una rete VPC dall'esterno del perimetro a cui vuoi fornire l'accesso. Per specificare un progetto, utilizza il seguente formato: projects/PROJECT_NUMBER. Per specificare una rete VPC, utilizza il seguente formato: //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.
- accessLevel:: (è necessario utilizzare questo attributo o l'attributo resource) specifica il livello di accesso dall'esterno del perimetro a cui viene concesso l'accesso. Se imposti l'attributo accessLevel su "*", il criterio di ingresso consente l'accesso da qualsiasi origine di rete.
ingressTo: - (Obbligatorio) Avvia il blocco to che elenca le operazioni di servizio consentite sulle risorse Google Cloud specificate all'interno del perimetro.
operations: - (Obbligatorio) Indica l'inizio dell'elenco di servizi e azioni/metodi accessibili a cui un client che soddisfa le condizioni del blocco from è autorizzato ad accedere.
- serviceName: - (Obbligatorio) Questo campo può essere un nome di servizio valido o essere impostato su "*" per consentire l'accesso a tutti i servizi. Ad esempio, bigquery.googleapis.com è un serviceName valido. Per un elenco dei servizi disponibili, consulta Prodotti supportati.
methodSelectors: - (obbligatorio se serviceName non è "*") L'inizio di un elenco di metodi a cui un client che soddisfa le condizioni di blocco from è autorizzato ad accedere. Per un elenco dei metodi e delle autorizzazioni limitabili per i servizi, consulta Limitazioni del metodo dei servizi supportati.
- method:: (deve essere utilizzato questo attributo o l'attributo permission) questo campo può essere un metodo di servizio valido o può essere impostato su "*" per consentire l'accesso a tutti i metodi del servizio specificato.
- permission:: (è obbligatorio utilizzare questo attributo o l'attributo method) questo campo deve essere un'autorizzazione di servizio valida. L'accesso alle risorse all'interno del perimetro è consentito per le operazioni che richiedono l'autorizzazione.

Quando una richiesta a una risorsa richiede più autorizzazioni, devi specificare tutte le autorizzazioni richieste nella stessa operazione affinché la regola di ingresso funzioni. Ad esempio, se una richiesta a una risorsa BigQuery richiede le autorizzazioni bigquery.jobs.create e bigquery.tables.create, devi specificare entrambe queste autorizzazioni nella stessa operazione. Inoltre, se specifichi le autorizzazioni più volte per la stessa risorsa utilizzando la console Google Cloud, le autorizzazioni non vengono create nella stessa operazione. Per evitare questo problema, specifica tutte le autorizzazioni contemporaneamente per la risorsa.
resources: - (Obbligatorio) Questo attributo specifica l'elenco delle risorse Google Cloud nel perimetro del servizio a cui il client esterno al perimetro può accedere. Questo campo può essere impostato su "*" per consentire l'accesso in entrata a qualsiasi risorsa Google Cloud all'interno del perimetro.

Per creare una regola in entrata funzionale, devi specificare i seguenti attributi:

sources. Devi specificare un accessLevel o un resource (progetto Google Cloud o rete VPC) o impostare l'attributo accessLevel su "*".

Attributo identityType o identities
Attributo resources
Attributo serviceName

Una volta completata la configurazione del file di criteri di ingresso, consulta Aggiornare i criteri di ingresso e di uscita per istruzioni su come applicare il file di criteri di ingresso al perimetro del servizio.

Se configuri più regole in entrata in un perimetro di servizio, i Controlli di servizio VPC consentono una richiesta se soddisfa le condizioni di una delle regole in entrata.

Riferimento alle regole in uscita

Le regole di uscita possono essere configurate utilizzando la console Google Cloud, un file JSON o un file YAML. L'esempio seguente utilizza il formato .yaml:

- egressTo:
    operations:
    - serviceName: SERVICE_NAME
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    resources:
    - projects/PROJECT
    *OR*
    externalResources:
    - EXTERNAL_RESOURCE_PATH
  egressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER

- egressTo: - (Obbligatorio) Avvia il blocco to che elenca le operazioni di servizio consentite sulle risorse Google Cloud in progetti specificati al di fuori del perimetro.
operations: - (Obbligatorio) Indica l'inizio dell'elenco di servizi e azioni/metodi accessibili a cui un client che soddisfa le condizioni del blocco from è autorizzato ad accedere.
- serviceName: - (Obbligatorio) Questo campo può essere un nome di servizio valido o essere impostato su "*" per consentire l'accesso a tutti i servizi. Per un elenco dei servizi disponibili, consulta Prodotti supportati.
methodSelectors: - (obbligatorio se serviceName non è "*") L'inizio di un elenco di metodi a cui un client che soddisfa le condizioni di blocco from è autorizzato ad accedere. Per un elenco dei metodi e delle autorizzazioni limitabili per i servizi, consulta Limitazioni del metodo dei servizi supportati.
- method:: deve essere utilizzato questo attributo o l'attributo permission. Questo campo può essere un metodo di servizio valido o può essere impostato su "*" per consentire l'accesso a tutti i metodi del servizio specificato.
- permission:: deve essere utilizzato questo attributo o l'attributo method. Questo campo deve essere un'autorizzazione di servizio valida. L'accesso alle risorse specificate al di fuori del perimetro è consentito per le operazioni che richiedono questa autorizzazione.

Quando una richiesta a una risorsa richiede più autorizzazioni, devi specificare tutte le autorizzazioni richieste nella stessa operazione affinché la regola di uscita funzioni. Ad esempio, se una richiesta a una risorsa BigQuery richiede le autorizzazioni bigquery.jobs.create e bigquery.tables.create, devi specificare entrambe queste autorizzazioni nella stessa operazione. Inoltre, se specifichi le autorizzazioni più volte per la stessa risorsa utilizzando la console Google Cloud, le autorizzazioni non vengono create nella stessa operazione. Per evitare questo problema, specifica tutte le autorizzazioni contemporaneamente per la risorsa.
resources:: questo attributo è un elenco di risorse Google Cloud specificate dai relativi progetti a cui possono accedere i client all'interno di un perimetro. Puoi impostare questo campo su "*" per consentire l'accesso in uscita a qualsiasi risorsa Google Cloud.
externalResources:: questo attributo viene utilizzato solo per specificare le risorse BigQuery Omni. Questo attributo è un elenco di risorse esterne supportate da BigQuery Omni a cui possono accedere i client all'interno di un perimetro. Puoi specificare solo risorse Amazon S3 o Archiviazione BLOB di Azure. Per Amazon S3, il formato supportato è s3://BUCKET_NAME. Per Azure Storage, il formato supportato è azure://myaccount.blob.core.windows.net/CONTAINER_NAME.
egressFrom: - (Obbligatorio) Avvia il blocco from che elenca le origini e le identità consentite all'interno del perimetro.
identityType:: deve essere utilizzato questo attributo o l'attributo identities. Questo attributo definisce i tipi di identità che possono essere utilizzati per accedere alle risorse specificate al di fuori del perimetro. Valori accettati: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY consente tutte le identità. ANY_USER_ACCOUNT consente tutti gli utenti umani. ANY_SERVICE_ACCOUNT consente tutti gli account di servizio.

Questo attributo non limita le identità in base all'organizzazione. Ad esempio, ANY_SERVICE_ACCOUNT consente un account di servizio di qualsiasi organizzazione.
identities:: deve essere utilizzato questo attributo o l'attributo identityType. Questo attributo avvia un elenco di account di servizio, account utente, gruppi Google o identità di terze parti che possono accedere alle risorse specificate al di fuori del perimetro.
PRINCIPAL_IDENTIFIER: specifica un account utente, un account di servizio, un gruppo Google o un'identità di terze parti che può accedere alle risorse specificate al di fuori del perimetro. Utilizza il formato specificato in Identificatori principali dell'API v1 IAM. Ad esempio, utilizza il formato group:GROUP_NAME@googlegroups.com per specificare un gruppo Google.

Controlli di servizio VPC supporta solo le identità v1 che iniziano con i prefissi user, serviceAccount, group (anteprima), principal (anteprima) e principalSet (anteprima) negli identificatori principali dell'API IAMv1.

Una volta completata la configurazione del file dei criteri di uscita, consulta Aggiornare i criteri di ingresso e di uscita per istruzioni su come applicare il file dei criteri di uscita al perimetro del servizio.

Se configuri più regole di uscita in un perimetro di servizio, Controlli di servizio VPC consente una richiesta se soddisfa le condizioni di una delle regole di uscita.

Utilizzo della modalità di prova per testare i criteri di ingresso/uscita

Quando non vuoi concedere l'accesso a tutti i metodi di un servizio, a volte può essere difficile determinare l'elenco preciso dei metodi da consentire. Questo può accadere perché un determinato metodo per un servizio può causare l'attivazione di un metodo diverso in un servizio Google Cloud separato. Ad esempio, BigQuery carica una tabella da un bucket Cloud Storage per eseguire una query.

Per determinare l'insieme corretto di metodi da consentire, puoi utilizzare la modalità di prova di Controlli di servizio VPC. Per farlo, abilita prima un perimetro in modalità di prova simulata senza criteri di entrata o di uscita e raccogli l'elenco dei metodi invocati dal log di controllo. Poi, aggiungere progressivamente questi metodi ai criteri di ingresso/uscita in modalità di prova simulata fino a quando tutte le violazioni non sono cessate. A questo punto, la configurazione può essere spostata dalla modalità di prova alla modalità applicata.

Funzionalità non supportate

Le seguenti funzionalità non sono attualmente supportate per le regole di ingresso e di uscita:

Identificazione delle risorse Google Cloud tramite etichette anziché progetti.
Non tutti i servizi supportano le regole di ingresso/uscita per metodo. Consulta Limitazioni del metodo dei servizi supportati.
I tipi di identità ANY_SERVICE_ACCOUNT e ANY_USER_ACCOUNT non possono essere utilizzati per consentire le seguenti operazioni:
- Tutte le operazioni di Container Registry.
- Tutte le operazioni del servizio notebooks.googleapis.com.
- Operazioni di Cloud Storage che utilizzano URL firmati.
- Con le funzioni Cloud Run, puoi eseguire il deployment di una Cloud Function dalla macchina locale.
- Esporta i log da una destinazione Cloud Logging in una risorsa Cloud Storage.
- Tutte le operazioni dell'interfaccia utente web di Apache Airflow in Cloud Composer.

Limitazioni

Per informazioni sui limiti di ingresso e uscita, consulta Quote e limiti.

Passaggi successivi

Completa questo codelab per scoprire come correggere le violazioni in entrata e in uscita.