Regras de entrada e saída

Esta página explica as regras de entrada e saída para o VPC Service Controls. Os VPC Service Controls usam regras de entrada e saída para permitir o acesso aos recursos e clientes protegidos por perímetros de serviço e a partir destes.

As regras de entrada e saída especificam a direção do acesso permitido a e a partir de diferentes identidades e recursos. As regras de entrada e saída podem substituir e simplificar os exemplos de utilização que anteriormente requeriam uma ou mais pontes de perímetro.

Para saber como aplicar políticas de entrada e saída ao seu perímetro de serviço, consulte o artigo Configurar políticas de entrada e saída.

Pode configurar grupos de identidades e identidades de terceiros e funções do IAM (pré-visualização) nas regras de entrada e saída.

Para ver uma lista de exemplos de utilização e exemplos de troca de dados segura, consulte o artigo Troca de dados segura com regras de entrada e saída.

Para ver uma lista de exemplos de utilização e exemplos de acesso sensível ao contexto, consulte o artigo Acesso sensível ao contexto com regras de entrada.

Vantagens das regras de entrada e saída

  1. As regras de entrada e saída permitem-lhe trocar dados de forma privada e eficiente dentro e entre organizações através das Google Cloud APIs de serviços.
  2. As regras de entrada e saída permitem-lhe conceder acesso a Google Cloud recursos num perímetro com base no contexto do pedido da API:
    1. Restrinja os tipos de identidades ou as identidades que podem ser usadas, tendo em conta uma rede de origem, um endereço IP ou um dispositivo.
    2. Restrinja Google Cloud as APIs e os métodos que podem ser acedidos, tendo em conta a rede de origem, o endereço IP, o dispositivo e o tipo de identidade.
  3. Minimize o risco de exfiltração restringindo o serviço, os métodos, os projetos, as redes VPC e as identidades exatos usados para executar a troca de dados.Google Cloud
  4. Conceder acesso só de leitura a conjuntos de dados e imagens externos que não são geridos por si.
  5. Certifique-se de que os clientes em segmentos menos privilegiados não têm acesso a recursos em segmentos mais privilegiados, ao mesmo tempo que permite o acesso na outra direção.Google Cloud
  6. Simplifique as configurações que exigiam anteriormente uma ou mais pontes de perímetro.

Definição de entrada e saída

As definições de entrada e saída são independentes da operação que está a ser invocada no recurso. Assim, as definições referem-se à direção do pedido e não à direção do movimento de dados.

  • Entrada: refere-se a qualquer acesso por parte de um cliente API de fora do perímetro do serviço a recursos dentro de um perímetro do serviço. Exemplo:

    • Um cliente do Cloud Storage fora de um perímetro de serviço que chama operações de leitura, escrita ou cópia do Cloud Storage num recurso do Cloud Storage dentro do perímetro.

  • Saída refere-se a qualquer acesso que envolva um cliente API ou recursos no perímetro de serviço e recursos fora de um perímetro de serviço. Exemplos:

    • Um cliente do Compute Engine num perímetro de serviço que chama uma operação do Compute Engine create em que o recurso de imagem está fora do perímetro.
    • Um cliente do Cloud Storage, dentro ou fora do perímetro, que chama um comando copy em que um contentor está dentro do perímetro e o outro contentor está fora dele.

Modelo de política

Uma regra de entrada ou saída consiste em blocos from e to, em que:

  • from faz referência aos atributos do cliente da API.
  • to faz referência aos atributos dos Google Cloud serviços e recursos.

É possível associar várias regras de entrada e saída a um perímetro de serviço. Uma chamada de serviçoGoogle Cloud é permitida ou recusada com base na seguinte semântica:

  • Um pedido de um cliente fora do perímetro para um Google Cloud recurso dentro do perímetro é permitido se as condições da regra de entrada necessária forem satisfeitas.
  • Um pedido de um cliente dentro do perímetro a um Google Cloud recurso fora do perímetro é permitido se as condições da regra de saída necessária forem satisfeitas.
  • Uma chamada API que envolva um Google Cloud recurso dentro do perímetro e um Google Cloud recurso fora do perímetro é permitida se existir uma regra de entrada que o cliente satisfaça (se o cliente não estiver dentro do perímetro) e uma regra de saída que o recurso externo satisfaça.

Exemplos de pedidos de API permitidos pelas regras de entrada

  • Um cliente do Cloud Storage fora do perímetro a transferir objetos de um contentor do Cloud Storage dentro do perímetro para a máquina local (por exemplo, através do comando gcloud storage cp).
  • Um cliente do BigQuery fora do perímetro que usa uma tarefa do BigQuery num projeto dentro do perímetro para consultar um conjunto de dados do BigQuery dentro do perímetro (por exemplo, através do comando bq query).
  • Uma VM do Compute Engine numa rede VPC que está fora do perímetro escreve num contentor do Cloud Storage dentro do perímetro.

Exemplos de pedidos de API permitidos pelas regras de saída

  • Um cliente do Cloud Storage dentro do perímetro que copia objetos entre um contentor do Cloud Storage fora do perímetro e um contentor dentro do perímetro (por exemplo, através do comando gcloud storage cp).
  • Um cliente do BigQuery dentro do perímetro que usa uma tarefa do BigQuery num projeto fora do perímetro para consultar um conjunto de dados do BigQuery dentro do perímetro (por exemplo, usando o comando bq query).

Exemplos de pedidos de API permitidos pela combinação de regras de entrada e saída

  • Um cliente do Cloud Storage fora do perímetro que copia objetos entre um contentor do Cloud Storage fora do perímetro e um contentor dentro do perímetro (por exemplo, através do comando gcloud storage cp).
  • Um cliente do BigQuery fora do perímetro que usa uma tarefa do BigQuery num projeto fora do perímetro para consultar um conjunto de dados do BigQuery dentro do perímetro (por exemplo, através do comando bq query).
  • Um cliente do Compute Engine fora do perímetro a criar um disco do Compute Engine fora do perímetro através de uma chave do Cloud KMS dentro do perímetro.

Nos exemplos do BigQuery e do Compute Engine, uma regra de entrada não é suficiente, porque a tarefa do BigQuery ou o disco do Compute Engine está fora do perímetro. É necessária uma regra de saída para permitir um pedido de API que envolva um recurso dentro do perímetro (o conjunto de dados do BigQuery ou a chave do Cloud KMS) e um recurso fora do perímetro (a tarefa do BigQuery ou o disco do Compute Engine). Google Cloud

Pedidos de API que envolvem vários perímetros de serviço

Quando os recursos acedidos e/ou o cliente API pertencem a diferentes perímetros de serviço, as políticas de todos os perímetros envolvidos têm de permitir o pedido API. Por exemplo, considere um cliente e um contentor do Cloud Storage a num perímetro de serviço A e um contentor b num perímetro de serviço B. Neste exemplo, para que o cliente do Cloud Storage copie objetos do contentor a para o contentor b e do contentor b para o contentor a, são necessárias as seguintes regras de entrada e saída:

  • Uma regra de saída no perímetro A para permitir o acesso ao contentor do Cloud Storage b ,
  • uma regra de saída no perímetro B para permitir o acesso ao contentor do Cloud Storage a,
  • Uma regra de entrada no perímetro B para permitir o acesso ao cliente do Cloud Storage que está fora do perímetro B.

Referência das regras de entrada

As regras de entrada podem ser configuradas através da Google Cloud consola, de um ficheiro JSON ou de um ficheiro YAML. O exemplo seguinte usa o 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
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
  title: TITLE

  • - ingressFrom: - (Obrigatório) Inicia o bloco from que lista as origens e as identidades permitidas fora do perímetro.

  • identityType: - (Este atributo ou o atributo identities tem de ser usado) Este atributo define os tipos de identidades que podem ser usados a partir da sources (origem da rede) especificada. Valores aceitáveis: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. O ANY_IDENTITY permite pedidos de todas as identidades, incluindo pedidos não autenticados. ANY_USER_ACCOUNT permite todos os utilizadores humanos e ANY_SERVICE_ACCOUNT permite todas as contas de serviço, mas ANY_USER_ACCOUNT e ANY_SERVICE_ACCOUNT não permitem pedidos não autenticados.

    Este atributo não restringe as identidades com base na organização. Por exemplo, ANY_SERVICE_ACCOUNT permite uma conta de serviço de qualquer organização.

  • identities: - (Este atributo ou o atributo identityType tem de ser usado) Este atributo inicia uma lista de contas de serviço, contas de utilizador, grupos Google ou identidades de terceiros que podem aceder a recursos no perímetro.

  • PRINCIPAL_IDENTIFIER: especifique uma conta de utilizador, uma conta de serviço, um grupo Google ou uma identidade de terceiros à qual quer conceder acesso a recursos no perímetro. Os VPC Service Controls só suportam as seguintes identidades dos identificadores principais da API IAMv1:

    • Para contas de utilizador e contas de serviço, use os formatos user:USER_EMAIL_ADDRESS e serviceAccount:SA_EMAIL_ADDRESS, respetivamente.

    • Para outras identidades, use os formatos especificados em Grupos de identidades suportados.

    Para mais informações sobre estas identidades, consulte o artigo Identificadores principais para políticas de permissão.

  • sources: - (Obrigatório) Este atributo refere-se a uma lista de origens de rede. Cada valor na lista é um nível de acesso ou um Google Cloud projeto. Se definir o atributo accessLevel como "*", a política de entrada permite o acesso a partir de qualquer origem de rede. Se definir este atributo para um projeto Google Cloud , a política de entrada permite o acesso a partir de uma rede VPC pertencente ao projeto.

    Este valor pode ser removido quando o projeto associado for eliminado permanentemente. No entanto, a remoção deste valor não causa um erro. Verifique sempre se este valor existe durante a resolução de problemas.

  • - resource: - (Use este atributo ou o atributo accessLevel) Especifica um projeto ou uma rede VPC de fora do perímetro ao qual quer conceder acesso. Para especificar um projeto, use o seguinte formato: projects/PROJECT_NUMBER. Para especificar uma rede de VPC, use o seguinte formato: //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.

  • - accessLevel: - (Este atributo ou o atributo resource tem de ser usado) Especifica o nível de acesso a partir do exterior do perímetro ao qual o acesso é concedido. Se definir o atributo accessLevel como "*", a política de entrada permite o acesso a partir de qualquer origem de rede.

  • ingressTo: - (Obrigatório) Inicia o bloco to que lista as operações de serviço permitidas em Google Cloud recursos especificados no perímetro.

  • operations: - (Este atributo ou o atributo roles tem de ser usado) Marca o início da lista de serviços acessíveis e ações/métodos aos quais um cliente que satisfaça as condições do bloco from tem permissão para aceder.

  • - serviceName: - (Obrigatório) Este campo pode ser um nome de serviço válido ou ser definido como "*" para permitir o acesso a todos os serviços. Por exemplo, bigquery.googleapis.com é um serviceName válido. Para ver uma lista dos serviços disponíveis, consulte o artigo Produtos suportados.

  • methodSelectors: - (Obrigatório se serviceName não for "*") O início de uma lista de métodos aos quais um cliente que satisfaça as condições do bloco from tem permissão de acesso. Para ver uma lista de métodos e autorizações restritivas para serviços, consulte o artigo Restrições de métodos de serviços suportadas.

    Para ver uma lista de métodos de serviço que o VPC Service Controls não consegue controlar, consulte as Exceções de métodos de serviço.

  • - method: - (Este atributo ou o atributo permission tem de ser usado) Este campo pode ser um método de serviço válido ou pode ser definido como "*" para permitir o acesso a todos os métodos do serviço especificado.

  • - permission: - (Este atributo ou o atributo method tem de ser usado) Este campo tem de ser uma autorização de serviço válida. O acesso aos recursos dentro do perímetro é permitido para as operações que requerem a autorização.

    Quando um pedido a um recurso requer várias autorizações, tem de especificar todas as autorizações necessárias na mesma operação para que a regra de entrada funcione. Por exemplo, se um pedido a um recurso do BigQuery exigir as autorizações bigquery.jobs.create e bigquery.tables.create, tem de especificar ambas as autorizações na mesma operação. Além disso, se especificar as autorizações várias vezes para o mesmo recurso através daGoogle Cloud consola, as autorizações não são criadas na mesma operação. Para evitar este problema, especifique todas as autorizações de uma vez para o recurso.

  • roles:: (Este atributo ou o atributo operations tem de ser usado) Este atributo refere-se a uma lista de funções de IAM que define o âmbito de acesso para os serviços especificados na regra.

  • ROLE_NAME: especifique uma única função ou uma combinação de funções que incluam todas as autorizações necessárias para aceder aos serviços. Para especificar uma função, use os formatos de nome de função mencionados em Componentes de funções, exceto o seguinte formato: projects/PROJECT_ID/roles/IDENTIFIER.

    Para informações sobre os serviços e as funções suportados, consulte o artigo Produtos suportados.

  • resources: - (Obrigatório) Este atributo especifica a lista de Google Cloud recursos no perímetro de serviço aos quais o cliente fora do perímetro pode aceder. Este campo pode ser definido como "*" para permitir o acesso de entrada a qualquer recurso Google Cloud dentro do perímetro.

  • title: - (Opcional) Este atributo especifica o título da regra de entrada. O título tem de ser exclusivo no perímetro e não pode exceder os 100 carateres. Na política de acesso, o comprimento combinado de todos os títulos das regras não pode exceder 240 000 carateres.

Para criar uma regra de entrada funcional, tem de especificar os seguintes atributos:

  • sources. Tem de especificar um accessLevel ou um resource (Google Cloud projeto ou rede de VPC), ou definir o atributo accessLevel como "*".
  • Atributo identityType ou identities
  • Atributo resources
  • Atributo serviceName

Depois de terminar a configuração do ficheiro de política de entrada, consulte o artigo Atualizar políticas de entrada e saída para obter instruções sobre como aplicar o ficheiro de política de entrada ao perímetro de serviço.

Se configurar várias regras de entrada num perímetro de serviço, o VPC Service Controls permite um pedido se este cumprir as condições de qualquer uma das regras de entrada.

Referência das regras de saída

As regras de saída podem ser configuradas através da Google Cloud consola, de um ficheiro JSON ou de um ficheiro YAML. O exemplo seguinte usa o formato .yaml:

- egressTo:
    operations:
    - serviceName: SERVICE_NAME
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
    *OR*
    externalResources:
    - EXTERNAL_RESOURCE_PATH
  egressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
    sourceRestriction: RESTRICTION_STATUS
  title: TITLE

  • - egressTo: - (Obrigatório) Inicia o bloco to que lista as operações de serviço permitidas em recursos nos projetos especificados fora do perímetro. Google Cloud

  • operations: - (Este atributo ou o atributo roles tem de ser usado) Marca o início da lista de serviços acessíveis e ações/métodos aos quais um cliente que satisfaça as condições do bloco from tem permissão para aceder.

  • - serviceName: - (Obrigatório) Este campo pode ser um nome de serviço válido ou ser definido como "*" para permitir o acesso a todos os serviços. Para ver uma lista dos serviços disponíveis, consulte o artigo Produtos suportados.

  • methodSelectors: - (Obrigatório se serviceName não for "*") O início de uma lista de métodos aos quais um cliente que satisfaça as condições do bloco from tem permissão de acesso. Para ver uma lista de métodos e autorizações restritivas para serviços, consulte o artigo Restrições de métodos de serviços suportadas.

    Para ver uma lista de métodos de serviço que o VPC Service Controls não consegue controlar, consulte as Exceções de métodos de serviço.

  • - method:: (tem de usar este atributo ou o atributo permission) Este campo pode ser um método de serviço válido ou pode ser definido como "*" para permitir o acesso a todos os métodos do serviço especificado.

  • - permission:: (tem de usar este atributo ou o atributo method) Este campo tem de ser uma autorização de serviço válida. O acesso aos recursos especificados fora do perímetro é permitido para as operações que requerem a autorização.

    Quando um pedido a um recurso requer várias autorizações, tem de especificar todas as autorizações necessárias na mesma operação para que a regra de saída funcione. Por exemplo, se um pedido a um recurso do BigQuery exigir as autorizações bigquery.jobs.create e bigquery.tables.create, tem de especificar ambas as autorizações na mesma operação. Além disso, se especificar as autorizações várias vezes para o mesmo recurso através daGoogle Cloud consola, as autorizações não são criadas na mesma operação. Para evitar este problema, especifique todas as autorizações de uma vez para o recurso.

  • roles:: (Este atributo ou o atributo operations tem de ser usado) Este atributo refere-se a uma lista de funções de IAM que define o âmbito de acesso para os serviços especificados na regra.

  • ROLE_NAME: especifique uma única função ou uma combinação de funções que incluam todas as autorizações necessárias para aceder aos serviços. Para especificar uma função, use os formatos de nome de função mencionados em Componentes de funções, exceto o seguinte formato: projects/PROJECT_ID/roles/IDENTIFIER.

    Para informações sobre os serviços e as funções suportados, consulte o artigo Produtos suportados.

  • resources:: este atributo é uma lista de recursos Google Cloud especificados pelos respetivos projetos aos quais os clientes dentro de um perímetro podem aceder. Pode definir este campo como "*" para permitir o acesso de saída a qualquer recurso.Google Cloud

  • externalResources: – Este atributo é usado apenas para especificar recursos do BigQuery Omni. Este atributo é uma lista de recursos externos suportados pelo BigQuery Omni aos quais os clientes dentro de um perímetro podem aceder. Só pode especificar recursos do Amazon S3 ou do Azure Blob Storage. Para o Amazon S3, o formato suportado é s3://BUCKET_NAME. Para o Azure Storage, o formato suportado é azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom: - (Obrigatório) Inicia o bloco from que lista as origens e as identidades permitidas no perímetro.

  • identityType:: (tem de usar este atributo ou o atributo identities) Este atributo define os tipos de identidades que podem ser usados para aceder aos recursos especificados fora do perímetro. Valores aceitáveis: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. O ANY_IDENTITY permite pedidos de todas as identidades, incluindo pedidos não autenticados. ANY_USER_ACCOUNT permite todos os utilizadores humanos e ANY_SERVICE_ACCOUNT permite todas as contas de serviço, mas ANY_USER_ACCOUNT e ANY_SERVICE_ACCOUNT não permitem pedidos não autenticados.

    Este atributo não restringe as identidades com base na organização. Por exemplo, ANY_SERVICE_ACCOUNT permite uma conta de serviço de qualquer organização.

  • identities:: (tem de usar este atributo ou o atributo identityType) Este atributo inicia uma lista de contas de serviço, contas de utilizador, grupos Google ou identidades de terceiros que podem aceder aos recursos especificados fora do perímetro.

  • PRINCIPAL_IDENTIFIER: especifique uma conta de utilizador, uma conta de serviço, um grupo Google ou uma identidade de terceiros que possa aceder aos recursos especificados fora do perímetro. Os VPC Service Controls só suportam as seguintes identidades dos identificadores principais da API IAMv1:

    • Para contas de utilizador e contas de serviço, use os formatos user:USER_EMAIL_ADDRESS e serviceAccount:SA_EMAIL_ADDRESS, respetivamente.

    • Para outras identidades, use os formatos especificados em Grupos de identidades suportados.

    Para mais informações sobre estas identidades, consulte o artigo Identificadores principais para políticas de permissão.

  • sources: - Este atributo especifica uma lista de origens de rede. O valor do atributo pode ser uma lista de projetos ou níveis de acesso. Para aplicar restrições de acesso com base no sources especificado, defina o atributo sourceRestriction como SOURCE_RESTRICTION_ENABLED.

    O VPC Service Controls avalia os atributos accessLevel e resource do atributo sources como uma condição OU.

  • - resource: - (Use este atributo ou o atributo accessLevel) Especifique um ou mais Google Cloud recursos do perímetro de serviço aos quais quer permitir o acesso a dados fora do perímetro. Este atributo só suporta projetos. Para especificar um projeto, use o seguinte formato: projects/PROJECT_NUMBER.

    Não pode usar "*" neste atributo para permitir todos os recursos Google Cloud .

  • - accessLevel: - (Use este atributo ou o atributo resource) Especifique um ou mais níveis de acesso que permitam que os recursos dentro do perímetro acedam a recursos fora do perímetro. Certifique-se de que estes níveis de acesso pertencem à mesma política de acesso que o perímetro. Se definir o atributo accessLevel como "*", a política de saída permite o acesso a partir de qualquer origem de rede.

  • sourceRestriction: - (Obrigatório se usar o atributo sources) Este atributo permite-lhe aplicar restrições de acesso com base no sources especificado. Para aplicar estas restrições de acesso, defina o atributo sourceRestriction como SOURCE_RESTRICTION_ENABLED.

    Para desativar estas restrições de acesso, defina o atributo sourceRestriction como SOURCE_RESTRICTION_DISABLED.

    Se não definir nenhum valor para o atributo sourceRestriction, o VPC Service Controls ignora o atributo sources e não aplica restrições de acesso.

  • title: - (Opcional) Este atributo especifica o título da regra de saída. O título tem de ser exclusivo no perímetro e não pode exceder os 100 carateres. Na política de acesso, o comprimento combinado de todos os títulos das regras não pode exceder 240 000 carateres.

Depois de terminar a configuração do ficheiro de política de saída, consulte o artigo Atualizar políticas de entrada e saída para obter instruções sobre como aplicar o ficheiro de política de saída ao perímetro de serviço.

Se configurar várias regras de saída num perímetro de serviço, o VPC Service Controls permite um pedido se este cumprir as condições de qualquer uma das regras de saída.

Usar o modo de execução de ensaio para testar políticas de entrada/saída

Quando não quer conceder acesso a todos os métodos de um serviço, por vezes, pode ser difícil determinar a lista precisa de métodos a permitir. Isto pode ocorrer porque um determinado método para um serviço pode fazer com que um método diferente seja invocado num serviço Google Cloud separado. Por exemplo, o BigQuery carregar uma tabela de um contentor do Cloud Storage para executar uma consulta.

Para determinar o conjunto correto de métodos a permitir, pode usar o modo de teste dos VPC Service Controls. Para o fazer, comece por ativar um perímetro no modo de teste sem políticas de entrada nem saída e recolha a lista de métodos invocados a partir do registo de auditoria. Em seguida, adicione progressivamente estes métodos às políticas de entrada/saída no modo de teste até que todas as violações cessem. Nesse momento, a configuração pode ser movida do modo de teste para o modo aplicado.

Funcionalidades não suportadas

As seguintes funcionalidades não são atualmente suportadas para regras de entrada e saída:

  1. Identificar Google Cloud recursos por etiquetas em vez de projetos.
  2. Nem todos os serviços suportam regras de entrada/saída por método. Consulte as restrições de métodos de serviço suportados.
  3. Não é possível usar os tipos de identidade ANY_SERVICE_ACCOUNT e ANY_USER_ACCOUNT para permitir as seguintes operações:

Limitações

Para informações sobre os limites de entrada e saída, consulte o artigo Quotas e limites.

O que se segue?