Muitas organizações implementam armazéns de dados que armazenam dados confidenciais para poderem analisar os dados para vários fins empresariais. Este documento destina-se a engenheiros de dados e administradores de segurança que implementam e protegem armazéns de dados através do BigQuery. Faz parte de um plano que é 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 que Google Cloud suporta um armazém de dados que armazena dados confidenciais. - Um guia para a arquitetura, a conceção e os controlos de segurança deste projeto (este documento).
- Um passo a passo que implementa um ambiente de exemplo.
Este documento aborda o seguinte:
- A arquitetura e os Google Cloud serviços que pode usar para ajudar a proteger um armazém de dados num ambiente de produção.
- Práticas recomendadas para importar dados para o BigQuery a partir de uma rede externa, como um ambiente nas instalações.
Práticas recomendadas para a governança de dados ao criar, implementar e operar um armazém de dados no Google Cloud, incluindo o seguinte:
Desidentificação dos dados
tratamento diferencial de dados confidenciais
encriptação ao nível da coluna
controlos de acesso ao nível da coluna
Este documento pressupõe que já configurou um conjunto básico de controlos de segurança, conforme descrito no projeto de bases empresariais. Ajuda a adicionar controlos adicionais aos controlos de segurança existentes para ajudar a proteger dados confidenciais num armazém de dados.
Exemplos de utilização do armazém de dados
O plano detalhado suporta os seguintes exemplos de utilização:
- Use o repositório
terraform-google-secured-data-warehousepara importar dados de Google Cloud para um armazém de dados do BigQuery - Use o repositório
terraform-google-secured-data-warehouse-onprem-ingestpara importar dados de um ambiente nas instalações ou de outra nuvem para um armazém de dados do BigQuery
Vista geral
Os armazéns de dados, como o BigQuery, permitem às empresas analisar os respetivos dados empresariais para obter estatísticas. Os analistas acedem aos dados da empresa que estão armazenados em armazéns de dados para criar estatísticas. Se o seu armazém de dados incluir dados confidenciais, tem de tomar medidas para preservar a segurança, a confidencialidade, a integridade e a disponibilidade dos dados da empresa enquanto são armazenados, enquanto estão em trânsito ou enquanto estão a ser analisados. Neste projeto, faz o seguinte:
- Quando importar dados de origens de dados externas, encripte os dados que se encontram fora do Google Cloud (por exemplo, num ambiente no local) e importe-os para Google Cloud.
- Configure controlos que ajudam a proteger o acesso a dados confidenciais.
- Configure controlos que ajudam a proteger o pipeline de dados.
- Configure uma separação de funções adequada para diferentes perfis fictícios.
- Quando importa dados de outras origens localizadas em Google Cloud (também conhecidas como origens de dados internas), configure modelos para encontrar e remover a identificação de dados confidenciais.
- Configure controlos de segurança e registo adequados para ajudar a proteger os dados confidenciais.
- Use a classificação de dados, as etiquetas de políticas, a ocultação dinâmica de dados e a encriptação ao nível da coluna para restringir o acesso a colunas específicas no data warehouse.
Arquitetura
Para criar um data warehouse confidencial, tem de importar dados em segurança e, em seguida, armazená-los num perímetro dos VPC Service Controls.
Arquitetura ao importar dados de Google Cloud
A imagem seguinte mostra como os dados carregados são categorizados, anonimizados e
armazenados quando importa dados de origem do Google Cloud usando o repositórioterraform-google-secured-data-warehouse. Também mostra como pode
voltar a identificar dados confidenciais a pedido para análise.
Arquitetura ao importar dados de origens externas
A imagem seguinte mostra como os dados são carregados e armazenados quando importa dados
de um ambiente nas instalações ou de outra nuvem para um armazém
do BigQuery através do repositório terraform-google-secured-data-warehouse-onprem-ingest.
Google Cloud serviços e funcionalidades
As arquiteturas usam uma combinação dos seguintes Google Cloud serviços e funcionalidades:
| Serviço ou funcionalidade | Descrição |
|---|---|
Aplicável a origens de dados internas e externas. No entanto, existem diferentes opções de armazenamento, como se segue:
O BigQuery usa vários controlos de segurança para ajudar a proteger o conteúdo, incluindo controlos de acesso, segurança ao nível da coluna para dados confidenciais e encriptação de dados. |
|
Cloud Key Management Service (Cloud KMS) com o Cloud HSM |
Aplicável a origens internas e externas. No entanto, existe um exemplo de utilização adicional para origens de dados externas. O Cloud HSM é um serviço de módulo de segurança de hardware (HSM) baseado na nuvem que aloja a chave de encriptação de chaves (KEK). Quando importa dados de uma origem externa, usa o Cloud HSM para gerar a chave de encriptação que usa para encriptar os dados na sua rede antes de os enviar para Google Cloud. |
Aplicável a origens internas e externas. O Cloud Logging recolhe todos os registos dos Google Cloud serviços para armazenamento e obtenção pelas suas ferramentas de análise e investigação. |
|
Aplicável a fontes internas e externas. O Cloud Monitoring recolhe e armazena informações de desempenho e métricas sobre os Google Cloud serviços. |
|
Aplicável apenas a origens de dados externas. As funções do Cloud Run são acionadas pelo Cloud Storage e escrevem os dados que o Cloud Storage carrega para o contentor de carregamento no BigQuery. |
|
Aplicável a fontes internas e externas. O Cloud Storage e o Pub/Sub recebem dados da seguinte forma:
|
|
Aplicável a origens internas e externas. O Data Profiler para o BigQuery procura automaticamente dados confidenciais 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 origens internas e externas; no entanto, existem diferentes pipelines. Os pipelines do Dataflow importam dados da seguinte forma:
|
Aplicável a fontes internas e externas. O catálogo universal do Dataplex categoriza automaticamente os dados confidenciais com metadados, também conhecidos como etiquetas de políticas, durante o carregamento. O catálogo universal do Dataplex também usa metadados para gerir o acesso a dados confidenciais. Para controlar o acesso aos dados no data warehouse, aplica etiquetas de políticas a colunas que incluem dados confidenciais. |
|
Aplicável apenas a origens de dados externas. O Dedicated Interconnect permite-lhe mover dados entre a sua rede e Google Cloud. Pode usar outra opção de conectividade, conforme descrito em Escolher um produto de conectividade de rede. |
|
Aplicável a fontes internas e externas. A gestão de identidade e de acesso (IAM) e o Resource Manager restringem o acesso e segmentam os recursos. Os controlos de acesso e a hierarquia de recursos seguem o princípio do menor privilégio. |
|
Aplicável a origens internas e externas. O Security Command Center monitoriza e revê os resultados de segurança de todo o seu Google Cloud ambiente numa localização central. |
|
Aplicável a origens internas e externas; no entanto, ocorrem verificações diferentes. A Proteção de dados confidenciais analisa os dados da seguinte forma:
|
|
Aplicável a origens internas e externas; no entanto, existem perímetros diferentes. O VPC Service Controls cria perímetros de segurança que isolam serviços e recursos através da configuração de autorização, controlos de acesso e troca de dados segura. Os perímetros são os seguintes:
Estes perímetros foram concebidos para proteger o conteúdo recebido, isolar dados confidenciais através da configuração de controlos de acesso e monitorização adicionais, e separar a sua administração dos dados reais no armazém. A sua administração inclui a gestão de chaves, a gestão do catálogo de dados e o registo. |
Estrutura da organização
Agrupa os recursos da sua organização para os poder gerir e separar os ambientes de teste do ambiente de produção. O Resource Manager permite-lhe agrupar logicamente os recursos por projeto, pasta e organização.
Os diagramas seguintes mostram uma hierarquia de recursos com pastas que representam diferentes ambientes, como bootstrap, common, produção, não produção (ou preparação) e desenvolvimento. Implementa a maioria dos projetos na arquitetura na pasta de produção e o projeto de gestão de dados na pasta comum, que é usada para a gestão.
Estrutura da organização ao importar dados do Google Cloud
O diagrama seguinte mostra a estrutura da organização quando importa dados de
Google Cloud através do repositório terraform-google-secured-data-warehouse.
Estrutura da organização ao importar dados de origens externas
O diagrama seguinte mostra a estrutura da organização quando importa dados de uma origem externa através do repositório terraform-google-secured-data-warehouse-onprem-ingest.
Pastas
Usa pastas para isolar o ambiente de produção e os serviços de administração dos ambientes de não produção e de testes. A tabela seguinte descreve as pastas do esquema de bases empresariais usadas por esta arquitetura.
| Pasta | Descrição |
|---|---|
Bootstrap |
Contém os recursos necessários para implementar o projeto das bases empresariais. |
Comum |
Contém serviços centralizados para a organização, como o projeto de administração de dados. |
Produção |
Contém projetos com recursos na nuvem que foram testados e estão prontos a usar. Nesta arquitetura, a pasta de produção contém o projeto de carregamento de dados e os projetos relacionados com dados. |
Não produção |
Contém projetos com recursos na nuvem que estão a ser testados e preparados para lançamento. Nesta arquitetura, a pasta Non-production contém o projeto de carregamento de dados e projetos relacionados com dados. |
Programação |
Contém projetos com recursos na nuvem que estão a ser desenvolvidos. Nesta arquitetura, a pasta Development contém o projeto de carregamento de dados e projetos relacionados com dados. |
Pode alterar os nomes destas pastas para se alinharem com a estrutura de pastas da sua organização, mas recomendamos que mantenha uma estrutura semelhante. Para mais informações, consulte o projeto de bases empresariais.
Projetos
Isola partes do seu ambiente através de projetos. A tabela seguinte descreve os projetos necessários na organização. Cria estes projetos quando executa o código do Terraform. Pode alterar os nomes destes projetos, mas recomendamos que mantenha uma estrutura de projeto semelhante.
| Projeto | Descrição |
|---|---|
Carregamento de dados |
Projeto comum para fontes internas e externas. Contém serviços que são necessários para receber dados e remover a identificação de dados confidenciais. |
Gestão de dados |
Projeto comum para fontes internas e externas. Contém serviços que oferecem capacidades de gestão de chaves, registo e catalogação de dados. |
Dados não confidenciais |
Projete apenas para fontes internas. Contém serviços que são necessários para armazenar dados que foram anonimizados. |
Dados confidenciais |
Projete apenas para fontes internas. Contém serviços que são necessários para armazenar e reidentificar dados confidenciais. |
Dados |
Projeto apenas para origens externas. Contém serviços que são necessários para armazenar dados. |
Além destes projetos, o seu ambiente também tem de incluir um projeto que aloje uma tarefa de Flex Template do Dataflow. A tarefa de modelo flexível é necessária para o pipeline de dados de streaming.
Mapeamento de funções e grupos para projetos
Tem de conceder a diferentes grupos de utilizadores na sua organização acesso aos projetos que compõem o data warehouse confidencial. As secções seguintes descrevem as recomendações de arquitetura para grupos de utilizadores e atribuições de funções nos projetos que criar. Pode personalizar os grupos para corresponderem à estrutura existente da sua organização, mas recomendamos que mantenha uma segregação de funções e uma atribuição de funções semelhantes.
Grupo de analistas de dados
Os analistas de dados analisam os dados no armazém. No repositório terraform-google-secured-data-warehouse-onprem-ingest, este grupo pode ver os dados depois de terem sido carregados no data warehouse e realizar as mesmas operações que o grupo Visualizador de dados encriptados.
A tabela seguinte descreve as funções do grupo em diferentes projetos para o repositório terraform-google-secured-data-warehouse (apenas origens de dados internas).
| Mapeamento de projetos | Funções |
|---|---|
Carregamento de dados |
Função adicional para analistas de dados que requerem acesso a dados confidenciais: |
Dados confidenciais |
|
Dados não confidenciais |
A tabela seguinte descreve as funções do grupo em diferentes projetos para o repositório terraform-google-secured-data-warehouse-onprem-ingest (apenas origens de dados externos).
| Âmbito da atribuição | Funções |
|---|---|
Projeto de carregamento de dados |
|
Projeto de dados |
|
Nível da Política de Dados |
Grupo de visualizadores de dados encriptados (apenas origens externas)
O grupo Visualizador de dados encriptados no repositório terraform-google-secured-data-warehouse-onprem-ingestpode ver dados encriptados de tabelas de relatórios do BigQuery através do Looker Studio e de outras ferramentas de relatórios, como o SAP Business Objects.
O grupo de visualizadores de dados encriptados não pode ver dados de texto não cifrado de colunas encriptadas.
Este grupo requer a função Utilizador do BigQuery
(roles/bigquery.jobUser) no projeto de dados. Este grupo também requer a função Leitor com máscara
(roles/bigquerydatapolicy.maskedReader)
ao nível da política de dados.
Grupo de leitores de texto simples (apenas fontes externas)
O grupo Plaintext reader no repositório terraform-google-secured-data-warehouse-onprem-ingesttem a autorização necessária para chamar a função definida pelo utilizador (UDF) de desencriptação para ver dados de texto simples e a autorização adicional para ler dados não ocultados.
Este grupo requer as seguintes funções no projeto de dados:
- Utilizador do BigQuery (
roles/bigquery.user) - Utilizador do BigQuery (
roles/bigquery.jobUser) - Visitante do Cloud KMS (
roles/cloudkms.viewer)
Além disso, este grupo requer a função Leitor detalhado
(roles/datacatalog.categoryFineGrainedReader) ao nível do
catálogo universal do Dataplex.
Grupo de engenheiros de dados
Os engenheiros de dados configuram e mantêm o pipeline de dados e o armazém.
A tabela seguinte descreve as funções do grupo em diferentes projetos para o repositório terraform-google-secured-data-warehouse.
| Pontuação do trabalho | Funções |
|---|---|
Projeto de carregamento de dados |
|
Projeto de dados confidenciais |
|
Projeto de dados não confidenciais |
A tabela seguinte 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, são membros da equipa de rede.
Os administradores de rede precisam das seguintes funções ao nível da organização:
- Administrador do Compute (
roles/compute.networkAdmin) - Visualizador de registos (
roles/logging.viewer)
Grupo de administradores de segurança
Os administradores de segurança administram controlos de segurança, como acesso, chaves, regras de firewall, VPC Service Controls e o Security Command Center.
Os administradores de segurança precisam das seguintes funções ao nível da organização:
- Access Context Manager
Administrador (
roles/accesscontextmanager.policyAdmin) - Cloud Asset Viewer (
roles/cloudasset.viewer) - Administrador do Cloud KMS (
roles/cloudkms.admin) - Administrador de segurança do Compute (
roles/compute.securityAdmin) - Administrador do catálogo de dados (
roles/datacatalog.admin) - Administrador da DLP (
roles/dlp.admin) - Administrador de registo (
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 monitorizam e respondem a incidentes de segurança e a resultados da proteção de dados confidenciais.
Os analistas de segurança precisam das seguintes funções ao nível da organização:
- Leitor do Gestor de contexto de acesso (
roles/accesscontextmanager.policyReader) - Visitante da rede de computação (
roles/compute.networkViewer) - Visitante do catálogo de dados (
roles/datacatalog.viewer) - Visitante do Cloud KMS (
roles/cloudkms.viewer) - Visualizador de registos (
roles/logging.viewer) - Leitor da política da organização (
roles/orgpolicy.policyViewer) - Visitante administrador do centro de segurança (
roles/securitycenter.adminViewer) - Editor de resultados do Centro de segurança(
roles/securitycenter.findingsEditor) - Uma das seguintes funções do Security Command Center:
Exemplos de fluxos de acesso a grupos para origens externas
As secções seguintes descrevem os fluxos de acesso para dois grupos quando importa dados de origens externas através do repositório terraform-google-secured-data-warehouse-onprem-ingest.
Fluxo de acesso para o grupo de visualizadores de dados encriptados
O diagrama seguinte mostra o que ocorre quando um utilizador do grupo visualizador de dados encriptados tenta aceder a dados encriptados no BigQuery.
Seguem-se os passos para aceder aos dados no BigQuery:
O visualizador de dados encriptados executa a seguinte consulta no BigQuery para aceder a dados confidenciais:
SELECT ssn, pan FROM cc_card_tableO BigQuery valida o acesso da seguinte forma:
- O utilizador está autenticado com credenciais válidas e não expiradas. Google Cloud
- A identidade do utilizador e o endereço IP de origem do pedido fazem parte da lista de autorizações no nível de acesso ou na regra de entrada no perímetro dos VPC Service Controls.
- O IAM verifica se o utilizador tem as funções adequadas e se tem autorização para aceder às colunas encriptadas selecionadas na tabela do BigQuery.
O BigQuery devolve os dados confidenciais em formato encriptado.
Fluxo de acesso para o grupo de leitores de texto simples
O diagrama seguinte mostra o que ocorre quando um utilizador do grupo leitor de texto simples tenta aceder a dados encriptados no BigQuery.
Seguem-se os passos para aceder aos dados no BigQuery:
O leitor de texto simples executa a seguinte consulta no BigQuery para aceder a dados confidenciais no formato descifrado:
SELECT decrypt_ssn(ssn) FROM cc_card_tableO BigQuery chama a função definida pelo utilizador (UDF) de desencriptação na consulta para aceder às colunas protegidas.
O acesso é validado da seguinte forma:
- O IAM verifica se o utilizador tem as funções adequadas e se tem autorização para aceder à UDF de desencriptação no BigQuery.
- A UDF obtém a chave de encriptação de dados (DEK) envolvida que foi usada para proteger as colunas de dados confidenciais.
A UDF de desencriptação chama a chave de encriptação de chaves (KEK) no Cloud HSM para desenvolver a DEK. A UDF de desencriptação usa a função de desencriptação AEAD do BigQuery para desencriptar as colunas de dados confidenciais.
O utilizador tem acesso aos dados de texto simples nas colunas de dados confidenciais.
Controlos de segurança comuns
As secções seguintes descrevem os controlos que se aplicam a fontes internas e externas.
Controlos de carregamento de dados
Para criar o seu armazém de dados, tem de transferir dados de outra Google Cloud origem (por exemplo, um lago de dados), do seu ambiente no local ou de outra nuvem. Pode usar uma das seguintes opções para transferir os seus dados para o armazém de dados no BigQuery:
- Uma tarefa em lote que usa o Cloud Storage.
- Uma tarefa de streaming que usa o Pub/Sub.
Para ajudar a proteger os dados durante o carregamento, pode usar a encriptação por parte do cliente, regras de firewall e políticas de nível de acesso. O processo de carregamento é, por vezes, denominado processo de extração, transformação e carregamento (ETL).
Regras de rede e de firewall
As regras da firewall da nuvem virtual privada (VPC) controlam o fluxo de dados
para os perímetros. Cria regras de firewall que negam todas as saídas, exceto as ligações específicas da porta TCP 443 dos nomes de domínios restricted.googleapis.comespeciais. O domínio restricted.googleapis.com tem as seguintes vantagens:
- Ajuda a reduzir a superfície de ataque da sua rede através do acesso privado à Google quando as cargas de trabalho comunicam com as APIs e os serviços Google.
- Garante que usa apenas serviços que suportam os VPC Service Controls.
Para mais informações, consulte o artigo Configurar o acesso privado da Google.
Quando usar o repositório terraform-google-secured-data-warehouse, tem de configurar sub-redes separadas para cada tarefa do Dataflow. As sub-redes
separadas garantem que os dados que estão a ser anonimizados são devidamente separados dos
dados que estão a ser reidentificados.
O pipeline de dados requer que abra portas TCP na firewall, conforme definido no ficheiro dataflow_firewall.tf nos repositórios respetivos. Para mais
informações, consulte o artigo Configurar o acesso à Internet e as regras
da firewall.
Para negar aos recursos a capacidade de usar endereços IP externos, a política da organização Definir IPs externos permitidos para instâncias de VMs (compute.vmExternalIpAccess)
está definida para negar tudo.
Controlos de perímetro
Conforme mostrado no diagrama de arquitetura, coloca os recursos do armazém de dados em perímetros separados. Para permitir que os serviços em diferentes perímetros partilhem dados, crie pontes de perímetro.
As pontes de perímetro permitem que os serviços protegidos façam pedidos de recursos fora do respetivo perímetro. Estas pontes estabelecem as seguintes ligações para o repositório terraform-google-secured-data-warehouse:
- Associam o projeto de carregamento de dados ao projeto de governação para que a anulação da identificação possa ocorrer durante o carregamento.
- Associam o projeto de dados não confidenciais e o projeto de dados confidenciais, para que os dados confidenciais possam ser reidentificados quando um analista de dados o solicitar.
- Associam o projeto confidencial ao projeto de administração de dados para que a reidentificação possa ocorrer quando um analista de dados a solicitar.
Estas pontes estabelecem as seguintes ligações para o repositório terraform-google-secured-data-warehouse-onprem-ingest:
- Associam o projeto de carregamento de dados ao projeto de dados para que os dados possam ser carregados para o BigQuery.
- Associam o projeto de dados ao projeto de administração de dados para que a Proteção de dados confidenciais possa analisar o BigQuery em busca de dados confidenciais não protegidos.
- Associam o projeto de carregamento de dados ao projeto de administração de dados para acesso ao registo, à monitorização e às chaves de encriptação.
Além das pontes de perímetro, usa regras de saída para permitir que os recursos protegidos por perímetros de serviço acedam a recursos que estão fora do perímetro. Nesta solução, configura regras de saída para obter as tarefas de modelo flexível do Dataflow externas localizadas no Cloud Storage num projeto externo. Para mais informações, consulte o artigo Aceda a um recurso fora do perímetro. Google Cloud
Política de acesso
Para ajudar a garantir que apenas identidades específicas (utilizador ou serviço) podem aceder a recursos e dados, ative os grupos e as funções da IAM.
Para ajudar a garantir que apenas origens específicas podem aceder aos seus projetos, ative uma política de acesso para a sua organização Google. Recomendamos que crie uma política de acesso que especifique o intervalo de endereços IP permitidos para pedidos e permita apenas pedidos de utilizadores ou contas de serviço específicos. Para mais informações, consulte os atributos do nível de acesso.
Contas de serviço e controlos de acesso
As contas de serviço são identidades que Google Cloud pode usar para executar pedidos de API
em seu nome. As contas de serviço garantem que as identidades dos utilizadores não têm acesso direto aos serviços. Para permitir a separação de funções, crie contas de serviço com funções diferentes para fins específicos. Estas contas de serviço estão definidas no módulo data-ingestion e no módulo 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 remove a identificação dos dados confidenciais.
- Uma conta de serviço do controlador do Dataflow para o pipeline do Dataflow que identifica novamente os dados confidenciais.
- Uma conta de serviço do Cloud Storage para carregar dados de um ficheiro em lote.
- Uma conta de serviço do Pub/Sub para carregar dados de um serviço de streaming.
- Uma conta de serviço do Cloud Scheduler para executar a tarefa em lote do Dataflow que cria o pipeline do Dataflow.
A tabela seguinte indica as funções atribuídas 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 de carregamento de dados em lote automatizado para o contentor de armazenamento de carregamento.
- A conta de serviço do Pub/Sub permite o streaming de dados para o serviço Pub/Sub.
- A conta de serviço do controlador do Dataflow é usada pelo pipeline do Dataflow para transformar e escrever dados do Pub/Sub para o BigQuery.
- A conta de serviço das funções do Cloud Run escreve dados de lotes subsequentes carregados do Cloud Storage para o BigQuery.
- A conta de serviço de carregamento de armazenamento permite que o pipeline de ETL crie objetos.
- A conta de serviço de escrita do Pub/Sub permite que o pipeline ETL escreva dados no Pub/Sub.
A tabela seguinte indica as funções atribuídas a cada conta de serviço:
| Nome | Funções | Âmbito da atribuição |
|---|---|---|
Conta de serviço do controlador do Dataflow |
|
Projeto de carregamento de dados |
Projeto de dados |
||
Gestão de dados |
||
Conta de serviço das funções do Cloud Run |
Projeto de carregamento de dados |
|
Projeto de dados |
||
Conta de serviço de carregamento de armazenamento |
Projeto de carregamento de dados |
|
Conta de serviço de gravação do Pub/Sub |
Projeto de carregamento de dados |
Políticas organizacionais
Esta arquitetura inclui as restrições da política da organização que o projeto detalhado das bases empresariais usa e adiciona restrições adicionais. Para mais informações acerca das restrições usadas no esquema detalhado das bases empresariais, consulte as restrições da política da organização.
A tabela seguinte descreve as restrições da política organizacional adicionais que estão definidas no módulo org_policies para os respetivos repositórios:
| Política | Nome da restrição | Valor recomendado |
|---|---|---|
Restrinja as implementações de recursos a localizações físicas específicas. Para valores adicionais, consulte Grupos de valores. |
|
Uma das seguintes opções:
|
|
|
|
|
|
|
Restrinja as novas regras de encaminhamento para serem apenas internas, com base no endereço IP. |
|
|
Definir o conjunto de sub-redes da VPC partilhada que os recursos do Compute Engine podem usar. |
|
Substitua pelo ID de recurso da sub-rede privada que quer que a arquitetura use. |
Desative o registo de saída da porta série no Cloud Logging. |
|
|
Exigir
proteção CMEK ( |
|
|
Desative a criação de chaves de contas de serviço
( |
|
verdadeiro |
Ativar o Início de sessão do SO para VMs criadas no projeto
( |
|
verdadeiro |
Desative
as concessões automáticas de funções à conta de serviço predefinida
( |
|
verdadeiro |
Definições de entrada permitidas (funções do Cloud Run)
( |
|
|
Controlos de segurança para origens de dados externas
As secções seguintes descrevem os controlos que se aplicam à ingestão de dados de origens externas.
Ligação encriptada a Google Cloud
Quando importa dados de origens externas, pode usar o Cloud VPN ou o Cloud Interconnect para proteger todos os dados que fluem entre Google Cloud e o seu ambiente. Esta arquitetura empresarial recomenda o Dedicated Interconnect, porque oferece uma ligação direta e um elevado débito, que são importantes se estiver a fazer stream de muitos dados.
Para permitir o acesso a Google Cloud a partir do seu ambiente, tem de definir endereços IP na lista de autorizações nas regras da política de níveis de acesso.
Encriptação do lado do cliente
Antes de mover os seus dados confidenciais para o Google Cloud, encriptar os dados localmente para ajudar a protegê-los em repouso e em trânsito. Pode usar a biblioteca de encriptação Tink ou outras bibliotecas de encriptação. A biblioteca de encriptação do Tink é compatível com a encriptação AEAD do BigQuery, que a arquitetura usa para desencriptar dados encriptados ao nível da coluna após a importação dos dados.
A biblioteca de encriptação Tink usa DEKs que pode gerar localmente ou a partir do Cloud HSM. Para encapsular ou proteger a DEK, pode usar uma KEK gerada no Cloud HSM. A KEK é um conjunto de chaves de encriptação CMEK simétricas que é armazenado em segurança no Cloud HSM e gerido através de funções e autorizações da IAM.
Durante o carregamento, a DEK envolvida e os dados são armazenados no BigQuery. O BigQuery inclui duas tabelas: uma para os dados e outra para a DEK envolvida. Quando os analistas precisam de ver dados confidenciais, o BigQuery pode usar a desencriptação AEAD para desencapsular a DEK com a KEK e desencriptar a coluna protegida.
Além disso, a encriptação do lado do cliente com o Tink protege ainda mais os seus dados encriptando as colunas de dados confidenciais no BigQuery. A arquitetura usa as seguintes chaves de encriptação do Cloud HSM:
- Uma chave CMEK para o processo de carregamento que também é usada pelo Pub/Sub, pela pipeline do Dataflow para streaming, pelo carregamento em lote do Cloud Storage e pelos artefactos das funções do Cloud Run para carregamentos em lote subsequentes.
- A chave criptográfica envolvida pelo Cloud HSM para os dados encriptados na sua rede através do Tink.
- Chave CMEK para o armazém do BigQuery no projeto de dados.
Especifica a localização da CMEK, que determina a localização geográfica onde a chave é armazenada e disponibilizada para acesso. Tem de garantir que a CMEK está na mesma localização que os seus recursos. Por predefinição, a CMEK é rodada a cada 30 dias.
Se as obrigações de conformidade da sua organização exigirem que faça a gestão das suas próprias chaves externamente ao Google Cloud, pode ativar o Cloud External Key Manager. Se usar chaves externas, é responsável pelas atividades de gestão de chaves, incluindo a rotação de chaves.
Ocultação dinâmica de dados
Para ajudar na partilha e aplicação de políticas de acesso aos dados em grande escala, pode configurar a ocultação de dados dinâmicos. A ocultação de dados dinâmica permite que as consultas existentes ocultem automaticamente os dados das colunas através dos seguintes critérios:
- As regras de ocultação aplicadas à coluna no tempo de execução da consulta.
- As funções atribuídas ao utilizador que está a executar a consulta. Para aceder aos dados de colunas não ocultados, o analista de dados tem de ter a função de Leitor detalhado.
Para definir o acesso a colunas no BigQuery, crie etiquetas de
políticas. Por exemplo, a taxonomia criada no exemplo autónomo cria a etiqueta de política 1_Sensitive para colunas que incluem dados que não podem ser tornados públicos, como o limite de crédito. A regra de ocultação de dados predefinida é aplicada a estas colunas para ocultar o valor da coluna.
Tudo o que não estiver etiquetado está disponível para todos os utilizadores que têm acesso ao data warehouse. Estes controlos de acesso garantem que, mesmo depois de os dados serem escritos no BigQuery, os dados em campos confidenciais continuam a não poder ser lidos até o acesso ser explicitamente concedido ao utilizador.
Encriptação e desencriptação ao nível da coluna
A encriptação ao nível da coluna permite-lhe encriptar dados no BigQuery a um nível mais detalhado. Em vez de encriptar uma tabela inteira, selecione as colunas que contêm dados confidenciais no BigQuery e apenas essas colunas são encriptadas. O BigQuery usa funções de encriptação e desencriptação AEAD que criam os conjuntos de chaves que contêm as chaves para encriptação e desencriptação. Estas chaves são, em seguida, usadas para encriptar e desencriptar valores individuais numa tabela e para rodar chaves num conjunto de chaves. A encriptação ao nível da coluna oferece controlo de acesso duplo aos dados encriptados no BigQuery, porque o utilizador tem de ter autorizações para a tabela e a chave de encriptação para ler dados em texto não cifrado.
Profiler de dados para o BigQuery com a proteção de dados confidenciais
O perfilador de dados permite-lhe identificar as localizações de dados confidenciais e de alto risco nas tabelas do BigQuery. O perfilador de dados analisa e examina automaticamente todas as tabelas e colunas do BigQuery em toda a organização, incluindo todas as pastas e projetos. Em seguida, o perfilador de dados produz métricas como os infoTypes previstos, os níveis de risco e sensibilidade dos dados avaliados e metadados sobre as suas tabelas. Com estas estatísticas, pode tomar decisões informadas sobre como protege, partilha e usa os seus dados.
Controlos de segurança para origens de dados internas
As secções seguintes descrevem os controlos que se aplicam ao carregamento de dados de Google Cloud origens.
Gestão de chaves e encriptação para carregamento
Ambas as opções de carregamento (Cloud Storage ou Pub/Sub) usam o Cloud HSM para gerir a CMEK. Usa as chaves CMEK para ajudar a proteger os seus dados durante o carregamento. A proteção de dados confidenciais protege ainda mais os seus dados encriptando dados confidenciais, usando os detetores que configurar.
Para carregar dados, usa as seguintes chaves de encriptação:
- Uma chave CMEK para o processo de carregamento 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 através da proteção de dados confidenciais.
- Duas chaves CMEK, uma para o armazém do BigQuery no projeto de dados não confidenciais e outra para o armazém no projeto de dados confidenciais. Para mais informações, consulte o artigo Gestão de chaves.
Especifica a localização da CMEK, que determina a localização geográfica onde a chave é armazenada e disponibilizada para acesso. Tem de garantir que a sua CMEK está na mesma localização que os seus recursos. Por predefinição, a CMEK é rodada a cada 30 dias.
Se as obrigações de conformidade da sua organização exigirem que faça a gestão das suas próprias chaves externamente a partir do Google Cloud, pode ativar o Cloud EKM. Se usar chaves externas, é responsável pelas atividades de gestão de chaves, incluindo a rotação de chaves.
Desidentificação dos dados
Utiliza a proteção de dados confidenciais para desidentificar os seus dados estruturados e não estruturados durante a fase de carregamento. Para dados estruturados, usa
transformações de
registos
com base em campos para anular a identificação dos dados. Para ver um exemplo desta abordagem, consulte a pasta
/examples/de_identification_template/. Este exemplo verifica se existem números de cartões de crédito e PINs de cartões nos dados estruturados. Para dados não estruturados, usa tipos de informações para remover a identificação dos dados.
Para desidentificar dados etiquetados como confidenciais, usa a proteção de dados confidenciais e uma pipeline do Dataflow para criar símbolos. Este pipeline recebe dados do Cloud Storage, processa-os e, em seguida, envia-os para o armazém de dados do BigQuery.
Para mais informações sobre o processo de desidentificação dos dados, consulte a governança de dados.
Controlos de acesso ao nível da coluna
Para ajudar a proteger os dados confidenciais, usa controlos de acesso para colunas específicas no armazém do BigQuery. Para aceder aos dados nestas colunas, um analista de dados tem de ter a função de leitor detalhado.
Para definir o acesso a colunas no BigQuery, crie etiquetas de políticas. Por exemplo, o ficheiro taxonomy.tf no módulo de exemplo bigquery-confidential-data cria as seguintes etiquetas:
- Uma etiqueta de política
3_Confidentialpara colunas que incluem informações muito confidenciais, como números de cartões de crédito. Os utilizadores que têm acesso a esta etiqueta também têm acesso a colunas etiquetadas com as etiquetas de políticas2_Privateou1_Sensitive. - Uma etiqueta de política
2_Privatepara colunas que incluem informações de identificação pessoal (IIP) sensíveis, como o nome próprio de uma pessoa. Os utilizadores que têm acesso a esta etiqueta também têm acesso a colunas etiquetadas com a etiqueta de política1_Sensitive. Os utilizadores não têm acesso a colunas etiquetadas com a etiqueta de política3_Confidential. - Uma etiqueta de política
1_Sensitivepara colunas que incluem dados que não podem ser tornados públicos, como o limite de crédito. Os utilizadores que têm acesso a esta etiqueta não têm acesso a colunas etiquetadas com as etiquetas de políticas2_Privateou3_Confidential.
Tudo o que não estiver etiquetado está disponível para todos os utilizadores que tenham acesso ao data warehouse.
Estes controlos de acesso garantem que, mesmo após a reidentificação dos dados, os dados continuam a não poder ser lidos até que o acesso seja explicitamente concedido ao utilizador.
Nota: pode usar as definições predefinidas para executar os exemplos. Para ver mais práticas recomendadas, consulte o artigo Práticas recomendadas para usar etiquetas de políticas no BigQuery.
Contas de serviço com funções limitadas
Tem de limitar o acesso ao projeto de dados confidenciais para que apenas os utilizadores autorizados possam ver os dados confidenciais. Para tal, crie uma conta de serviço com a função Utilizador da conta de serviço (roles/iam.serviceAccountUser) que os utilizadores autorizados têm de se fazer passar. A representação da conta de serviço
ajuda os utilizadores a usar contas de serviço sem transferir as chaves
das contas de serviço, o que melhora a segurança geral do seu projeto. A representação cria um token de curto prazo que os utilizadores autorizados com a função Criador de tokens de conta de serviço (roles/iam.serviceAccountTokenCreator) podem transferir.
Gestão de chaves e encriptação para armazenamento e reidentificação
Gerir chaves CMEK separadas para os seus dados confidenciais, para que possa voltar a identificar os dados. Usa o Cloud HSM para proteger as suas chaves. Para voltar a identificar os seus dados, use as seguintes chaves:
- Uma chave CMEK que o pipeline do Dataflow usa para o processo de reidentificação.
- A chave criptográfica original que a proteção de dados confidenciais usa para desidentificar os seus dados.
- Uma chave CMEK para o armazém do BigQuery no projeto de dados confidenciais.
Conforme mencionado em Gestão de chaves e encriptação para carregamento, pode especificar a localização da CMEK e os períodos de rotação. Pode usar o EKM na nuvem se for exigido pela sua organização.
Operações
Pode ativar o registo e as funcionalidades do Security Command Center Premium ou do nível Enterprise, como as estatísticas de segurança e a deteção de ameaças de eventos. Estes controlos ajudam a fazer o seguinte:
- Monitorizar quem está a aceder aos seus dados.
- Certifique-se de que é implementada uma auditoria adequada.
- Gerar resultados para recursos na nuvem com erros de configuração
- Apoiar a capacidade das suas equipas de gestão de incidentes e operações de responder a problemas que possam ocorrer.
Transparência de acesso
A Transparência de acesso envia-lhe uma notificação em tempo real quando o pessoal da Google precisa de aceder aos seus dados. Os registos da Transparência de acesso são gerados sempre que um humano acede ao conteúdo, e apenas o pessoal da Google com justificações comerciais válidas (por exemplo, um registo de apoio técnico) pode obter acesso.
Registo
Para ajudar a cumprir os requisitos de auditoria e obter estatísticas sobre os seus projetos,
configure o Google Cloud Observability
com registos de dados para os serviços que quer acompanhar. O módulo centralized-logging nos repositórios configura as seguintes práticas recomendadas:
- Criar um destino de registo agregado em todos os projetos.
- Armazenar os registos na região adequada.
- Adicionar chaves CMEK ao seu destino de registo.
Para todos os serviços nos projetos, os seus registos têm de incluir informações sobre leituras e escritas de dados, bem como informações sobre o que os administradores leem. Para ver práticas recomendadas de registo adicionais, consulte o artigo Controlos de deteção.
Alertas e monitorização
Depois de implementar a arquitetura, pode configurar alertas para notificar o seu centro de operações de segurança (SOC) de que pode estar a ocorrer um incidente de segurança. Por exemplo, pode usar alertas para informar o seu analista de segurança quando uma autorização do IAM tiver sido alterada. Para mais informações sobre a configuração de alertas do Security Command Center, consulte o artigo Configurar notificações de resultados. Para alertas adicionais que não são publicados pelo Security Command Center, pode configurar alertas com o Cloud Monitoring.
Considerações de segurança adicionais
Além dos controlos de segurança descritos neste documento, deve rever e gerir a segurança e o risco em áreas importantes que se sobrepõem e interagem com a sua utilização desta solução. Estas incluem o seguinte:
- A segurança do código que usa para configurar, implementar e executar tarefas do Dataflow e funções do Cloud Run.
- A taxonomia de classificação de dados que usa com esta solução.
- Geração e gestão de chaves de encriptação.
- O conteúdo, a qualidade e a segurança dos conjuntos de dados que armazena e analisa no data warehouse.
- O ambiente geral no qual implementa a solução, incluindo o seguinte:
- A conceção, a segmentação e a segurança das redes às quais se liga a esta solução.
- A segurança e a governação dos controlos de IAM da sua organização.
- As definições de autenticação e autorização para os intervenientes aos quais concede acesso à infraestrutura que faz parte desta solução e que têm acesso aos dados armazenados e geridos nessa infraestrutura.
Reunir tudo num só lugar
Para implementar a arquitetura descrita neste documento, faça o seguinte:
- Determine se vai implementar a arquitetura com o esquema detalhado das bases empresariais ou de forma autónoma. Se optar por não implementar o projeto detalhado das bases empresariais, certifique-se de que o seu ambiente tem uma base de segurança semelhante implementada.
- Para importar dados de origens externas, configure uma ligação Dedicated Interconnect com a sua rede.
- Reveja o
terraform-google-secured-data-warehouseREADME ou oterraform-google-secured-data-warehouse-onprem-ingestREADME e certifique-se de que cumpre todos os pré-requisitos. Verifique se a sua identidade de utilizador tem as funções Utilizador da conta de serviço (
roles/iam.serviceAccountUser) e Criador de tokens da conta de serviço Criador de tokens 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 não tiver uma pasta que use para testes, crie uma pasta e configure o acesso.Registe o ID da conta de faturação, o nome a apresentar da organização, o ID da pasta para a sua pasta de teste ou demonstração e os endereços de email dos seguintes grupos de utilizadores:
- Analistas de dados
- Visualizador de dados encriptados
- Leitor de texto simples
- Engenheiros de dados
- Administradores de rede
- Administradores de segurança
- Analistas de segurança
Crie os projetos. Para ver uma lista das APIs que tem de ativar, consulte o ficheiro README.
Crie a conta de serviço para o Terraform e atribua as funções adequadas para todos os projetos.
Configure a política de controlo de acesso.
Para Google Cloud origens de dados que usam o repositório
terraform-google-secured-data-warehouse, no seu ambiente de teste, implemente o passo a passo para ver a solução em ação. Como parte do processo de testes, considere o seguinte:- Adicione os seus próprios dados de exemplo ao armazém do BigQuery.
- Trabalhe com um analista de dados na sua empresa para testar o respetivo acesso aos dados confidenciais e se consegue interagir com os dados do BigQuery da forma esperada.
Para origens de dados externas que usam o repositório
terraform-google-secured-data-warehouse-onprem-ingest, no ambiente de teste, implemente a solução:- Clone e execute os scripts do Terraform para configurar um ambiente no Google Cloud.
Instale a biblioteca de encriptação do Tink na sua rede.
Configure as Credenciais padrão da aplicação para poder executar a biblioteca Tink na sua rede.
Crie chaves de encriptação com o Cloud KMS.
Gere conjuntos de chaves encriptados com o Tink.
Encriptar dados com o Tink através de um dos seguintes métodos:
- Usar encriptação determinística.
- Usar um script auxiliar com dados de exemplo.
Carregue dados encriptados para o BigQuery através de carregamentos por streaming ou em lote.
Para origens de dados externas, verifique se os utilizadores autorizados podem ler dados não encriptados do BigQuery através da função de desencriptação AEAD do BigQuery. Por exemplo, execute a seguinte função de descifragem:
Execute a consulta de criação de vista:
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 a partir da vista:
SELECT Card_Type_Code, Issuing_Bank, Card_Number, Card_Number_Decrypted FROM `{project_id}.{bigquery_dataset}.decrypted_view`Para consultas e exemplos de utilização adicionais, consulte o artigo Encriptação ao nível da coluna com o Cloud KMS.
Use o Security Command Center para analisar os projetos recém-criados em função dos seus requisitos de conformidade.
Implemente a arquitetura no seu ambiente de produção.
O que se segue?
- Reveja o projeto de base das empresas para um ambiente seguro de base.
- Para ver os detalhes da arquitetura, leia o README da configuração do Terraform
para origens de dados internas (
terraform-google-secured-data-warehouserepositório) ou leia o README da configuração do Terraform para origens de dados externas (terraform-google-secured-data-warehouse-onprem-ingestrepositório).