Regole per il traffico in entrata e in uscita

Questa pagina illustra le regole di traffico in entrata e in uscita per i Controlli di servizio VPC. I Controlli di servizio VPC utilizzano le regole in entrata e in uscita per consentire l'accesso da e verso e client protetti dai perimetri di servizio.

Il traffico in entrata e in uscita I blocchi di regole specificano la direzione dell'accesso consentito da e verso diversi di identità e risorse. Le regole in entrata e in uscita possono sostituire e semplificare l'utilizzo casi che in precedenza richiedevano uno o più bridge perimetri.

Per scoprire come applicare i criteri di traffico in entrata e in uscita al tuo perimetro di servizio, consulta Configurazione dei criteri di traffico in entrata e in uscita.

Per un elenco di casi d'uso ed esempi di scambio di dati sicuro, vedi Scambio di dati sicuro con regole 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 le regole in entrata.

Vantaggi delle regole in entrata e in uscita

  1. Le regole in entrata e in uscita consentono di scambiare dati in modo privato ed efficiente all'interno e tra le organizzazioni usando le API di servizio Google Cloud.
  2. Le regole in entrata e in uscita consentono di concedere l'accesso a Google Cloud risorse in un perimetro basato sul contesto della richiesta API:
    1. Limita i tipi di identità o le identità che possono essere utilizzate da un'origine rete, indirizzo IP o dispositivo.
    2. Vincola le API e i metodi di Google Cloud a cui è possibile accedere la rete di origine, l'indirizzo IP, il dispositivo e il tipo di identità.
  3. Ridurre al minimo il rischio di esfiltrazione vincolando l'esatto servizio, metodi Progetti, reti VPC e identità Google Cloud utilizzati per eseguire lo scambio di dati.
  4. Concedi l'accesso di sola lettura a set di dati e immagini esterni che non gestiti da te.
  5. Assicurati che i clienti nei segmenti con meno privilegi non abbiano accesso a le risorse di Google Cloud in segmenti con più privilegi; consentendo al contempo l'accesso nell'altra direzione.
  6. Semplifica le configurazioni che in precedenza hanno richiesto uno o più bridge perimetri.

Definizione di traffico in entrata e in uscita

Le definizioni di traffico in entrata e in uscita sono indipendenti dall'operazione richiamati sulla risorsa. Pertanto, le definizioni si riferiscono alla direzione e non verso lo spostamento dei dati.

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

    • Un client Cloud Storage esterno a una chiamata del perimetro di servizio Operazioni di lettura, scrittura o copia di Cloud Storage su un ambiente risorsa all'interno del perimetro.

  • In uscita si riferisce a qualsiasi accesso che interessa risorse o client API all'interno del perimetro di servizio e le risorse al di fuori di un perimetro di servizio. Esempi:

    • Un client Compute Engine all'interno di un perimetro di servizio che chiama Operazione create di Compute Engine in cui la risorsa immagine si trova all'esterno perimetrale.
    • Un client Cloud Storage, all'interno o all'esterno del perimetro, che chiama una il comando copy, in cui un bucket si trova all'interno del perimetro e l'altro bucket è fuori.

Modello dei criteri

Una regola in entrata o in uscita è composta da blocchi from e to dove:

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

È possibile associare più regole in entrata e in uscita a un perimetro di servizio. R La chiamata al servizio Google Cloud è consentita o rifiutata in base a quanto segue semantica:

  • Richiesta di un client esterno al perimetro a una risorsa Google Cloud all'interno del perimetro è consentita se le condizioni del traffico siano soddisfatte.
  • Richiesta di un client all'interno del perimetro a una risorsa Google Cloud fuori dal perimetro è consentita se le condizioni del traffico in uscita siano soddisfatte.
  • Una chiamata API che coinvolge una risorsa Google Cloud all'interno del perimetro e una risorsa Google Cloud al di fuori del perimetro è consentita se è presente una regola in entrata soddisfatta dal client (se il client non si trova all'interno del perimetro) e una regola di traffico in uscita soddisfatta dalla risorsa esterna.

Esempi di richieste API consentite dalle regole in entrata

  • Un client Cloud Storage esterno al perimetro che scarica oggetti da un Bucket Cloud Storage all'interno del perimetro alla macchina locale (ad esempio usando il comando gsutil cp).
  • Un client BigQuery all'esterno del perimetro che utilizza un job BigQuery in un progetto all'interno del perimetro per eseguire query su un set di dati BigQuery il perimetro (ad esempio usando 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 oggetti tra un il bucket Cloud Storage all'esterno del perimetro e un bucket all'interno (ad esempio usando il comando gsutil 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 il perimetro (ad esempio usando il comando bq query).

Esempi di richieste API consentite dalla combinazione di regole in entrata e in uscita

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

Negli esempi di BigQuery e Compute Engine, una regola in entrata non è perché il job BigQuery o il disco Compute Engine sono fuori dal perimetro. È necessaria una regola in uscita per consentire una richiesta API prevede una risorsa Google Cloud all'interno del perimetro (il set di dati BigQuery o la chiave Cloud KMS) e una risorsa esterna il perimetro (il job BigQuery o il Compute Engine ).

Richieste API che coinvolgono più perimetri di servizio

Quando le risorse a cui si accede e/o il client API appartengono a un servizio diverso perimetri, i criteri di tutti i perimetri coinvolti devono consentire richiesta. Ad esempio, considera un client e un bucket Cloud Storage a all'interno di una il perimetro di servizio A e un bucket b all'interno di un perimetro di servizio B. In questo esempio, per al client Cloud Storage di copiare 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 a Cloud Storage bucket b ,
  • una regola in uscita nel perimetro B per consentire l'accesso a Cloud Storage bucket a,
  • una regola in entrata nel perimetro B per consentire l'accesso Client Cloud Storage esterno al perimetro B.

Riferimento alle regole in entrata

Le regole in entrata possono essere configurate utilizzando la console Google Cloud. un file JSON o un file YAML. Nell'esempio seguente viene utilizzato il formato .yaml:

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *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 che elenca gli elenchi consentiti di origini e identità esterne al perimetro.

  • identityType: - (È necessario utilizzare questo attributo o l'attributo identities) Questo definisce i tipi di identità che possono essere utilizzati sources (origine della rete). Valori accettati: ANY_IDENTITY, ANY_USER_ACCOUNT e ANY_SERVICE_ACCOUNT. ANY_IDENTITY consente tutti identities. 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 account utente che possono accedere alle risorse nel perimetro. Il traffico in entrata da parte delle identità della federazione delle identità per i carichi di lavoro non è supportato.

  • serviceAccount: un account di servizio a cui accedere alle risorse in un perimetro specifico.

  • user - Un account utente a cui accedere alle risorse del un perimetro specifico.

  • sources: - (Obbligatorio) Questo attributo si riferisce a un elenco di origini della 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 da qualsiasi origine di rete. Se imposti questo attributo su un progetto Google Cloud, Il criterio in entrata consente l'accesso da una rete VPC che appartiene al progetto.

  • - 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 formato seguente: projects/<project_number>. Per specificare una rete VPC, utilizza il formato seguente: //compute.googleapis.com/projects/<project-id>/global/networks/<network_name>.

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

  • ingressTo: - (Obbligatorio) Avvia il blocco to che elenca i servizi consentiti operazioni su specifiche risorse Google Cloud all'interno del perimetro.

  • operations: - (Obbligatorio) Contrassegna l'inizio dell'elenco di elementi accessibili servizi e azioni/metodi con cui un client soddisfa il blocco from a cui è consentito l'accesso.

  • - serviceName: - (Obbligatorio) Questo campo può essere un nome di servizio valido o essere impostato a \"*\" per consentire l'accesso a tutti i servizi. Ad esempio: bigquery.googleapis.com è un serviceName valido. Per un elenco delle vedi Prodotti supportati.

  • methodSelectors: - (Obbligatorio se serviceName non è \"*\") L'inizio di un elenco di metodi a cui un client soddisfa le condizioni di blocco from autorizzati ad accedere. Per un elenco di metodi e autorizzazioni limitati per vedi Limitazioni relative ai metodi di servizio supportati.

  • - method: - (È necessario utilizzare questo attributo o l'attributo permission) Questo campo può essere un metodo di servizio valido oppure puoi impostarlo su \"*\" per consentire l'accesso a tutti 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 sono consentiti 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 al lavoro. Ad esempio, se una richiesta a una risorsa BigQuery richiede le autorizzazioni bigquery.jobs.create e bigquery.tables.create, devi e specificare entrambe le autorizzazioni nella stessa operazione. Inoltre, se specifichi le autorizzazioni più volte per la stessa risorsa utilizzando Console Google Cloud, le autorizzazioni non vengono create con la stessa operazione. A evitare questo problema, specifica contemporaneamente tutte le autorizzazioni per la risorsa.

  • resources: - (Obbligatorio) Questo attributo specifica l'elenco di Risorse Google Cloud nel perimetro di servizio che il client ha a cui può accedere il perimetro. Questo campo può essere impostato su \"*\" per consentire il traffico in entrata a qualsiasi risorsa Google Cloud all'interno del perimetro.

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

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

Dopo aver completato la configurazione del file dei criteri in entrata, consulta Aggiornamento dei criteri di traffico in entrata e in uscita. per 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. Nell'esempio seguente viene utilizzato 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:
    - serviceAccount:service-account
    - user:user-account

  • - egressTo: - (Obbligatorio) Avvia il blocco to che elenca i servizi consentiti operazioni sulle risorse Google Cloud in progetti specificati al di fuori perimetrale.

  • operations: - (Obbligatorio) Contrassegna l'inizio dell'elenco di elementi accessibili servizi e azioni/metodi con cui un client soddisfa il blocco from a cui è consentito l'accesso.

  • - serviceName: - (Obbligatorio) Questo campo può essere un nome di servizio valido o essere impostato a \"*\" per consentire l'accesso a tutti i servizi. Per un elenco dei servizi disponibili, consulta la sezione Prodotti supportati.

  • methodSelectors: - (Obbligatorio se serviceName non è \"*\") L'inizio di un elenco di metodi a cui un client soddisfa le condizioni di blocco from autorizzati ad accedere. Per un elenco di metodi e autorizzazioni limitati per vedi Limitazioni relative ai metodi di servizio supportati.

  • - method: - È necessario utilizzare questo attributo o l'attributo permission. Questo campo può essere un metodo di servizio valido oppure 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 sono consentite 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 al lavoro. Ad esempio, se una richiesta a una risorsa BigQuery richiede le autorizzazioni bigquery.jobs.create e bigquery.tables.create, devi e specificare entrambe le autorizzazioni nella stessa operazione. Inoltre, se specifichi le autorizzazioni più volte per la stessa risorsa utilizzando Console Google Cloud, le autorizzazioni non vengono create con la stessa operazione. A evitare questo problema, specifica contemporaneamente tutte le autorizzazioni per la risorsa.

  • resources: - Questo attributo è un elenco di Google Cloud a risorse specificate dai propri progetti che i clienti all'interno di un perimetro possono access. 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 Amazon S3 o di Azure Blob Storage. Per Amazon S3, il formato supportato è s3://BUCKET_NAME. Per Archiviazione di Azure, il formato supportato è azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom: - (Obbligatorio) Avvia il blocco from che elenca gli elementi consentiti di origini e identità all'interno del perimetro.

  • identityType: - È necessario utilizzare questo attributo o l'attributo identities. Questo definisce i tipi di identità che possono essere utilizzati per accedere al di fuori del perimetro. Valori accettati: ANY_IDENTITY, ANY_USER_ACCOUNT e ANY_SERVICE_ACCOUNT. ANY_IDENTITY consente tutti identities. 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 avvia un elenco di account di servizio o account utente che possono accedere all'attributo specificato di risorse esterne al perimetro. Il traffico in uscita per identità di federazione delle identità per i carichi di lavoro non è supportato.

  • serviceAccount: un account di servizio che può accedere alle risorse specificate. fuori dal perimetro.

  • user: un account utente che può accedere alle risorse specificate. fuori dal perimetro.

Dopo aver completato la configurazione del file dei criteri in uscita, consulta Aggiornamento dei criteri di traffico in entrata e in uscita. per istruzioni sull'applicazione del file dei criteri in uscita al perimetro di servizio.

Utilizzo della modalità dry run per testare i criteri in entrata/in uscita

Quando non vuoi concedere l'accesso a tutti i metodi di un servizio, puoi farlo a volte è difficile determinare l'elenco preciso di metodi da consentire. Questo può verificarsi perché un determinato metodo per un servizio può causare un su un servizio Google Cloud separato. Ad esempio, BigQuery carica da un bucket Cloud Storage per eseguire una query.

Per determinare il set di metodi corretto da consentire, puoi utilizzare il Controlli di servizio VPC Modalità dry run. Per farlo, abilita prima un perimetro in modalità dry run senza traffico in entrata o in uscita criteri e raccolgono l'elenco dei metodi richiamati dall'audit log. Poi, aggiungere progressivamente questi metodi ai criteri in entrata/in uscita nella modalità dry run fino alla cessazione di tutte le violazioni. A quel punto, la configurazione può essere spostata dalla modalità dry run a quella di applicazione forzata.

Funzionalità non supportate

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

  1. Identificazione delle risorse Google Cloud tramite etichette anziché per progetti.
  2. Specificare gruppi nel campo identities di una regola from in entrata/in uscita.
  3. Non tutti i servizi supportano le regole in entrata/in uscita per metodo. Vedi Limitazioni relative ai metodi di servizio supportati.
  4. Impossibile utilizzare i tipi di identità ANY_SERVICE_ACCOUNT e ANY_USER_ACCOUNT per consentire le seguenti operazioni:

Limitazioni

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