Uma plataforma empresarial de gerenciamento e análise de dados oferece um enclave em que é possível armazenar, analisar e manipular informações sensíveis, mantendo os controles de segurança. Você pode usar a arquitetura de malha de dados empresariais para implantar uma plataforma no Google Cloud para gerenciamento e análise de dados. A arquitetura foi projetada para funcionar em um ambiente híbrido, em que os componentes do Google Cloud interagem com os componentes locais e processos operacionais atuais.
A arquitetura de malha de dados corporativos inclui o seguinte:
- Um repositório do GitHub
que contém um conjunto de configurações, scripts e código do Terraform para criar
o seguinte:
- Um projeto de governança que permite usar a implementação do Google do framework de controles de chave dos recursos de gerenciamento de dados do Cloud (CDMS).
- Um exemplo de plataforma de dados que oferece suporte a fluxos de trabalho interativos e de produção.
- Um ambiente de produção na plataforma de dados que oferece suporte a vários domínios de dados. Os domínios de dados são agrupamentos lógicos de elementos de dados.
- Um ambiente de consumidor na plataforma de dados que oferece suporte a vários projetos de consumidores.
- Um serviço de transferência de dados que usa a federação de identidade da carga de trabalho e a biblioteca de criptografia Tink para ajudar você a transferir dados para Google Cloud de maneira segura.
- Um exemplo de domínio de dados que contém projetos de ingestão, não confidenciais e confidenciais.
- Um exemplo de sistema de acesso aos dados que permite que os consumidores de dados solicitem acesso a conjuntos de dados e que os proprietários de dados concedam acesso a esses conjuntos. O exemplo também inclui um gerenciador de fluxo de trabalho que muda as permissões do IAM desses conjuntos de dados de acordo com a situação.
- Um guia para a arquitetura, o design, os controles de segurança e os processos operacionais a serem implementados com o uso dessa arquitetura (este documento).
A arquitetura de malha de dados empresariais foi projetada para ser compatível com o blueprint de bases empresariais. O blueprint de fundação empresarial fornece vários serviços de nível básico de que essa arquitetura depende, como redes VPC e geração de registros. É possível implantar essa arquitetura sem implantar o blueprint de bases empresariais se o seu ambienteGoogle Cloud fornecer a funcionalidade necessária.
Este documento é destinado a arquitetos de nuvem, cientistas de dados, engenheiros de dados e arquitetos de segurança que podem usar a arquitetura para criar e implantar serviços de dados abrangentes no Google Cloud. Neste documento,presumimos que você esteja familiarizado com os conceitos de malhas de dados, serviços de dados do Google Cloude a implementação do Google Cloud framework CDMC.
Arquitetura
A arquitetura de malha de dados corporativa usa uma abordagem em camadas para oferecer os recursos que permitem ingestão de dados, tratamento de dados e governança. A arquitetura precisa ser implantada e controlada por um fluxo de trabalho de CI/CD. O diagrama a seguir mostra como a camada de dados implantada por essa arquitetura se relaciona com outras camadas no seu ambiente.
O diagrama inclui os seguintes pontos:
- A infraestrutura doGoogle Cloud oferece recursos de segurança, como criptografia em repouso e criptografia em trânsito, além de elementos básicos, como computação e armazenamento.
- A base empresarial fornece uma referência de recursos, como sistemas de identidade, rede, geração de registros, monitoramento e implantação, que permitem adotar o Google Cloud para suas cargas de trabalho de dados.
- A camada de dados oferece vários recursos, como ingestão de dados, armazenamento de dados, controle de acesso aos dados, governança de dados, monitoramento de dados e compartilhamento de dados pessoais.
- A camada de aplicativo representa vários aplicativos diferentes que usam os recursos da camada de dados.
- A CI/CD fornece as ferramentas para automatizar o provisionamento, a configuração, o gerenciamento e a implantação de infraestrutura, fluxos de trabalho e componentes de software. Esses componentes ajudam a garantir implantações consistentes, confiáveis e auditáveis, minimizar erros manuais e acelerar o ciclo de desenvolvimento geral.
Para mostrar como o ambiente de dados é usado, a arquitetura inclui um exemplo de fluxo de trabalho de dados. O fluxo de trabalho de dados de amostra mostra os seguintes processos: governança de dados, ingestão de dados, tratamento de dados, compartilhamento de dados e consumo de dados.
Principais decisões de arquitetura
A tabela a seguir resume as decisões de alto nível da arquitetura.
| arearea de decisão | Decisão |
|---|---|
| Google Cloud architecture | |
Hierarquia de recursos |
A arquitetura usa a hierarquia de recursos do blueprint de bases empresariais. |
Rede |
A arquitetura inclui um exemplo de serviço de transferência de dados que usa a federação de identidade da carga de trabalho e uma biblioteca Tink. |
Funções e permissões do IAM |
A arquitetura inclui papéis segmentados de produtor de dados, papéis de consumidor de dados, papéis de governança de dados e papéis de plataforma de dados. |
| Serviços de dados comuns | |
Metadados |
A arquitetura usa o Data Catalog para gerenciar metadados de dados. |
Gerenciamento central de políticas |
Para gerenciar políticas, a arquitetura usa a implementação do framework CDMC pelo Google Cloud. |
Gerenciamento de acesso aos dados |
Para controlar o acesso aos dados, a arquitetura inclui um processo independente que exige que os consumidores de dados solicitem acesso aos recursos do proprietário dos dados. |
Qualidade dos dados |
A arquitetura usa o Cloud Data Quality Engine para definir e executar regras de qualidade de dados em colunas de tabelas especificadas, medindo a qualidade dos dados com base em métricas como correção e integridade. |
Segurança de dados |
A arquitetura usa controles de inclusão de tags, criptografia, mascaramento, tokenização e IAM para fornecer segurança de dados. |
| Domínio de dados | |
Ambientes de dados |
A arquitetura inclui três ambientes. Dois ambientes (não produção e produção) são ambientes operacionais controlados por pipelines. Um ambiente (desenvolvimento) é interativo. |
Proprietários de dados |
Os proprietários de dados ingerem, processam, expõem e concedem acesso a ativos de dados. |
Consumidores de dados |
Os consumidores de dados solicitam acesso a recursos de dados. |
| Integração e operações | |
Pipelines |
A arquitetura usa os seguintes pipelines para implantar recursos:
|
Repositórios |
Cada pipeline usa um repositório separado para permitir a segregação de responsabilidade. |
Fluxo de processo |
O processo exige que as mudanças no ambiente de produção incluam um remetente e um aprovador. |
| Operações do Cloud | |
Visão geral dos produtos de dados |
O Report Engine gera visões gerais dos produtos de dados. |
Cloud Logging |
A arquitetura usa a infraestrutura de registro em log do blueprint de base empresarial. |
Cloud Monitoring |
A arquitetura usa a infraestrutura de monitoramento do blueprint de base empresarial. |
Identidade: como mapear papéis para grupos
A malha de dados aproveita a arquitetura de autenticação, autorização e gerenciamento do ciclo de vida de identidade do blueprint de bases empresariais. Os usuários não recebem papéis diretamente. Em vez disso, os grupos são o principal método de atribuição de papéis e permissões no IAM. Os papéis e as permissões do IAM são atribuídos durante a criação do projeto pelo pipeline de base.
A malha de dados associa grupos a uma de quatro áreas principais: infraestrutura, governança de dados, produtores de dados baseados em domínio e consumidores baseados em domínio.
Os escopos de permissão para esses grupos são os seguintes:
- O escopo de permissão do grupo de infraestrutura é a malha de dados como um todo.
- O escopo de permissão dos grupos de governança de dados é o projeto de governança de dados.
- As permissões de produtores e consumidores baseadas em domínio são limitadas ao domínio de dados deles.
As tabelas a seguir mostram os vários papéis usados nessa implementação de malha de dados e as permissões associadas.
Infraestrutura
| Grupo | Descrição | Papéis |
|---|---|---|
|
Administradores gerais da malha de dados |
|
Governança de dados
| Grupo | Descrição | Papéis |
|---|---|---|
|
Administradores do projeto de governança de dados |
|
|
Desenvolvedores que criam e mantêm os componentes de governança de dados |
Vários papéis no projeto de governança de dados, incluindo
|
|
Leitores de informações sobre governança de dados |
|
|
Administradores de segurança do projeto de governança |
|
|
Grupo com permissão para usar modelos de tag |
|
|
Grupo com permissão para usar modelos de tag e adicionar tags |
|
|
Grupo de contas de serviço para notificações do Security Command Center |
Nenhuma. Esse é um grupo para associação, e uma conta de serviço é criada com esse nome, que tem as permissões necessárias. |
Produtores de dados baseados em domínio
| Grupo | Descrição | Papéis |
|---|---|---|
|
Administradores de um domínio de dados específico |
|
|
Desenvolvedores que criam e mantêm produtos de dados em um domínio de dados |
Vários papéis no projeto do domínio de dados, incluindo
|
|
Leitores das informações do domínio de dados |
|
|
Editores de entradas do Data Catalog |
Papéis para editar entradas do Data Catalog |
|
Gestores de dados para o domínio de dados |
Funções para gerenciar metadados e aspectos da governança de dados |
Consumidores de dados baseados em domínio
| Grupo | Descrição | Papéis |
|---|---|---|
|
Administradores de um projeto de consumidor específico |
|
|
Desenvolvedores trabalhando em um projeto do consumidor |
Vários papéis no projeto do consumidor, incluindo
|
|
Leitores das informações do projeto do consumidor |
|
Estrutura da organização
Para diferenciar as operações e os dados de produção, a arquitetura usa ambientes diferentes para desenvolver e lançar fluxos de trabalho. As operações Production incluem a governança, a rastreabilidade e a repetibilidade de um fluxo de trabalho e a capacidade de auditoria dos resultados dele. Os dados Production se referem a dados possivelmente sensíveis necessários para administrar sua organização. Todos os ambientes são projetados para ter controles de segurança que permitem ingerir e operar seus dados.
Para ajudar cientistas e engenheiros de dados, a arquitetura inclui um ambiente interativo, em que os desenvolvedores podem trabalhar diretamente com o ambiente e adicionar serviços por um catálogo selecionado de soluções. Os ambientes operacionais são conduzidos por pipelines, que têm arquitetura e configuração codificadas.
Essa arquitetura usa a estrutura organizacional do blueprint de bases empresariais como base para implantar cargas de trabalho de dados. O diagrama a seguir mostra as pastas e os projetos de nível superior usados na arquitetura de malha de dados empresariais.
A tabela a seguir descreve as pastas e os projetos de nível superior que fazem parte da arquitetura.
| Pasta | Componente | Descrição |
|---|---|---|
|
|
Contém o pipeline de implantação usado para criar os artefatos de código da arquitetura. |
|
Contém a infraestrutura usada pelo catálogo de serviços para implantar recursos no ambiente interativo. |
|
|
Contém todos os recursos usados pela implementação do framework do CDMC feita por Google Cloud. |
|
|
|
Contém os projetos e recursos da plataforma de dados para desenvolver casos de uso no modo interativo. |
|
|
Contém os projetos e recursos da plataforma de dados para testar casos de uso que você quer implantar em um ambiente operacional. |
|
|
Contém os projetos e recursos da plataforma de dados para implantação em produção. |
Pasta da plataforma de dados
A pasta da plataforma de dados contém todos os componentes do plano de dados e alguns dos recursos do CDMC. Além disso, a pasta da plataforma de dados e o projeto de governança de dados contêm os recursos do CDMC. O diagrama a seguir mostra as pastas e os projetos implantados na pasta da plataforma de dados.
Cada pasta de plataforma de dados inclui uma pasta de ambiente (produção, não produção e desenvolvimento). A tabela a seguir descreve as pastas em cada pasta da plataforma de dados.
| Pastas | Descrição |
|---|---|
Produtores |
Contém os domínios de dados. |
Consumidores |
Contém os projetos do consumidor. |
Domínio de dados |
Contém os projetos associados a um domínio específico. |
Pasta "Produtores"
Cada pasta de produtores inclui um ou mais domínios de dados. Um domínio de dados se refere a um agrupamento lógico de elementos de dados que compartilham um significado, uma finalidade ou um contexto comercial comum. Com os domínios de dados, é possível categorizar e organizar recursos de dados em uma organização. O diagrama a seguir mostra a estrutura de um domínio de dados. A arquitetura implanta projetos na pasta da plataforma de dados para cada ambiente.
A tabela a seguir descreve os projetos implantados na pasta da plataforma de dados para cada ambiente.
| Projeto | Descrição |
|---|---|
Ingestão |
O projeto de ingestão ingere dados no domínio de dados. A arquitetura fornece exemplos de como fazer streaming de dados para o BigQuery, o Cloud Storage e o Pub/Sub. O projeto de ingestão também contém exemplos do Dataflow e do serviço gerenciado para Apache Airflow que podem ser usados para orquestrar a transformação e a movimentação dos dados ingeridos. |
Não confidencial |
O projeto não confidencial contém dados que foram desidentificados. É possível mascarar, contêinerizar, criptografar, tokenizar ou ofuscar dados. Use tags de política para controlar como os dados são apresentados. |
Confidencial |
O projeto confidencial contém dados de texto simples. É possível controlar o acesso com permissões do IAM. |
Pasta do consumidor
A pasta do consumidor contém projetos pessoais. Os projetos de consumidor oferecem um mecanismo para segmentar usuários de dados com base no limite de confiança necessário. Cada projeto é atribuído a um grupo de usuários separado, e o grupo recebe acesso aos recursos de dados necessários em cada projeto. É possível usar o projeto do consumidor para coletar, analisar e aumentar os dados do grupo.
Pasta comum
A pasta "common" contém os serviços usados por diferentes ambientes e projetos. Esta seção descreve os recursos adicionados à pasta comum para ativar a malha de dados corporativos.
Arquitetura do CDMC
A arquitetura usa a arquitetura do CDMC para governança de dados. As funções de governança de dados estão no projeto de governança de dados na pasta comum. O diagrama a seguir mostra os componentes da arquitetura do CDMC. Os números no diagrama representam os principais controles abordados com os serviços do Google Cloud.
A tabela a seguir descreve os componentes da arquitetura do CDMC usados pela arquitetura de malha de dados corporativos.
| Componente do CDMC | Serviço doGoogle Cloud | Descrição |
|---|---|---|
| Componentes de acesso e ciclo de vida | ||
Gerenciamento de chaves |
Cloud KMS |
Um serviço que gerencia com segurança as chaves de criptografia que protegem dados sensíveis. |
Gerente de registros |
Cloud Run |
Um aplicativo que mantém registros e registros abrangentes de atividades de tratamento de dados, garantindo que as organizações possam rastrear e auditar o uso de dados. |
Política de arquivamento |
BigQuery |
Uma tabela do BigQuery que contém a política de armazenamento de dados. |
Direitos |
BigQuery |
Uma tabela do BigQuery que armazena informações sobre quem pode acessar dados sensíveis. Essa tabela garante que apenas usuários autorizados possam acessar dados específicos com base nas funções e nos privilégios deles. |
| Componentes de verificação | ||
Perda de dados |
Proteção de Dados Sensíveis |
Serviço usado para inspecionar recursos em busca de dados sensíveis. |
Descobertas da DLP |
BigQuery |
Uma tabela do BigQuery que cataloga classificações de dados na plataforma de dados. |
Políticas |
BigQuery |
Uma tabela do BigQuery que contém práticas consistentes de governança de dados (por exemplo, tipos de acesso aos dados). |
Exportação de faturamento |
BigQuery |
Uma tabela que armazena informações de custo exportadas do Cloud Billing para permitir a análise de métricas de custo associadas a recursos de dados. |
Cloud Data Quality Engine |
Cloud Run |
Um aplicativo que executa verificações de qualidade de dados para tabelas e colunas. |
Descobertas de qualidade de dados |
BigQuery |
Uma tabela do BigQuery que registra discrepâncias identificadas entre as regras de qualidade de dados definidas e a qualidade real dos recursos de dados. |
| Componentes de relatórios | ||
Programador |
Cloud Scheduler |
Um serviço que controla quando o Cloud Data Quality Engine é executado e quando a inspeção da Proteção de dados sensíveis ocorre. |
Mecanismo de relatórios |
Cloud Run |
Um aplicativo que gera relatórios para ajudar a rastrear e medir a adesão aos controles da estrutura do CDMC. |
Descobertas e recursos |
BigQuery e Pub/Sub |
Um relatório do BigQuery sobre discrepâncias ou inconsistências nos controles de gerenciamento de dados, como tags ausentes, classificações incorretas ou locais de armazenamento não compatíveis. |
Exportações de tags |
BigQuery |
Uma tabela do BigQuery que contém informações de tag extraídas do Data Catalog. |
| Outros componentes | ||
Gerenciamento de políticas |
Serviço de política da organização |
Um serviço que define e aplica restrições sobre onde os dados podem ser armazenados geograficamente. |
Políticas de acesso com base em atributos |
Access Context Manager |
Um serviço que define e aplica políticas de acesso granular com base em atributos para que apenas usuários autorizados de locais e dispositivos permitidos possam acessar informações sensíveis. |
Metadados |
Data Catalog |
Um serviço que armazena informações de metadados sobre as tabelas em uso na malha de dados. |
Tag Engine |
Cloud Run |
Um aplicativo que adiciona tags aos dados em tabelas do BigQuery. |
Relatórios da CDMC |
Data Studio |
Painéis que permitem aos analistas ver relatórios gerados pelos mecanismos de arquitetura do CDMC. |
Implementação do CDMC
A tabela a seguir descreve como a arquitetura implementa os controles principais no framework do CDMC.
| Requisito de controle do CDMC | Implementação |
|---|---|
O Report Engine detecta recursos de dados não compatíveis e publica descobertas em um tópico do Pub/Sub. Essas descobertas também são carregadas no BigQuery para geração de relatórios usando o Data Studio. |
|
A propriedade dos dados é estabelecida para dados migrados e gerados na nuvem |
O Data Catalog captura automaticamente metadados técnicos do BigQuery. O Tag Engine aplica tags de metadados comerciais, como nome do proprietário e nível de sensibilidade, de uma tabela de referência, o que ajuda a garantir que todos os dados sensíveis sejam marcados com informações do proprietário para fins de conformidade. Esse processo de inclusão de tags automatizado ajuda a fornecer governança de dados e compliance ao identificar e rotular dados sensíveis com as informações de proprietário adequadas. |
A automação rege e apoia o fornecimento e o consumo de dados |
O Data Catalog classifica os recursos de dados marcando-os com uma flag |
Soberania de dados e movimentação de dados entre países são gerenciadas |
O Serviço de políticas da organização define as regiões de armazenamento permitidas para recursos de dados, e o Access Context Manager restringe o acesso com base na localização do usuário. O Data Catalog armazena os locais de armazenamento aprovados como tags de metadados. O Report Engine compara essas tags com a localização real dos recursos de dados no BigQuery e publica as discrepâncias como descobertas usando o Pub/Sub. O Security Command Center oferece uma camada extra de monitoramento gerando descobertas de vulnerabilidade se os dados forem armazenados ou acessados fora das políticas definidas. |
Os catálogos de dados são implementados, usados e interoperáveis |
O Data Catalog armazena e atualiza os metadados técnicos de todos os recursos de dados do BigQuery, criando um Data Catalog sincronizado continuamente. O Data Catalog garante que todas as tabelas e visualizações novas ou modificadas sejam adicionadas imediatamente ao catálogo, mantendo um inventário atualizado de recursos de dados. |
A Proteção de Dados Sensíveis inspeciona os dados do BigQuery e identifica tipos de informações sensíveis. Essas descobertas são classificadas com base em uma tabela de referência de classificação, e o nível de sensibilidade mais alto é atribuído como uma tag no Data Catalog nos níveis da coluna e da tabela. O Tag Engine gerencia esse processo atualizando o Data Catalog com tags de sensibilidade sempre que novos recursos de dados são adicionados ou os existentes são modificados. Esse processo garante uma classificação de dados constantemente atualizada com base na sensibilidade, que você pode monitorar e gerar relatórios usando o Pub/Sub e ferramentas integradas. |
|
Os direitos de dados são gerenciados, aplicados e rastreados |
As tags de política do BigQuery controlam o acesso a dados sensíveis no nível da coluna, garantindo que apenas usuários autorizados possam acessar dados específicos com base na tag de política atribuída. O IAM gerencia o acesso geral ao data warehouse, enquanto o Data Catalog armazena classificações de sensibilidade. Verificações regulares são realizadas para garantir que todos os dados sensíveis tenham tags de política correspondentes, e as discrepâncias são informadas usando o Pub/Sub para correção. |
O acesso, o uso e os resultados éticos dos dados são gerenciados |
Os contratos de compartilhamento de dados pessoais para provedores e consumidores são armazenados em um data warehouse dedicado do BigQuery para controlar as finalidades de consumo. O Data Catalog rotula os ativos de dados com as informações do contrato do provedor, enquanto os contratos do consumidor são vinculados às vinculações do IAM para controle de acesso. Os rótulos de consulta exigem finalidades de consumo, obrigando os consumidores a especificar uma finalidade válida ao consultar dados sensíveis, que é validada em relação aos direitos deles no BigQuery. Uma trilha de auditoria no BigQuery rastreia todo o acesso aos dados e garante a conformidade com os contratos de compartilhamento de dados pessoais. |
A criptografia em repouso padrão do Google ajuda a proteger os dados armazenados em disco. O Cloud KMS oferece suporte a chaves de criptografia gerenciadas pelo cliente (CMEK) para gerenciamento de chaves aprimorado. O BigQuery implementa o mascaramento de dados dinâmicos no nível da coluna para desidentificação e oferece suporte à desidentificação no nível do aplicativo durante a ingestão de dados. O Data Catalog armazena tags de metadados para técnicas de criptografia e desidentificação aplicadas a recursos de dados. As verificações automatizadas garantem que os métodos de criptografia e desidentificação estejam alinhados às políticas de segurança predefinidas, e as discrepâncias são informadas como descobertas usando o Pub/Sub. |
|
Uma estrutura de privacidade de dados é definida e operacional |
O Data Catalog marca recursos de dados sensíveis com informações relevantes para a avaliação de impacto, como local do assunto e links de relatórios de avaliação. O Tag Engine aplica essas tags com base na sensibilidade dos dados e em uma tabela de políticas no BigQuery, que define os requisitos de avaliação com base na residência de dados e de assunto. Esse processo automatizado de inclusão de tags permite o monitoramento e a geração de relatórios contínuos de compliance com os requisitos de avaliação de impacto, garantindo que as avaliações de impacto da proteção de dados (DPIAs) ou de impacto da proteção (PIAs) sejam realizadas quando necessário. |
O Data Catalog rotula recursos de dados com políticas de retenção, especificando períodos de retenção e ações de expiração (como arquivar ou limpar). O Record Manager automatiza a aplicação dessas políticas limpando ou arquivando tabelas do BigQuery com base nas tags definidas. Essa aplicação garante a adesão às políticas de ciclo de vida dos dados e mantém a conformidade com os requisitos de retenção de dados. Todas as discrepâncias são detectadas e informadas usando o Pub/Sub. |
|
O Cloud Data Quality Engine define e executa regras de qualidade de dados em colunas de tabelas especificadas, medindo a qualidade dos dados com base em métricas como correção e integridade. Os resultados dessas verificações, incluindo porcentagens e limites de sucesso, são armazenados como tags no Data Catalog. O armazenamento desses resultados permite o monitoramento e a geração de relatórios contínuos da qualidade dos dados, com problemas ou desvios dos limites aceitáveis publicados como descobertas usando o Pub/Sub. |
|
Os princípios de gerenciamento de custos são estabelecidos e aplicados |
O Data Catalog armazena métricas relacionadas a custos de recursos de dados, como custos de consulta, armazenamento e saída de dados, que são calculados usando informações de faturamento exportadas do Cloud Billing para o BigQuery. O armazenamento de métricas relacionadas a custos permite um rastreamento e uma análise abrangentes de custos, garantindo a adesão às políticas de custos e a utilização eficiente de recursos. Todas as anomalias são informadas usando o Pub/Sub. |
Os recursos integrados de linhagem de dados do Data Catalog rastreiam a procedência e a linhagem dos recursos de dados, representando visualmente o fluxo de dados. Além disso, os scripts de ingestão de dados identificam e marcam a origem original dos dados no Data Catalog, aumentando a capacidade de rastreamento até a origem. |
Gerenciamento de acesso aos dados
O acesso da arquitetura aos dados é controlado por um processo independente que separa o controle operacional (por exemplo, execução de jobs do Dataflow) do controle de acesso aos dados. O acesso de um usuário a um serviço do Google Cloud é definido por uma questão ambiental ou operacional e é provisionado e aprovado por um grupo de engenharia de nuvem. O acesso de um usuário a recursos de dados Google Cloud (por exemplo, uma tabela do BigQuery) é uma questão de privacidade, regulamentação ou governança e está sujeito a um contrato de acesso entre as partes produtora e consumidora, controlado pelos processos a seguir. O diagrama a seguir mostra como o acesso aos dados é provisionado pela interação de diferentes componentes de software.
Conforme mostrado no diagrama anterior, a integração de acessos a dados é processada pelos seguintes processos:
- Os recursos de dados da nuvem são coletados e inventariados pelo Data Catalog.
- O gerenciador de fluxo de trabalho recupera os recursos de dados do Data Catalog.
- Os proprietários de dados são integrados ao gerenciador de fluxos de trabalho.
O funcionamento do gerenciamento de acesso aos dados é o seguinte:
- Um consumidor de dados faz uma solicitação de um recurso específico.
- O proprietário dos dados do recurso é alertado sobre a solicitação.
- O proprietário dos dados aprova ou rejeita a solicitação.
- Se a solicitação for aprovada, o gerenciador de fluxo de trabalho vai transmitir o grupo, o recurso e a tag associada ao mapeador do IAM.
- O mapeador do IAM traduz as tags do gerenciador de fluxos de trabalho em permissões do IAM e concede ao grupo especificado permissões do IAM para o recurso de dados.
- Quando um usuário quer acessar o recurso de dados, o IAM avalia o acesso ao recurso Google Cloud com base nas permissões do grupo.
- Se permitido, o usuário acessa o recurso de dados.
Rede
O processo de segurança de dados começa no aplicativo de origem, que pode estar no local ou em outro ambiente externo aoGoogle Cloud projeto de destino. Antes de qualquer transferência de rede, esse aplicativo usa a federação de identidade da carga de trabalho para se autenticar com segurança nas APIs do Cloud. Usando essas credenciais, ele interage com o Cloud KMS para receber ou unir as chaves necessárias e emprega a biblioteca Tink para realizar a criptografia e a desidentificação iniciais no payload de dados sensíveis de acordo com modelos predefinidos.
Depois que a carga de dados é protegida, ela precisa ser transferida com segurança para o projeto de ingestão do Google Cloud . Para aplicativos locais, você pode usar o Cloud Interconnect ou o Cloud VPN. Na Google Cloud rede, use o Private Service Connect para rotear os dados para o endpoint de ingestão na rede VPC do projeto de destino. O Private Service Connect permite que o aplicativo de origem se conecte às APIs do Google usando endereços IP particulares, garantindo que o tráfego não seja exposto à Internet.
Todo o caminho de rede e os serviços de ingestão de destino (Cloud Storage, BigQuery e Pub/Sub) no projeto de ingestão são protegidos por um perímetro do VPC Service Controls. Esse perímetro impõe um limite de segurança, garantindo que os dados protegidos originados da fonte só possam ser ingeridos nos serviços autorizados doGoogle Cloud dentro desse projeto específico.
Logging
Essa arquitetura usa os recursos do Cloud Logging fornecidos pelo blueprint de base da empresa.
Pipelines
A arquitetura de malha de dados empresarial usa uma série de pipelines para provisionar a infraestrutura, a orquestração, os conjuntos de dados, os pipelines de dados e os componentes de aplicativos. Os pipelines de implantação de recursos da arquitetura usam o Terraform como ferramenta de infraestrutura como código (IaC) e o Cloud Build como serviço de CI/CD para implantar as configurações do Terraform no ambiente de arquitetura. O diagrama a seguir mostra a relação entre os pipelines.
O pipeline de base e o pipeline de infraestrutura fazem parte do blueprint de bases empresariais. A tabela a seguir descreve a finalidade dos pipelines e os recursos que eles provisionam.
| Pipeline | Provisionado por | Recursos |
|---|---|---|
Pipeline de base |
Inicializar |
|
Pipeline de infraestrutura |
Pipeline de base |
|
Pipeline do catálogo de serviços |
Pipeline de infraestrutura |
|
Pipelines de artefato |
Pipeline de infraestrutura |
Os pipelines de artefatos produzem os vários contêineres e outros componentes da base de código usada pela malha de dados. |
Cada pipeline tem o próprio conjunto de repositórios de onde extrai código e arquivos de configuração. Cada repositório tem uma separação de funções em que remetentes e aprovações de implantações de código operacional são as responsabilidades de grupos diferentes.
Implantação interativa pelo catálogo de serviços
Os ambientes interativos são o ambiente de desenvolvimento na arquitetura e estão na pasta de desenvolvimento. A interface principal do ambiente interativo é o catálogo de serviços, que permite aos desenvolvedores usar modelos pré-configurados para instanciar serviços do Google. Esses modelos pré-configurados são conhecidos como modelos de serviço. Os modelos de serviço ajudam você a reforçar sua postura de segurança, como tornar obrigatória a criptografia CMEK, e também impedem que seus usuários tenham acesso direto às APIs do Google.
O diagrama a seguir mostra os componentes do ambiente interativo e como os cientistas de dados implantam recursos.
Para implantar recursos usando o catálogo de serviços, as seguintes etapas ocorrem:
- O engenheiro de MLOps coloca um modelo de recurso do Terraform para Google Cloud em um repositório Git.
- O comando Git Commit aciona um pipeline do Cloud Build.
- O Cloud Build copia o modelo e todos os arquivos de configuração associados para o Cloud Storage.
- O engenheiro de MLOps configura manualmente as soluções e o catálogo de serviços. Em seguida, o engenheiro compartilha o catálogo de serviços com um projeto de serviço no ambiente interativo.
- O cientista de dados seleciona um recurso do catálogo de serviços.
- O catálogo de serviços implanta o modelo no ambiente interativo.
- O recurso extrai todos os scripts de configuração necessários.
- O cientista de dados interage com os recursos.
Pipelines de artefato
O processo de ingestão de dados usa o Airflow Gerenciado e o Dataflow para orquestrar a movimentação e a transformação de dados no domínio de dados. O pipeline de artefatos cria todos os recursos necessários para a ingestão de dados e os move para o local adequado para que os serviços possam acessá-los. O pipeline de artefato cria os artefatos de contêiner que o orquestrador usa.
Controles de segurança
A arquitetura de malha de dados empresarial usa um modelo de segurança de defesa profunda em camadas que inclui recursos padrão do Google Cloud , serviços do Google Cloude recursos de segurança configurados pelo blueprint de base empresarial. O diagrama a seguir mostra as camadas dos vários controles de segurança da arquitetura.
A tabela a seguir descreve os controles de segurança associados aos recursos em cada camada.
| Camada | Recurso | Controle de segurança |
|---|---|---|
Framework do CDMC |
Google Cloud Implementação do CDMC |
Fornece um modelo de governança que ajuda a proteger, gerenciar e controlar seus recursos de dados. Consulte a estrutura de controles principais do CDMC para mais informações. |
Implantação |
Pipeline de infraestrutura |
Fornece uma série de pipelines que implantam infraestrutura, criam contêineres e criam pipelines de dados. O uso de pipelines permite auditabilidade, rastreabilidade e repetibilidade. |
Pipeline de artefato |
Implanta vários componentes que não são implantados pelo pipeline de infraestrutura. |
|
Modelos do Terraform |
Cria a infraestrutura do sistema. |
|
Open Policy Agent |
Ajuda a garantir que a plataforma esteja em conformidade com as políticas selecionadas. |
|
Rede |
Private Service Connect |
Fornece proteções contra exfiltração de dados em torno dos recursos de arquitetura na camada da API e da camada IP. Permite que você se comunique com as APIs do Cloud usando endereços IP particulares para evitar a exposição do tráfego à internet. |
Rede VPC com endereços IP privados |
Ajuda a remover a exposição a ameaças voltadas à Internet. |
|
VPC Service Controls |
Ajuda a proteger recursos sensíveis contra a exfiltração de dados. |
|
Firewall |
Ajuda a proteger a rede VPC contra acesso não autorizado. |
|
Gerenciamento de acesso |
Access Context Manager |
Controla quem pode acessar quais recursos e ajuda a evitar o uso não autorizado deles. |
Federação de identidade da carga de trabalho |
Elimina a necessidade de credenciais externas para transferir dados para a plataforma de ambientes locais. |
|
Data Catalog |
Fornece um índice de recursos disponíveis para os usuários. |
|
IAM |
Oferece acesso refinado. |
|
Criptografia |
Cloud KMS |
Permite gerenciar chaves de criptografia e secrets e ajudar a proteger seus dados com criptografia em repouso e em trânsito. |
Secrets Manager |
Oferece um armazenamento de secrets para pipelines controlados pelo IAM. |
|
Criptografia em repouso |
Por padrão,o Google Cloud criptografa os dados em repouso. |
|
Criptografia em trânsito |
Por padrão,o Google Cloud criptografa dados em trânsito. |
|
Detecção |
Security Command Center |
Ajuda a detectar configurações incorretas e atividades maliciosas na sua organização Google Cloud. |
Arquitetura contínua |
Verifica continuamente sua organização do Google Cloud em relação a uma série de políticas do OPA definidas por você. |
|
Recomendador do IAM |
Analisa as permissões do usuário e fornece sugestões sobre como reduzir as permissões para ajudar a aplicar o princípio de privilégio mínimo. |
|
Firewall Insights |
Analisa regras de firewall, identifica regras de firewall excessivamente permissivas e sugere firewalls mais restritivos para ajudar a fortalecer sua postura geral de segurança. |
|
Cloud Logging |
Fornece visibilidade sobre a atividade do sistema e ajuda a ativar a detecção de anomalias e atividades maliciosas. |
|
Cloud Monitoring |
Monitora os principais indicadores e eventos que podem ajudar a identificar atividades suspeitas. |
|
Preventivo |
Política da organização |
Permite controlar e restringir ações na sua organização do Google Cloud. |
Workflows
As seções a seguir descrevem o fluxo de trabalho do produtor e do consumidor de dados, garantindo controles de acesso adequados com base na sensibilidade dos dados e nas funções do usuário.
Fluxo de trabalho do produtor de dados
O diagrama a seguir mostra como os dados são protegidos durante a transferência para o BigQuery.
O fluxo de trabalho para transferência de dados é o seguinte:
- Um aplicativo integrado à federação de identidade da carga de trabalho usa o Cloud KMS para descriptografar uma chave de criptografia encapsulada.
- O aplicativo usa a biblioteca Tink para desidentificar ou criptografar os dados usando um modelo.
- O aplicativo transfere dados para o projeto de ingestão em Google Cloud.
- Os dados chegam ao Cloud Storage, BigQuery ou Pub/Sub.
- No projeto de ingestão, os dados são descriptografados ou reidentificados usando um modelo.
- Os dados descriptografados são criptografados ou mascarados com base em outro modelo de desidentificação e, em seguida, colocados no projeto não confidencial. As tags são aplicadas pelo mecanismo de inclusão de tag conforme necessário.
- Os dados do projeto não confidencial são transferidos para o projeto confidencial e identificados novamente.
O seguinte acesso aos dados é permitido:
- Os usuários com acesso ao projeto confidencial podem acessar todos os dados brutos em texto simples.
- Os usuários que têm acesso ao projeto não confidencial podem acessar dados mascarados, tokenizados ou criptografados com base nas tags associadas aos dados e nas permissões deles.
Fluxo de trabalho do consumidor de dados
As etapas a seguir descrevem como um consumidor pode acessar dados armazenados no BigQuery.
- O consumidor de dados pesquisa recursos de dados usando o Data Catalog.
- Depois que o consumidor encontra os recursos que procura, ele solicita acesso aos ativos de dados.
- O proprietário dos dados decide se vai conceder acesso aos recursos.
- Se o consumidor conseguir acesso, ele poderá usar um notebook e o Catálogo de soluções para criar um ambiente em que seja possível analisar e transformar os ativos de dados.
resumo geral
O repositório do GitHub oferece instruções detalhadas sobre como implantar a malha de dados emGoogle Cloud depois de implantar a base empresarial. O processo para implantar a arquitetura envolve modificar os repositórios de infraestrutura atuais e implantar novos componentes específicos da malha de dados.
Preencha os campos:
- Conclua todos os pré-requisitos, incluindo:
- Instale a Google Cloud CLI, o Terraform, o Tink, o Java e o Go.
- Implante o blueprint de bases empresariais (v4.1).
- Mantenha os seguintes repositórios locais:
gcp-data-mesh-foundationsgcp-bootstrapgcp-environmentsgcp-networksgcp-orggcp-projects
- Modifique o blueprint de base atual e implante os aplicativos de malha de dados. Para cada item, faça o seguinte:
- No repositório de destino, confira a ramificação
Plan. - Para adicionar componentes da malha de dados, copie os arquivos e diretórios relevantes de
gcp-data-mesh-foundationspara o diretório de base apropriado. Substitua os arquivos quando necessário. - Atualize as variáveis, funções e configurações da malha de dados nos arquivos do Terraform (por exemplo,
*.tfvarse*.tf). Defina os tokens do GitHub como variáveis de ambiente. - Execute as operações de inicialização, planejamento e aplicação do Terraform em cada repositório.
- Faça commit das mudanças, envie o código para o repositório remoto, crie solicitações de pull e faça a mesclagem nos ambientes de desenvolvimento, não produção e produção.
- No repositório de destino, confira a ramificação
A seguir
- Leia sobre a arquitetura e as funções em uma malha de dados.
- Importar dados de Google Cloud para um data warehouse seguro do BigQuery.
- Implemente o framework de controles de chave do CDMC em um data warehouse do BigQuery.
- Leia sobre o blueprint de bases empresariais.