Uma plataforma de gestão e estatísticas de dados empresariais oferece um enclave onde pode armazenar, analisar e manipular informações confidenciais, mantendo os controlos de segurança. Pode usar a arquitetura de malha de dados empresariais para implementar uma plataforma no Google Cloud para gestão e estatísticas de dados. A arquitetura foi concebida para funcionar num ambiente híbrido, onde os Google Cloud componentes interagem com os seus componentes nas instalações e processos de funcionamento existentes.
A arquitetura de malha de dados empresarial 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 governação que lhe permite usar a implementação da Google da estrutura de controlos de chaves das capacidades de gestão de dados na nuvem (CDMS).
- Um exemplo de plataforma de dados que suporta fluxos de trabalho interativos e de produção.
- Um ambiente de produção na plataforma de dados que suporta 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 suporta vários projetos de consumidor.
- Um serviço de transferência de dados que usa a Workload Identity Federation e a biblioteca de encriptação Tink para ajudar a transferir dados para o Google Cloud de forma segura.
- Um exemplo de domínio de dados que contém projetos de carregamento, não confidenciais e confidenciais.
- Um exemplo de um sistema de acesso a dados que permite que os consumidores de dados peçam acesso a conjuntos de dados e que os proprietários de dados concedam acesso a esses conjuntos de dados. O exemplo também inclui um gestor de fluxo de trabalho que altera as autorizações da IAM desses conjuntos de dados em conformidade.
A arquitetura de malha de dados empresarial foi concebida para ser compatível com o projeto de bases empresariais. O projeto de base empresarial oferece vários serviços de nível base dos quais esta arquitetura depende, como redes de VPC e registo. Pode implementar esta arquitetura sem implementar o projeto de base empresarial se o seuGoogle Cloud ambiente fornecer a funcionalidade necessária.
Este documento destina-se a arquitetos da nuvem, cientistas de dados, engenheiros de dados e arquitetos de segurança que podem usar a arquitetura para criar e implementar serviços de dados abrangentes no Google Cloud. Este documento pressupõe que conhece os conceitos de malhas de dados, Google Cloud serviços de dados e a Google Cloud implementação da framework CDMC.
Arquitetura
A arquitetura de malha de dados empresarial adota uma abordagem em camadas para fornecer as capacidades que permitem o carregamento, o tratamento e a governação de dados. A arquitetura destina-se a ser implementada e controlada através de um fluxo de trabalho de CI/CD. O diagrama seguinte mostra como a camada de dados implementada por esta arquitetura se relaciona com outras camadas no seu ambiente.
Este diagrama inclui o seguinte:
- A Google Cloud infraestrutura oferece capacidades de segurança, como encriptação em repouso e encriptação em trânsito, bem como bases básicas, como computação e armazenamento.
- A base empresarial oferece uma base de recursos, como identidade, rede, registo, monitorização e sistemas de implementação que lhe permitem adotar Google Cloud para as suas cargas de trabalho de dados.
- A camada de dados oferece várias capacidades, como carregamento de dados, armazenamento de dados, controlo de acesso aos dados, governação de dados, monitorização de dados e partilha de dados.
- A camada de aplicação representa várias aplicações diferentes que usam os recursos da camada de dados.
- A CI/CD fornece as ferramentas para automatizar o aprovisionamento, a configuração, a gestão e a implementação de infraestruturas, fluxos de trabalho e componentes de software. Estes componentes ajudam a garantir implementações consistentes, fiáveis e auditáveis; minimizam os erros manuais; e aceleram o ciclo de desenvolvimento geral.
Para mostrar como o ambiente de dados é usado, a arquitetura inclui um fluxo de trabalho de dados de amostra. O fluxo de trabalho de dados de amostra explica os seguintes processos: gestão de dados, carregamento de dados, processamento de dados, partilha de dados e consumo de dados.
Principais decisões de arquitetura
A tabela seguinte resume as decisões de nível superior da arquitetura.
| Área de decisão | Decisão |
|---|---|
| Google Cloud arquitetura | |
Hierarquia de recursos |
A arquitetura usa a hierarquia de recursos do esquema de base empresarial. |
Trabalhar em rede |
A arquitetura inclui um serviço de transferência de dados de exemplo que usa a federação de identidades da carga de trabalho e uma biblioteca Tink. |
Funções e autorizações de IAM |
A arquitetura inclui funções de produtor de dados segmentadas, funções de consumidor de dados, funções de administração de dados e funções de plataforma de dados. |
| Serviços de dados comuns | |
Metadados |
A arquitetura usa o Data Catalog para gerir metadados de dados. |
Gestão central de políticas |
Para gerir políticas, a arquitetura usa a implementação da framework CDMC da Google Cloud. |
Gestão de acessos a dados |
Para controlar o acesso aos dados, a arquitetura inclui um processo independente que exige que os consumidores de dados solicitem acesso aos recursos de dados ao proprietário dos dados. |
Qualidade de dados |
A arquitetura usa o Cloud Data Quality Engine para definir e executar regras de qualidade dos dados em colunas de tabelas especificadas, medindo a qualidade dos dados com base em métricas como a correção e a integridade. |
Segurança dos dados |
A arquitetura usa etiquetagem, encriptação, ocultação, tokenização e controlos de 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 que são geridos por pipelines. Um ambiente (desenvolvimento) é um ambiente interativo. |
Proprietários dos dados |
Os proprietários de dados carregam, processam, expõem e concedem acesso a recursos de dados. |
Consumidores de dados |
Os consumidores de dados pedem acesso a recursos de dados. |
| Integração e operações | |
Pipelines |
A arquitetura usa os seguintes pipelines para implementar recursos:
|
Repositórios |
Cada pipeline usa um repositório separado para permitir a segregação de responsabilidades. |
Fluxo de processo |
O processo requer que as alterações ao ambiente de produção incluam um remetente e um aprovador. |
| Operações na nuvem | |
Tabelas de dados de produtos de dados |
O Report Engine gera tabelas de dados de produtos. |
Cloud Logging |
A arquitetura usa a infraestrutura de registo do esquema de base empresarial. |
Cloud Monitoring |
A arquitetura usa a infraestrutura de monitorização do esquema fundamental empresarial. |
Identidade: mapeamento de funções para grupos
A malha de dados tira partido da gestão do ciclo de vida da identidade, da autorização e da arquitetura de autenticação existentes no projeto de base empresarial. Os utilizadores não têm funções atribuídas diretamente. Em alternativa, os grupos são o método principal de atribuição de funções e autorizações na IAM. As funções e as autorizações do IAM são atribuídas durante a criação do projeto através do 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ínios> e consumidores baseados em domínios.
Os âmbitos de autorização para estes grupos são os seguintes:
- O âmbito de autorização do grupo de infraestrutura é a malha de dados como um todo.
- O âmbito de autorização dos grupos de gestão de dados é o projeto de gestão de dados.
- As permissões de produtores e consumidores baseadas em domínios têm âmbito no respetivo domínio de dados.
As tabelas seguintes mostram as várias funções usadas nesta implementação da malha de dados e as respetivas autorizações associadas.
Infraestrutura
| Grupo | Descrição | Funções |
|---|---|---|
|
Administradores gerais da malha de dados |
|
Gestão de dados
| Grupo | Descrição | Funções |
|---|---|---|
|
Administradores do projeto de gestão de dados |
|
|
Programadores que criam e mantêm os componentes de administração de dados |
Várias funções no projeto de administração de dados, incluindo
|
|
Leitores de informações de administração de dados |
|
|
Administradores de segurança do projeto de gestão |
|
|
Grupo com autorização para usar modelos de etiquetas |
|
|
Grupo com autorização para usar modelos de etiquetas e adicionar etiquetas |
|
|
Grupo de contas de serviço para notificações do Security Command Center |
Nenhum. Este é um grupo para adesão, e é criada uma conta de serviço com este nome, que tem as autorizações necessárias. |
Produtores de dados baseados em domínios
| Grupo | Descrição | Funções |
|---|---|---|
|
Administradores de um domínio de dados específico |
|
|
Programadores que criam e mantêm produtos de dados num domínio de dados |
Várias funções no projeto do domínio de dados, incluindo
funções do BigQuery e funções do Cloud Storage |
|
Leitores das informações do domínio de dados |
|
|
Editores de entradas do Data Catalog |
Funções para editar entradas do catálogo de dados |
|
Responsáveis pelos dados do domínio de dados |
Funções para gerir os aspetos de metadados e gestão de dados |
Consumidores de dados baseados em domínios
| Grupo | Descrição | Funções |
|---|---|---|
|
Administradores de um projeto de consumidor específico |
|
|
Programadores a trabalhar num projeto do consumidor |
Várias funções no projeto de consumidor, incluindo funções do
|
|
Leitores das informações do projeto do consumidor |
|
Estrutura da organização
Para diferenciar entre as operações de produção e os dados de produção, a arquitetura usa diferentes ambientes para desenvolver e lançar fluxos de trabalho. As operações de produção incluem a governação, a rastreabilidade e a repetibilidade de um fluxo de trabalho, bem como a capacidade de auditoria dos resultados do fluxo de trabalho. Os dados de produção referem-se a dados possivelmente confidenciais de que precisa para gerir a sua organização. Todos os ambientes foram concebidos para ter controlos de segurança que lhe permitem carregar e operar os seus dados.
Para ajudar os cientistas e os engenheiros de dados, a arquitetura inclui um ambiente interativo, onde os programadores podem trabalhar diretamente com o ambiente e adicionar serviços através de um catálogo organizado de soluções. Os ambientes operacionais são conduzidos através de pipelines que têm uma arquitetura e uma configuração codificadas.
Esta arquitetura usa a estrutura organizacional do projeto detalhado de bases empresariais como base para implementar cargas de trabalho de dados. O diagrama seguinte mostra as pastas e os projetos de nível superior usados na arquitetura de malha de dados empresariais.
A tabela seguinte descreve as pastas e os projetos de nível superior que fazem parte da arquitetura.
| Pasta | Componente | Descrição |
|---|---|---|
|
|
Contém o pipeline de implementação usado para criar os artefactos de código da arquitetura. |
|
Contém a infraestrutura usada pelo Service Catalog para implementar recursos no ambiente interativo. |
|
|
Contém todos os recursos usados pela implementação do Google Cloudframework CDMC. |
|
|
|
Contém os projetos e os recursos da plataforma de dados para desenvolver exemplos de utilização no modo interativo. |
|
|
Contém os projetos e os recursos da plataforma de dados para casos de utilização de testes que quer implementar num ambiente operacional. |
|
|
Contém os projetos e os recursos da plataforma de dados para implementaçã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 governação de dados contêm os recursos do CDMC. O diagrama seguinte mostra as pastas e os projetos implementados na pasta da plataforma de dados.
Cada pasta da plataforma de dados inclui uma pasta de ambiente (produção, não produção e desenvolvimento). A tabela seguinte 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 Producers
Cada pasta de produtores inclui um ou mais domínios de dados. Um domínio de dados refere-se a um agrupamento lógico de elementos de dados que partilham um significado, uma finalidade ou um contexto empresarial comuns. Os domínios de dados permitem-lhe categorizar e organizar recursos de dados numa organização. O diagrama seguinte mostra a estrutura de um domínio de dados. A arquitetura implementa projetos na pasta da plataforma de dados para cada ambiente.
A tabela seguinte descreve os projetos implementados na pasta da plataforma de dados para cada ambiente.
| Projeto | Descrição |
|---|---|
Carregamento |
O projeto de carregamento carrega dados para o domínio de dados. A arquitetura oferece exemplos de como pode transmitir dados para o BigQuery, o Cloud Storage e o Pub/Sub. O projeto de carregamento também contém exemplos do Dataflow e do Cloud Composer que pode usar para orquestrar a transformação e a movimentação dos dados carregados. |
Não confidencial |
O projeto não confidencial contém dados que foram desidentificados. Pode ocultar, colocar em contentores, encriptar, tokenizar ou tornar os dados ininteligíveis. Use etiquetas de políticas para controlar a forma como os dados são apresentados. |
Confidencial |
O projeto confidencial contém dados de texto simples. Pode controlar o acesso através de autorizações de IAM. |
Pasta do consumidor
A pasta do consumidor contém projetos do consumidor. Os projetos de consumidor oferecem um mecanismo para segmentar os utilizadores de dados com base no respetivo limite de confiança necessário. Cada projeto é atribuído a um grupo de utilizadores separado, e o grupo tem acesso aos recursos de dados necessários projeto a projeto. Pode usar o projeto de consumidor para recolher, analisar e aumentar os dados do grupo.
Pasta comum
A pasta comum contém os serviços usados por diferentes ambientes e projetos. Esta secção descreve as capacidades que são adicionadas à pasta comum para ativar a malha de dados empresarial.
Arquitetura CDMC
A arquitetura usa a arquitetura CDMC para a gestão de dados. As funções de administração de dados residem no projeto de administração de dados na pasta comum. O diagrama seguinte mostra os componentes da arquitetura do CDMC. Os números no diagrama representam os controlos principais abordados com os serviços Google Cloud.
A tabela seguinte descreve os componentes da arquitetura CDMC que a arquitetura de malha de dados empresarial usa.
| Componente CDMC | Google Cloud serviço | Descrição |
|---|---|---|
| Componentes de acesso e ciclo de vida | ||
Gestão de chaves |
Cloud KMS |
Um serviço que gere de forma segura as chaves de encriptação que protegem os dados confidenciais. |
Gestor de registos |
Cloud Run |
Uma aplicação que mantém registos abrangentes de atividades de processamento de dados, garantindo que as organizações podem monitorizar e auditar a utilização de dados. |
Política de arquivo |
BigQuery |
Uma tabela do BigQuery que contém a política de armazenamento para dados. |
Concessões |
BigQuery |
Uma tabela do BigQuery que armazena informações sobre quem pode aceder a dados confidenciais. Esta tabela garante que apenas os utilizadores autorizados podem aceder a dados específicos com base nas respetivas funções e privilégios. |
| Analisar componentes | ||
Perda de dados |
Proteção de dados confidenciais |
Serviço usado para inspecionar recursos quanto a dados confidenciais. |
Resultados da DLP |
BigQuery |
Uma tabela do BigQuery que cataloga as classificações de dados na plataforma de dados. |
Políticas |
BigQuery |
Uma tabela do BigQuery que contém práticas de administração de dados consistentes (por exemplo, tipos de acesso aos dados). |
Exportação de faturação |
BigQuery |
Uma tabela que armazena informações de custos exportadas da Faturação do Google Cloud para permitir a análise de métricas de custos associadas a recursos de dados. |
Cloud Data Quality Engine |
Cloud Run |
Uma aplicação que executa verificações de qualidade de dados para tabelas e colunas. |
Conclusões sobre a qualidade de dados |
BigQuery |
Uma tabela do BigQuery que regista as 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 motor de qualidade de dados na nuvem é executado e quando ocorre a inspeção da proteção de dados confidenciais. |
Report Engine |
Cloud Run |
Uma aplicação que gera relatórios que ajudam a monitorizar e medir a conformidade com os controlos da estrutura CDMC. |
Resultados e recursos |
BigQuery e Pub/Sub |
Um relatório do BigQuery de discrepâncias ou inconsistências nos controlos de gestão de dados, como etiquetas em falta, classificações incorretas ou localizações de armazenamento não conformes. |
Exportações de etiquetas |
BigQuery |
Uma tabela do BigQuery que contém informações de etiquetas extraídas do Data Catalog. |
| Outros componentes | ||
Gestão de políticas |
Serviço de políticas da organização |
Um serviço que define e aplica restrições sobre onde os dados podem ser armazenados geograficamente. |
Políticas de acesso baseadas em atributos |
Gestor de acesso sensível ao contexto |
Um serviço que define e aplica políticas de acesso detalhadas baseadas em atributos, para que apenas os utilizadores autorizados de localizações e dispositivos permitidos possam aceder a informações confidenciais. |
Metadados |
Data Catalog |
Um serviço que armazena informações de metadados sobre as tabelas que estão a ser usadas na malha de dados. |
Motor de etiquetas |
Cloud Run |
Uma aplicação que adiciona etiquetas a dados em tabelas do BigQuery. |
Relatórios do CDMC |
Looker Studio |
Painéis de controlo que permitem aos seus analistas ver relatórios gerados pelos motores da arquitetura CDMC. |
Implementação do CDMC
A tabela seguinte descreve como a arquitetura implementa os controlos principais na estrutura do CDMC.
| Requisito de controlo do CDMC | Implementação |
|---|---|
O motor de relatórios deteta recursos de dados não conformes e publica conclusões num tópico do Pub/Sub. Estas conclusões também são carregadas no BigQuery para a criação de relatórios através do Looker Studio. |
|
A propriedade dos dados é estabelecida para os dados migrados e gerados na nuvem |
O Data Catalog captura automaticamente metadados técnicos do BigQuery. O Tag Engine aplica etiquetas de metadados empresariais, como o nome do proprietário e o nível de sensibilidade, a partir de uma tabela de referência, o que ajuda a garantir que todos os dados confidenciais são etiquetados com informações do proprietário para fins de conformidade. Este processo de etiquetagem automática ajuda a fornecer governação e conformidade de dados através da identificação e etiquetagem de dados confidenciais com as informações do proprietário adequadas. |
A obtenção e o consumo de dados são regidos e suportados pela automatização |
O catálogo de dados classifica os recursos de dados etiquetando-os com uma flag |
A soberania dos dados e a movimentação de dados transfronteiriça são geridas |
O serviço de políticas da organização define as regiões de armazenamento permitidas para os recursos de dados e o Access Context Manager restringe o acesso com base na localização do utilizador. O catálogo de dados armazena as localizações de armazenamento aprovadas como etiquetas de metadados. O motor de relatórios compara estas etiquetas com a localização real dos recursos de dados no BigQuery e publica quaisquer discrepâncias como resultados através do Pub/Sub. O Security Command Center oferece uma camada de monitorização adicional gerando resultados de vulnerabilidades se os dados forem armazenados ou acedidos 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 efetivamente um Data Catalog sincronizado continuamente. O catálogo de dados garante que todas as tabelas e vistas novas ou modificadas são adicionadas imediatamente ao catálogo, mantendo um inventário atualizado de recursos de dados. |
A proteção de dados confidenciais inspeciona os dados do BigQuery e identifica os tipos de informações confidenciais. Em seguida, estas conclusões são classificadas com base numa tabela de referência de classificação, e o nível de sensibilidade mais elevado é atribuído como uma etiqueta no catálogo de dados ao nível da coluna e da tabela. A etiqueta do motor gere este processo atualizando o catálogo de dados com etiquetas de sensibilidade sempre que são adicionados novos recursos de dados ou os existentes são modificados. Este processo garante uma classificação dos dados constantemente atualizada com base na sensibilidade, que pode monitorizar e comunicar através do Pub/Sub e de ferramentas de relatórios integradas. |
|
As etiquetas de políticas do BigQuery controlam o acesso a dados confidenciais ao nível da coluna, garantindo que apenas os utilizadores autorizados podem aceder a dados específicos com base na respetiva etiqueta de política atribuída. A IAM gere o acesso geral ao data warehouse, enquanto o Data Catalog armazena classificações de sensibilidade. São realizadas verificações regulares para garantir que todos os dados confidenciais têm etiquetas de políticas correspondentes, com quaisquer discrepâncias comunicadas através do Pub/Sub para remediação. |
|
O acesso, a utilização e os resultados dos dados éticos são geridos |
Os contratos de partilha de dados para fornecedores e consumidores são armazenados num armazém de dados do BigQuery dedicado para fins de controlo do consumo. O catálogo de dados etiqueta os recursos de dados com as informações do contrato do fornecedor, enquanto os contratos do consumidor estão associados a associações da IAM para controlo de acesso. As etiquetas de consulta aplicam finalidades de consumo, o que exige que os consumidores especifiquem uma finalidade válida quando consultam dados confidenciais, que é validada em função dos respetivos direitos no BigQuery. Uma trilha de auditoria no BigQuery monitoriza todo o acesso aos dados e garante a conformidade com os contratos de partilha de dados. |
A encriptação em repouso predefinida da Google ajuda a proteger os dados armazenados no disco. O Cloud KMS suporta chaves de encriptação geridas pelo cliente (CMEK) para uma gestão de chaves melhorada. O BigQuery implementa a ocultação dinâmica de dados ao nível da coluna para desidentificação e suporta a desidentificação ao nível da aplicação durante a ingestão de dados. O catálogo de dados armazena etiquetas de metadados para técnicas de encriptação e desidentificação que são aplicadas a recursos de dados. As verificações automáticas garantem que os métodos de encriptação e desidentificação estão alinhados com as políticas de segurança predefinidas, com quaisquer discrepâncias que são comunicadas como conclusões através do Pub/Sub. |
|
A estrutura de privacidade dos dados está definida e operacional |
O catálogo de dados etiqueta os recursos de dados confidenciais com informações relevantes para a avaliação de impacto, como a localização do assunto e links para relatórios de avaliação. O Tag Engine aplica estas etiquetas com base na sensibilidade dos dados e numa tabela de políticas no BigQuery, que define os requisitos de avaliação com base na residência dos dados e do sujeito. Este processo de etiquetagem automatizado permite a monitorização e a criação de relatórios contínuos da conformidade com os requisitos de avaliação de impacto, garantindo que as avaliações de impacto da proteção de dados (AIPDs) ou as avaliações de impacto da proteção (AIPs) são realizadas quando necessário. |
O catálogo de dados etiqueta os recursos de dados com políticas de retenção, especificando períodos de retenção e ações de expiração (como arquivo ou remoção completa). O Gestor de registos automatiza a aplicação destas políticas purgando ou arquivando tabelas do BigQuery com base nas etiquetas definidas. Esta aplicação garante a conformidade com as políticas do ciclo de vida dos dados e mantém a conformidade com os requisitos de retenção de dados, com quaisquer discrepâncias detetadas e comunicadas através do Pub/Sub. |
|
O motor de qualidade de dados na nuvem define e executa regras de qualidade de dados nas colunas de tabelas especificadas, medindo a qualidade de dados com base em métricas como a correção e a integridade. Os resultados destas verificações, incluindo as percentagens de sucesso e os limites, são armazenados como etiquetas no Data Catalog. O armazenamento destes resultados permite a monitorização e a criação de relatórios contínuos da qualidade dos dados, com quaisquer problemas ou desvios dos limites aceitáveis publicados como conclusões através do Pub/Sub. |
|
Os princípios de gestão de custos estão estabelecidos e são aplicados |
O Data Catalog armazena métricas relacionadas com custos para recursos de dados, como custos de consultas, custos de armazenamento e custos de saída de dados, que são calculados através de informações de faturação exportadas da Cloud Billing para o BigQuery. O armazenamento de métricas relacionadas com custos permite uma análise e uma monitorização de custos abrangentes, garantindo a conformidade com as políticas de custos e a utilização eficiente dos recursos, com todas as anomalias comunicadas através do Pub/Sub. |
As funcionalidades de linhagem de dados incorporadas do catálogo de dados acompanham a proveniência e a linhagem dos recursos de dados, representando visualmente o fluxo de dados. Além disso, os scripts de carregamento de dados identificam e etiquetam a origem original dos dados no catálogo de dados, o que melhora a rastreabilidade dos dados até à sua origem. |
Gestão de acessos a dados
O acesso da arquitetura aos dados é controlado através de um processo independente que separa o controlo operacional (por exemplo, a execução de tarefas do Dataflow) do controlo de acesso aos dados. O acesso de um utilizador a um Google Cloud serviço é definido por uma preocupação ambiental ou operacional e é aprovisionado e aprovado por um grupo de engenharia na nuvem. O acesso de um utilizador a Google Cloud recursos de dados (por exemplo, uma tabela do BigQuery) é uma preocupação de privacidade, regulamentar ou de governação e está sujeito a um contrato de acesso entre as partes produtoras e consumidoras, e é controlado através dos seguintes processos. O diagrama seguinte mostra como o acesso aos dados é aprovisionado através da interação de diferentes componentes de software.
Conforme mostrado no diagrama anterior, a integração dos acessos aos dados é processada pelos seguintes processos:
- Os recursos de dados na nuvem são recolhidos e inventariados pelo Data Catalog.
- O gestor de fluxo de trabalho obtém os recursos de dados do catálogo de dados.
- Os proprietários de dados são integrados no gestor de fluxo de trabalho.
O funcionamento da gestão de acessos a dados é o seguinte:
- Um consumidor de dados faz um pedido de um recurso específico.
- O proprietário dos dados do recurso é alertado para o pedido.
- O proprietário dos dados aprova ou rejeita o pedido.
- Se o pedido for aprovado, o gestor de fluxo de trabalho passa o grupo, o recurso e a etiqueta associada ao mapeador do IAM.
- O mapeador de IAM traduz as etiquetas do gestor de fluxo de trabalho em autorizações de IAM e atribui ao grupo especificado autorizações de IAM para o recurso de dados.
- Quando um utilizador quer aceder ao recurso de dados, o IAM avalia o acesso ao recurso com base nas autorizações do grupo. Google Cloud
- Se for permitido, o utilizador acede ao recurso de dados.
Trabalhar em rede
O processo de segurança de dados é iniciado na aplicação de origem, que pode residir no local ou noutro ambiente externo ao projeto de destinoGoogle Cloud . Antes de ocorrer qualquer transferência de rede, esta aplicação usa a Workload Identity Federation para se autenticar de forma segura nas APIs Google Cloud. Através destas credenciais, interage com o Cloud KMS para obter ou encapsular as chaves necessárias e, em seguida, usa a biblioteca Tink para realizar a encriptação inicial e a desidentificação no payload de dados confidenciais de acordo com modelos predefinidos.
Depois de a carga útil de dados estar protegida, tem de ser transferida em segurança para o Google Cloud projeto de carregamento. Para aplicações nas instalações, pode usar o Cloud Interconnect ou, potencialmente, o Cloud VPN. Na Google Cloud rede, use o Private Service Connect para encaminhar os dados para o ponto final de carregamento na rede VPC do projeto de destino. O Private Service Connect permite que a aplicação de origem se ligue às APIs Google através de endereços IP privados, garantindo que o tráfego não é exposto à Internet.
Todo o caminho de rede e os serviços de carregamento de destino (Cloud Storage, BigQuery e Pub/Sub) no projeto de carregamento estão protegidos por um perímetro dos VPC Service Controls. Este perímetro aplica um limite de segurança, garantindo que os dados protegidos provenientes da origem só podem ser carregados nos serviços autorizados no âmbito desse projeto específico.Google Cloud
Registo
Esta arquitetura usa as capacidades do Cloud Logging fornecidas pelo projeto de base empresarial.
Pipelines
A arquitetura de malha de dados empresarial usa uma série de pipelines para aprovisionar a infraestrutura, a orquestração, os conjuntos de dados, os pipelines de dados e os componentes da aplicação. Os pipelines de implementaçã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 implementar as configurações do Terraform no ambiente de arquitetura. O diagrama seguinte mostra a relação entre os pipelines.
O pipeline de base e o pipeline de infraestrutura fazem parte do projeto de bases empresariais. A tabela seguinte descreve a finalidade dos pipelines e os recursos que aprovisionam.
| Fornecimento | Aprovisionado por | Recursos |
|---|---|---|
Pipeline de fundações |
Bootstrap |
|
Pipeline de infraestrutura |
Pipeline de fundações |
|
Pipeline do catálogo de serviços |
Pipeline de infraestrutura |
|
Pipelines de artefactos |
Pipeline de infraestrutura |
Os pipelines de artefactos produzem os vários contentores e outros componentes do código base usado pela malha de dados. |
Cada pipeline tem o seu próprio conjunto de repositórios a partir dos quais extrai código e ficheiros de configuração. Cada repositório tem uma separação de funções em que os responsáveis pelo envio e pela aprovação das implementações de código operacional são grupos diferentes.
Implementação interativa através do catálogo de serviços
Os ambientes interativos são o ambiente de programação na arquitetura e existem na pasta de programação. A interface principal do ambiente interativo é o catálogo de serviços, que permite aos programadores usar modelos pré-configurados para instanciar serviços Google. Estes modelos pré-configurados são conhecidos como modelos de serviços. Os modelos de serviços ajudam a aplicar a sua postura de segurança, como tornar a encriptação CMEK obrigatória, e também impedem que os utilizadores tenham acesso direto às APIs Google.
O diagrama seguinte mostra os componentes do ambiente interativo e como os cientistas de dados implementam recursos.
Para implementar recursos através do Service Catalog, ocorrem os seguintes passos:
- O engenheiro de MLOps coloca um modelo de recurso do Terraform para Google Cloud num repositório Git.
- O comando Git Commit aciona um pipeline do Cloud Build.
- O Cloud Build copia o modelo e todos os ficheiros de configuração associados para o Cloud Storage.
- O engenheiro de MLOps configura as soluções do catálogo de serviços e o catálogo de serviços manualmente. Em seguida, o engenheiro partilha o catálogo de serviços com um projeto de serviço no ambiente interativo.
- O cientista de dados seleciona um recurso no catálogo de serviços.
- O catálogo de serviços implementa 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 artefactos
O processo de carregamento de dados usa o Cloud Composer e o Dataflow para orquestrar a movimentação e a transformação de dados no domínio de dados. O pipeline de artefactos cria todos os recursos necessários para o carregamento de dados e move os recursos para a localização adequada para que os serviços acedam aos mesmos. O pipeline de artefactos cria os artefactos de contentores que o orquestrador usa.
Controlos de segurança
A arquitetura de malha de dados empresarial usa um modelo de segurança de defesa em profundidade em camadas que inclui capacidades, serviços e capacidades de segurança predefinidas que são configuradas através do esquema de base empresarial. Google Cloud Google CloudO diagrama seguinte mostra as camadas dos vários controlos de segurança para a arquitetura.
A tabela seguinte descreve os controlos de segurança associados aos recursos em cada camada.
| Camada | Recurso | Controlo de segurança |
|---|---|---|
Estrutura CDMC |
Google Cloud Implementação do CDMC |
Oferece uma estrutura de governação que ajuda a proteger, gerir e controlar os seus recursos de dados. Consulte o CDMC Key Controls Framework para mais informações. |
Implementação |
Pipeline de infraestrutura |
Fornece uma série de pipelines que implementam infraestrutura, criam contentores e criam pipelines de dados. A utilização de pipelines permite a auditabilidade, a rastreabilidade e a repetibilidade. |
Pipeline de artefactos |
Implementa vários componentes não implementados pelo pipeline de infraestrutura. |
|
Modelos do Terraform |
Desenvolve a infraestrutura do sistema. |
|
Open Policy Agent |
Ajuda a garantir que a plataforma está em conformidade com as políticas selecionadas. |
|
Rede |
Private Service Connect |
Oferece proteções contra a exfiltração de dados em torno dos recursos de arquitetura na camada de API e na camada de IP. Permite-lhe comunicar com as Google Cloud APIs através de endereços IP privados, para que possa evitar a exposição do tráfego à Internet. |
Rede VPC com endereços IP privados |
Ajuda a remover a exposição a ameaças viradas para a Internet. |
|
VPC Service Controls |
Ajuda a proteger recursos confidenciais contra a exfiltração de dados. |
|
Firewall |
Ajuda a proteger a rede VPC contra o acesso não autorizado. |
|
Gestão do acesso |
Gestor de acesso sensível ao contexto |
Controla quem pode aceder a que recursos e ajuda a impedir a utilização não autorizada dos seus recursos. |
Workload Identity Federation |
Elimina a necessidade de credenciais externas para transferir dados para a plataforma a partir de ambientes no local. |
|
Data Catalog |
Fornece um índice de recursos disponíveis para os utilizadores. |
|
IAM |
Oferece acesso detalhado. |
|
Encriptação |
Cloud KMS |
Permite-lhe gerir as suas chaves de encriptação e segredos, e ajudar a proteger os seus dados através da encriptação em repouso e da encriptação em trânsito. |
Secrets Manager |
Oferece um armazenamento secreto para pipelines controlados pela IAM. |
|
Encriptação em repouso |
Por predefinição, Google Cloud encripta os dados em repouso. |
|
Encriptação em trânsito |
Por predefinição, Google Cloud encriptaos dados em trânsito. |
|
Detetive |
Security Command Center |
Ajuda a detetar configurações incorretas e atividade maliciosa na sua Google Cloud organização. |
Arquitetura contínua |
Verifica continuamente a sua Google Cloud organização em relação a uma série de políticas da OPA que definiu. |
|
IAM Recommender |
Analisa as autorizações dos utilizadores e fornece sugestões sobre a redução das autorizações para ajudar a aplicar o princípio do menor privilégio. |
|
Firewall Insights |
Analisa as regras de firewall, identifica regras de firewall excessivamente permissivas e sugere firewalls mais restritivos para ajudar a reforçar a sua postura de segurança geral. |
|
Cloud Logging |
Oferece visibilidade da atividade do sistema e ajuda a ativar a deteção de anomalias e atividade maliciosa. |
|
Cloud Monitoring |
Monitoriza sinais e eventos principais que podem ajudar a identificar atividade suspeita. |
|
Preventivo |
Política da organização |
Permite-lhe controlar e restringir ações na sua Google Cloud organização. |
Workflows
As secções seguintes descrevem o fluxo de trabalho do produtor de dados e o fluxo de trabalho do consumidor de dados, garantindo controlos de acesso adequados com base na sensibilidade dos dados e nas funções do utilizador.
Fluxo de trabalho do produtor de dados
O diagrama seguinte mostra como os dados são protegidos à medida que são transferidos para o BigQuery.
O fluxo de trabalho para a transferência de dados é o seguinte:
- Uma aplicação integrada com a Workload Identity Federation usa o Cloud KMS para desencriptar uma chave de encriptação envolvida.
- A aplicação usa a biblioteca Tink para desidentificar ou encriptar os dados através de um modelo.
- A aplicação transfere dados para o projeto de carregamento em Google Cloud.
- Os dados chegam ao Cloud Storage, ao BigQuery ou ao Pub/Sub.
- No projeto de carregamento, os dados são desencriptados ou reidentificados através de um modelo.
- Os dados desencriptados são encriptados ou ocultados com base noutro modelo de desidentificação e, em seguida, colocados no projeto não confidencial. As etiquetas são aplicadas pelo motor de etiquetagem conforme adequado.
- Os dados do projeto não confidencial são transferidos para o projeto confidencial e reidentificados.
O acesso aos seguintes dados é permitido:
- Os utilizadores que têm acesso ao projeto confidencial podem aceder a todos os dados de texto simples não processados.
- Os utilizadores que têm acesso ao projeto não confidencial podem aceder a dados ocultados, tokenizados ou encriptados com base nas etiquetas associadas aos dados e nas respetivas autorizações.
Fluxo de trabalho do consumidor de dados
Os passos seguintes descrevem como um consumidor pode aceder aos dados armazenados no BigQuery.
- O consumidor de dados pesquisa recursos de dados através do catálogo de dados.
- Depois de o consumidor encontrar os recursos que procura, pede acesso aos recursos de dados.
- O proprietário dos dados decide se concede acesso aos recursos.
- Se o consumidor obtiver acesso, pode usar um bloco de notas e o catálogo de soluções para criar um ambiente no qual pode analisar e transformar os recursos de dados.
Reunir tudo num só lugar
O repositório do GitHub fornece instruções detalhadas sobre a implementação da malha de dados no Google Cloud depois de implementar a base empresarial. O processo de implementação da arquitetura envolve a modificação dos repositórios de infraestrutura existentes e a implementação de novos componentes específicos da malha de dados.
Faça o seguinte:
- Cumpra todos os pré-requisitos, incluindo o seguinte:
- Instale a CLI do Google Cloud, Terraform, Tink, Java e Go.
- Implemente o projeto de base empresarial (v4.1).
- Mantenha os seguintes repositórios locais:
gcp-data-mesh-foundationsgcp-bootstrapgcp-environmentsgcp-networksgcp-orggcp-projects
- Modificar o projeto base existente e, em seguida, implementar as aplicações de malha de dados. Para cada item, conclua o seguinte:
- No repositório de destino, consulte o ramo
Plan. - Para adicionar componentes da malha de dados, copie os ficheiros e os diretórios relevantes de
gcp-data-mesh-foundationspara o diretório de base adequado. Substitua ficheiros quando necessário. - Atualize as variáveis, as funções e as definições da malha de dados nos ficheiros do Terraform (por exemplo,
*.tfvarse*.tf). Defina os tokens do GitHub como variáveis de ambiente. - Execute as operações de inicialização, planeamento e aplicação do Terraform em cada repositório.
- Confirme as alterações, envie o código para o seu repositório remoto, crie pedidos de obtenção e faça a união aos seus ambientes de desenvolvimento, não produção e produção.
- No repositório de destino, consulte o ramo
O que se segue?
- Leia acerca da arquitetura e das funções numa malha de dados.
- Importe dados de Google Cloud para um data warehouse do BigQuery seguro.
- Implemente a estrutura de controlos principais do CDMC num data warehouse do BigQuery.
- Leia acerca do projeto de bases empresariais.