Uma plataforma de análise e gerenciamento de dados corporativos oferece um enclave em que você pode armazenar, analisar e manipular informações sensíveis, mantendo os controles de segurança. É possível usar a arquitetura de malha de dados corporativos para implantar uma plataforma em Google Cloud para gerenciamento e análise de dados. A arquitetura é projetada para funcionar em um ambiente híbrido, em que os componentes Google Cloud interagem com os componentes e processos operacionais locais.
A arquitetura de malha de dados corporativos inclui:
- 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 framework de controles de chave dos Recursos de gerenciamento de dados do Cloud (CDMS, na sigla em inglês) do Google.
- Um exemplo de plataforma de dados que oferece suporte a fluxos de trabalho interativos e de produção.
- Um ambiente de produtor 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 o Google Cloud de forma 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 a 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.
- 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 empresarial foi projetada para ser compatível com o blueprint de bases empresariais. O blueprint de bases empresariais fornece vários serviços de nível básico de que essa arquitetura depende, como redes VPC e registro. É possível implantar essa arquitetura sem implantar o blueprint de bases empresariais se o 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. Este documento pressupõe que você tenha familiaridade com os conceitos de redes de dados, Google Cloud serviços de dados e a Google Cloud implementação da estrutura do CDMC.
Arquitetura
A arquitetura de malha de dados corporativos usa uma abordagem em camadas para fornecer os recursos que permitem a ingestão, o processamento e a governança de dados. 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 infraestruturaGoogle Cloud oferece recursos de segurança, como criptografia em repouso e criptografia em trânsito, bem como 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 a adoção do Google Cloud para suas cargas de trabalho de dados.
- A camada de dados oferece vários recursos, como ingestão de dados, armazenamento, controle de acesso, governança, monitoramento e compartilhamento de dados.
- A camada do 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 exemplo apresenta os seguintes processos: governança de dados, ingestão de dados, processamento 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. |
Papéis e permissões do IAM |
A arquitetura inclui papéis segmentados de produtores de dados, consumidores de dados, governança de dados e plataformas de dados. |
| Serviços de dados comuns | |
Metadados |
A arquitetura usa o Data Catalog para gerenciar metadados de dados. |
Gerenciamento de políticas central |
Para gerenciar políticas, a arquitetura usa a implementação do framework CDMC do 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 de dados do proprietário. |
Qualidade dos dados |
A arquitetura usa o Cloud Data Quality Engine para definir e executar regras de qualidade de dados em colunas de tabela especificadas, medindo a qualidade dos dados com base em métricas como correção e integridade. |
Segurança de dados |
A arquitetura usa marcação, criptografia, mascaramento, tokenização e controles 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 impulsionados por pipelines. Um ambiente (de desenvolvimento) é um ambiente interativo. |
Proprietários de dados |
Os proprietários de dados recebem, processam, expõem e concedem acesso aos recursos de dados. |
Consumidores de dados |
Os consumidores de dados solicitam acesso aos 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 geração de registros do blueprint de base empresarial. |
Cloud Monitoring |
A arquitetura usa a infraestrutura de monitoramento do blueprint de base empresarial. |
Identidade: mapeamento de funções para grupos
A malha de dados aproveita o gerenciamento de ciclo de vida de identidade atual do blueprint de bases empresariais, a autorização e a arquitetura de autenticação. Os papéis não são atribuídos diretamente aos usuários. 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 das 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 aplicadas ao domínio de dados.
As tabelas a seguir mostram os vários papéis usados nesta implementação de malha de dados e as permissões associadas a eles.
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árias funções no projeto de governança de dados, incluindo
|
|
Leitores de informações de governança de dados |
|
|
Administradores de segurança do projeto de governança |
|
|
Grupo com permissão para usar modelos de tags |
|
|
Grupo com permissão para usar modelos de tags 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árias funções 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 |
|
Gestor de dados do domínio de dados |
Papéis para gerenciar aspectos de metadados e 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árias funções no projeto do consumidor, incluindo
|
|
Leitores das informações do projeto do consumidor |
|
Estrutura da organização
Para diferenciar as operações de produção e os dados de produção, a arquitetura usa ambientes diferentes para desenvolver e lançar fluxos de trabalho. As operações de Production incluem a governança, a rastreabilidade e a repetibilidade de um fluxo de trabalho e a auditabilidade dos resultados do fluxo de trabalho. Dados de Production se referem a dados possivelmente sensíveis necessários para a organização. Todos os ambientes são projetados para ter controles de segurança que permitem a ingestão e a operação dos dados.
Para ajudar cientistas e engenheiros de dados, a arquitetura inclui um ambiente interativo, em que os desenvolvedores podem trabalhar com o ambiente diretamente e adicionar serviços por meio de um catálogo selecionado de soluções. Os ambientes operacionais são impulsionados 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 empresarial.
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 Google Clouddo framework CDMC. |
|
|
|
Contém os projetos e recursos da plataforma de dados para o desenvolvimento de 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 na 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 CDCM. 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 do Data Platform.
Cada pasta do Data Platform inclui uma pasta de ambiente (produção, não produção e desenvolvimento). A tabela a seguir descreve as pastas em cada pasta do Data Platform.
| 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 se refere a um grupo lógico de elementos de dados que compartilham um significado, propósito ou contexto de negócios comum. Os domínios de dados permitem 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 do 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 insere dados no domínio de dados. A arquitetura oferece exemplos de como transmitir 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 Cloud Composer que podem ser usados para orquestrar a transformação e o movimento 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 em texto simples. É possível controlar o acesso com as permissões do IAM. |
Pasta do consumidor
A pasta do consumidor contém projetos de consumidor. Os projetos de consumidor fornecem 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 por projeto. Você pode usar o projeto de consumidor para coletar, analisar e aumentar os dados do grupo.
Pasta comum
A pasta comum contém os serviços usados por diferentes ambientes e projetos. Esta seção descreve os recursos que são 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 Google Cloud.
A tabela a seguir descreve os componentes da arquitetura do CDMC que a arquitetura de malha de dados corporativos usa.
| Componente CDMC | serviçoGoogle 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. |
Gerenciador de registros |
Cloud Run |
Um aplicativo que mantém registros e registros abrangentes de atividades de processamento de dados, garantindo que as organizações possam acompanhar 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 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. |
Resultados 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 a 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 de Proteção de dados sensíveis ocorre. |
Mecanismo de relatórios |
Cloud Run |
Um aplicativo que gera relatórios para ajudar a acompanhar e medir a adesão aos controles do framework 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 baseadas em atributos |
Access Context Manager |
Um serviço que define e aplica políticas de acesso granulares e baseadas 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 nas tabelas do BigQuery. |
Relatórios do CDMC |
Looker Studio |
Painéis que permitem que seus analistas acessem relatórios gerados pelos motores de arquitetura do CDMC. |
Implementação do CDMC
A tabela a seguir descreve como a arquitetura implementa os controles de chave no framework do CDMC.
| Requisito de controle do CDMC | Implementação |
|---|---|
O mecanismo de relatório detecta recursos de dados que não estão em conformidade e publica os resultados em um tópico do Pub/Sub. Essas descobertas também são carregadas no BigQuery para relatórios usando o Looker 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, em 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 compliance. Esse processo de marcação automatizada ajuda a fornecer governança e conformidade de dados, identificando e marcando dados sensíveis com as informações de proprietário adequadas. |
A automação e o fornecimento de dados são regidos e apoiados pela automação |
O Data Catalog classifica os recursos de dados com uma
flag |
A soberania de dados e a movimentação de dados entre países são gerenciadas |
O serviço de política 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 mecanismo de relatório compara essas tags com a localização real dos recursos de dados no BigQuery e publica todas 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 dos recursos de dados. |
A proteção de dados confidenciais 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 confidencialidade 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 modificados. Esse processo garante uma classificação constantemente atualizada dos dados com base na sensibilidade, que pode ser monitorada e relatada usando o Pub/Sub e ferramentas de relatórios integrados. |
|
Os direitos de dados são gerenciados, aplicados e rastreados |
As tags de política do BigQuery controlam o acesso a dados confidenciais 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, com qualquer discrepância informada usando o Pub/Sub para correção. |
O acesso, o uso e os resultados éticos dos dados são gerenciados |
Os acordos de compartilhamento de dados para provedores e consumidores são armazenados em um data warehouse do BigQuery dedicado para fins de consumo. O Data Catalog rotula os ativos de dados com as informações do contrato do provedor, enquanto os contratos de consumo são vinculados a vinculações do IAM para controle de acesso. Os rótulos de consulta aplicam finalidades de consumo, exigindo que os consumidores especifiquem uma finalidade válida ao consultar dados sensíveis, que são validados de acordo com os direitos no BigQuery. Uma trilha de auditoria no BigQuery rastreia todo o acesso a dados e garante a conformidade com os contratos de compartilhamento de dados. |
A criptografia em repouso padrão do Google ajuda a proteger os dados armazenados no 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âmico 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 com as políticas de segurança predefinidas. Todas as discrepâncias são relatadas 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 o 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 nos dados e na residência do sujeito. Esse processo de inclusão de tags automatizada permite o monitoramento contínuo e o relatório de conformidade com os requisitos de avaliação de impacto, garantindo que as avaliações de impacto da proteção de dados (DPIAs) ou de proteção de impacto (PIAs) sejam realizadas quando necessário. |
O Data Catalog rotula os recursos de dados com políticas de retenção, especificando períodos de retenção e ações de expiração (como arquivamento ou eliminação). 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, com todas as discrepâncias detectadas e relatadas usando o Pub/Sub. |
|
O Cloud Data Quality Engine define e executa regras de qualidade de dados em colunas de tabela 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 o relatório contínuos da qualidade dos dados, com problemas ou desvios de 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 para recursos de dados, como custos de consulta, de armazenamento e de 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 ao custo permite o monitoramento e a análise abrangentes dos custos, garantindo a adesão às políticas de custo e a utilização eficiente dos recursos, com qualquer anomalia relatada 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, melhorando a rastreabilidade dos dados 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, a execução de jobs do Dataflow) do controle de acesso a dados. O acesso de um usuário a um serviço Google Cloud é definido por uma preocupação ambiental ou operacional e é provisionado e aprovado por um grupo de engenharia de nuvem. O acesso de um usuário aos ativos de dados Google Cloud (por exemplo, uma tabela do BigQuery) é uma preocupação de privacidade, regulamentação ou governança e está sujeito a um contrato de acesso entre as partes produtoras e consumidoras e controlado pelos seguintes processos. 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 do Cloud são coletados e inventariados pelo Data Catalog.
- O gerenciador de fluxos de trabalho recupera os recursos de dados do Data Catalog.
- Os proprietários de dados são integrados ao Gerenciador de fluxos de trabalho.
A operação do gerenciamento de acesso aos dados é a seguinte:
- Um consumidor de dados faz uma solicitação de um recurso específico.
- O proprietário dos dados do recurso é notificado 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 converte as tags do gerenciador de fluxo 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 Google Cloud recurso 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 é iniciado no aplicativo de origem, que pode estar no local ou em outro ambiente externo ao projeto Google Cloud 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 Google Cloud. Usando essas credenciais, ele interage com o Cloud KMS para receber ou agrupar as chaves necessárias e, em seguida, emprega a biblioteca Tinkoff para realizar a criptografia inicial e a desidentificação no payload de dados sensíveis de acordo com modelos predefinidos.
Depois que o payload de dados é protegido, ele precisa ser transferido com segurança para o projeto de ingestão Google Cloud . Para aplicativos locais, você pode usar o Cloud Interconnect ou o Cloud VPN. Na rede Google Cloud , use o Private Service Connect para rotear os dados para o endpoint de transferência 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 transferência de destino (Cloud Storage, BigQuery e Pub/Sub) no projeto de transferência 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 Google Cloud autorizados 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 do aplicativo. 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 o serviço de CI/CD para implantar as configurações do Terraform no ambiente da 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 base da empresa. A tabela a seguir descreve a finalidade dos pipelines e os recursos provisionados por eles.
| Pipeline | Provisionado por | Recursos |
|---|---|---|
Pipeline de base |
Inicializar |
|
Pipeline de infraestrutura |
Pipeline de base |
|
Fluxo de trabalho 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ódigos e arquivos de configuração. Cada repositório tem uma separação de funções em que os remetentes e as aprovações de implantações de código operacional são 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 existem na pasta de desenvolvimento. A interface principal do ambiente interativo é o catálogo de serviços, que permite que os desenvolvedores usem modelos pré-configurados para instanciar serviços do Google. Esses modelos predefinidos são conhecidos como modelos de serviço. Os modelos de serviço ajudam a aplicar sua postura de segurança, como tornar a criptografia CMEK obrigatória, e também impedem que os 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, siga estas etapas:
- O engenheiro de MLOps coloca um modelo de recurso do Terraform para Google Cloud em um repositório Git.
- O comando de confirmação do Git 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 Cloud Composer e o Dataflow para orquestrar o movimento e a transformação de dados no domínio de dados. O pipeline de artefato 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 artefatos cria os artefatos de contêiner usados pelo orquestrador.
Controles de segurança
A arquitetura de malha de dados empresarial usa um modelo de segurança de defesa aprofundada em camadas que inclui recursos Google Cloud padrão, Google Cloud serviços e recursos de segurança configurados pelo blueprint de base empresarial. O diagrama a seguir mostra a camada dos vários controles de segurança da arquitetura.
A tabela a seguir descreve os controles de segurança associados aos recursos de cada camada.
| Camada | Recurso | Controle de segurança |
|---|---|---|
Framework do CDMC |
Google Cloud Implementação do CDMC |
Oferece um modelo de governança que ajuda a proteger, gerenciar e controlar seus recursos de dados. Consulte a Estrutura de controles de chave 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 artefatos |
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 |
Oferece proteções contra exfiltração de dados em torno dos recursos da arquitetura na camada da API e da camada IP. Permite que você se comunique com as APIs do Google 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 na 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 detalhado. |
|
Criptografia |
Cloud KMS |
Permite gerenciar chaves e segredos de criptografia e ajuda 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 dados em repouso. |
|
Criptografia em trânsito |
Por padrão, Google Cloud criptografa dados em trânsito. |
|
Detecção |
Security Command Center |
Ajuda a detectar configurações incorretas e atividades maliciosas na Google Cloud organização. |
Arquitetura contínua |
Verifica continuamente sua Google Cloud organização 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 Google Cloud organização. |
Fluxos de trabalho
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 de carga de trabalho usa o Cloud KMS para descriptografar uma chave criptográfica encapsulada.
- O aplicativo usa a biblioteca Tink para desidentificar ou criptografar os dados usando um modelo.
- O aplicativo transfere dados para o projeto de transferência em Google Cloud.
- Os dados chegam no Cloud Storage, BigQuery ou Pub/Sub.
- No projeto de transferência, 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 motor de inclusão de tags conforme apropriado.
- Os dados do projeto não confidencial são transferidos para o projeto confidencial e reidentificados.
O acesso aos seguintes dados é permitido:
- Os usuários que têm acesso ao projeto confidencial podem acessar todos os dados de texto simples brutos.
- 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 está procurando, ele solicita acesso aos recursos de dados.
- O proprietário dos dados decide se vai conceder acesso aos recursos.
- Se o consumidor tiver acesso, ele poderá usar um notebook e o Solution Catalog para criar um ambiente em que possa analisar e transformar os recursos de dados.
resumo geral
O repositório do GitHub oferece instruções detalhadas sobre como implantar a malha de dados no Google Cloud depois de implantar a base empresarial. O processo de implantação da arquitetura envolve a modificação dos repositórios de infraestrutura existentes e a implantação de novos componentes específicos da malha de dados.
Preencha os campos:
- Conclua todos os pré-requisitos, incluindo os seguintes:
- 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 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.
- Confirme as alterações, envie o código para o repositório remoto, crie solicitações de pull e mescle 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.
- Importe 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.