Importar dados do Google Cloud para um data warehouse seguro do BigQuery

Last reviewed 2021-12-16 UTC

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:

Informações gerais

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 de armazenamento de dados confidencial.

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.

Hierarquia de recursos para um armazenamento de dados confidencial.

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
Produção 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
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/dataflow.viewer
  • roles/dataflow.developer
  • roles/logging.viewer
Dados não confidenciais
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/logging.viewer

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
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudbuild.builds.editor
  • roles/cloudkms.viewer
  • roles/compute.networkUser
  • roles/dataflow.admin
  • roles/logging.viewer
Dados não confidenciais
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudkms.viewer
  • roles/logging.viewer

Grupo de administradores de rede

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

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

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:

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 na dataflow_firewall.tf no arquivo dwh-networking módulo repositório. 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
  • roles/storage.objectViewer
  • roles/storage.objectCreator
Veja as descrições desses papéis em Papéis do IAM para o Cloud Storage.
Pub/Sub sa-pubsub-writer Ingestão de dados
  • roles/pubsub.publisher
  • roles/pubsub.subscriber
Veja as descrições desses papéis em Papéis do IAM para o Pub/Sub.
Cloud Scheduler sa-scheduler-controller Ingestão de dados
  • roles/compute.viewer
  • roles/dataflow.developer

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_Confidential para 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ítica 2_Private ou 1_Sensitive.

  • Uma tag de política 2_Private para 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ítica 1_Sensitive. Os usuários não têm acesso às colunas marcadas com a tag de política 3_Confidential.

  • Uma tag de política 1_Sensitive para 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ítica 2_Private ou 3_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-locations
in:eu-locations
in: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:

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 segurança cibernética 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:

  1. 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.

  2. Leia o arquivo Readme do blueprint e verifique se você atende a todos os pré-requisitos.

  3. No ambiente de teste, implante o tutorial para ver a solução em ação. Como parte do processo de teste, considere o seguinte:

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

    2. Adicione seus próprios dados de amostra ao armazenamento do BigQuery.

    3. 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.

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

A seguir