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 nenhum serviço de API protegido pelo perímetro de serviço, permitindo que consultas sejam executadas em conjuntos de dados públicos e que os resultados sejam salvos em uma tabela de projeto. A consulta é executada em um projeto, e a tabela (onde os resultados são salvos) é criada em outro, simulando 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 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. As metas deste codelab são:

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

2. Configuração e requisitos de recursos

Antes de começar

Neste codelab, presumimos que você já sabe:

• Os conceitos básicos para executar uma consulta do BigQuery: confira este codelab para saber como 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 existente para 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 foi projetada da seguinte maneira:

Se você concluiu o Tutorial básico do VPC Service Controls, pode reutilizar os mesmos projetos, pasta e perímetro 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, vamos chamá-los de project-1 e project-2
  .
  • Se você ainda não tiver criado a pasta e os projetos, no console do Google Cloud, crie uma pasta na organização e crie dois projetos nessa pasta.
• 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.

Para este codelab, conceda a si mesmo os seguintes papéis predefinidos: Administrador da pasta 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). Assim, você terá os papéis necessários para configurar os recursos necessários para todo o codelab.

Criar um perímetro de serviço regular

Neste codelab, vamos usar um perímetro de serviço regular que protege 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 depois.

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 chamada default.

• Consulte a documentação como uma diretriz para criar uma instância do Compute Engine com base em uma imagem pública.

Neste codelab, vamos usar a rede VPC padrão, chamada default. Você também pode usar qualquer outra rede, desde que ela tenha pelo menos uma sub-rede.

Custo

É necessário ativar o faturamento no console do Google Cloud para usar recursos/APIs do Cloud. Recomendamos encerrar os recursos usados para evitar cobranças além deste codelab. Novos usuários do Google Cloud estão qualificados para o programa de US $300 de avaliação sem custos.

Os recursos que geram custos são o BigQuery e a instância do Compute Engine. Você pode estimar o custo usando a calculadora de preços do BigQuery e a calculadora de preços do Compute Engine.

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

Consultar o conjunto de dados público e salvar os resultados em project-1

1. Acesse project-2 e project-1 para verificar se você consegue acessar a API BigQuery na página do BigQuery Studio. Isso é possível porque, mesmo que project-1 esteja em um perímetro de serviço, ele ainda não está protegendo nenhum serviço.
2. No project-2, execute a consulta a seguir 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 (sem sair do project-2):

1. Clique em Salvar resultados e selecione Tabela do BigQuery. Consulte 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 você esteja usando 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 em project-1 como resultado da execução da consulta em project-2.

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

Ainda no project-2 BigQuery Studio, execute a seguinte consulta para selecionar dados de:

• 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 sem problemas porque nem project-2 nem project-1 têm restrições para usar o BigQuery. O acesso ao BigQuery é permitido de e para qualquer lugar, desde que o usuário tenha as permissões adequadas do IAM.

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 realiza a operação real, neste cenário, a recuperação de dados. O acesso principal é demonstrado em uma instância do Compute Engine e na Internet, ao consultar um conjunto de dados público e um projeto separado do Google Cloud. O processo para consultar os dados (GetData) é 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 API BigQuery junto com o recurso protegido 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;

Uma violação do VPC Service Controls RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER vai ocorrer

O registro de auditoria de violação vai estar em project-1, porque foi lá que ocorreu a violação de cruzamento do perímetro. 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 executa 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 permissão de destino devido ao funcionamento do BigQuery. Quando você usa o console do Google Cloud (ou a ferramenta de linha de comando bq) para gerenciar dados do BigQuery, o BigQuery cria jobs, que são usados para concluir as ações desejadas. Enquanto isso, o primeiro evento é criar um job do BigQuery.

Este diagrama ilustra quando um principal executa uma consulta de 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 devido ao perímetro de serviço perimeter-1 que protege a API BigQuery. Com o perímetro em vigor, nenhuma solicitação da API BigQuery pode ser iniciada de project-1 para fora do perímetro ou iniciada fora do perímetro para o projeto protegido, a menos que permitido pelas configurações do perímetro de serviço.

Para corrigir uma violação de saída, crie uma regra de saída com base no seguinte:

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

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 executa a consulta ([e-mail]) no serviço do BigQuery e no método/ permissão bigquery.jobs.create.

Comportamento esperado da regra de saída configurada:

• FROM | Identities: somente a identidade especificada [e-mail] pode cruzar o limite do perímetro.
• TO | projects: a identidade especificada só pode cruzar os limites do perímetro se o destino for o projeto especificado project-2.
• TO | Serviços: a identidade especificada pode iniciar tráfego fora do perímetro, em direção ao projeto especificado, somente se a chamada de API for para o serviço e o método especificados. Caso contrário, por exemplo, se eles tentarem um serviço diferente protegido pelo perímetro de serviço, a operação será bloqueada porque outros serviços não são permitidos.

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

Depois que 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;

Outra violação vai ocorrer, desta vez uma violação de entrada 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 não vão ocorrer. Uma nova chamada de API com um contexto diferente daqueles permitidos por uma política já configurada vai causar uma violação diferente.

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

• principalEmail: [conta de usuário que executa a consulta]
• callerIp: [o endereço IP do user agent que executa 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 extrair dados da tabela do BigQuery.

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

6. Como corrigir violações para receber dados de tabelas do BigQuery

Uma regra de entrada corrige uma violação de entrada e oferece um controle granular sobre quem pode cruzar 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 da API que pode ser acessado.

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

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

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:

• FROM | Identities: somente a identidade especificada [e-mail] pode cruzar o limite do perímetro.
• TO | projects: a identidade especificada só pode cruzar os limites do perímetro se o destino for o projeto especificado project-1.
• PARA | Serviços: a identidade especificada só pode iniciar o tráfego dentro do perímetro se a chamada de API for para a API BigQuery e o método especificado bigquery.tables.getData.

A execução da consulta idêntica vai funcionar corretamente sem violações do VPC Service Controls.

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

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

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

A configuração atual permite que o usuário designado execute consultas no BigQuery em project-1 de qualquer lugar da Internet, desde que tenha permissão do IAM para consultar os dados e use a conta dele. Do ponto de vista da segurança, isso implica que, se a conta for comprometida, qualquer pessoa que tiver acesso a ela poderá acessar os dados do BigQuery sem restrições adicionais.

Outras restrições podem ser implementadas usando o nível de acesso em 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 em conjunto com uma regra de entrada configurada anteriormente que autoriza o acesso pela identidade do caller. O acesso por IP de origem é viável para intervalos CIDR de IP público, desde que o cliente do usuário tenha um IP público atribuído a ele, ou usando um endereço IP interno se o cliente do usuário operar em um projeto do Google Cloud.

Criar um 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: você pode usar codelab-al.
   2. Na seção "Condições", clique em Sub-redes de IP.
   3. Selecione a guia IP particular e clique em SELECIONAR REDES VPC.
   4. No painel Adicionar redes VPC, navegue 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 DE IP.
   7. Selecione a região em que a instância de VM está localizada. Neste codelab, é us-central1.
   8. Clique em SALVAR.

Criamos um nível de acesso, que ainda não é aplicado a 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 aos 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

Depois da adição do nível de acesso na 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 violação de entrada.

Por padrão:

• O escopo de acesso de uma instância do Compute Engine é definido como acesso padrão, que não permite o acesso à API BigQuery.
• Uma instância do Compute Engine terá a conta de serviço padrão do Compute Engine anexada a ela. 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 anexada à 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 porque a regra de entrada ainda está configurada para permitir apenas o principal [e-mail]. No entanto, a VM está usando a conta de serviço padrão do Compute Engine.

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

• A VM tem escopo de acesso para usar a API BigQuery. Para isso, selecione Permitir acesso total 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
  • Receber dados do BigQuery da tabela 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 a obtenção 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 bq query:

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ó vai funcionar se:

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

O comando de consulta do BigQuery vai falhar se for executado em 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 no nível de acesso; ou
• se executado pelo usuário [e-mail] com um cliente de usuário na Internet.

Este diagrama ilustra o acesso iniciado pelo mesmo principal, [e-mail], de dois locais diferentes: a Internet e uma instância do Compute Engine. O acesso ao BigQuery diretamente da Internet (linhas pontilhadas azuis) é bloqueado pelo VPC Service Controls, enquanto o acesso de uma VM (linhas sólidas verdes), ao simular a conta de serviço padrão do Compute Engine, é permitido. O acesso permitido ocorre porque o perímetro de serviço está configurado para permitir o acesso a recursos protegidos de um endereço IP interno.

8. Limpeza

Não há cobrança extra pelo uso do VPC Service Controls quando o serviço não está em uso, mas é recomendável limpar a configuração usada neste 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, siga estas etapas:
  • No Console do Google Cloud, acesse a página Instâncias de VMs.
  • Marque a caixa de seleção no lado esquerdo do nome da instância de VM, selecione Excluir e clique em Excluir novamente para confirmar.
• Para excluir o perímetro de serviço, siga estas etapas:
  • No console do Google Cloud, selecione Segurança e VPC Service Controls no nível em que a política de acesso está no escopo, neste caso, no nível da pasta.
  • Na página do 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, siga estas 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 Configurações do IAM e do administrador do projeto que você quer excluir.
  • Na página "Configurações do IAM e administrador", selecione Desativar.
  • Digite o ID do projeto e selecione Encerrar mesmo assim.

9. Parabéns!

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

Saiba mais

Você também pode conferir 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 ao próprio perímetro e mantenha project-1 no perímetro atual.
• Execute consultas para atualizar dados na tabela, não apenas para recuperá-los.

Licença

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