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 (Prévia) 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 tráfego de entrada e saída regras.
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
- 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.
- 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:
- Restringir os tipos de identidade ou as identidades que podem ser usados com uma rede de origem, um endereço IP ou um dispositivo.
- 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.
- 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.
- Conceder acesso somente leitura a imagens e conjuntos de dados externos que não sejam gerenciados por você.
- 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.
- 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.
- Um cliente do Compute Engine em um perímetro de serviço que chama uma operação
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
dentro de um perímetro de serviço B
. Neste exemplo, para o
O cliente do Cloud Storage copiará 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 bucketb
do Cloud Storage, - uma regra de saída no perímetro
B
para permitir o acesso ao Cloud Storage bucketa
, - uma regra de entrada no perímetro
B
para permitir o acesso ao cliente do Cloud Storage que está fora do perímetroB
.
Referência de regras de entrada
As regras de entrada podem ser configuradas usando o console do Google Cloud,
um arquivo JSON ou 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 blocofrom
que lista as origens e identidades permitidas fora do perímetro.identityType:
- Esse atributo ou oidentities
precisam ser usados. Esse atributo define os tipos de identidades que podem ser usadas nassources
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.identities:
- (esse atributo ou o atributoidentityType
deve ser usado) este atributo inicia uma lista de contas de serviço, contas de usuário, Grupos do Google ou contas de terceiros que podem acessar os recursos no perímetro.PRINCIPAL_IDENTIFIER
: especifica uma conta de usuário, uma conta de serviço. um grupo do Google ou uma identidade de terceiros ao qual você quer dar acesso. recursos no perímetro. Use o formato especificado no IAMv1
Identificadores principais da API. Por exemplo, use o métodogroup:GROUP_NAME@googlegroups.com
para especificar um grupo do Google.O VPC Service Controls é compatível apenas com as identidades
v1
que começam com ouser
,serviceAccount
,group
(pré-lançamento), eprincipal
(Visualização) no IAMv1
identificadores principais da API.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 atributoaccessLevel
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.- resource:
(use este atributo ou o atributoaccessLevel
): 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 oresource
precisam ser usados. Esse atributo especifica o nível de acesso fora do perímetro a que o acesso é concedido. Se você definir o atributoaccessLevel
como"*"
, a política de entrada vai permitir o acesso de qualquer origem de rede.ingressTo:
(obrigatório): inicia o blocoto
, 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 blocofrom
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
é umserviceName
válido. Para uma lista dos serviços disponíveis, consulte Produtos compatíveis.methodSelectors:
: (obrigatório seserviceName
não for"*"
): o início de uma lista de métodos que um cliente que satisfaz as condições de bloqueiofrom
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 opermission
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 omethod
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 para um recurso exige várias permissões, é preciso especificar todas as permissões necessárias na mesma operação para que a regra de entrada funcionam. Por exemplo, se uma solicitação para um recurso do BigQuery exige as permissões
bigquery.jobs.create
ebigquery.tables.create
, é necessário especificar ambas as permissões na mesma operação. Além disso, se você especificar as permissões várias vezes para o mesmo recurso usando a console do Google Cloud, as permissões 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 umaccessLevel
ouresource
(projeto ou rede VPC do Google Cloud) ou defina o atributoaccessLevel
como"*"
.
- Atributo
identityType
ouidentities
- 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.
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 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 blocoto
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 blocofrom
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 seserviceName
não for"*"
): o início de uma lista de métodos que um cliente que satisfaz as condições de bloqueiofrom
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 opermission
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 omethod
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 para um recurso exige várias permissões, é preciso especificar todas as permissões necessárias na mesma operação para que a regra de saída funcionam. Por exemplo, se uma solicitação para um recurso do BigQuery exige as permissões
bigquery.jobs.create
ebigquery.tables.create
, é necessário especificar ambas as permissões na mesma operação. Além disso, se você especificar as permissões várias vezes para o mesmo recurso usando a console do Google Cloud, as permissões 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 blocofrom
que lista as origens e identidades permitidas dentro do perímetro.identityType:
: esse atributo ou oidentities
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
eANY_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.identities:
: esse atributo ou oidentityType
precisam ser usados. Isso 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 possa acessar os recursos especificados fora dele. Use o formato especificado no IAMv1
Identificadores principais da API. Por exemplo, use o métodogroup:GROUP_NAME@googlegroups.com
para especificar um grupo do Google.O VPC Service Controls é compatível apenas com as identidades
v1
que começam com ouser
,serviceAccount
,group
(pré-lançamento), eprincipal
(Visualização) no IAMv1
identificadores principais da API.
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.
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:
- identificar os recursos do Google Cloud por rótulos, em vez de projetos;
- 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.
- Os tipos de identidade
ANY_SERVICE_ACCOUNT
eANY_USER_ACCOUNT
não podem ser usados para permitir as seguintes operações:- Todas as operações do Container Registry.
- Todas as operações de serviço de notebooks.googleapis.com.
- Operações do Cloud Storage usando URLs assinados.
- Com o Cloud Functions, a implantação de uma Função do Cloud a partir da máquina local.
- Exporte registros de um coletor do Cloud Logging para um recurso do Cloud Storage.
- Todas as operações da interface do usuário da Web do Apache Airflow no Cloud Composer.
Limitações
Para informações sobre limites de entrada e saída, consulte Cotas e limites.