VPC Service Controls: codelab I sobre proteção do BigQuery

1. Introdução

Neste codelab, você vai aprender a proteger a API BigQuery usando o VPC Service Controls. O codelab começa sem um serviço de API protegido pelo perímetro de serviço, permitindo que consultas em conjuntos de dados públicos e os resultados sejam salvos em uma tabela do projeto. A consulta é executada em um projeto e a tabela (em que os resultados são salvos) é criada em outro, imitando uma configuração em que os dados podem ser armazenados em um projeto, mas precisam ser acessados usando um projeto diferente.

Em seguida, vamos apresentar um perímetro de serviço para proteger o projeto de dados. Você vai aprender a corrigir as violações observadas usando regras de entrada e saída e, depois, adicionar um nível de acesso para restringir o acesso usando endereços IP internos. Os objetivos deste codelab são:

• Entenda como corrigir violações de entrada e saída usando regras de entrada e saída, respectivamente.
• Entenda por que ocorreu uma violação específica.
• Analise o escopo da correção de violação aplicada.
• Modifique a correção (regra de entrada / saída) para mudar o escopo aproveitando a opção de permitir o tráfego de endereços IP internos em uma rede VPC usando níveis de acesso.

2. Configuração dos recursos e requisitos

Antes de começar

Neste codelab, presumimos que você já saiba:

• Noções básicas para executar uma consulta do BigQuery: confira este codelab para aprender a consultar o conjunto de dados da Wikipédia no BigQuery.
• Como criar e gerenciar uma pasta
• Como criar um projeto em uma pasta ou mover um projeto atual em uma pasta
• Como criar uma política de acesso com escopo
• Como criar e configurar um perímetro de serviço.
• Como encontrar violações da política de segurança nos registros.

Configuração

Nossa configuração inicial é projetada da seguinte maneira:

Se você concluiu o Tutorial básico do VPC Service Controls, pode reutilizar os mesmos projetos, pastas e perímetros de serviço.

• Uma organização do Google Cloud.
• Uma pasta na organização. Neste codelab, vamos chamá-lo de codelab-folder.
• Dois projetos do Google Cloud colocados na mesma pasta, codelab-folder. Neste codelab, eles são chamados de project-1 e project-2
  .
  • Se você ainda não tiver a pasta e os projetos criados, no console do Google Cloud, crie uma pasta na organização e crie dois projetos nela.
• As permissões necessárias:
  • Papéis do IAM para gerenciar pastas: atribuídos no nível da pasta
  • Papéis do IAM para gerenciar projetos: atribuídos no nível do projeto
  • Papéis do IAM necessários para configurar o VPC Service Controls: atribuídos no nível da organização
  • Papéis do IAM para gerenciar o BigQuery: atribuídos no nível do projeto
  • Papéis do IAM para gerenciar instâncias do Compute Engine: atribuídos no nível do projeto
• Conta de faturamento para os dois projetos, project-2 e project-1.

Neste codelab, você pode conceder a si mesmo os seguintes papéis predefinidos: Administrador de pastas e Criador de projetos (no nível da pasta), Proprietário (no nível do projeto), Administrador do BigQuery (no nível do projeto) e Administrador do Access Context Manager (no nível da organização). e você terá os papéis necessários para configurar os recursos necessários para este codelab inteiro.

Criar um perímetro de serviço regular

Neste codelab, usaremos um perímetro de serviço normal protegendo project-1.

• Crie um perímetro regular, perimeter-1, e adicione o project-1.

No perímetro, não restrinja nenhum serviço ainda. Vamos fazer isso mais tarde.

Criar uma VM do Compute Engine

Neste codelab, vamos usar uma instância do Compute Engine em project-2, localizada em us-central1 e usando a rede VPC padrão default.

• Consulte a documentação como orientação para criar uma instância do Compute Engine a partir de uma imagem pública.

Neste codelab, vamos usar a rede VPC padrão, chamada default. Também é possível usar qualquer outra rede, desde que ela tenha pelo menos uma sub-rede.

Custo

Você precisa ativar o faturamento no console do Google Cloud para usar recursos/APIs da nuvem. Recomendamos encerrar os recursos usados para evitar cobranças posteriores a este codelab. Novos usuários do Google Cloud estão qualificados para o programa de teste sem custo financeiro de US $300.

Os recursos que geram custos são o BigQuery e a instância do Compute Engine. É possível estimar o custo usando as calculadoras de preços do BigQuery e do Compute Engine.

3. Acesso ao BigQuery sem restrições do VPC Service Controls

Consulte o conjunto de dados público e salve os resultados em project-1

1. Acesse project-2 e project-1 para verificar se você pode acessar a API BigQuery visitando a página do BigQuery Studio. Isso deve ser feito porque, mesmo que project-1 esteja em um perímetro de serviço, o perímetro ainda não protege nenhum serviço.
2. Em project-2, execute a seguinte consulta para consultar um conjunto de dados público.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

Depois de executar a consulta no conjunto de dados público (enquanto permanece em project-2):

1. Clique em Salvar resultados e selecione a tabela do BigQuery. (confira a captura de tela abaixo).
2. Selecione project-1 como o projeto de destino.
3. Nomeie o conjunto de dados como codelab_dataset. Selecione CRIAR NOVO CONJUNTO DE DADOS, a menos que use um conjunto de dados existente.
4. Nomeie a tabela como: codelab-table.
5. Clique em Salvar.

Os dados do conjunto de dados público foram armazenados com sucesso em project-1, como resultado da execução da consulta de project-2.

Conjunto de dados de consultas salvo em project-1 de project-2

Enquanto permanecer no project-2 BigQuery Studio, execute a seguinte consulta para selecionar dados:

• Projeto: project-1
• Conjunto de dados: codelab_dataset
• Tabela: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

A consulta será executada corretamente, porque project-2 e project-1 não estão restritos ao uso do BigQuery. O acesso ao BigQuery é permitido de e para qualquer lugar, desde que o usuário tenha as permissões de IAM apropriadas.

Este diagrama ilustra o processo quando um principal consulta um conjunto de dados do BigQuery. Cada consulta do BigQuery inicia um job do BigQuery, que executa a operação real, nesse cenário, de recuperação dos dados. O acesso principal é demonstrado em uma instância do Compute Engine e na Internet, durante a consulta em um conjunto de dados público e em um projeto separado do Google Cloud. O processo para consultar os dados (GetData) foi bem-sucedido, sem ser bloqueado pelo VPC Service Controls.

4. Proteger a API BigQuery no projeto do conjunto de dados de origem

Modifique a configuração do perímetro perimeter-1 e restrinja o serviço da API BigQuery com o recurso protegido sendo project-1.

Verificar a aplicação do perímetro de serviço

Em project-2, execute a seguinte consulta no BigQuery Studio, como na etapa anterior:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Ocorrerá uma violação RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER do VPC Service Controls

O registro de auditoria de violação estará localizado em project-1, porque esse é o local onde a violação para atravessar o perímetro ocorreu. Os registros podem ser filtrados com o vpcServiceControlsUniqueId observado (substitua VPC_SC_DENIAL_UNIQUE_ID pelo ID exclusivo observado).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

A violação é um egressViolations com:

• principalEmail: [conta de usuário que executa a consulta]
• callerIp: [o endereço IP do user agent que está executando a consulta]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. Como corrigir a violação para criar um job do BigQuery

A violação do VPC Service Controls tem bigquery.jobs.create como a permissão de destino devido à forma como o BigQuery funciona. Quando você usa o console do Google Cloud (ou a ferramenta de linha de comando bq) para gerenciar dados do BigQuery, ele cria jobs que são usados para concluir as ações desejadas. O primeiro evento, por sua vez, é criar um job do BigQuery.

Este diagrama ilustra quando um principal executa uma consulta em project-2 para um conjunto de dados em project-1. A operação para criar um job do BigQuery do projeto do conjunto de dados (project-1) no projeto em que a consulta é executada (project-2) falha com uma violação de saída do VPC Service Controls porque o perímetro de serviço perimeter-1 protege a API BigQuery. Com o perímetro ativo, nenhuma solicitação da API BigQuery pode ser iniciada de project-1 para fora do perímetro ou iniciada fora dele para o projeto protegido. a menos que permitido pelas configurações do perímetro de serviço.

Uma violação de saída pode ser corrigida com a criação de uma regra de saída baseada no seguinte:

• source (FROM): ou seja, o endereço de e-mail e o contexto do usuário (por exemplo, endereço IP do autor da chamada, estado do dispositivo, localização etc.)
• destino (TO): ou seja, o recurso de destino, serviço e método ou permissão.

Para corrigir a violação de saída observada, crie uma regra de saída que permita o tráfego para o targetResource (project-2) pela conta de usuário que está executando a consulta ([e-mail]) no serviço do BigQuery e pelo método/ permissão bigquery.jobs.create.

Comportamento esperado da regra de saída configurada:

• DE | Identidades: apenas a identidade [e-mail] especificada precisa ter permissão para atravessar o limite do perímetro.
• PARA | projetos: a identidade especificada pode cruzar os limites do perímetro somente se o destino for o projeto project-2 especificado.
• PARA | Serviços: a identidade especificada pode iniciar tráfego fora do perímetro, para o projeto especificado, somente se a chamada de API for para o serviço e o método especificados. Caso contrário, se eles tentarem um serviço diferente protegido pelo perímetro de serviço, por exemplo, a operação será bloqueada porque outros serviços não são permitidos.

Teste a correção: regra de saída

Quando a regra de saída estiver em vigor, execute a mesma consulta.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Haverá outra violação, desta vez uma violação de entrada de NO_MATCHING_ACCESS_LEVEL. A nova violação é diferente da primeira em termos de projeto de destino e método.

Corrigir uma violação do VPC Service Controls não significa que outras violações vão acontecer. Uma nova chamada de API com contexto diferente dos permitidos pela política já configurada causará uma violação diferente.

A nova violação é uma violação de entrada

• principalEmail: [conta de usuário que executa a consulta]
• callerIp: [o endereço IP do user agent que está executando a consulta]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

A violação do método bigquery.tables.getData ocorre devido a uma chamada de API iniciada pelo job do BigQuery que tenta receber dados da tabela do BigQuery.

É importante entender como um determinado serviço da API funciona para antecipar as violações esperadas.

6. Como corrigir uma violação para acessar os dados da tabela do BigQuery

Uma regra de entrada corrige uma violação de entrada, além de fornecer um controle granular sobre quem tem permissão para atravessar o limite do perímetro de serviço, além do contexto do acesso permitido, como o projeto de origem/ destino e o método de API que eles podem acessar.

Uma violação de entrada é corrigida por uma regra de entrada configurada com:

• source (FROM): ou seja, o endereço de e-mail e o contexto do usuário (por exemplo, endereço IP do autor da chamada, estado do dispositivo, localização etc.)
• destino (TO): ou seja, o recurso de destino, serviço e método ou permissão.

A regra de entrada vai permitir o tráfego para project-1 pelo usuário especificado no serviço e método especificados.

Comportamento esperado da regra de entrada configurada:

• DE | Identidades: apenas a identidade [e-mail] especificada precisa ter permissão para atravessar o limite do perímetro.
• PARA | projetos: a identidade especificada só pode cruzar os limites do perímetro se o destino for o projeto project-1 especificado.
• PARA | Serviços: a identidade especificada poderá iniciar tráfego dentro do perímetro somente se a chamada de API for para a API BigQuery e o método bigquery.tables.getData especificado.

A execução da mesma consulta precisa funcionar corretamente sem violações do VPC Service Controls.

Restringimos a API BigQuery no project-1 para que ela só possa ser usada pelo [e-mail], e não pelo [e-mail].

Este diagrama ilustra como dois principais diferentes tentam consultar o mesmo conjunto de dados. O acesso por [e-mail] (linhas azuis pontilhadas) é negado pelo VPC Service Controls, porque ele não tem permissão para executar operações do BigQuery de ou para project-1 pela configuração do perímetro de serviço. O acesso pelo [e-mail] (linha contínua verde) foi bem-sucedido, porque é permitido pelas configurações do VPC Service Controls para executar operações de e para project-1.

7. Restringir o tráfego permitido pelo perímetro do serviço com base no endereço IP interno

A configuração atual permite que o usuário designado execute consultas no BigQuery no project-1 de qualquer local. em qualquer lugar da Internet, desde que tenham permissão do IAM para consultar os dados e usem a conta. Da perspectiva da segurança, isso implica que, se a conta for comprometida, qualquer indivíduo que tenha acesso à conta poderá acessar os dados do BigQuery sem nenhuma restrição adicional.

Outras restrições podem ser implementadas usando o nível de acesso nas regras de entrada e saída para especificar o contexto do usuário. Por exemplo, é possível permitir o acesso com base no IP de origem com uma regra de entrada configurada anteriormente que autoriza o acesso por identidade do autor da chamada. O acesso por IP de origem é viável para os dois intervalos CIDR de IP público, desde que o cliente do usuário tenha um IP público atribuído a ele ou use um endereço IP interno se o cliente do usuário operar em um projeto do Google Cloud.

Criar nível de acesso com uma condição de acesso de endereço IP interno

Na mesma pasta de política de acesso com escopo, abra a página do Access Context Manager para criar um nível de acesso.

1. Na página do Access Context Manager, selecione CRIAR NÍVEL DE ACESSO.
2. No painel "Novo nível de acesso":
   1. Forneça um título: use codelab-al.
   2. Na seção "Condições", clique em Sub-redes de IP.
   3. Selecione a guia IP privado e clique em SELECIONAR REDES VPC.
   4. No painel Adicionar redes VPC, procure e encontre a rede default ou insira manualmente o nome completo da rede no formato //compute.googleapis.com/projects/project-2/global/networks/default.
   5. Clique em ADICIONAR rede VPC.
   6. Clique em SELECIONAR SUB-redes IP.
   7. Selecione a região em que a instância de VM está localizada. Neste codelab, ele é us-central1.
   8. Clique em SALVAR.

Criamos um nível de acesso, que ainda não é aplicado em nenhum perímetro ou política de entrada/saída.

Adicionar nível de acesso à regra de entrada

Para garantir que o usuário permitido pela regra de entrada também seja verificado em relação ao nível de acesso, é necessário configurar o nível de acesso na regra de entrada. A regra de entrada que autoriza o acesso a dados de consulta está em perimeter-1. Altere a regra de entrada para definir a origem como o nível de acesso codelab-al.

Como testar novas configurações

Após a adição do nível de acesso à regra de entrada, a mesma consulta do BigQuery vai falhar, a menos que seja executada pelo cliente na rede VPC default para o projeto project-2. Para verificar esse comportamento, execute a consulta no console do Google Cloud enquanto o dispositivo de endpoint estiver conectado à Internet. A consulta será encerrada sem sucesso, acompanhada de uma indicação de uma violação de entrada.

Por padrão:

• Por padrão, um escopo de acesso da instância do Compute Engine é definido como acesso padrão, que não permite o acesso à API BigQuery.
• Uma conta de serviço padrão do Compute Engine será anexada a uma instância do Compute Engine. Enquanto isso, todos os comandos executados na VM serão executados como essa conta de serviço, que precisa estar no formato [e-mail].
  O escopo de acesso e a conta de serviço anexadas à VM podem ser alterados.

A mesma consulta pode ser executada na rede VPC default, localizada em project-2. Da mesma forma, a execução da mesma consulta do BigQuery em uma instância do Compute Engine localizada em project-2 usando a rede VPC default também vai falhar. Isso ocorre porque a regra de entrada ainda está configurada para permitir apenas o [e-mail] principal. No entanto, a VM está usando a conta de serviço padrão do Compute Engine.

Para executar o mesmo comando pela instância do Compute Engine em project-2,verifique se:

• A VM tem um escopo de acesso para usar a API BigQuery. Para isso, selecione Permitir acesso completo a todas as APIs do Cloud como o escopo de acesso da VM.
• A conta de serviço anexada à VM precisa das permissões do IAM para:
  • Criar jobs do BigQuery em project-2
  • Extrair dados do BigQuery da tabela do BigQuery localizada em project-1
• A conta de serviço padrão do Compute Engine precisa ser permitida pela regra de entrada e saída.

Agora precisamos adicionar a conta de serviço padrão do Compute Engine às regras de entrada (para permitir o recebimento de dados da tabela do BigQuery) e à regra de saída (para permitir a criação de jobs do BigQuery).

Em uma instância do Compute Engine em project-2 na rede VPC default, execute o seguinte comando de consulta bq:

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

Com a configuração atual, o comando do BigQuery só funcionará se:

• executadas em uma VM usando a rede VPC padrão em project-2;
• localizada na região us-central1 especificada (sub-rede de IPs) e
• executadas usando a conta de serviço padrão do Compute Engine configurada no perímetro de serviço.

A consulta de comando do BigQuery falhará se executada de qualquer outro lugar, incluindo:

• se executado em uma VM usando a rede VPC padrão em project-2, mas localizada em uma região diferente da sub-rede adicionada ao nível de acesso; ou
• se executado pelo usuário [e-mail] com um cliente do usuário na Internet.

Este diagrama ilustra o acesso iniciado pelo mesmo principal, [e-mail], em dois locais diferentes: na Internet e em uma instância do Compute Engine. O acesso ao BigQuery diretamente pela Internet (linhas pontilhadas azuis) é bloqueado pelo VPC Service Controls. Já o acesso por uma VM (linhas sólidas verdes), representando a conta de serviço padrão do Compute Engine, é permitido. O acesso permitido se deve à configuração do perímetro de serviço para permitir o acesso de um endereço IP interno a recursos protegidos.

8. Limpeza

Não há cobrança separada pelo uso do VPC Service Controls quando o serviço não está em uso, mas a prática recomendada é limpar o ambiente usado no laboratório. Também é possível excluir a instância de VM e os conjuntos de dados do BigQuery ou os projetos do Google Cloud para evitar cobranças. A exclusão do projeto do Cloud interrompe o faturamento de todos os recursos usados nele.

• Para excluir a instância de VM, conclua as etapas a seguir:
  • No Console do Google Cloud, acesse a página Instâncias de VMs.
  • Marque a caixa de seleção à esquerda do nome da instância de VM, selecione Excluir e clique novamente em Excluir para confirmar.
• Para excluir o perímetro de serviço, conclua as seguintes etapas:
  • No console do Google Cloud, selecione Segurança e VPC Service Controls no nível do escopo da política de acesso, neste caso, no nível da pasta.
  • Na página "VPC Service Controls", na linha da tabela correspondente ao perímetro que você quer excluir, clique em Excluir.
• Para excluir o nível de acesso, conclua as seguintes etapas:
  • No console do Google Cloud, abra a página Access Context Manager no escopo da pasta.
  • Na grade, identifique a linha do nível de acesso que você quer excluir, selecione o menu de três pontos e clique em Excluir.
• Para encerrar os projetos, siga estas etapas:
  • No console do Google Cloud, acesse a página IAM e Configurações de administrador do projeto que você quer excluir.
  • Na página "IAM e Na página "Configurações de administrador", selecione Encerrar.
  • Digite o ID do projeto e selecione Encerrar mesmo assim.

9. Parabéns!

Neste codelab, você criou, aplicou e resolveu um perímetro de VPC Service Controls.

Saiba mais

Também é possível explorar os seguintes cenários:

• Execute a mesma consulta no conjunto de dados público, depois que o projeto for protegido pelo VPC Service Controls.
• Adicione project-2 no mesmo perímetro que project-1.
• Adicione project-2 no próprio perímetro e mantenha project-1 no perímetro atual.
• Executar consultas para atualizar dados na tabela, não apenas para recuperar dados.

Licença

Este conteúdo está sob a licença Atribuição 2.0 Genérica da Creative Commons.