Regole per il traffico in entrata e in uscita

Questa pagina illustra le regole del 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 da e verso le risorse e i client protetti dai perimetri di servizio.

I blocchi regole in entrata ed in uscita specificano la direzione dell'accesso consentito da e verso identità e risorse diverse. Le regole Ingress e in uscita possono sostituire e semplificare i casi d'uso che in precedenza richiedevano uno o più ponti perimetrali.

Per scoprire come applicare i criteri in entrata e in uscita al perimetro di servizio, vedi Configurare i criteri in entrata e in uscita.

Per un elenco di esempi e casi d'uso di scambio di dati sicuri, vedi Scambio di dati sicuro con regole di traffico in entrata e in uscita.

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

Vantaggi delle regole in entrata e in uscita

  1. Le regole in entrata e in uscita consentono di scambiare i dati in modo privato ed efficiente all'interno delle organizzazioni e utilizzando le API di servizio Google Cloud.
  2. Le regole Ingress e in uscita consentono di concedere l'accesso alle risorse Google Cloud in un perimetro in base al contesto della richiesta API:
    1. Limitare i tipi di identità o identità che possono essere utilizzati in base a una rete di origine, a un indirizzo IP o a un dispositivo.
    2. Limitare le API e i metodi di Google Cloud accessibili in base alla rete di origine, all'indirizzo IP, al dispositivo e al tipo di identità.
  3. Riduci al minimo il rischio di esfiltrazione vincolando l'esatto servizio, metodi, progetti Google Cloud, reti VPC e identità utilizzate per eseguire lo scambio di dati.
  4. Concedi l'accesso in sola lettura ai set di dati e alle immagini esterne che non sono gestiti da te.
  5. Assicurati che i client nei segmenti meno privilegiati non abbiano accesso alle risorse Google Cloud nei segmenti più privilegiati, pur consentendo l'accesso nell'altra direzione.
  6. Semplifica le configurazioni che in precedenza richiedevano uno o più ponti perimetrali.

Definizione di traffico in entrata e in uscita

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

  • In entrata: si riferisce a qualsiasi accesso di un client API dall'esterno del perimetro di servizio alle risorse all'interno di un perimetro di servizio. Esempio:

    • Un client Cloud Storage esterno a un perimetro di servizio che effettua chiamate alle operazioni di lettura, scrittura o copia di Cloud Storage su una risorsa Cloud Storage all'interno del perimetro.
  • In uscita si riferisce a qualsiasi accesso che prevede un client API o risorse all'interno del perimetro di servizio e risorse esterne al 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 e all'esterno del perimetro.

Modello dei criteri

Una regola in entrata o in uscita è composta 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.

È possibile associare più regole di traffico in entrata e in uscita a un perimetro di servizio. Una chiamata di servizio Google Cloud è consentita o rifiutata in base alla seguente semantica:

  • Una richiesta da un client all'esterno del perimetro a una risorsa Google Cloud all'interno del perimetro è consentita se sono soddisfatte le condizioni della regola in entrata necessaria.
  • Una richiesta da un client all'interno del perimetro a una risorsa Google Cloud al di fuori del perimetro è consentita se sono soddisfatte le condizioni della regola in uscita necessaria.
  • Una chiamata API che coinvolge una risorsa Google Cloud all'interno del perimetro e una risorsa Google Cloud esterna al perimetro è consentita se esiste una regola in entrata che il client soddisfa (se il client non è all'interno del perimetro) e una regola in uscita che la risorsa esterna soddisfa.

Esempi di richieste API consentite dalle regole in entrata

  • Un client Cloud Storage all'esterno del perimetro che scarica gli oggetti da un bucket Cloud Storage all'interno del perimetro della macchina locale (ad esempio utilizzando il comando gsutil cp).
  • Un client BigQuery esterno al perimetro che utilizza un job BigQuery in un progetto all'interno del perimetro per eseguire una query su un set di dati BigQuery all'interno del perimetro (ad esempio, utilizzando il comando bq query).
  • Una VM di 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 in uscita

  • Un client Cloud Storage all'interno del perimetro che copia gli oggetti tra un bucket Cloud Storage all'esterno del perimetro e un bucket all'interno del perimetro (ad esempio utilizzando il comando gsutil cp).
  • Un client BigQuery all'interno del perimetro che utilizza un job BigQuery in un progetto all'esterno del perimetro per eseguire una query su un set di dati BigQuery all'interno del perimetro (ad esempio, utilizzando il comando bq query).

Esempi di richieste API consentite da una combinazione di regole in entrata e in uscita

  • Un client Cloud Storage all'esterno del perimetro che copia gli oggetti tra un bucket Cloud Storage all'esterno del perimetro e un bucket all'interno del perimetro (ad esempio, utilizzando il comando gsutil cp).
  • Un client BigQuery fuori dal perimetro che utilizza un job BigQuery in un progetto esterno al perimetro per eseguire una query su un set di dati BigQuery all'interno del perimetro (ad esempio, utilizzando il comando bq query).

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 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, per consentire al client Cloud Storage di copiare gli oggetti dal bucket a al bucket b e dal bucket b al bucket a, sono necessarie le seguenti regole in entrata e in uscita:

  • una regola in uscita nel perimetro A per consentire l'accesso al bucket Cloud Storage b ,
  • una regola in uscita nel perimetro B per consentire l'accesso al bucket Cloud Storage a,
  • una regola in entrata nel perimetro B per consentire l'accesso al client Cloud Storage che si trova al di fuori del perimetro B.

Riferimento alle regole Ingress

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

- ingressFrom:
    identityType: ANY_IDENTITY
    *OR*
    identities:
    - serviceAccount:service-account
    - user:user-account
    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 in cui sono elencate le origini e le identità consentite all'esterno del perimetro.

  • identityType:: questo attributo o l'attributo identities deve essere utilizzato. Questo attributo definisce i tipi di identità che possono essere utilizzati dall'attributo specificato sources (origine). Valori accettati: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY consente tutte le identità. ANY_USER_ACCOUNT consente a tutti gli utenti umani. ANY_SERVICE_ACCOUNT consente tutti gli account di servizio.

  • identities: (questo attributo o l'attributo identityType deve essere utilizzato) Questo attributo avvia un elenco di account di servizio o di account utente che possono accedere alle risorse nel perimetro. La funzionalità Ingress per federazione delle identità per il carico di lavoro non è supportata.

  • serviceAccount: un account di servizio a cui viene concesso l'accesso alle risorse nel perimetro.

  • user: un account utente a cui viene concesso l'accesso alle risorse nel perimetro.

  • sources: (obbligatorio). Questo attributo si riferisce 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 in entrata consente l'accesso da qualsiasi origine di rete.

  • - 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 formato seguente: //compute.googleapis.com/projects/<project-id>/global/networks/<network_name>.

  • - accessLevel:: questo attributo o l'attributo resource deve essere utilizzato. Specifica il livello di accesso dall'esterno del perimetro a cui viene concesso l'accesso. Se imposti l'attributo accessLevel su \"*\", il criterio in entrata consente l'accesso da qualsiasi origine di rete.

  • ingressTo:: (obbligatorio) avvia il blocco to che elenca le operazioni di servizio consentite su risorse Google Cloud specificate all'interno del perimetro.

  • operations: (obbligatorio). Contrassegna l'inizio dell'elenco di servizi e azioni/metodi accessibili a cui un client che soddisfa le condizioni di blocco from può 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 la sezione Prodotti supportati.

  • methodSelectors: (obbligatorio) È consentito l'accesso di un elenco di metodi a cui un client che soddisfa le condizioni di blocco from. Per un elenco delle autorizzazioni e dei metodi limitati per i servizi, vedi Limitazioni dei metodi di servizio supportati.

  • - method: (è necessario utilizzare 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: (è necessario 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 in entrata funzioni. Ad esempio, se una richiesta a una risorsa BigQuery richiede le autorizzazioni bigquery.jobs.create e bigquery.tables.create, devi specificare entrambe le autorizzazioni nell'ambito della stessa operazione. Inoltre, se specifichi le autorizzazioni più volte per la stessa risorsa utilizzando la console Google Cloud, le autorizzazioni non vengono create con la 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 di servizio a cui può accedere il client all'esterno del perimetro. Questo campo può essere impostato su \"*\" per consentire l'accesso in entrata a qualsiasi risorsa Google Cloud all'interno del perimetro.

Per rendere efficace una regola in entrata, devi specificare i seguenti attributi:

  • Attributo sources. Devi specificare accessLevel o resource (progetto Google Cloud o rete VPC) oppure impostare l'attributo accessLevel su \"*\".
  • Attributo identityType o identities
  • Attributo resources
  • Attributo serviceName

Dopo aver configurato il file dei criteri in entrata, consulta Aggiornamento dei criteri in entrata e in uscita per le istruzioni sull'applicazione del file dei criteri in entrata al perimetro di servizio.

Riferimento alle regole in uscita

Le regole in uscita possono essere configurate utilizzando la console Google Cloud, un file JSON o un file YAML. Il seguente esempio 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
    *OR*
    identities:
    - serviceAccount:service-account
    - user:user-account
  • - egressTo:: (obbligatorio) avvia il blocco to che elenca le operazioni di servizio consentite sulle risorse Google Cloud nei progetti specificati al di fuori del perimetro.

  • operations: (obbligatorio). Contrassegna l'inizio dell'elenco di servizi e azioni/metodi accessibili a cui un client che soddisfa le condizioni di blocco from può 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 la pagina Prodotti supportati.

  • methodSelectors: (obbligatorio) È consentito l'accesso di un elenco di metodi a cui un client che soddisfa le condizioni di blocco from. Per un elenco delle autorizzazioni e dei metodi limitati per i servizi, vedi Limitazioni dei metodi di servizio supportati.

  • - method: (è necessario utilizzare 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: (è necessario utilizzare questo attributo o l'attributo method). Questo campo deve essere un'autorizzazione di servizio valida. L'accesso alle risorse specificate all'esterno 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 in uscita funzioni. Ad esempio, se una richiesta a una risorsa BigQuery richiede le autorizzazioni bigquery.jobs.create e bigquery.tables.create, devi specificare entrambe le autorizzazioni nell'ambito della stessa operazione. Inoltre, se specifichi le autorizzazioni più volte per la stessa risorsa utilizzando la console Google Cloud, le autorizzazioni non vengono create con la stessa operazione. Per evitare questo problema, specifica tutte le autorizzazioni contemporaneamente per la risorsa.

  • resources: (è necessario utilizzare questo attributo o l'attributo externalResources). Questo attributo è un elenco di risorse Google Cloud specificate dai loro progetti a cui i client all'interno di un perimetro possono accedere. Questo campo può essere impostato su \"*\" per consentire l'accesso in uscita a qualsiasi risorsa Google Cloud.

  • externalResources: (è necessario utilizzare questo attributo o l'attributo resources). Questo attributo è un elenco di risorse esterne a cui possono accedere i client all'interno di un perimetro. Questo attributo supporta solo risorse AWS o Azure. Per Amazon S3, il formato supportato è s3://BUCKET_NAME. Il formato supportato per l'archiviazione di Azure è azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom:: (obbligatorio) avvia il blocco from in cui sono elencate le origini e le identità consentite all'interno del perimetro.

  • identityType: (è necessario utilizzare questo attributo o l'attributo identities). Questo attributo definisce i tipi di identità che possono essere utilizzati per accedere alle risorse specificate all'esterno del perimetro. Valori accettati: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY consente tutte le identità. ANY_USER_ACCOUNT consente a tutti gli utenti umani. ANY_SERVICE_ACCOUNT consente tutti gli account di servizio.

  • identities: (è necessario utilizzare questo attributo o l'attributo identityType). Questo attributo avvia un elenco di account di servizio o di account utente che possono accedere alle risorse specificate fuori dal perimetro. Il traffico in uscita da identità di federazione delle identità per il carico di lavoro non è supportato.

  • serviceAccount: un account di servizio che può accedere alle risorse specificate all'esterno del perimetro.

  • user: un account utente che può accedere alle risorse specificate all'esterno del perimetro.

Dopo aver configurato il file dei criteri in uscita, consulta Aggiornamento dei criteri in entrata e in uscita per le istruzioni sull'applicazione del file dei criteri in uscita al perimetro di servizio.

Utilizzo della modalità di prova per testare i criteri in entrata/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 la chiamata a un metodo diverso su un servizio Google Cloud separato. Ad esempio, BigQuery carica una tabella da un bucket Cloud Storage per eseguire una query.

Per determinare il set di metodi corretto da consentire, puoi utilizzare la modalità di prova dei Controlli di servizio VPC. Per farlo, abilita prima un perimetro in modalità di prova senza criteri di traffico in entrata o in uscita e raccogli l'elenco dei metodi richiamati dall'audit log. Quindi, aggiungi questi metodi in modo progressivo ai criteri in entrata/uscita in modalità di prova fino alla cessazione di tutte le violazioni. A quel punto, la configurazione può essere spostata dalla modalità di prova alla modalità di applicazione forzata.

Funzionalità non supportate

Le seguenti funzionalità non sono attualmente supportate per le regole relative al traffico in entrata e in uscita:

  1. Identificare le risorse Google Cloud in base alle etichette anziché ai progetti.
  2. Specifica dei gruppi nel campo identities di una regola from in entrata/uscita.
  3. Non tutti i servizi supportano le regole in entrata/in uscita per metodo. Vedi Limitazioni dei metodi di servizio supportati.
  4. I tipi di identità ANY_SERVICE_ACCOUNT e ANY_USER_ACCOUNT non possono essere utilizzati per consentire le seguenti operazioni:

Limitazioni

Per informazioni sui limiti di traffico in entrata e in uscita, consulta Quote e limiti.