Importar dados de uma rede externa para um data warehouse seguro do BigQuery

Last reviewed 2023-08-15 UTC

Muitas organizações implantam data warehouses que armazenam informações confidenciais para que possam analisar os dados para vários fins comerciais. Este documento é destinado a engenheiros e administradores de segurança que implantam e protegem data warehouses usando o BigQuery. Ele faz parte de um blueprint de segurança que inclui o seguinte:

  • Um repositório do GitHub que contém um conjunto de configurações e scripts do Terraform. A configuração do Terraform configura um ambiente no Google Cloud compatível com um data warehouse que armazena dados confidenciais.
  • Um guia para os controles de arquitetura, design e segurança que você usa para implementar esse blueprint (este documento).

Neste documento, você verá os seguintes tópicos:

  • A arquitetura e os serviços do Google Cloud que podem ser usados para ajudar a proteger um data warehouse em um ambiente de produção.
  • Práticas recomendadas para importar dados para o BigQuery a partir de uma rede externa, como um ambiente local.
  • Práticas recomendadas para governança de dados ao criar, implantar e operar um data warehouse no Google Cloud, incluindo a criptografia na coluna, tratamento diferencial de dados confidenciais e controles de acesso no nível da coluna.

Neste documento, pressupomos que você já tenha configurado um conjunto básico de controles de segurança, conforme descrito no blueprint de bases empresariais do Google Cloud. Ele ajuda você a sobrepor controles adicionais aos seus controles de segurança atuais para proteger dados confidenciais em um data warehouse.

Casos de uso do data warehouse

O blueprint é compatível com os seguintes casos de uso:

Informações gerais

Data warehouses como o BigQuery permitem que as empresas analisem os dados da empresa para conseguir insights. Os analistas acessam os dados da empresa que estão armazenados nos data warehouses para criar insights. Se o data warehouse incluir dados que você considera confidenciais, será necessário tomar medidas para preservar a segurança, confidencialidade, integridade e disponibilidade dos dados da empresa enquanto eles são importados e armazenados, enquanto estão em trânsito, ou durante a análise. Neste blueprint, você realizará as ações a seguir:

  • Criptografe os dados de origem localizados fora do Google Cloud (por exemplo, em um ambiente local) e importe-os para o BigQuery.
  • Configurar controles que ajudem a proteger o acesso a dados confidenciais.
  • Configurar controles que ajudem a proteger o pipeline de dados.
  • Configurar uma separação adequada de tarefas para diferentes perfis.
  • Configurar controles de segurança e registros apropriados para proteger os dados confidenciais.
  • Use a classificação de dados, tags de política, mascaramento dinâmico de dados e criptografia no nível da coluna para restringir o acesso a colunas específicas no data warehouse.

Arquitetura

Para criar um data warehouse confidenciais, é necessário importá-los com segurança e armazená-los em um perímetro do VPC Service Controls. A imagem a seguir mostra como os dados são ingeridos e armazenados.

A arquitetura de data warehouse segura para redes externas.

A arquitetura usa uma combinação dos seguintes serviços e recursos do Google Cloud:

  • A interconexão dedicada permite mover dados entre sua rede e o Google Cloud. É possível usar outra opção de conectividade, conforme descrito em Como escolher um produto de conectividade de rede.

  • O Identity and Access Management (IAM) e o Resource Manager restringem os recursos de acesso e segmento. A hierarquia de recursos e controles de acesso segue o princípio do menor privilégio.

  • O VPC Service Controls cria perímetros de segurança que isolam serviços e recursos, configurando autorização, controles de acesso e troca segura de dados. Os perímetros são os seguintes:

    • Um perímetro de ingestão de dados que aceita dados recebidos (em lote ou stream). Um perímetro separado ajuda a proteger o restante das cargas de trabalho contra dados recebidos.
    • Um perímetro de dados que isola os dados de criptografia de outras cargas de trabalho.
    • Um perímetro de governança que armazena as chaves de criptografia e define o que é considerado como dados confidenciais.

    Eles são projetados para proteger o conteúdo recebido, isolar dados confidenciais configurando controles e acesso adicionais e separar sua governança dos dados reais no armazenamento. Sua governança inclui gerenciamento de chaves, gerenciamento de catálogo de dados e geração de registros.

  • O Cloud Storage e o Pub/Sub recebem dados da seguinte maneira:

  • O Cloud Functions é acionado pelo Cloud Storage e grava os dados que o Cloud Storage faz upload no bucket de ingestão no BigQuery.

  • Um pipeline do Dataflow grava dados de streaming no BigQuery. Para proteger os dados, o Dataflow usa uma conta de serviço exclusiva e controles de acesso. Para proteger a execução do pipeline movendo-o para o serviço de back-end, o Dataflow usa o Streaming Engine. Para mais informações, consulte Segurança e permissões do Dataflow.

  • O Cloud Data Loss Prevention (Cloud DLP) verifica os dados armazenados no BigQuery para encontrar dados confidenciais que não estejam protegidos. Para mais informações, consulte Como usar o Cloud DLP para verificar dados do BigQuery.

  • O Cloud HSM hospeda a chave de criptografia de chaves (KEK). O Cloud HSM é um serviço Módulo de segurança de hardware (HSM, na sigla em inglês) baseado na nuvem. Use o Cloud HSM para gerar a chave de criptografia que você usa para criptografar os dados na sua rede antes de enviá-los para o Google Cloud.

  • O Data Catalog categoriza automaticamente os dados confidenciais com metadados, também conhecidos como tags de política, quando são descobertos no BigQuery. O Data Catalog também usa metadados para gerenciar o acesso a dados confidenciais. Para mais informações, consulte Visão geral do Data Catalog. Para controlar o acesso aos dados no data warehouse, aplique tags de política a colunas que incluam dados confidenciais.

  • O BigQuery armazena os dados criptografados e a chave de criptografia encapsulada em tabelas separadas.

    O BigQuery usa vários controles de segurança para ajudar a proteger o conteúdo, incluindo controles de acesso, criptografia no nível de coluna, nível de segurança e criptografia de dados.

  • O Security Command Center monitora e analisa as descobertas de segurança em todo o ambiente do Google Cloud em um só local.

  • O Cloud Logging coleta todos os registros dos serviços do Google Cloud para armazenamento e recuperação pelas ferramentas de análise e investigação.

  • O Cloud Monitoring coleta e armazena informações de desempenho e métricas sobre os serviços do Google Cloud.

  • O Data Profiler para BigQuery verifica automaticamente dados confidenciais em todas as tabelas e colunas do BigQuery em toda a organização, incluindo todas as pastas e projetos.

Estrutura da organização

Você agrupa os recursos da sua organização para gerenciá-los e separar os ambientes de teste do ambiente de produção. O Resource Manager permite agrupar logicamente recursos por projeto, pasta e organização.

Veja no diagrama a seguir uma hierarquia de recursos com pastas que representam diferentes ambientes, como bootstrap, comum, produção, não produção (ou preparo) e desenvolvimento. Essa hierarquia está alinhada com a estrutura organizacional usada pelo blueprint de bases empresariais. Você implanta a maioria dos projetos no blueprint na pasta de produção e o projeto de governança de dados na pasta comum usada para governança.

A hierarquia de recursos para um data warehouse seguro para redes externas.

Para hierarquias alternativas de recursos, consulte Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud.

Pastas

Use pastas para isolar o ambiente de produção e os serviços de governança dos ambientes de não produção e teste. A tabela a seguir descreve as pastas do blueprint de bases empresariais que são usadas por esse blueprint.

Pasta Descrição
Inicializar Contém os recursos necessários para implantar o blueprint de bases empresariais.
Nome Contêm serviços centralizados para a organização, como o projeto de governança de dados.
Produção Contém projetos que têm recursos de nuvem testados e prontos para uso. Nesse blueprint, a pasta "Produção" contém o projeto de ingestão de dados e o projeto de dados.
Não produção Contém projetos com recursos de nuvem em teste e preparo para lançamento. Nesse blueprint, a pasta "Não produção" contém o projeto de ingestão de dados e o projeto de dados.
Desenvolvimento Contém projetos que têm recursos de nuvem que estão sendo desenvolvidos no momento. Nesse blueprint, a pasta "Desenvolvimento" contém o projeto de ingestão de dados e o projeto de dados.

Altere os nomes dessas pastas para alinhá-las à estrutura de pastas da sua organização, mas recomendamos manter uma estrutura semelhante. Para mais informações, consulte o Blueprint de bases empresariais do Google Cloud.

Projetos

Isolar partes do ambiente usando projetos. A tabela a seguir descreve os projetos necessários na organização. Você cria esses projetos ao executar o código do Terraform. É possível alterar os nomes desses projetos, mas recomendamos que você mantenha uma estrutura de projeto semelhante.

Projeto Descrição
Ingestão de dados Contém serviços necessários para receber dados e gravá-los no BigQuery.
Governança de dados Contém serviços que oferecem recursos de gerenciamento de chaves, geração de registros e catalogação de dados.
Dados Contém serviços necessários para armazenar dados.

Além desses projetos, o ambiente também precisa incluir um projeto que hospede um job Flex Template do Dataflow. O job de modelo flexível é necessário para o pipeline de dados de streaming.

Como mapear papéis e grupos para projetos

Você precisa conceder a diferentes grupos de usuários da sua organização acesso aos projetos que compõem o data warehouse confidencial. As seções a seguir descrevem as recomendações de blueprints para grupos de usuários e atribuições de papéis nos projetos que você criar. É possível personalizar os grupos para que correspondam à estrutura da sua organização. No entanto, recomendamos que você mantenha uma segregação semelhante das tarefas e da atribuição de funções.

Grupo de analistas de dados

Os analistas de dados visualizam e analisam os dados no armazenamento. Esse grupo pode visualizar dados depois de serem carregados no data warehouse e realizar as mesmas operações que o grupo de visualizador de dados criptografados. Esse grupo requer papéis em diferentes projetos, conforme descrito na tabela a seguir.

Escopo da atribuição Papéis
Projeto de ingestão de dados
Projeto de dados
Nível da política de dados Leitor mascarado (roles/bigquerydatapolicy.maskedReader)

Grupo de leitores de dados criptografados

O grupo de visualizador de dados criptografados pode visualizar dados criptografados das tabelas de relatórios do BigQuery por meio do Cloud Looker Studio e de outras ferramentas de relatórios, como o SAP Business Objects. O grupo de visualizadores de dados criptografados não pode visualizar dados de texto não criptografado de colunas criptografadas.

Esse grupo requer o papel de usuário do BigQuery (roles/bigquery.jobUser) no projeto de dados. Esse grupo também requer o leitor mascarado (roles/bigquerydatapolicy.maskedReader) no nível da política de dados.

Grupo de leitores de texto simples

O grupo de leitor de texto simples tem a permissão necessária para chamar a função de descriptografia definida pelo usuário (UDF, na sigla em inglês) para visualizar dados de texto simples e a permissão extra para ler dados não mascarados. Esse grupo exige papéis no projeto de dados, conforme descrito na tabela a seguir.

Esse grupo exige os seguintes papéis no projeto de dados:

Além disso, esse grupo exige o papel Leitor refinado (roles/datacatalog.categoryFineGrainedReader) no nível do Data Catalog.

Grupo de engenheiros de dados

Engenheiros de dados configuram e mantêm o pipeline de dados e o armazenamento. Esse grupo requer papéis em diferentes projetos, conforme descrito na tabela a seguir.

Escopo da atribuição Papéis
Projeto de ingestão de dados
Projeto de dados
  • Editor de dados do BigQuery (roles/bigquery.dataeditor)
  • Usuário de jobs do BigQuery (roles/bigquery.jobUser)
  • Editor do Cloud Build (roles/cloudbuild.builds.editor)
  • Leitor do Cloud KMS (roles/cloudkms.viewer)
  • Usuário da rede do Compute (roles/compute.networkuser)
  • Administrador do Dataflow (roles/dataflow.admin)
  • Administrador do DLP (roles/dlp.admin)
  • Visualizador de registros (roles/logging.viewer)

Grupo de administradores de rede

Os administradores de rede configuram a rede. Normalmente, eles fazem parte da equipe de rede.

Os administradores de rede exigem os seguintes papéis no nível da organização:

  • Administrador do Compute (roles/compute.networkAdmin)
  • Visualizador de registros (roles/logging.viewer)

Grupo de administradores de segurança

Os administradores de segurança administram os controles de segurança, como o acesso, as chaves, as regras de firewall, o VPC Service Controls e o Security Command Center.

Os administradores de segurança exigem os seguintes papéis no nível da organização:

Grupo de analistas de segurança

Os analistas de segurança monitoram e respondem a incidentes de segurança e descobertas do Cloud DLP.

Os analistas de segurança exigem os seguintes papéis no nível da organização:

Exemplos de fluxos de acesso ao grupo

Nas seções a seguir, descrevemos os fluxos de acesso para dois grupos na solução de data warehouse segura.

Fluxo de acesso para o grupo do visualizador de dados criptografados

O diagrama a seguir mostra o que ocorre quando um usuário do grupo de visualizador de dados criptografados tenta acessar dados criptografados no BigQuery.

O fluxo para o grupo do visualizador de dados criptografados.

As etapas para acessar dados no BigQuery são as seguintes:

  1. O visualizador de dados criptografados executa a seguinte consulta no BigQuery para acessar dados confidenciais:

    SELECT ssn, pan FROM cc_card_table

  2. O BigQuery verifica o acesso da seguinte maneira:

    • O usuário é autenticado usando credenciais válidas e não expiradas do Google Cloud.
    • A identidade do usuário e o endereço IP de origem da solicitação fazem parte da lista de permissões na regra de nível de acesso/entrada no perímetro do VPC Service Controls.
    • O IAM verifica se o usuário tem os papéis apropriados e está autorizado a acessar as colunas criptografadas selecionadas na tabela do BigQuery.

O BigQuery retorna os dados confidenciais em formato criptografado.

Fluxo de acesso para o grupo de leitor de texto simples

O diagrama a seguir mostra o que ocorre quando um usuário do grupo de leitores de texto simples tenta acessar dados criptografados no BigQuery.

O fluxo do grupo de leitor de texto simples.

As etapas para acessar dados no BigQuery são as seguintes:

  1. O leitor de texto simples executa a seguinte consulta no BigQuery para acessar dados confidenciais no formato descriptografado:

    SELECT decrypt_ssn(ssn) FROM cc_card_table

  2. O BigQuery chama a função definida pelo usuário (UDF, na sigla em inglês) na consulta para acessar colunas protegidas.

  3. O acesso é verificado da seguinte maneira:

    • O IAM verifica se o usuário tem papéis apropriados e está autorizado a acessar a UDF de descriptografia no BigQuery.
    • A UDF recupera a chave de criptografia de dados (DEK) incorporada que foi usada para proteger colunas de dados confidenciais.

    A UDF descriptografada chama a chave de criptografia de chaves (KEK) no Cloud HSM para desencapsular a DEK. A UDF descriptografada usa a função de descriptografia AEAD do BigQuery para descriptografar as colunas de dados confidenciais.

  4. O usuário recebe acesso aos dados em texto simples nas colunas de dados confidenciais.

Noções básicas dos controles de segurança necessários

Nesta seção, discutiremos os controles de segurança do Google Cloud que você usa para proteger o data warehouse. Os princípios básicos de segurança a serem considerados são os seguintes:

  • Proteja o acesso adotando princípios de privilégio mínimo.
  • Conexões de rede seguras por meio da concepção e políticas de segmentação.
  • Proteja a configuração de cada um dos serviços.
  • Classificar e proteger dados com base no nível de risco.
  • Entenda os requisitos de segurança do ambiente que hospeda o data warehouse.
  • Configure o monitoramento e a geração de registros suficientes para detecção, investigação e resposta.

Controles de segurança para ingestão de dados

Para criar o data warehouse, você precisa transferir dados de outra origem no ambiente local, de outra nuvem ou de outra fonte do Google Cloud. Este documento se concentra na transferência de dados do seu ambiente local ou de outra nuvem. Se você estiver transferindo dados de outra fonte do Google Cloud, consulte Importar dados do Google Cloud para um data warehouse seguro do BigQuery.

Use uma das opções a seguir para transferir dados para o data warehouse no BigQuery:

  • Um job em lote que carrega dados em um bucket do Cloud Storage.
  • Um job de streaming que use o Pub/Sub.

Para ajudar a proteger os dados durante a ingestão, é possível usar a criptografia do lado do cliente, regras de firewall e políticas de nível de acesso. Em alguns casos, o processo de ingestão é chamado de processo de extração, transformação e carregamento (ETL).

Conexão criptografada com o Google Cloud

Use o Cloud VPN ou o Cloud Interconnect para proteger todos os dados que fluem entre o Google Cloud e seu ambiente. Esse blueprint recomenda a Interconexão dedicada, porque fornece uma conexão direta e uma alta capacidade, o que é importante se você estiver transmitindo muitos dados.

Para permitir o acesso ao Google Cloud a partir do seu ambiente, é preciso definir endereços IP permitidos nas regras da política de níveis de acesso.

Regras de rede e firewall

Regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados nos perímetros. Você cria regras de firewall que negam todas as saídas, exceto para conexões de porta TCP 443 específicas dos nomes de domínio especiais restricted.googleapis.com. O domínio restricted.googleapis.com tem os seguintes benefícios:

  • Ele reduz a superfície de ataque à rede usando o Acesso privado do Google quando as cargas de trabalho se comunicam com os serviços e as APIs.
  • Isso garante que você use apenas serviços compatíveis com o VPC Service Controls.

Para mais informações, consulte Como configurar o acesso particular do Google.

O pipeline de dados exige que você abra portas TCP no firewall, conforme definido no arquivo dataflow_firewall.tf (em inglês) no repositório Módulo de arcabouço de projetos. Para mais informações, consulte Como configurar o acesso à Internet e as regras de firewall.

Para impedir que os recursos usem endereços IP externos, a política da organização Definir IPs externos permitidos para instâncias de VM (compute.vmExternalIpAccess) está definida para negar tudo.

Controles de perímetro

Conforme mostrado no diagrama de arquitetura, você coloca os recursos do data warehouse em perímetros separados. Para permitir que serviços em diferentes perímetros compartilhem dados, crie pontes do perímetro.

Pontes do perímetro permitem que os serviços protegidos façam solicitações de recursos fora do perímetro. Essas pontes fazem as seguintes conexões:

  • Elas conectam o projeto de ingestão de dados ao projeto de dados para que os dados possam ser ingeridos no BigQuery.
  • Elas conectam o projeto de dados ao projeto de governança de dados para que o Cloud DLP possa verificar o BigQuery em busca de dados confidenciais desprotegidos.
  • Elas conectam o projeto de ingestão de dados ao projeto de governança de dados para acessar as chaves de geração de registros, monitoramento e criptografia.

Além das pontes do perímetro, use regras de saída para permitir que os recursos protegidos por perímetros acessem recursos que estão fora do perímetro. Nesta solução, você configura regras de saída para conseguir os jobs externos de modelo flexível do Dataflow localizados no Cloud Storage em um projeto externo. Para mais informações, consulte Acessar um recurso do Google Cloud fora do perímetro.

Política de acesso

Para garantir que apenas identidades específicas (usuários ou serviços) possam acessar recursos e dados, ative os grupos e os papéis do IAM.

Para garantir que apenas fontes específicas possam acessar seus projetos, ative uma política de acesso para sua organização do Google. Recomendamos que você crie uma política de acesso que especifique o intervalo de endereços IP permitido para solicitações provenientes do seu ambiente local e que permita apenas solicitações de usuários ou contas de serviço específicos. Para mais informações, consulte Atributos de nível de acesso.

Criptografia do lado do cliente

Antes de mover seus dados confidenciais para o Google Cloud, criptografe seus dados localmente para protegê-los em repouso e em trânsito. É possível usar a biblioteca de criptografia Tink ou outras bibliotecas de criptografia. A biblioteca de criptografia Tink é compatível com a criptografia AEAD do BigQuery, que o blueprint usa para descriptografar dados criptografados no nível da coluna após a importação dos dados.

A biblioteca de criptografia Tink usa DEKs geradas automaticamente ou no Cloud HSM. Para encapsular ou proteger a DEK, use uma KEK gerada no Cloud HSM. A KEK é um conjunto de chaves de criptografia CMEK simétrica que é armazenada com segurança no Cloud HSM e gerenciada com o uso de papéis e permissões do IAM.

Durante o processamento, a DEK encapsulada e os dados são armazenados no BigQuery. O BigQuery inclui duas tabelas: uma para os dados e outra para a DEK encapsulada. Quando os analistas precisam visualizar dados confidenciais, o BigQuery pode usar a descriptografia AEAD para decodificar a DEK com a KEK e descriptografar a coluna protegida.

Além disso, a criptografia no cliente usando o Tink protege ainda mais seus dados por meio da criptografia de colunas de dados confidenciais no BigQuery. O blueprint usa as seguintes chaves de criptografia do Cloud HSM:

  • Uma chave CMEK para o processo de ingestão que também é usado pelo Pub/Sub, pipeline do Dataflow para streaming, upload em lote do Cloud Storage e artefatos do Cloud Functions para uploads em lote subsequentes.
  • A chave criptográfica encapsulada pelo Cloud HSM para os dados criptografados na sua rede usando o Tink.
  • Chave CMEK para o armazenamento do BigQuery no projeto de dados.

Especifique o local da CMEK, que determina a localização geográfica em que a chave é armazenada e fica disponível para acesso. É preciso garantir que a CMEK esteja no mesmo local que os recursos. Por padrão, as CMEKs são alternadas a cada 30 dias.

Se as obrigações de compliance da sua organização exigirem o gerenciamento externo das suas próprias chaves no Google Cloud, será possível ativar o Gerenciador de chaves externo do Cloud. Ao usar chaves externas, você será responsável pelas atividades de gerenciamento, incluindo a rotação de chaves.

Contas de serviço e controles de acesso

As contas de serviço são identidades que o Google Cloud pode usar para executar solicitações de API em seu nome. As contas de serviço garantem que as identidades dos usuários não tenham acesso direto aos serviços. Para permitir a separação de tarefas, crie contas de serviço com papéis diferentes para fins específicos. Essas contas de serviço são definidas nos módulos data-ingestion-sa e data-governance-sa.

As contas de serviço são as seguintes:

  • A conta de serviço do Cloud Storage executa o processo automatizado de upload de dados em lote para o bucket de armazenamento de ingestão.
  • A conta de serviço do Pub/Sub permite o streaming de dados para o serviço do Pub/Sub.
  • A conta de serviço do controlador do Dataflow é usada pelo pipeline do Dataflow para transformar e gravar dados do Pub/Sub no BigQuery.
  • A conta de serviço do Cloud Functions grava dados em lote subsequentes enviados do Cloud Storage para o BigQuery.
  • A conta de serviço de upload do Storage permite que o pipeline de ETL crie objetos.
  • A conta de serviço de gravação do Pub/Sub permite que o pipeline de ETL grave dados no Pub/Sub.

A tabela a seguir lista os papéis que são atribuídos a cada conta de serviço:

Nome Papéis Escopo da atribuição
Conta de serviço do controlador do Dataflow Projeto de ingestão de dados
Projeto de dados
Governança de dados
Conta de serviço do Cloud Functions Projeto de ingestão de dados
  • Editor de dados do BigQuery (roles/bigquery.dataEditor)
  • Leitor de metadados do BigQuery (roles/bigquery.metadataViewer)
 Projeto de dados
Conta de serviço de upload do Storage Projeto de ingestão de dados
Conta de serviço de gravação do Pub/Sub Projeto de ingestão de dados

Controles de segurança para data warehouse

Configure os seguintes controles de segurança para ajudar a proteger dados no armazenamento do BigQuery:

  • Controles de acesso no nível da coluna
  • Contas de serviço com papéis limitados
  • Mascaramento dinâmico de dados de campos confidenciais
  • Políticas da organização
  • Verificação automática e criador de perfil de dados do Cloud DLP
  • Perímetros do VPC Service Controls entre o projeto de ingestão de dados e o projeto de dados, com pontes do perímetro apropriadas
  • Criptografia e gerenciamento de chaves, da seguinte maneira:
    • Criptografia em repouso com chaves CMEK armazenadas no Cloud HSM
    • Criptografia no nível da coluna usando Tink e AEAD

Mascaramento de dados dinâmico

Para ajudar no compartilhamento e na aplicação de políticas de acesso a dados em grande escala, configure a máscara de dados dinâmica. Com a máscara de dados dinâmica, as consultas podem mascarar automaticamente os dados da coluna usando os seguintes critérios:

  • As regras de mascaramento aplicadas à coluna no tempo de execução da consulta.
  • Os papéis atribuídos ao usuário que está executando a consulta. Para acessar dados de coluna não mascarados, o analista de dados precisa ter o papel Leitor refinado.

Para definir o acesso de colunas no BigQuery, crie tags de política. Por exemplo, a taxonomia criada no exemplo autônomo cria a tag de política 1_Sensitive para colunas que incluem dados que não podem ser publicados, como o limite de crédito. A regra de mascaramento de dados padrão é aplicada a essas colunas para ocultar o valor da coluna.

Qualquer item que não esteja marcado com tag estará disponível para todos os usuários com acesso ao data warehouse. Esses controles de acesso garantem que, mesmo após a gravação dos dados no BigQuery, eles não possam ser lidos até que o acesso seja explicitamente concedido ao usuário.

Criptografia e descriptografia no nível da coluna

A criptografia no nível da coluna permite criptografar dados no BigQuery em um nível mais granular. Em vez de criptografar uma tabela inteira, você seleciona as colunas que contêm dados confidenciais no BigQuery, e apenas essas colunas são criptografadas. O BigQuery usa funções de criptografia e descriptografia AEAD que criam os conjuntos de chaves que contêm as chaves para criptografia e descriptografia. Essas chaves são então usadas para criptografar e descriptografar valores individuais em uma tabela e fazer a rotação de chaves dentro de um conjunto de chaves. A criptografia no nível da coluna oferece controle de acesso duplo sobre dados criptografados no BigQuery, porque o usuário precisa ter permissões na tabela e na chave de criptografia para ler dados em texto não criptografado.

Data Profiler para BigQuery com o Cloud DLP

O Data Profiler permite identificar as localizações de dados confidenciais e de alto risco nas tabelas do BigQuery. O Data Profiler verifica e analisa automaticamente todas as tabelas e colunas do BigQuery em toda a organização, incluindo todas as pastas e projetos. Em seguida, o criador de perfil de dados gera métricas como os infoTypes previstos, os níveis de risco e confidencialidade dos dados avaliados e os metadados sobre as tabelas. Com esses insights, é possível tomar decisões fundamentadas sobre como proteger, compartilhar e usar seus dados.

Contas de serviço com papéis limitados

Você precisa limitar o acesso ao projeto de dados para que apenas usuários autorizados possam visualizar os campos de dados confidenciais. Para fazer isso, crie uma conta de serviço com o papel roles/iam.serviceAccountUser que os usuários autorizados precisam personificar. A representação da conta de serviço ajuda os usuários a usar contas de serviço sem fazer o download das chaves da conta de serviço, o que melhora a segurança geral do projeto. A representação cria um token de curto prazo que tem permissão para fazer o download de usuários autorizados com o papel roles/iam.serviceAccountTokenCreator.

Políticas da organização

Esse blueprint inclui as restrições da política da organização que o blueprint de bases empresariais usa e adiciona mais restrições. Para mais informações sobre as restrições usadas pelo blueprint de bases empresariais, consulte Restrições da política da organização.

A tabela a seguir descreve as restrições adicionais de políticas organizacionais definidas no módulo organization-policies.

Política Nome da restrição Valor recomendado
Restringir implantações de recursos a locais físicos específicos. gcp.resourceLocations Opções:
in:us-locations
in:eu-locations
in:asia-locations
Exigir proteção de CMEK gcp.restrictNonCmekServices bigquery.googleapis.com
Desativar criação de conta de serviço iam.disableServiceAccountCreation verdadeiro
Desative criação de chave da conta de serviço disableServiceAccountKeyCreation verdadeiro
Ative o Login do SO nas VMs criadas no projeto. compute.requireOsLogin verdadeiro
Desative concessões de papel automáticas para contas de serviço padrão automaticIamGrantsForDefaultServiceAccounts verdadeiro
Configurações de saída permitidas (Cloud Functions) cloudfunctions.allowedIngressSettings ALLOW_INTERNAL_AND_GCLB
Restrinja as novas regras de encaminhamento para que sejam apenas internas com base no endereço IP. compute.restrictProtocolForwardingCreationForTypes INTERNAL
Desative a geração de registros de saída da porta serial para o Cloud Logging compute.disableSerialPortLogging true
Defina o conjunto de sub-redes VPC compartilhadas que os recursos do Compute Engine podem usar. compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/subnetworks/SUBNETWORK-NAME

Substitua SUBNETWORK-NAME pelo ID do recurso da sub-rede particular que você quer que o blueprint use.

Controles operacionais

É possível ativar a geração de registros e os recursos do nível Premium do Security Command Center Premium, como análise de integridade de segurança e detecção de ameaças. Esses controles ajudam você a fazer o seguinte:

  • Monitore quem está acessando seus dados.
  • Confira se a auditoria foi realizada de maneira adequada.
  • Gerar descobertas para recursos de nuvem configurados incorretamente
  • Ofereça suporte às equipes de gerenciamento e operações de incidentes para responder a problemas que possam ocorrer.

Transparência no acesso

A transparência no acesso fornece uma notificação em tempo real caso os suportes do Google precisem de acesso aos seus dados. Os registros de transparência no acesso são gerados sempre que uma pessoa acessa o conteúdo. Somente funcionários do Google com justificativas comerciais válidas (por exemplo, um caso de suporte) podem ter acesso. Recomendamos que você ative a Transparência no acesso.

Geração de registros

Para ajudar a atender aos requisitos de auditoria e receber insights sobre seus projetos, configure o Google Cloud Observability com registros de dados dos serviços que você quer rastrear. O módulo Harness-logging configura as seguintes práticas recomendadas:

Para todos os serviços nos projetos, os registros precisam incluir informações sobre leitura e gravação de dados e informações sobre a leitura dos administradores. Para outras práticas recomendadas de geração de registros, consulte Controles de detecção no blueprint de bases empresariais.

Alertas e monitoramento

Depois de implantar o blueprint, configure alertas para notificar a central de operações de segurança (SOC) que pode ocorrer um incidente de segurança. Por exemplo, é possível usar alertas para informar seu analista de segurança quando uma permissão do IAM for alterada. Para mais informações sobre como configurar alertas do Security Command Center, consulte Como configurar notificações de localização. Para alertas extras que não são publicados pelo Security Command Center, é possível configurar alertas com o Cloud Monitoring.

Outras considerações de segurança

Além dos controles de segurança descritos nesta solução, você precisa revisar e gerenciar a segurança e o risco em áreas importantes que se sobrepõem e interagem com o uso desta solução. Essas considerações de segurança incluem o seguinte:

  • A segurança do código usado para configurar, implantar e executar jobs do Dataflow e Cloud Functions.
  • Taxonomia de classificação de dados usada com esta solução.
  • Geração e gerenciamento de chaves de criptografia.
  • O conteúdo, a qualidade e a segurança dos conjuntos de dados que você armazena e analisa no data warehouse.
  • O ambiente geral em que você implanta a solução, incluindo o seguinte:
    • O design, a segmentação e a segurança das redes conectadas a esta solução.
    • A segurança e a governança dos controles do IAM da sua organização.
    • As configurações de autenticação e autorização dos agentes a quem você concede acesso à infraestrutura que faz parte desta solução e quem tem acesso aos dados armazenados e gerenciados nessa infraestrutura.

Resumo geral

Para implementar a arquitetura descrita neste documento, faça o seguinte:

  1. Determine se você implantará o blueprint com o blueprint de bases empresariais ou por conta própria. Se você optar por não implantar o blueprint de bases empresariais, verifique se o ambiente tem uma linha de base de segurança semelhante.
  2. Configure uma conexão do Dedicated Interconnect com sua rede.
  3. Leia o arquivo README do blueprint e verifique se você atende a todos os pré-requisitos.
  4. Verifique se a identidade do usuário tem os papéis iam.serviceAccountUser e iam.serviceAccountTokenCreator para a pasta de desenvolvimento da sua organização, conforme descrito em Estrutura da organização. Se você não tem uma pasta para testes, crie uma e configure o acesso.
  5. Registre o ID da conta de faturamento, o nome de exibição da organização, o ID da pasta de teste ou a pasta de demonstração e os endereços de e-mail dos seguintes grupos de usuários:
    • Analistas de dados
    • Visualizador de dados criptografados
    • Leitor de texto simples
    • Engenheiros de dados
    • Administradores de rede
    • Administradores de segurança
    • Analistas de segurança
  6. Criar os projetos de dados, governança de dados, ingestão de dados e modelo flexível. Para acesssar uma lista de APIs que você deve ativar, consulte o README.
  7. Crie a conta de serviço do Terraform e atribua os papéis apropriados a todos os projetos.
  8. Configure a política de controle de acesso.

  9. No ambiente de teste, implante a solução:

    1. Clone e execute os scripts do Terraform para configurar um ambiente no Google Cloud.
    2. Instale a biblioteca de criptografia Tink na sua rede.
    3. Configure o Application Default Credentials para executar a biblioteca do Tink na rede.
    4. Crie chaves de criptografia com o Cloud KMS.
    5. Gere conjuntos de chaves criptografados com o Tink.

    6. Criptografe dados com o Tink usando um dos seguintes métodos:

    7. Fazer upload de dados criptografados para o BigQuery usando streaming ou uploads em lote.

  10. Verifique se os usuários autorizados podem ler dados não criptografados do BigQuery usando a função de descriptografia AEAD do BigQuery. Por exemplo, execute a seguinte função de criação de descriptografia:

    CREATE OR REPLACE FUNCTION `{project_id}.{bigquery_dataset}.decrypt`(encodedText STRING) RETURNS STRING AS
(
AEAD.DECRYPT_STRING(
KEYS.KEYSET_CHAIN('gcp-kms://projects/myProject/locations/us/keyRings/myKeyRing/cryptoKeys/myKeyName', b'\012\044\000\321\054\306\036\026…..'),
FROM_BASE64(encodedText), "")
);

    Execute a consulta de criação de visualização:

    CREATE OR REPLACE VIEW `{project_id}.{bigquery_dataset}.decryption_view` AS

SELECT
 Card_Type_Code,
 Issuing_Bank,
 Card_Number,
 `bigquery_dataset.decrypt`(Card_Number) AS Card_Number_Decrypted
FROM `project_id.dataset.table_name`

    Execute a consulta de seleção na visualização:

    SELECT
  Card_Type_Code,
  Issuing_Bank,
  Card_Number,
  Card_Number_Decrypted
FROM
`{project_id}.{bigquery_dataset}.decrypted_view`

    Para mais consultas e casos de uso, consulte Criptografia no nível da coluna com o Cloud KMS.

  11. Use o Security Command Center para verificar os projetos recém-criados de acordo com seus requisitos de conformidade.

  12. Implante o blueprint no ambiente de produção.

A seguir