Regras de entrada e saída

Esta página explica as regras de entrada e saída do VPC Service Controls. O VPC Service Controls usa regras de entrada e saída para permitir acesso de e para recursos e clientes protegidos por perímetros de serviço.

Os blocos de regras de entrada e de saída especificam a direção de acesso permitido de e para diferentes identidades e recursos. As regras de entrada e saída podem substituir e simplificar casos de uso que anteriormente exigiam uma ou mais pontes do perímetro.

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

É possível configurar grupos de identidade e identidades de terceiros (pré-lançamento) nas regras de entrada e saída. Para um exemplo de caso de uso, consulte Exemplo de uso de grupos de identidade e identidades de terceiros em regras de entrada e saída.

Para uma lista de casos de uso e amostras de troca de dados segura, consulte Troca de dados segura com regras de entrada e saída.

Para ver uma lista de casos de uso com acesso baseado no contexto e amostras, consulte Acesso baseado no contexto com regras de entrada.

Benefícios das regras de entrada e saída

  1. As regras de entrada e saída permitem que você troque dados de forma particular e eficiente dentro e entre organizações usando as APIs de serviço do Google Cloud.
  2. As regras de entrada e saída permitem que você conceda acesso aos recursos do Google Cloud em um perímetro com base no contexto da solicitação da API:
    1. Restringir os tipos de identidade ou as identidades que podem ser usados com uma rede de origem, um endereço IP ou um dispositivo.
    2. Restringir as APIs e os métodos do Google Cloud que podem ser acessados de acordo com a rede de origem, o endereço IP, o dispositivo e o tipo de identidade.
  3. Minimizar o risco de exfiltração restringindo com precisão o serviço, os métodos, os projetos do Google Cloud, redes VPC e as identidades usadas para executar a troca de dados.
  4. Conceder acesso somente leitura a imagens e conjuntos de dados externos que não sejam gerenciados por você.
  5. Garantir que os clientes em segmentos menos privilegiados não tenham acesso aos recursos do Google Cloud em segmentos mais privilegiados; permitindo o acesso na outra direção.
  6. Simplificar as configurações que antes precisavam de uma ou mais pontes do perímetro.

Definição de entrada e saída

As definições de entrada e saída são independentes da operação invocada no recurso. Assim, as definições se referem à direção da solicitação, e não à direção do movimento de dados.

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

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

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

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

Modelo de política

Uma regra de entrada ou de 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 serviços e recursos do Google Cloud.

Várias regras de entrada e saída podem ser associadas a um perímetro de serviço. Uma chamada de serviço do Google Cloud é permitida ou negada com base nas seguintes semânticas:

  • Uma solicitação de um cliente fora do perímetro para um recurso do Google Cloud dentro do perímetro será permitida se as condições da regra de entrada necessária forem atendidas.
  • Uma solicitação de um cliente dentro do perímetro para um recurso do Google Cloud fora do perímetro será permitida se as condições da regra de saída necessária forem atendidas.
  • Uma chamada de API que envolve um recurso do Google Cloud no perímetro e um recurso do Google Cloud fora do perímetro será permitida se houver uma regra de entrada atendida pelo cliente (se o cliente não estiver no perímetro) e uma regra de saída atendida pelo recurso externo.

Exemplos de solicitações de API permitidas por regras de entrada

  • um cliente do Cloud Storage fora do perímetro que faz o download de objetos de um bucket do Cloud Storage dentro do perímetro para a máquina local (por exemplo, usando o comando gcloud storage cp);
  • um cliente do BigQuery fora do perímetro usando um job do BigQuery em um projeto dentro do perímetro para consultar um conjunto de dados do BigQuery dentro do perímetro (por exemplo, usando o comando bq query);
  • Uma VM do Compute Engine em uma rede VPC fora do perímetro faz gravações em um bucket do Cloud Storage dentro do perímetro.

Exemplos de solicitações de API permitidas por regras de saída

  • Um cliente do Cloud Storage dentro do perímetro copiando objetos entre um bucket do Cloud Storage fora do perímetro e um bucket dentro do perímetro (por exemplo, usando o comando gcloud storage cp).
  • Um cliente do BigQuery dentro do perímetro usando um job do BigQuery em um 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 solicitações de API permitidas pela combinação de regras de entrada e saída

  • Um cliente do Cloud Storage fora do perímetro que copia objetos entre um bucket do Cloud Storage fora do perímetro e um bucket dentro do perímetro (por exemplo, usando o comando gcloud storage cp).
  • um cliente do BigQuery fora do perímetro usando um job do BigQuery em um projeto fora dele para consultar um conjunto de dados do BigQuery dentro do perímetro (por exemplo, usando o comando bq query);
  • Um cliente do Compute Engine fora do perímetro que cria um disco do Compute Engine fora do perímetro usando 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 o job do BigQuery ou o disco do Compute Engine está fora do perímetro. É necessária uma regra de saída para permitir uma solicitação de API que envolve um recurso do Google Cloud dentro do perímetro (o conjunto de dados do BigQuery ou a chave do Cloud KMS) e um recurso fora do perímetro (o job do BigQuery ou o disco do Compute Engine).

Solicitações de API envolvendo vários perímetros de serviço

Quando os recursos acessados e/ou o cliente da API pertencerem a diferentes perímetros de serviço, as políticas de todos os perímetros envolvidos precisarão permitir a solicitação da API. Por exemplo, considere um cliente do Cloud Storage e um bucket a em um perímetro de serviço A e um bucket b em um perímetro de serviço B. Neste exemplo, para que o cliente do Cloud Storage copie objetos do bucket a para o bucket b e do bucket b para o bucket a, as seguintes regras de entrada e saída são necessárias:

  • uma regra de saída no perímetro A para permitir acesso ao bucket b do Cloud Storage,
  • uma regra de saída no perímetro B para permitir o acesso ao bucket a do Cloud Storage,
  • 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 de regras de entrada

As regras de entrada podem ser configuradas usando o console do Google Cloud, um arquivo JSON ou um arquivo YAML. A amostra a seguir 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
    resources:
    - projects/PROJECT

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

  • identityType: - Esse atributo ou o identities precisam ser usados. Esse atributo define os tipos de identidades que podem ser usadas nas sources especificadas (origem da rede). Valores aceitáveis: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY permite todas as identidades. ANY_USER_ACCOUNT permite todos os usuários humanos. ANY_SERVICE_ACCOUNT permite todas as contas de serviço.

    Esse 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:: esse ou o atributo identityType precisa ser usado. Esse atributo inicia uma lista de contas de serviço, contas de usuário, Grupos do Google ou identidades de terceiros que podem acessar recursos no perímetro.

  • PRINCIPAL_IDENTIFIER: especifique uma conta de usuário, uma conta de serviço, um Grupo do Google ou uma identidade de terceiros a que você quer conceder acesso aos recursos no perímetro. Use o formato especificado em Identificadores principais da API v1 do IAM. Por exemplo, use o formato group:GROUP_NAME@googlegroups.com para especificar um grupo do Google.

    O VPC Service Controls só oferece suporte às identidades v1 que começam com os prefixos user, serviceAccount, group (pré-lançamento), principal (pré-lançamento) e principalSet (pré-lançamento) nos identificadores de principal da API IAM v1.

  • sources: (obrigatório): esse atributo se refere a uma lista de origens de rede. Cada valor da lista é um nível de acesso ou um projeto do Google Cloud. Se você definir o atributo accessLevel como "*", a política de entrada vai permitir o acesso de qualquer origem de rede. Se você definir esse atributo como um projeto do Google Cloud, a política de entrada permitirá acesso de uma rede VPC que pertence ao projeto.

    Esse valor pode ser removido quando o projeto associado for excluído permanentemente. No entanto, a remoção desse valor não causa um erro. Sempre verifique se esse valor existe ao resolver problemas.

  • - resource: (use este atributo ou o atributo accessLevel): especifica um projeto ou rede VPC de fora do perímetro a que você quer fornecer acesso. Para especificar um projeto, use o seguinte formato: projects/PROJECT_NUMBER. Para especificar uma rede VPC, use o seguinte formato: //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.

  • - accessLevel: - Esse atributo ou o resource precisam ser usados. Esse atributo especifica o nível de acesso fora do perímetro a que o acesso é concedido. Se você definir o atributo accessLevel como "*", a política de entrada vai permitir o acesso de qualquer origem de rede.

  • ingressTo: (obrigatório): inicia o bloco to, que lista as operações de serviço permitidas nos recursos do Google Cloud especificados dentro do perímetro.

  • operations: (obrigatório): marca o início da lista de serviços acessíveis e ações/métodos que um cliente que satisfaz as condições de bloco from tem permissão para acessar.

  • - 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 uma lista dos serviços disponíveis, consulte Produtos compatíveis.

  • methodSelectors:: (obrigatório se serviceName não for "*"): o início de uma lista de métodos que um cliente que satisfaz as condições de bloqueio from tem permissão para acessar. Para ver uma lista de métodos e permissões que podem ser restritos, consulte Restrições de método de serviço compatíveis.

  • - method: - Esse atributo ou o permission precisam ser usados. Esse 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: - Esse atributo ou o method precisam ser usados. Esse campo precisa ser uma permissão de serviço válida. O acesso aos recursos dentro do perímetro é permitido para as operações que exigem a permissão.

    Quando uma solicitação a um recurso exige várias permissões, é necessário especificar todas as permissões necessárias na mesma operação para que a regra de entrada funcione. Por exemplo, se uma solicitação para um recurso do BigQuery exigir as permissões bigquery.jobs.create e bigquery.tables.create, você precisará especificar essas duas permissões na mesma operação. Além disso, se você especificar as permissões várias vezes para o mesmo recurso usando o console do Google Cloud, elas não serão criadas na mesma operação. Para evitar esse problema, especifique todas as permissões de uma só vez para o recurso.

  • resources: (obrigatório): esse atributo especifica a lista de recursos do Google Cloud no perímetro de serviço que o cliente fora do perímetro pode acessar. Esse campo pode ser definido como "*" para permitir o acesso de entrada a qualquer recurso do Google Cloud dentro do perímetro.

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

  • sources atributo. Especifique um accessLevel ou resource (projeto ou rede VPC do Google Cloud) ou defina o atributo accessLevel como "*".
  • Atributo identityType ou identities
  • Atributo resources
  • Atributo serviceName

Depois de concluir a configuração do arquivo de política de entrada, consulte Como atualizar políticas de entrada e saída para ver instruções sobre como aplicar esse arquivo ao perímetro de serviço.

Se você configurar várias regras de entrada em um perímetro de serviço, o VPC Service Controls permitirá uma solicitação se ela atender às condições de qualquer uma das regras de entrada.

Referência de regras de saída

As regras de saída podem ser configuradas usando o console do Google Cloud, um arquivo JSON ou um arquivo YAML. A amostra a seguir usa o 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: (obrigatório): inicia o bloco to que lista as operações de serviço permitidas nos recursos do Google Cloud nos projetos especificados fora do perímetro.

  • operations: (obrigatório): marca o início da lista de serviços acessíveis e ações/métodos que um cliente que satisfaz as condições de bloco from tem permissão para acessar.

  • - 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 uma lista dos serviços disponíveis, consulte Produtos compatíveis.

  • methodSelectors:: (obrigatório se serviceName não for "*"): o início de uma lista de métodos que um cliente que satisfaz as condições de bloqueio from tem permissão para acessar. Para ver uma lista de métodos e permissões que podem ser restritos, consulte Restrições de método de serviço compatíveis.

  • - method:: esse atributo ou o permission precisam ser usados. Esse 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:: esse atributo ou o method precisam ser usados. Este campo precisa ser uma permissão de serviço válida. O acesso aos recursos especificados fora do perímetro será permitido para as operações que exigirem essa permissão.

    Quando uma solicitação a um recurso exige várias permissões, é necessário especificar todas as permissões necessárias na mesma operação para que a regra de saída funcione. Por exemplo, se uma solicitação para um recurso do BigQuery exigir as permissões bigquery.jobs.create e bigquery.tables.create, você precisará especificar essas duas permissões na mesma operação. Além disso, se você especificar as permissões várias vezes para o mesmo recurso usando o console do Google Cloud, elas não serão criadas na mesma operação. Para evitar esse problema, especifique todas as permissões de uma só vez para o recurso.

  • resources: (obrigatório): esse atributo é uma lista de recursos do Google Cloud especificados pelos projetos que os clientes dentro de um perímetro podem acessar. É possível definir esse campo como "*" para permitir o acesso de saída a qualquer recurso do Google Cloud.

  • externalResources:: esse atributo é usado apenas para especificar recursos do BigQuery Omni. Esse atributo é uma lista de recursos externos compatíveis com o BigQuery Omni que os clientes dentro de um perímetro podem acessar. É possível especificar apenas recursos do Amazon S3 ou do Azure Blob Storage. Para o Amazon S3, o formato compatível é s3://BUCKET_NAME. Para o Azure Storage, o formato compatível é azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom: (obrigatório): inicia o bloco from que lista as origens e identidades permitidas dentro do perímetro.

  • identityType:: esse atributo ou o identities precisam ser usados. Esse atributo define os tipos de identidades que podem ser usados para acessar os recursos especificados fora do perímetro. Valores aceitáveis: ANY_IDENTITY, ANY_USER_ACCOUNT e ANY_SERVICE_ACCOUNT. ANY_IDENTITY permite todas as identidades. ANY_USER_ACCOUNT permite todos os usuários humanos. ANY_SERVICE_ACCOUNT permite todas as contas de serviço.

    Esse 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:: esse atributo ou o identityType precisam ser usados. Esse atributo inicia uma lista de contas de serviço, contas de usuário, grupos do Google ou identidades de terceiros que podem acessar os recursos especificados fora do perímetro.

  • PRINCIPAL_IDENTIFIER: especifica uma conta de usuário, uma conta de serviço, um grupo do Google ou uma identidade de terceiros que pode acessar os recursos especificados fora do perímetro. Use o formato especificado em Identificadores principais da API v1 do IAM. Por exemplo, use o formato group:GROUP_NAME@googlegroups.com para especificar um grupo do Google.

    O VPC Service Controls só oferece suporte às identidades v1 que começam com os prefixos user, serviceAccount, group (pré-lançamento), principal (pré-lançamento) e principalSet (pré-lançamento) nos identificadores de principal da API IAM v1.

Depois de concluir a configuração do arquivo de política de saída, consulte Como atualizar políticas de entrada e saída para ver instruções sobre como aplicar esse arquivo ao perímetro de serviço.

Se você configurar várias regras de saída em um perímetro de serviço, o VPC Service Controls permitirá uma solicitação se ela atender às condições de qualquer uma das regras de saída.

Como usar o modo de simulação para testar políticas de entrada/saída

Quando você não quer conceder acesso a todos os métodos de um serviço, às vezes pode ser difícil determinar a lista de métodos precisos para permitir. Isso pode ocorrer porque um determinado método de um serviço pode fazer com que um método diferente seja invocado em um serviço separado do Google Cloud. Por exemplo, o BigQuery carregar uma tabela em um bucket do Cloud Storage para executar uma consulta.

Para determinar o conjunto correto de métodos a serem permitidos, use o modo de teste do VPC Service Controls. Primeiro, ative um perímetro no modo de teste sem políticas de entrada ou de saída e colete a lista de métodos invocados no registro de auditoria. Em seguida, adicione esses métodos de maneira progressiva às políticas de entrada/saída no modo de teste até que todas as violações sejam interrompidas. Nesse ponto, a configuração pode ser movida do modo de teste para o modo restrito.

Recursos não suportados

No momento, os recursos a seguir não são compatíveis com as regras de entrada e saída:

  1. identificar os recursos do Google Cloud por rótulos, em vez de projetos;
  2. Nem todos os serviços aceitam regras de entrada/saída por método. Veja as restrições de método de serviço compatíveis.
  3. Os tipos de identidade ANY_SERVICE_ACCOUNT e ANY_USER_ACCOUNT não podem ser usados para permitir as seguintes operações:

Limitações

Para informações sobre limites de entrada e saída, consulte Cotas e limites.

A seguir

  • Conclua este codelab para saber como corrigir violações de entrada e saída.