Muitas organizações implantam armazenamentos de dados que armazenam informações confidenciais 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 de segurança composto pelos seguintes itens:
Um repositório do GitHub que contém um conjunto de configurações e scripts do Terraform. A configuração do Terraform configura um ambiente no Google Cloud compatível com um armazenamento de dados que armazena dados confidenciais.
Um guia para os controles de arquitetura, design e segurança que você usa para implementar esse blueprint (este documento).
Um tutorial que implanta um ambiente de amostra.
Neste documento, você verá os seguintes tópicos:
A arquitetura e os serviços do Google Cloud que podem ser usados para ajudar a proteger um armazenamento de dados em um ambiente de produção.
Práticas recomendadas para governança de dados ao criar, implantar e operar um armazenamento de dados no Google Cloud, incluindo desidentificação de dados, tratamento diferencial de dados confidenciais e controles de acesso no nível da coluna.
Neste documento, pressupomos que você já tenha configurado um conjunto básico de controles de segurança, conforme descrito nas fundações corporativas do Google Cloud. Ele ajuda você a sobrepor controles adicionais aos seus controles de segurança atuais para proteger dados confidenciais em um armazenamento de dados.
Casos de uso do data warehouse
O blueprint é compatível com os seguintes casos de uso:
Importar dados do Google Cloud para um data warehouse seguro do BigQuery (este documento)
Importar dados de um ambiente local ou de outra nuvem para um armazenamento do BigQuery
Visão geral
Armazenamentos de dados como o BigQuery permitem que as empresas analisem os dados da empresa para conseguir insights. Os analistas acessam os dados da empresa que estão armazenados nos armazenamentos de dados para criar insights. Se o armazenamento de dados incluir dados confidenciais, você precisará tomar medidas para preservar a segurança, a confidencialidade, a integridade e a disponibilidade dos dados da empresa enquanto estão armazenados, em trânsito ou enquanto são analisados. Neste blueprint, você realizará as ações a seguir:
- Configurar controles que ajudem a proteger o acesso a dados confidenciais.
- Configurar controles que ajudem a proteger o pipeline de dados.
- Configurar uma separação adequada de tarefas para diferentes perfis.
- Configurar modelos para encontrar e desidentificar dados confidenciais
- Configurar controles de segurança e registros apropriados para proteger os dados confidenciais.
- Usar a classificação de dados e as tags de política para restringir o acesso a colunas específicas no armazenamento de dados.
Arquitetura
Para criar um armazenamento de dados confidenciais, você precisa categorizar os dados como confidenciais e não confidenciais e, em seguida, armazená-los em perímetros separados. A imagem a seguir mostra como os dados ingeridos são categorizados, desidentificados e armazenados. Você também verá como identificar novamente dados confidenciais sob demanda para análise.
A arquitetura usa uma combinação dos seguintes serviços e recursos do Google Cloud:
O Identity and Access Management (IAM) e o Resource Manager restringem os recursos de acesso e segmento. A hierarquia de recursos e controles de acesso segue o princípio do menor privilégio.
O VPC Service Controls cria perímetros de segurança que isolam serviços e recursos, configurando autorização, controles de acesso e troca segura de dados. Os perímetros são os seguintes:
Um perímetro de ingestão de dados que aceite dados de entrada (em lote ou stream) e os desidentifique. Uma zona de destino separada ajuda a proteger o restante das cargas de trabalho contra dados de entrada.
Um perímetro de dados confidencial que pode reidentificar os dados confidenciais e armazená-los em uma área restrita.
Um perímetro de governança que armazena as chaves de criptografia e define o que é considerado como dados confidenciais.
Eles são projetados para proteger o conteúdo recebido, isolar dados confidenciais configurando controles e acesso adicionais e separar sua governança dos dados reais no armazenamento. Sua governança inclui gerenciamento de chaves, gerenciamento de catálogo de dados e geração de registros.
O Cloud Storage e o Pub/Sub recebem dados da seguinte maneira:
Cloud Storage: recebe e armazena dados em lote antes da desidentificação. O Cloud Storage usa o TLS para criptografar dados em trânsito e criptografa dados no armazenamento por padrão. A chave de criptografia é uma chave de criptografia gerenciada pelo cliente (CMEK). É possível ajudar a proteger o acesso a buckets do Cloud Storage usando controles de segurança, como gerenciamento de identidade e acesso, listas de controle de acesso (ACLs) e documentos de política. Para mais informações sobre controles de acesso compatíveis, consulte Visão geral do controle de acesso.
Pub/Sub: recebe e armazena dados de streaming antes da desidentificação. O Pub/Sub usa autenticação, controles de acesso e criptografia no nível da mensagem com uma CMEK para proteger seus dados.
Dois pipelines do Dataflow desidentificam e reidentificam dados confidenciais da seguinte maneira:
- O primeiro pipeline identifica dados confidenciais usando pseudonimização.
- O segundo pipeline identifica novamente dados confidenciais quando usuários autorizados exigem acesso.
Para proteger dados, o Dataflow usa uma conta de serviço e uma chave de criptografia exclusivas para cada pipeline, além de oferecer controle de acesso. Para proteger a execução do pipeline movendo-o para o serviço de back-end, o Dataflow usa o Streaming Engine. Para mais informações, consulte Segurança e permissões do Dataflow.
A Proteção de dados confidenciais desidentifica dados confidenciais durante o processamento.
A proteção de dados confidenciais desidentifica dados estruturados e não estruturados com base nos infoTypes ou registros detectados.
O Cloud HSM hospeda a chave de criptografia de chaves (KEK). O Cloud HSM é um serviço Módulo de segurança de hardware (HSM, na sigla em inglês) baseado na nuvem.
O Data Catalog categoriza automaticamente dados confidenciais com metadados, também conhecidos como tags de política, durante o processamento. O Data Catalog também usa metadados para gerenciar o acesso a dados confidenciais. Para mais informações, consulte Visão geral do Data Catalog. Para controlar o acesso aos dados no armazenamento de dados, aplique tags de política a colunas que incluam dados confidenciais.
O BigQuery armazena os dados confidenciais no perímetro de dados confidenciais.
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.
O Security Command Center monitora e analisa as descobertas de segurança em todo o ambiente do Google Cloud em um só local.
Estrutura da organização
Você agrupa os recursos da sua organização para gerenciá-los e separar os ambientes de teste do ambiente de produção. O Resource Manager permite agrupar logicamente recursos por projeto, pasta e organização.
Veja no diagrama a seguir uma hierarquia de recursos com pastas que representam diferentes ambientes, como bootstrap, comum, produção, não produção (ou preparo) e desenvolvimento. Você implanta a maioria dos projetos no blueprint na pasta de produção e o projeto de governança de dados na pasta comum usada para governança.
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 corporativo que são usadas por esse blueprint.
| Pasta | Descrição |
|---|---|
| Prod. | Contém projetos que têm recursos de nuvem testados e prontos para uso. |
| Comum | Contêm serviços centralizados para a organização, como o projeto de governança. |
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 corporativos do Google Cloud.
Projetos
Isolar partes do ambiente usando projetos. A tabela a seguir descreve os projetos necessários na organização. Você cria esses projetos ao executar o código do Terraform. É possível alterar os nomes desses projetos, mas recomendamos que você mantenha uma estrutura de projeto semelhante.
| Projeto | Descrição |
|---|---|
| Ingestão de dados | Contém serviços que são necessários para receber dados e desidentificar dados confidenciais. |
| Governança | Contém serviços que oferecem recursos de gerenciamento de chaves, geração de registros e catalogação de dados. |
| Dados não confidenciais | Contém serviços que são necessários para armazenar dados que foram desidentificados. |
| Dados confidenciais | Contém serviços que são necessários para armazenar e reidentificar dados confidenciais. |
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 armazenamento de dados confidencial. As seções a seguir descrevem as recomendações de blueprints para grupos de usuários e atribuições de papéis nos projetos que você criar. É possível personalizar os grupos para que correspondam à estrutura da sua organização. No entanto, recomendamos que você mantenha uma segregação semelhante das tarefas e da atribuição de funções.
Grupo de analistas de dados
Analistas de dados analisam os dados no armazenamento. Esse grupo requer papéis em diferentes projetos, conforme descrito na tabela a seguir.
| 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 |
|
Grupo de engenheiros de dados
Engenheiros de dados configuram e mantêm o pipeline de dados e o armazenamento. Esse grupo requer papéis em diferentes projetos, conforme descrito na tabela a seguir.
| Mapeamento do projeto | Papéis |
|---|---|
| Ingestão de dados | |
| Dados confidenciais |
|
| Dados não confidenciais |
|
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:
roles/logging.viewer
Grupo de administradores de segurança
Os administradores de segurança administram os controles de segurança, como o acesso, as chaves, as regras de firewall, o VPC Service Controls e o Security Command Center.
Os administradores de segurança exigem os seguintes papéis no nível da organização:
Grupo de analistas de segurança
Os analistas de segurança monitoram e respondem a incidentes de segurança e descobertas da proteção de dados confidenciais.
Os analistas de segurança exigem os seguintes papéis no nível da organização:
roles/cloudkms.viewerroles/logging.viewerroles/securitycenter.findingsEditorUm dos seguintes papéis do Security Command Center:
roles/securitycenter.findingsBulkMuteEditorroles/securitycenter.findingsMuteSetterroles/securitycenter.findingsStateSetter
Noções básicas dos controles de segurança necessários
Nesta seção, discutiremos os controles de segurança do Google Cloud que você usa para proteger o armazenamento de dados. Os princípios básicos de segurança a serem considerados são os seguintes:
Proteja o acesso adotando princípios de privilégio mínimo.
Conexões de rede seguras por meio da concepção e políticas de segmentação.
Proteja a configuração de cada um dos serviços.
Classificar e proteger dados com base no nível de risco.
Entenda os requisitos de segurança do ambiente que hospeda o armazenamento de dados.
Configurar o monitoramento e a geração de registros suficientes para detecção, investigação e resposta.
Controles de segurança para ingestão de dados
Para criar o armazenamento de dados, é necessário transferir os dados de outra fonte do Google Cloud, como um data lake. 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 proteger os dados durante o processamento, é possível usar regras de firewall, políticas de acesso e criptografia.
Regras de rede e firewall
Regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados
nos perímetros. Você cria regras de firewall que negam todas as saídas, exceto para
conexões de porta TCP 443 específicas dos nomes de domínio
especiais restricted.googleapis.com. O domínio restricted.googleapis.com tem os seguintes benefícios:
- Ele reduz a superfície de ataque à rede usando o Acesso privado do Google quando as cargas de trabalho se comunicam com os serviços e as APIs.
- Isso garante que você use apenas serviços compatíveis com o VPC Service Controls.
Para mais informações, consulte Como configurar o acesso particular do Google.
É 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 as portas TCP no firewall, conforme
definido no
arquivo dataflow_firewall.tf no
repositório do módulo dwh-networking. Para mais informações, consulte Como configurar o acesso à Internet e as
regras de firewall.
Para impedir que os recursos usem endereços IP externos, a política da organização compute.vmExternalIpAccess está definida para negar tudo.
Controles de perímetro
Conforme mostrado no diagrama de arquitetura, você coloca os recursos do armazenamento de dados confidenciais 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:
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 solicita.
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.
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 do Google Cloud fora do perímetro.
Política de acesso
Para garantir que apenas identidades específicas (usuários ou serviços) possam acessar recursos e dados, ative os grupos e os papéis do IAM.
Para garantir que apenas fontes específicas possam acessar seus projetos, ative uma política de acesso para sua organização do Google. Recomendamos que você crie uma política de acesso que especifique o intervalo de endereços IP permitido para solicitações e permita somente solicitações de usuários ou contas de serviço específicos. Para mais informações, consulte Atributos de nível de acesso.
Gerenciamento e criptografia de chaves para processamento
Ambas as opções de processamento usam o Cloud HSM para gerenciar as CMEK. Você usa as chaves CMEK para ajudar a proteger seus dados durante o processamento. A proteção de dados confidenciais protege seus dados ainda mais, criptografando dados confidenciais com os detectores configurados.
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. Em alguns casos, o processo de ingestão é chamado de processo de extração, transformação e carregamento (ETL).
A chave criptográfica encapsulada pelo Cloud HSM para o processo de desidentificação de dados usando a proteção de dados confidenciais.
Duas chaves CMEK, uma para o armazenamento do BigQuery no projeto de dados não confidenciais, e outra para o armazenamento 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 Gerenciador de chaves externo do Cloud. Se você usar chaves externas, será responsável pelas atividades de gerenciamento de chaves, incluindo a rotação de chaves.
Contas de serviço e controles de acesso
As contas de serviço são identidades que o Google Cloud pode usar para executar solicitações de API em seu nome. As contas de serviço garantem que as identidades dos usuários não tenham acesso direto aos serviços. Para permitir a separação de tarefas, crie contas de serviço com papéis diferentes para fins
específicos. Essas contas de serviço são definidas no módulo data-ingestion e no módulo confidential-data. As contas de serviço são as seguintes:
Uma conta de serviço do controlador do Dataflow que desidentifica dados confidenciais.
Uma conta de serviço do controlador 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:
| Conta de serviço | Nome | Projeto | Papéis |
|---|---|---|---|
Controlador do Dataflow Esta conta é usada para desidentificação. |
sa-dataflow-controller |
Ingestão de dados | |
Controlador do Dataflow Esta conta é usada para reidentificação. |
sa-dataflow-controller-reid |
Dados confidenciais | |
| Cloud Storage | sa-storage-writer |
Ingestão de dados |
|
| Pub/Sub | sa-pubsub-writer |
Ingestão de dados |
|
| Cloud Scheduler | sa-scheduler-controller |
Ingestão de dados |
|
Desidentificação de dados
Você usa a proteção de dados confidenciais 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 ver um exemplo dessa abordagem,
consulte a pasta
/examples/de_identification_template/ (em inglês). 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, você usa tipos de
informações para desidentificar dados.
Para desidentificar dados marcados como confidenciais, use a proteção de dados confidenciais e um pipeline do Dataflow para tokenizá-los. Esse pipeline processa os dados do Cloud Storage e os envia para o armazenamento de dados do BigQuery.
Para mais informações sobre o processo de desidentificação de dados, consulte governança de dados.
Controles de segurança para armazenamento de dados
Configure os seguintes controles de segurança para ajudar a proteger dados no armazenamento do BigQuery:
Controles de acesso no nível da coluna
Contas de serviço com papéis limitados
Políticas organizacionais
Os perímetros do VPC Service Controls entre o projeto confidencial e o projeto não confidencial, com pontes do perímetro apropriadas
Criptografia e gerenciamento de chaves
Controles de acesso no nível da coluna
Para ajudar a proteger dados confidenciais, use controles de acesso para colunas específicas no armazenamento do BigQuery. Para acessar os dados nessas colunas, um analista de dados precisa ter o papel Leitor refinado.
Para definir o acesso de colunas no BigQuery, crie tags de
política. Por exemplo, o arquivo taxonomy.tf
no módulo
bigquery-confidential-data de exemplo 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 confidenciais 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 às colunas marcadas com a tag de política3_Confidential.Uma tag de política
1_Sensitivepara colunas com 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 armazenamento de dados.
Esses controles de acesso garantem que, mesmo depois da nova identificação, as informações não possam ser lidas até que o acesso seja explicitamente concedido ao usuário.
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 roles/iam.serviceAccountUser que os usuários autorizados precisam personificar. A representação da
conta de serviço ajuda os usuários a usar contas de serviço sem
fazer o download das chaves da conta de serviço, o que melhora a segurança geral do projeto. A representação cria
um token de curto prazo que tem permissão para fazer o download de usuários autorizados com o papel roles/iam.serviceAccountTokenCreator.
Políticas organizacionais
Esse blueprint inclui as restrições da política da organização que o blueprint de base corporativa usa e adiciona mais restrições. Para mais informações sobre as restrições usadas pelo blueprint do Enterprise Foundation, consulte Restrições da política da organização.
A tabela a seguir descreve as restrições da política da organização que estão definidas no módulo org_policies:
| Política | Nome da restrição | Valor recomendado |
|---|---|---|
| Restringir implantações de recursos a locais físicos específicos. Para ver outros valores, consulte Grupos de valores. |
gcp.resourceLocations
|
Uma das seguintes opções:in:us-locationsin:eu-locationsin:asia-locations
|
| Desativar criação de conta de serviço |
iam.disableServiceAccountCreation
|
true
|
| Ative o Login do SO nas VMs criadas no projeto. Para mais informações, consulte Como gerenciar o Login do SO em uma organização e Login do SO. |
compute.requireOsLogin
|
true
|
| Restrinja as novas regras de encaminhamento para que sejam apenas internas com base no endereço IP. | compute.restrictProtocolForwardingCreationForTypes
|
INTERNAL
|
| Defina o conjunto de sub-redes VPC compartilhadas que os recursos do Compute Engine podem usar. |
compute.restrictSharedVpcSubnetworks
|
projects/PROJECT_ID/regions/REGION/s
ubnetworks/SUBNETWORK-NAME.Substitua SUBNETWORK-NAME pelo ID do recurso da sub-rede particular que você quer que o blueprint use. |
| Desative a geração de registros de saída da porta serial para o Cloud Logging. | compute.disableSerialPortLogging |
true |
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 anteriormente 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.
Controles operacionais
É possível ativar a geração de registros e os recursos do nível Premium do Security Command Center Premium, como análise de integridade de segurança e detecção de ameaças. Esses controles ajudam você a fazer o seguinte:
Monitore quem está acessando seus dados.
Confira se a auditoria foi realizada de maneira adequada.
Ofereça suporte às equipes de gerenciamento e operações de incidentes para responder a problemas que possam ocorrer.
Transparência no acesso
A transparência no acesso fornece uma notificação em tempo real caso os suportes do Google precisem de acesso aos seus dados. Os registros de transparência no acesso são gerados sempre que uma pessoa acessa o conteúdo. Somente funcionários do Google com justificativas comerciais válidas (por exemplo, um caso de suporte) podem ter acesso. Recomendamos que você ative a Transparência no acesso.
Geração de registros
Para ajudar a atender aos requisitos de auditoria e receber insights sobre seus projetos, configure o Google Cloud Observability com registros de dados dos serviços que você quer rastrear. O módulo centralized-logging configura as seguintes práticas recomendadas:
Como criar um coletor de registros agregado em todos os projetos.
Armazenamento dos registros na região apropriada.
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 conferir outras práticas recomendadas de geração de registros, consulte Controles de detecção.
Alertas e monitoramento
Depois de implantar o blueprint, configure alertas para notificar a central de operações de segurança (SOC) que pode ocorrer um incidente de segurança. Por exemplo, é possível usar alertas para informar seu analista de segurança quando uma permissão do IAM for alterada. Para mais informações sobre como configurar alertas do Security Command Center, consulte Como configurar notificações de localização. Para alertas adicionais que não são publicados pelo Security Command Center, é possível configurar alertas com o Cloud Monitoring.
Outras considerações de segurança
Os controles de segurança neste blueprint foram revisados pela equipe de ação de cibersegurança do Google e por uma equipe de segurança terceirizada. Para solicitar acesso por NDA a um modelo de ameaças STRIDE e ao relatório de avaliação resumida, envie um e-mail para secured-dw-blueprint-support@google.com.
Além dos controles de segurança descritos nesta solução, você precisa revisar e gerenciar a segurança e o risco em áreas importantes que se sobrepõem e interagem com o uso desta solução. Isso inclui o seguinte:
O código usado para configurar, implantar e executar jobs do Dataflow.
Taxonomia de classificação de dados usada com esta solução.
O conteúdo, a qualidade e a segurança dos conjuntos de dados que você armazena e analisa no armazenamento de dados.
O ambiente geral em que você implanta a solução, incluindo o seguinte:
- O design, a segmentação e a segurança das redes conectadas a esta solução.
- A segurança e a governança dos controles do IAM da sua organização.
- As configurações de autenticação e autorização dos agentes a quem você concede acesso à infraestrutura que faz parte desta solução e quem tem acesso aos dados armazenados e gerenciados nessa infraestrutura.
Resumo geral
Para implementar a arquitetura descrita neste documento, faça o seguinte:
Determine se você implantará o blueprint com o blueprint do enterprise foundation ou por conta própria. Se você optar por não implantar o blueprint do enterprise foundation, verifique se o ambiente tem uma linha de base de segurança semelhante.
Leia o arquivo Readme do blueprint e verifique se você atende a todos os pré-requisitos.
No ambiente de teste, implante o tutorial para ver a solução em ação. Como parte do processo de teste, considere o seguinte:
Use o Security Command Center para verificar os projetos recém-criados de acordo com seus requisitos de conformidade.
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.
Implante o blueprint no ambiente de produção.
A seguir
Consulte o blueprint do enterprise foundation do Google Cloud para um ambiente seguro de referência.
Para ver detalhes sobre o blueprint, leia o leia sobre a configuração do Terraform.
Para ver mais práticas recomendadas e blueprints, consulte a central de práticas recomendadas de segurança.