Muitas organizações implantam data warehouses que armazenam dados sensíveis para que possam analisar os dados para diversos fins comerciais. Este documento é destinado a engenheiros e administradores de segurança que implantam e protegem armazenamentos de dados usando o BigQuery. Ele faz parte de um blueprint composto pelo seguinte:
- Dois repositórios do GitHub
(
terraform-google-secured-data-warehouseeterraform-google-secured-data-warehouse-onprem-ingest) que contêm configurações e scripts do Terraform. A configuração do Terraform configura um ambiente no Google Cloud que oferece suporte a um data warehouse que armazena dados confidenciais. - Um guia para os controles de arquitetura, design e segurança desse blueprint (este documento).
- Um tutorial que implanta um ambiente de amostra.
Neste documento, você verá os seguintes tópicos:
- A arquitetura e os Google Cloud serviços 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:
Desidentificação de dados
tratamento diferencial de dados confidenciais
criptografia no nível da coluna
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. Ele ajuda você a sobrepor controles adicionais aos seus controles de segurança atuais para ajudar a proteger dados confidenciais em um data warehouse.
Casos de uso do data warehouse
O blueprint é compatível com os seguintes casos de uso:
- Use o repositório
terraform-google-secured-data-warehousepara importar dados de Google Cloud para um data warehouse do BigQuery - Use o repositório
terraform-google-secured-data-warehouse-onprem-ingestpara importar dados de um ambiente local ou de outra nuvem para um data warehouse do BigQuery
Visão geral
Data warehouses como o BigQuery permitem que as empresas analisem os dados comerciais para conseguir insights. Os analistas acessam os dados de negócios que estão armazenados nos data warehouses para criar insights. Se o data warehouse incluir dados confidenciais, você precisará tomar medidas para preservar a segurança, a confidencialidade, a integridade e a disponibilidade dos dados da empresa enquanto eles estão armazenados, em trânsito ou sendo analisados. Neste blueprint, você vai:
- Ao importar dados de fontes externas, criptografe os dados que estão fora do Google Cloud (por exemplo, em um ambiente local) e importe-os para Google Cloud.
- 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.
- Ao importar dados de outras fontes localizadas em Google Cloud (também conhecidas como fontes de dados internas), configure modelos para encontrar e desidentificar dados confidenciais.
- Configurar controles de segurança e registros apropriados para proteger 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.
Arquitetura ao importar dados de Google Cloud
A imagem a seguir mostra como os dados ingeridos são categorizados, desidentificados e
armazenados quando você importa dados de origem de Google Cloud usando o
repositório terraform-google-secured-data-warehouse. Você também vai aprender a
identificar novamente dados confidenciais sob demanda para análise.
Arquitetura ao importar dados de fontes externas
A imagem a seguir mostra como os dados são ingeridos e armazenados quando você importa dados de um ambiente local ou de outra nuvem para um data warehouse do BigQuery usando o repositório terraform-google-secured-data-warehouse-onprem-ingest.
Serviços e recursos doGoogle Cloud
As arquiteturas usam uma combinação dos seguintes serviços e recursos Google Cloud :
| Serviço ou recurso | Descrição |
|---|---|
Aplicável a fontes de dados internas e externas. No entanto, existem diferentes opções de armazenamento:
O BigQuery usa vários controles de segurança para ajudar a proteger o conteúdo, incluindo controles de acesso, segurança no nível da coluna para dados confidenciais e criptografia de dados. |
|
Cloud Key Management Service (Cloud KMS) com Cloud HSM |
Aplicável a fontes internas e externas. No entanto, existe outro caso de uso para fontes de dados externas. O Cloud HSM é um serviço de módulo de segurança de hardware (HSM) baseado na nuvem que hospeda a chave de criptografia de chaves (KEK). Ao importar dados de uma fonte externa, você usa o Cloud HSM para gerar a chave de criptografia que você usa para criptografar os dados na sua rede antes de enviá-los para Google Cloud. |
Aplicável a fontes internas e externas. 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. |
|
Aplicável a fontes internas e externas. O Cloud Monitoring coleta e armazena informações de desempenho e métricas sobre Google Cloud serviços. |
|
Aplicável apenas a fontes de dados externas. O Cloud Run functions é acionado pelo Cloud Storage e grava os dados que o Cloud Storage faz upload no bucket de ingestão no BigQuery. |
|
Aplicável a fontes internas e externas. O Cloud Storage e o Pub/Sub recebem dados da seguinte maneira:
|
|
Aplicável a fontes internas e externas. O Data Profiler para BigQuery verifica automaticamente dados sensíveis em todas as tabelas e colunas do BigQuery em toda a organização, incluindo todas as pastas e projetos. |
|
Pipelines do Dataflow |
Aplicável a fontes internas e externas. No entanto, existem pipelines diferentes. Os pipelines do Dataflow importam dados da seguinte maneira:
|
Aplicável a fontes internas e externas. O Dataplex Universal Catalog categoriza automaticamente dados confidenciais com metadados, também conhecidos como tags de política, durante o processamento. O Dataplex Universal Catalog também usa metadados para gerenciar o acesso a dados confidenciais. Para controlar o acesso aos dados no data warehouse, aplique tags de política a colunas que incluam dados confidenciais. |
|
Aplicável apenas a fontes de dados externas. Com a Interconexão dedicada, é possível 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. |
|
Aplicável a fontes internas e externas. O Identity and Access Management (IAM) e o Resource Manager restringem o acesso e segmentam recursos. A hierarquia de recursos e controles de acesso seguem o princípio de privilégio mínimo. |
|
Aplicável a fontes internas e externas. O Security Command Center monitora e analisa as descobertas de segurança em todo o ambiente do Google Cloud em um só local. |
|
Aplicável a fontes internas e externas. No entanto, diferentes verificações ocorrem. A Proteção de Dados Sensíveis verifica os dados da seguinte maneira:
|
|
Aplicável a fontes internas e externas. No entanto, existem diferentes perímetros. 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:
Eles são projetados para proteger o conteúdo recebido, isolar dados confidenciais configurando controles e monitoramento de 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. |
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.
Os diagramas a seguir mostram uma hierarquia de recursos com pastas que representam diferentes ambientes, como bootstrap, comum, produção, não produção (ou preparatório) e desenvolvimento. Você implanta a maioria dos projetos na arquitetura na pasta de produção e o projeto de governança de dados na pasta comum usada para governança.
Estrutura da organização ao importar dados de Google Cloud
O diagrama a seguir mostra a estrutura da organização ao importar dados de
Google Cloud usando o repositório terraform-google-secured-data-warehouse.
Estrutura da organização ao importar dados de fontes externas
O diagrama a seguir mostra a estrutura da organização ao importar dados de
uma fonte externa usando o
repositório terraform-google-secured-data-warehouse-onprem-ingest.
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 corporativas que são usadas por essa arquitetura.
| 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. Nessa arquitetura, a pasta "Production" contém o projeto de ingestão de dados e projetos relacionados a dados. |
Não produção |
Contém projetos com recursos de nuvem que estão sendo testados e preparados para lançamento. Nessa arquitetura, a pasta "Não produção" contém o projeto de ingestão de dados e projetos relacionados a dados. |
Desenvolvimento |
Contém projetos que têm recursos de nuvem que estão sendo desenvolvidos. Nessa arquitetura, a pasta "Desenvolvimento" contém o projeto de ingestão de dados e projetos relacionados a 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.
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 |
Projeto comum para fontes internas e externas. Contém serviços que são necessários para receber dados e desidentificar dados confidenciais. |
Governança de dados |
Projeto comum para fontes internas e externas. Contém serviços que oferecem recursos de gerenciamento de chaves, geração de registros e catalogação de dados. |
Dados não confidenciais |
Projeto apenas para fontes internas. Contém serviços que são necessários para armazenar dados que foram desidentificados. |
Dados confidenciais |
Projeto apenas para fontes internas. Contém serviços que são necessários para armazenar e reidentificar dados confidenciais. |
Dados |
Projeto apenas para fontes externas. 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 arquitetura 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
Analistas de dados analisam os dados no armazenamento. No repositório
terraform-google-secured-data-warehouse-onprem-ingest, esse grupo pode
visualizar dados depois que eles são carregados no data warehouse e realizar as mesmas
operações que o grupo de visualizador de dados criptografados.
A tabela a seguir descreve as funções do grupo em diferentes projetos para o
repositório terraform-google-secured-data-warehouse (somente fontes de dados internas).
| Mapeamento do projeto | Papéis |
|---|---|
Ingestão de dados |
Papel adicional para analistas de dados que exigem acesso a dados confidenciais: |
Dados confidenciais |
|
Dados não confidenciais |
A tabela a seguir descreve os papéis do grupo em diferentes projetos para o
repositório terraform-google-secured-data-warehouse-onprem-ingest (somente fontes de dados
externas).
| Escopo da atribuição | Papéis |
|---|---|
Projeto de ingestão de dados |
|
Projeto de dados |
|
Nível da política de dados |
Grupo de leitores de dados criptografados (somente fontes externas)
O grupo de visualizador de dados criptografados no repositório terraform-google-secured-data-warehouse-onprem-ingest pode acessar dados criptografados das tabelas de relatórios do BigQuery pelo Looker Studio e outras ferramentas de relatórios, como o SAP Business Objects.
O grupo de visualizadores de dados criptografados não pode acessar 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 exige o papel de Leitor mascarado
(roles/bigquerydatapolicy.maskedReader)
no nível da política de dados.
Grupo de leitores de texto simples (somente fontes externas)
O grupo de leitor de texto simples no repositório
terraform-google-secured-data-warehouse-onprem-ingest 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 os seguintes papéis no projeto de dados:
- Usuário do BigQuery (
roles/bigquery.user) - Usuário do BigQuery (
roles/bigquery.jobUser) - Leitor do Cloud KMS (
roles/cloudkms.viewer)
Além disso, esse grupo exige o papel Leitor refinado
(roles/datacatalog.categoryFineGrainedReader) no nível do
Dataplex Universal Catalog.
Grupo de engenheiros de dados
Engenheiros de dados configuram e mantêm o pipeline de dados e o armazenamento.
A tabela a seguir descreve as funções do grupo em diferentes projetos para o
repositório terraform-google-secured-data-warehouse.
| Pontuação da atividade | Papéis |
|---|---|
Projeto de ingestão de dados |
|
Projeto de dados confidenciais |
|
Projeto de dados não confidenciais |
A tabela a seguir descreve as funções do grupo em diferentes projetos para o
repositório terraform-google-secured-data-warehouse-onprem-ingest.
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:
- Administrador do Access Context Manager (
roles/accesscontextmanager.policyAdmin) - Leitor de recursos do Cloud (
roles/cloudasset.viewer) - Administrador do Cloud KMS (
roles/cloudkms.admin) - Administrador de segurança do Compute (
roles/compute.securityAdmin) - Administrador do Data Catalog (
roles/datacatalog.admin) - Administrador do DLP (
roles/dlp.admin) - Administrador do Logging (
roles/logging.admin) - Administrador da organização (
roles/orgpolicy.policyAdmin) - Administrador de segurança (
roles/iam.securityAdmin)
Grupo de analistas de segurança
Os analistas de segurança monitoram e respondem a incidentes de segurança e descobertas da proteção de dados sensíveis.
Os analistas de segurança exigem os seguintes papéis no nível da organização:
- Leitor Access Context Manager (
roles/accesscontextmanager.policyReader) - Leitor da rede do Compute (
roles/compute.networkViewer) - Leitor do Data Catalog (
roles/datacatalog.viewer) - Leitor do Cloud KMS (
roles/cloudkms.viewer) - Visualizador de registros (
roles/logging.viewer) - Leitor da política da organização (
roles/orgpolicy.policyViewer) - Leitor administrador da Central de segurança (
roles/securitycenter.adminViewer) - Editor de descobertas da Central de segurança(
roles/securitycenter.findingsEditor) - Um dos seguintes papéis do Security Command Center:
- Editor de desativação de som em massa de descobertas da Central de segurança (
roles/securitycenter.findingsBulkMuteEditor) - Configurador de desativação de som dos localizadores da Central de segurança (
roles/securitycenter.findingsMuteSetter) - Definidor de estado de descobertas da Central de segurança (
roles/securitycenter.findingsStateSetter)
- Editor de desativação de som em massa de descobertas da Central de segurança (
Exemplos de fluxos de acesso ao grupo para fontes externas
As seções a seguir descrevem os fluxos de acesso para dois grupos ao importar dados
de fontes externas usando o
repositório terraform-google-secured-data-warehouse-onprem-ingest.
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 visualizadores de dados criptografados tenta acessar dados criptografados no BigQuery.
As etapas para acessar dados no BigQuery são as seguintes:
O visualizador de dados criptografados executa a seguinte consulta no BigQuery para acessar dados confidenciais:
SELECT ssn, pan FROM cc_card_tableO BigQuery verifica o acesso da seguinte maneira:
- O usuário é autenticado usando credenciais Google Cloud válidas e não expiradas.
- 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 ou 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.
As etapas para acessar dados no BigQuery são as seguintes:
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_tableO BigQuery chama a função definida pelo usuário (UDF) na consulta para acessar colunas protegidas.
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 sensíveis.
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 sensíveis.
O usuário recebe acesso aos dados em texto simples nas colunas de dados confidenciais.
Controles de segurança comuns
As seções a seguir descrevem os controles que se aplicam a fontes internas e externas.
Controles de ingestão de dados
Para criar o data warehouse, é necessário transferir dados de outra fonteGoogle Cloud , como um data lake, do ambiente local ou de outra nuvem. Use uma das opções a seguir para transferir dados para o armazenamento de dados no BigQuery:
- Um job em lote que usa o 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).
Regras de rede e firewall
As 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.
Ao usar o repositório terraform-google-secured-data-warehouse, é necessário
configurar sub-redes separadas para cada job do Dataflow. Sub-redes
separadas garantem que os dados que estão sendo desidentificados sejam devidamente
separados dos dados que estão sendo reidentificados.
O pipeline de dados exige que você abra portas TCP no firewall, conforme definido no
arquivo dataflow_firewall.tf nos respectivos repositórios. Para mais
informações, consulte Como configurar o acesso à Internet e as
regras de firewall.
Para impedir que os recursos usem endereços IP externo, 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 para o repositório
terraform-google-secured-data-warehouse:
- Eles conectam o projeto de ingestão de dados ao projeto de governança para que a desidentificação possa ocorrer durante o processamento.
- Eles conectam o projeto de dados não confidenciais e o projeto de dados confidenciais para que esses dados possam ser identificados novamente quando um analista de dados os solicitar.
- Eles conectam o projeto confidencial ao projeto de governança de dados para que a reidentificação possa ocorrer quando um analista de dados solicitar.
Essas pontes fazem as seguintes conexões para o repositório
terraform-google-secured-data-warehouse-onprem-ingest:
- 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 a Proteção de dados sensíveis 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 de serviço 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 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 e 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.
Contas de serviço e controles de acesso
As contas de serviço são identidades que Google Cloud podem ser usadas 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 e confidential-data
em cada arquitetura.
Para o repositório terraform-google-secured-data-warehouse, as contas de serviço
são as seguintes:
- Uma conta de serviço do controlador do Dataflow para o pipeline do Dataflow que desidentifica dados confidenciais.
- Uma conta de serviço do controlador do Dataflow para o pipeline do Dataflow que reidentifica dados confidenciais.
- Uma conta de serviço do Cloud Storage para ingerir dados de um arquivo em lote.
- Uma conta de serviço do Pub/Sub para ingerir dados de um serviço de streaming.
- Uma conta de serviço do Cloud Scheduler para executar o job do Dataflow em lote que cria o pipeline do Dataflow.
A tabela a seguir lista os papéis que são atribuídos a cada conta de serviço:
Para o repositório terraform-google-secured-data-warehouse-onprem-ingest, 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 Run 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 Run functions |
Projeto de ingestão de dados |
|
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 |
Políticas organizacionais
Essa arquitetura 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 outras restrições
da política da organização definidas no módulo org_policies para os respectivos repositórios:
| Política | Nome da restrição | Valor recomendado |
|---|---|---|
Restringir implantações de recursos a locais físicos específicos. Para outros valores, consulte Grupos de valores. |
|
Uma das seguintes opções:
|
|
|
|
|
|
|
Restrinja as novas regras de encaminhamento para que sejam apenas internas com base no endereço IP. |
|
|
Defina o conjunto de VPC compartilhada compartilhadas que os recursos do Compute Engine podem usar. |
|
Substitua pelo ID do recurso da sub-rede particular que você quer que a arquitetura use. |
Desative a geração de registros de saída da porta serial para o Cloud Logging. |
|
|
Exigir
proteção de CMEK (somente
|
|
|
Desativar a criação de chaves da conta de serviço
( |
|
verdadeiro |
Ativar o Login do
SO nas VMs criadas no projeto
( |
|
verdadeiro |
Desative
concessões de papel automáticas para a conta de serviço padrão
( |
|
verdadeiro |
Configurações de entrada permitidas (funções do Cloud Run)
( |
|
|
Controles de segurança para fontes de dados externas
As seções a seguir descrevem os controles que se aplicam à ingestão de dados de fontes externas.
Conexão criptografada com Google Cloud
Ao importar dados de fontes externas, use o Cloud VPN ou o Cloud Interconnect para proteger todos os dados que fluem entre Google Cloud e seu ambiente. Essa arquitetura empresarial recomenda a Interconexão dedicada, porque ela fornece uma conexão direta e uma alta capacidade, o que é importante se você estiver transmitindo muitos dados.
Para permitir o acesso a Google Cloud no seu ambiente, é preciso definir endereços IP permitidos nas regras da política de níveis de acesso.
Criptografia do lado do cliente
Antes de mover seus dados sensíveis 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 do Tink é compatível com a criptografia AEAD do BigQuery, que a arquitetura usa para descriptografar dados criptografados no nível da coluna após a importação.
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 armazenado com segurança no Cloud HSM e gerenciado com 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. A arquitetura usa as seguintes chaves de criptografia do Cloud HSM:
- Uma chave CMEK para o processo de ingestão que também é usada pelo Pub/Sub, pipeline do Dataflow para streaming, upload em lote do Cloud Storage e artefatos do Cloud Run 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. Se você usar chaves externas, será responsável pelas atividades de gerenciamento, incluindo a rotação de chaves.
Mascaramento de dados dinâmico
Para ajudar no compartilhamento e na aplicação de políticas de acesso a dados em grande escala, configure o mascaramento de dados dinâmico. 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 de forma mais granular. Em vez de criptografar uma tabela inteira, você seleciona as colunas que contêm dados sensíveis 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 proteção de dados sensíveis
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.
Controles de segurança para fontes de dados internas
As seções a seguir descrevem os controles que se aplicam à ingestão de dados de fontesGoogle Cloud .
Gerenciamento e criptografia de chaves para processamento
Ambas as opções de transferência (Cloud Storage ou Pub/Sub) usam o Cloud HSM para gerenciar a CMEK. Você usa as chaves CMEK para ajudar a proteger seus dados durante o processamento. A Proteção de Dados Sensíveis protege ainda mais seus dados criptografando dados confidenciais com os detectores que você configura.
Para ingerir dados, use as seguintes chaves de criptografia:
- Uma chave CMEK para o processo de ingestão que também é usada pelo pipeline do Dataflow e pelo serviço Pub/Sub.
- A chave criptográfica encapsulada pelo Cloud HSM para o processo de desidentificação de dados usando a Proteção de dados sensíveis.
- Duas chaves CMEK, uma para o data warehouse do BigQuery no projeto de dados não confidenciais e outra para o data warehouse no projeto de dados confidenciais. Para mais informações, consulte Gerenciamento de chaves.
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 EKM do Cloud. Se você usar chaves externas, será responsável pelas atividades de gerenciamento de chaves, incluindo a rotação de chaves.
Desidentificação de dados
Você usa a Proteção de Dados Sensíveis para desidentificar os dados estruturados e não estruturados durante a fase de ingestão. Para dados estruturados, você usa
transformações de
registro
com base em campos para desidentificar dados. Para conferir um exemplo dessa abordagem, consulte a
pasta
/examples/de_identification_template/. Este exemplo verifica os dados estruturados em busca de números de cartão de crédito
e PINs de cartão. Para dados não estruturados, use tipos de
informações
para desidentificar dados.
Para desidentificar dados marcados como confidenciais, use a proteção de dados sensíveis e um pipeline do Dataflow para tokenizá-los. Esse pipeline processa os dados do Cloud Storage e os envia para o data warehouse do BigQuery.
Para mais informações sobre o processo de desidentificação de dados, consulte governança de dados.
Controles de acesso no nível da coluna
Para ajudar a proteger dados confidenciais, use controles de acesso para colunas específicas no armazém do BigQuery. Para acessar os dados nessas colunas, um analista de dados precisa ter a função Leitor refinado.
Para definir o acesso de colunas no BigQuery, crie tags de
política. Por
exemplo, o arquivo taxonomy.tf no módulo
exemplo bigquery-confidential-data
cria as seguintes tags:
- Uma tag de política
3_Confidentialpara colunas com informações muito confidenciais, como números de cartão de crédito. Os usuários que têm acesso a essa tag também têm acesso a colunas marcadas com as tags de política2_Privateou1_Sensitive. - Uma tag de política
2_Privatepara colunas que incluem informações sensíveis de identificação pessoal (PII), como o nome de uma pessoa. Os usuários que têm acesso a essa tag também têm acesso a colunas marcadas com a tag de política1_Sensitive. Os usuários não têm acesso a colunas marcadas com a tag de política3_Confidential. - Uma tag de política
1_Sensitivepara colunas que incluem dados que não podem ser publicados, como o limite de crédito. Os usuários que têm acesso a essa tag não têm acesso a colunas marcadas com as tags de política2_Privateou3_Confidential.
Tudo o que não estiver marcado estará disponível para todos os usuários com acesso ao data warehouse.
Esses controles de acesso garantem que, mesmo depois da nova identificação, os dados não possam ser lidos até que o acesso seja explicitamente concedido ao usuário.
Observação: use as definições padrão para executar os exemplos. Para mais práticas recomendadas, consulte Práticas recomendadas para uso de tags de política no BigQuery.
Contas de serviço com papéis limitados
Você precisa limitar o acesso ao projeto de dados confidenciais para que apenas usuários autorizados
possam visualizar os dados confidenciais. Para fazer isso, crie uma conta de serviço
com o papel Usuário da conta de serviço (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
Criador de token da conta de serviço (roles/iam.serviceAccountTokenCreator).
Gerenciamento e criptografia de chaves para armazenamento e reidentificação
Gerencie chaves CMEK separadas para seus dados confidenciais para poder reidentificar os dados. Use o Cloud HSM para proteger as chaves. Para reidentificar seus dados, use as seguintes chaves:
- Uma chave CMEK usada pelo pipeline do Dataflow para o processo de reidentificação.
- A chave criptográfica original que a Proteção de dados confidenciais usa para desidentificar seus dados.
- Uma chave CMEK para o armazenamento do BigQuery no projeto de dados confidenciais.
Como mencionado em Gerenciamento de chaves e criptografia para ingestão, é possível especificar os períodos de CMEK e localização do CMEK. É possível usar o Cloud EKM se ele for exigido pela organização.
Operações
É possível ativar a geração de registros e os recursos do nível Premium ou Enterprise do Security Command Center, como a análise de integridade de segurança e a 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 oferece uma notificação em tempo real quando os suportes do Google precisam 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.
Logging
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 centralized-logging
nos repositórios configura as seguintes práticas recomendadas:
- Criação de um coletor de registros agregado em todos os projetos.
- Armazenamento dos registros na região adequada.
- Como adicionar chaves CMEK no coletor de registros.
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.
Alertas e monitoramento
Depois de implantar a arquitetura, configure alertas para notificar a central de operações de segurança (SOC) de que pode estar ocorrendo 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 neste documento, você precisa analisar e gerenciar a segurança e o risco em áreas importantes que se sobrepõem e interagem com o uso desta solução. Isso inclui o seguinte:
- A segurança do código usado para configurar, implantar e executar jobs do Dataflow e Cloud Run 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 que têm acesso aos dados armazenados e gerenciados nessa infraestrutura.
resumo geral
Para implementar a arquitetura descrita neste documento, faça o seguinte:
- Determine se você vai implantar a arquitetura 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.
- Para importar dados de fontes externas, configure uma conexão de Interconexão dedicada com sua rede.
- Leia o arquivo
terraform-google-secured-data-warehouseREADME ou o arquivoterraform-google-secured-data-warehouse-onprem-ingestREADME e verifique se você atende a todos os pré-requisitos. Verifique se a identidade do usuário tem os papéis Usuário da conta de serviço (
roles/iam.serviceAccountUser) e Criador de token da conta de serviço (roles/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 pasta e configure o acesso.Registre o ID da conta de faturamento, o nome de exibição da organização, o ID da pasta de teste ou 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
Crie os projetos. Para conferir uma lista de APIs que você precisa ativar, consulte o README.
Crie a conta de serviço do Terraform e atribua os papéis apropriados a todos os projetos.
Configure a política de controle de acesso.
Para Google Cloud fontes de dados que usam o repositório
terraform-google-secured-data-warehouse, implante o tutorial no ambiente de teste para conferir a solução em ação. Como parte do processo de teste, considere o seguinte:- Adicione seus próprios dados de amostra ao armazenamento do BigQuery.
- Trabalhe com um analista de dados na sua empresa para testar o acesso dele aos dados confidenciais e se eles podem interagir com os dados do BigQuery da maneira esperada.
Para fontes de dados externas que usam o repositório
terraform-google-secured-data-warehouse-onprem-ingest, implante a solução no ambiente de teste:- Clone e execute os scripts do Terraform para configurar um ambiente no Google Cloud.
Instale a biblioteca de criptografia do Tink na sua rede.
Configure o Application Default Credentials para executar a biblioteca do Tink na rede.
Crie chaves de criptografia com o Cloud KMS.
Gerar conjuntos de chaves criptografados com o Tink.
Criptografe dados com o Tink usando um dos seguintes métodos:
- Usar criptografia determinística.
- Usar um script auxiliar com dados de exemplo.
Faça upload de dados criptografados para o BigQuery usando streaming ou uploads em lote.
Para fontes de dados externas, 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:
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.
Use o Security Command Center para verificar os projetos recém-criados de acordo com seus requisitos de conformidade.
Implante a arquitetura no ambiente de produção.
A seguir
- Consulte o blueprint de bases empresariais para um ambiente seguro de referência.
- Para conferir os detalhes da arquitetura, leia o README da configuração do Terraform
para fontes de dados internas (repositório
terraform-google-secured-data-warehouse) ou o README da configuração do Terraform para fontes de dados externas (repositórioterraform-google-secured-data-warehouse-onprem-ingest).