Quais serviços determinam quais recursos os usuários podem acessar além das operações que podem executar?

O que faz uma solução de IAM?

Uma solução de IAM permite que os administradores de TI gerenciem com segurança e eficácia as identidades digitais dos usuários e os privilégios de acesso relacionados. Com o IAM, os administradores podem configurar e modificar as funções do usuário, rastrear e relatar a atividade do usuário e aplicar políticas corporativas e regulatórias para proteger a segurança e a privacidade dos dados.

Uma solução de IAM pode ser uma coleção de vários processos e ferramentas, incluindo uma solução de controle de acesso à rede (NAC). Os administradores de TI usam soluções de NAC para controlar o acesso às redes por meio de recursos, como gerenciamento do ciclo de vida da política, acesso à rede para convidados e verificações de postura de segurança. As soluções de IAM podem ser fornecidas como serviços em nuvem ou implantadas no local, ou podem ser soluções híbridas, tanto no local quanto na nuvem. Muitas empresas escolhem aplicações em nuvem para IAM porque são mais fáceis de implementar, atualizar e gerenciar.

O que é identidade digital?

Identidade digital é uma fonte de verdade central no gerenciamento de identidade e acesso. Refere-se às credenciais necessárias para que um usuário obtenha acesso a recursos on-line ou em uma rede corporativa. As soluções de IAM correspondem a essas credenciais, conhecidas como fatores de autenticação, para usuários ou entidades que estão solicitando acesso às aplicações, principalmente no nível da camada 7. Os fatores ajudam a verificar a identidade dos usuários.

Quais são os fatores de autenticação comuns?

Três dos fatores de autenticação mais comumente usados para IAM são algo que o usuário conhece (como uma senha), algo que o usuário possui (como um smartphone) e algo que o usuário é (uma propriedade física, como uma impressão digital). Normalmente, um usuário precisa fornecer uma combinação de fatores de autenticação para uma aplicação de autenticador, para confirmar a identidade e conceder acesso aos recursos protegidos que ele tem o privilégio de visualizar ou usar.

Muitas empresas usam a autenticação de dois fatores (2FA), que é uma forma básica de autenticação multifatorial (MFA). O processo de 2FA requer que um usuário forneça um nome de usuário e uma senha e, em seguida, insira um código gerado pela aplicação de 2FA ou responda a uma notificação em um dispositivo, como um smartphone.

O que é governança de dados?

Este documento ajuda você a entender o conceito de governança de dados e quais controles podem ser necessários para proteger os recursos do BigQuery.

Introdução

A governança de dados é uma abordagem baseada em princípios para gerenciar dados durante o ciclo de vida deles, desde a aquisição até o uso e o descarte. O programa de governança de dados descreve claramente políticas, procedimentos, responsabilidades e controles relacionados às atividades de dados. Esse programa garante que as informações sejam coletadas, mantidas, usadas e distribuídas de maneira que atenda às necessidades de integridade e segurança de dados da sua organização. Além disso, os funcionários conseguem descobrir e usar os dados da melhor maneira possível.

Desde quando os dados são ingeridos até quando podem ser usados para informações e insights valiosos, o gerenciamento e a governança dos dados precisam ser considerados como de extrema importância para qualquer organização.

Recomendamos que você crie sua prática de governança de dados em torno de três componentes principais:

• Uma estrutura que permite às pessoas definir, acordar e aplicar políticas de dados.
• Processos eficazes para controle, supervisão e administração de todos os ativos de dados em sistemas locais, armazenamento em nuvem e plataformas de armazenamento de dados.
• As ferramentas e tecnologias certas para supervisionar e gerenciar a conformidade com a política de dados.

Nas próximas seções, apresentaremos uma estrutura de governança de dados baseada na Governança de dados na arquitetura de referência do data lake (em inglês) da Gartner e nas ferramentas e tecnologias que permitem a implementação dela. Para ler mais sobre as necessidades de negócios que a governança atende e os processos envolvidos na operacionalização da governança de dados, consulte o whitepaper Princípios e práticas recomendadas para governança de dados na nuvem (em inglês).

Gerenciamento de acesso a dados

Tradicionalmente, as empresas confiam na segurança do perímetro para proteger os recursos internos. A segurança de perímetro, também conhecida como segurança de casca de ovo ou segurança de castelo e fosso, pressupõe que as ameaças sejam apenas externas aos muros e que tudo dentro das paredes do perímetro seja confiável. Esse pressuposto não está correto, com consequências onerosas para as empresas (em inglês) porque, quando um invasor ganha acesso à rede interna, pode se mover para outros sistemas e explorar ativos de dados valiosos quase sem impedimentos.

Os invasores ganham acesso às redes internas por meio de vulnerabilidades, malware instalado por funcionários, engenharia social e outros meios. No entanto, agentes externos mal-intencionados que criam furos no modelo de segurança de perímetro não são a única ameaça. Funcionários confiáveis podem, consciente ou inconscientemente, modificar, excluir ou extrair dados quando os ativos da sua rede interna não estão protegidos da maneira correta.

Por último, mas não menos importante, a segurança de perímetro tornou-se cada vez mais complexa devido à evolução da rede corporativa. Por exemplo, é difícil aplicar um perímetro nas seguintes situações:

• Quando os funcionários precisam trabalhar remotamente em redes não confiáveis, como locais de clientes, aeroportos ou em casa.
• Quando fornecedores, parceiros e contratados precisam de acesso mais direto aos seus recursos de dados.
• Quando alguns dos sistemas da empresa estão na nuvem.

Como você está migrando de um armazenamento de dados corporativo local, é possível que sua abordagem atual para permitir que os usuários acessem consultas e visualizem dados não seja aprofundada ou seja complexa e cara para manter, ou ambas. A mudança para um armazenamento de dados na nuvem, como o BigQuery, oferece segurança aprofundada e, do lado do usuário, é de baixa manutenção, porque a estrutura de segurança faz parte da oferta de serviços gerenciados.

No restante deste documento, apresentaremos e detalharemos como conseguir o gerenciamento de acesso a dados no Google Cloud e no BigQuery. O objetivo é fornecer uma visão geral do que você consegue dessa estrutura de segurança ao migrar seu armazenamento de dados corporativo. Os mesmos princípios se aplicam se você estiver migrando de outra nuvem ou criando seus recursos do BigQuery do zero.

Gerenciamento de recurso

A configuração das cargas de trabalho no Google Cloud requer adesão à estrutura que rege todos os recursos do Google Cloud, além das diretrizes específicas de cada um dos produtos.

Todos os recursos do Google Cloud são organizados em uma hierarquia. No nível mais baixo, você tem os componentes fundamentais, como conjuntos de dados do BigQuery, buckets do Cloud Storage e máquinas virtuais do Compute Engine. Esses recursos de baixo nível são agrupados em contêineres lógicos chamados projetos. Os projetos formam a base para usar todos os serviços do Google Cloud, gerenciar o faturamento e atribuir papéis e permissões referentes aos recursos do projeto. Os projetos, por sua vez, são agrupados em pastas que podem corresponder a diferentes departamentos ou equipes de uma empresa. No topo da hierarquia, está o nó da organização, que representa a empresa à qual pertence e contém várias pastas. Para mais detalhes, consulte a documentação sobre hierarquia de recursos.

Na perspectiva do Google Cloud, conjuntos de dados do BigQuery ficam no nível mais baixo da hierarquia de recursos. Olhando para eles mais de perto, da perspectiva do BigQuery, vemos que são contêineres de nível superior usados para organizar e controlar o acesso a tabelas e visualizações. Eles têm princípios semelhantes a bancos de dados ou namespaces em ambientes de processamento transacional on-line (OLTP, na sigla em inglês) e de processamento analítico on-line (OLAP, na sigla em inglês) tradicionais. No momento da criação, você escolhe um local para o conjunto de dados. Uma consulta só pode fazer referência a conjuntos de dados no mesmo local. Portanto, é importante considerar o local ao criar conjuntos de dados e projetar consultas pela primeira vez.

Estrutura de segurança

A iniciativa BeyondCorp do Google (em inglês) estabelece um framework de segurança baseado na segurança Confiança Zero. Nesta estrutura, o princípio dos controles de acesso dinâmico define que qualquer usuário ou dispositivo que queira acessar um recurso precisa seguir os itens abaixo:

1. Precisa se autenticar com as credenciais.
2. Precisar estar autorizado a acessar o recurso mencionado.
3. Precisa se comunicar usando criptografia.

Esses requisitos precisam ser atendidos, independentemente do local da rede ou do dispositivo do usuário, seja dentro da intranet da empresa, em um Wi-Fi público ou em um avião, por exemplo.

Nas seções subsequentes deste artigo, exploramos conceitos e práticas recomendadas para gerenciar o acesso a ativos de dados, incluindo os princípios estabelecidos no BeyondCorp. No artigo, também explicamos como é possível implementar uma sobreposição de segurança de perímetro como uma medida protetora contra a exfiltração.

Autenticação refere-se ao processo de determinar e verificar a identidade de um cliente que interage com o BigQuery. Autorização refere-se ao processo de determinar quais permissões a identidade verificada tem para interagir com o BigQuery e os conjuntos de dados dele. Em resumo, a autenticação identifica quem você é, e a autorização determina o que você pode fazer.

Identidade

No Google Cloud, o Cloud Identity é o provedor de identidade integrado. Ao migrar do armazenamento de dados local, considere federar o provedor de identidade em uso, como o Microsoft Active Directory, com o Cloud Identity. É possível continuar usando o provedor de identidade atual para lidar com as seguintes tarefas:

• Provisionar e gerenciar usuários e grupos.
• Configurar o logon único.
• Configurar a autenticação multifator.

Os usuários do BigQuery podem ser humanos ou aplicativos não humanos que se comunicam usando uma biblioteca de cliente do BigQuery ou a API REST. Esses aplicativos precisam se identificar usando uma conta de serviço, o tipo especial de identidade do Google utilizado para representar um usuário não humano.

O Cloud Identity é a primeira metade de um produto maior chamado Gerenciamento de identidade e acesso (IAM, na sigla em inglês).

Após a autenticação de um usuário, ainda é preciso determinar se o usuário tem os privilégios necessários para interagir com o BigQuery e os conjuntos de dados dele.

Gerenciamento de acesso

Além da autenticação, o IAM oferece controle centralizado para autorizar identidades com permissões específicas para o BigQuery e os conjuntos de dados dele. O IAM gerencia a política de segurança do BigQuery em toda a organização e permite conceder acesso aos recursos do BigQuery em níveis detalhados, além do acesso para envolvidos no projeto.

No Cloud IAM, as permissões determinam as operações permitidas em um recurso, mas não é possível atribuir essas permissões diretamente às identidades do Google (usuários, contas de serviço, Grupos do Google, Google Workspace ou domínios do Cloud Identity). Em vez disso, atribua papéis (que são coleções de permissões) às identidades do Google e use uma política (declarada em um arquivo JSON ou YAML) para impor essas vinculações em qualquer um dos seguintes níveis de recursos do Google Cloud:

• Organização
• Pasta
• Projeto
• Nível de recurso (conjuntos de dados do BigQuery)

Os papéis do BigQuery podem ser vinculados em qualquer um dos níveis de recursos listados anteriormente, por exemplo:

• No nível do projeto, um usuário pode ter o papel de admin, metadataViewer ou jobUser.
• No nível do recurso do conjunto de dados do BigQuery, um usuário (ou uma visualização) pode ter o papel de dataEditor, dataOwner ou dataViewer.

IAM para tabelas e visualizações

O BigQuery permite atribuir papéis individualmente a determinados tipos de recursos dentro de conjuntos de dados, como tabelas e visualizações, sem fornecer acesso total aos recursos do conjunto de dados. As permissões no nível da tabela determinam os usuários, grupos e contas de serviço que podem acessar uma tabela ou visualização.

Para mais informações sobre controle de acesso de tabela e visualização, consulte Introdução aos controles de acesso de tabela.

Papéis não podem ser aplicados aos seguintes recursos individuais: rotinas ou modelos.

Como alternativa, é possível usar uma visualização autorizada para conceder a usuários específicos acesso aos resultados da consulta, sem conceder a eles acesso às tabelas subjacentes. Usar visualizações autorizadas para restringir o acesso em um nível mais baixo do recurso, como no nível da tabela, coluna, linha ou célula. Segurança no nível da coluna e segurança no nível da linha, que são formas de classificação de dados, são recomendadas em vez de visualizações autorizadas, mas suas necessidades e circunstâncias determinam quais métodos são melhores para usar.

IAM para endpoints

O IAM permite gerenciar autenticação e autorização com base em identidades. Ele também permite criar um perímetro seguro em torno de serviços que têm endpoints públicos, como o BigQuery. Para mais informações sobre esse método de controle de acesso, consulte a seção sobre segurança de rede.

Métodos de implementação

O esforço de migração geralmente exigirá que você conecte um aplicativo local ao BigQuery. Veja abaixo exemplos de quando esse acesso é necessário:

• Pipelines de dados locais que carregam dados no BigQuery.
• Relatórios locais, analíticos ou outros aplicativos empresariais que consultam ou extraem dados do BigQuery.

Para acessar dados do BigQuery, um aplicativo precisa conseguir e enviar credenciais junto com solicitações de API. Credenciais de curta ou longa duração podem ser usadas para interagir com a API BigQuery de um aplicativo local ou de outra nuvem pública.

Um cliente do BigQuery precisa ser autenticado com o uso de uma conta de serviço ou das credenciais de um usuário. Depois que um cliente é autenticado, uma chave ou um token de acesso precisa ser transmitido para a API BigQuery. Essas credenciais são então verificadas quanto à autorização adequada para garantir que o cliente tenha permissões IAM suficientes para quaisquer interações que tenha com o BigQuery.

Credenciais de curta duração

As credenciais de curta duração expiram automaticamente após um curto período (ciclo de vida máximo de 1 hora para OAuth2.0 e OpenID, e de 12 horas para JWT), especificado na criação. Se você quiser evitar o gerenciamento de chaves de conta de serviço ou quiser emitir concessões expiradas para os serviços do Google Cloud, use credenciais de curta duração.

Os seguintes tipos de credenciais podem ser solicitados como de curta duração:

• Tokens de acesso do OAuth 2.0
• Tokens de ID do OpenID Connect
• JSON Web Tokens (JWTs) autoassinados
• Objetos binários (blobs) autoassinados

As credenciais de curta duração permitem que os serviços locais se comuniquem com o BigQuery sem exigir uma identidade do Google Cloud. Embora uma identidade do Google Cloud precise ter credenciais de curta duração, o aplicativo ou serviço que está usando o token não exige uma identidade do Google Cloud.

Credenciais de longa duração

As credenciais de longa duração (por exemplo, chaves privadas de contas de serviço ou tokens de acesso do OAuth 2.0 com tokens de atualização) permitem o acesso ao BigQuery até que sejam excluídas ou revogadas. As chaves privadas da conta de serviço persistem depois de criadas e não exigem atualização. Os tokens de acesso do OAuth 2.0 expiram, mas podem ser usados como se fossem de longa duração com um token de atualização que o acompanha. Esse token de atualização permite solicitar novos tokens de acesso (sem a necessidade de nova autenticação) enquanto o token de atualização permanecer ativo. Esse processo é ilustrado no OAuth 2.0 Playground do Google.

Considerando a vida útil estendida delas, é preciso gerenciar as credenciais de longa duração com cuidado em máquinas clientes remotas ou em nós de trabalho. Recomendamos que você as armazene em um local seguro que limite o acesso apenas a usuários autorizados. Nunca armazene credenciais em um repositório de código: qualquer pessoa com acesso ao seu código também teria acesso à sua chave e, portanto, aos seus dados. No caso de vazamento de credenciais, é possível usar perímetros de serviço para reduzir o risco desse acesso indesejado oriundo de fora.

Veja abaixo exemplos de estratégias recomendadas para armazenar credenciais de longa duração:

• Cloud Storage com ou sem serviço de gerenciamento de chaves (KMS, na sigla em inglês)
• Armazenamento seguro no local
• Solução de gerenciamento de secret de terceiros

Uma chave privada de conta de serviço é um JWT assinado criptograficamente que pertence a uma conta de serviço individual. O JWT assinado é usado diretamente como um token do portador. Portanto, não é necessária uma solicitação de rede ao servidor de autorização do Google. Se vazadas, as chaves não expiram automaticamente nem têm o acesso revogado. Portanto, é uma prática recomendada de segurança alternar as chaves regularmente. Esse processo requer a geração de uma nova chave, o que garante que todos os usuários e serviços autorizados têm acesso à nova chave, e a exclusão da antiga. A rotação de chaves garante que o acesso de uma chave comprometida ao BigQuery seja revogado automaticamente, mesmo que o vazamento não seja detectado

As chaves de conta de serviço privadas e os tokens de atualização aceitam autenticação usando contas de serviço. Vários usuários e aplicativos podem ter acesso à mesma conta de serviço. Portanto, essas solicitações são anônimas, porque o usuário ou o aplicativo não podem ser identificados. No entanto, muitos clientes corporativos exigem que o acesso aos recursos do Google Cloud, como o BigQuery, seja atribuído ao usuário individual que iniciou a solicitação. Nesse caso, é possível usar o fluxo de três etapas (3LO) do OAuth 2.0 para autenticar em nome de um usuário final em vez de uma conta de serviço.

Em um fluxo de duas etapas, um aplicativo mantém diretamente as credenciais de uma conta de serviço e chama a API BigQuery em nome dela. No entanto, em um fluxo de três etapas, o proprietário do recurso concede ao cliente acesso aos recursos do BigQuery sem compartilhar diretamente as credenciais dele. As solicitações são feitas em nome do usuário e, algumas vezes, é necessário o consentimento dele. Depois que um usuário se autentica, um código de autorização pode ser trocado por um token de acesso e um token de atualização.

Segurança de rede

Uma rede de nuvem privada virtual é semelhante a uma rede física, mas virtualizada no Google Cloud. Você define regras de firewall no nível da rede para controlar o tráfego de e para as instâncias da máquina virtual. No entanto, não é possível definir regras de firewall para serviços baseados em API, como o BigQuery ou o Cloud Storage. Para esses tipos de serviços, use os Service Controls da nuvem privada virtual (VPC, na sigla em inglês) do Google para restringir o tráfego.

Uma VPC define perímetros de serviço nos serviços baseados na API do Google que têm um endpoint público, como o BigQuery ou o Cloud Storage. Os perímetros de serviço atenuam os riscos de exfiltração de dados por meio da restrição da saída e da entrada de dados entre recursos dentro e fora do perímetro. Quando você implementa corretamente esses controles, as redes não autorizadas não podem acessar dados e serviços, e os dados não podem ser copiados para projetos não autorizados do Google Cloud. A comunicação livre ainda pode ocorrer dentro do perímetro, mas a comunicação fica restrita nele.

Recomendamos que você use o VPC Service Controls com os controles de acesso do IAM. O IAM oferece controle de acesso granular baseado em identidade, e os VPC Service Controls permitem uma segurança mais ampla de perímetro baseada em contexto.

Controle de acesso baseado no contexto

As solicitações de API da Internet pública têm acesso permitido ou negado a recursos dentro de um perímetro de serviço com base nos níveis de acesso desse perímetro. As solicitações são classificadas de acordo com o contexto do cliente, como intervalos de IP e identidades de conta de usuário/serviço. Por exemplo, se uma solicitação da API do BigQuery vier de uma credencial válida, mas de uma rede não confiável, poderá ser negado o acesso à solicitação à rede VPC e ao perímetro de serviço, como mostra o diagrama a seguir.

Perímetros de serviço

Os perímetros de serviço da VPC são configurados no nível de organização do Google Cloud para que as políticas de segurança possam ser gerenciadas centralmente. Vários projetos nessa Organização e serviços (por exemplo, API BigQuery) podem ser atribuídos a cada perímetro. Projetos e dados no mesmo perímetro de serviço podem processar, transformar e copiar dados de maneira flexível, desde que todas essas ações permaneçam dentro do perímetro. O diagrama a seguir mostra como usar os perímetros de serviço.

Se os recursos do Google Cloud em diferentes perímetros de serviço precisarem se comunicar (por exemplo, BigQuery em um projeto e perímetro de serviço e Compute Engine em outro), crie uma ponte de perímetro no nível da organização. Uma ponte do perímetro permite a comunicação entre recursos do Google Cloud em vários perímetros de serviço. Embora um projeto do Google Cloud possa pertencer a apenas um perímetro de serviço, ele pode fazer parte de várias pontes do perímetro.

Acesso a dados em ambientes híbridos

Para ambientes híbridos locais e na nuvem, é possível configurar o Acesso privado do Google para redes locais a fim de permitir a comunicação privada entre o perímetro de serviço e os ambientes locais. Isso pode permitir que ambientes locais acessem os conjuntos de dados do BigQuery. Essas solicitações precisam ser enviadas via conexão particular com o Google Cloud, que pode ser uma VPN baseada em rota ou uma conexão do Cloud Interconnect. As solicitações não passam pela Internet pública.

Essa configuração estende o perímetro de serviço das redes locais para os dados armazenados nos serviços do Google Cloud, garantindo que os dados confidenciais sejam mantidos em sigilo. Use essa configuração de comunicação particular somente para APIs em restricted.googleapis.com. O diagrama a seguir mostra um exemplo dessa configuração.

Encryption

Ao examinar como os dados são armazenados e transferidos no Google Cloud e no BigQuery em comparação com o armazenamento de dados local da empresa, convém reconsiderar a estrutura de segurança.

O princípio de controles de acesso dinâmico (em inglês) do BeyondCorp afirma que todo acesso precisa ser criptografado. Portanto, é essencial que você institua a criptografia como um método de proteção de dados para garantir que, mesmo no caso improvável de exposição de dados, eles não poderão ser lidos em repouso ou em trânsito. Dessa forma, a criptografia adiciona uma camada de defesa para proteger os dados.

Criptografia em repouso

O Google Cloud criptografa os dados armazenados em repouso por padrão, sem a necessidade de outras ações. O Padrão de criptografia avançada (AES, na sigla em inglês) é usado para criptografar dados em repouso, conforme recomendado pelo Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (em inglês).

Antes de serem gravados em disco, os dados em um conjunto de dados do BigQuery são divididos em vários blocos. Cada bloco é criptografado com uma chave de criptografia de dados (DEK, na sigla em inglês) exclusiva. Ao usar chaves diferentes, o impacto de um comprometimento improvável da DEK é contido apenas nessa parte dos dados. Essas chaves são então criptografadas com o uso de chaves de criptografia de chaves (KEK, na sigla em inglês) exclusivas. As DEKs criptografadas são armazenadas perto dos dados associados a elas, mas as KEKs são armazenadas centralmente no Cloud Key Management Service (KMS). Esse método hierárquico de gerenciamento de chaves é chamado de criptografia de envelope. Para mais detalhes, consulte a seção "Gerenciamento de chaves" do artigo "Criptografia em repouso".

O diagrama a seguir mostra como a criptografia em repouso funciona.

Por padrão, todas as chaves são gerenciadas pelo Google. No entanto, é possível optar por gerenciar as chaves sozinho. Essa técnica é chamada de Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês). Com essa técnica, você usa o Cloud KMS para criar, revezar, revezar automaticamente e destruir chaves de criptografia simétricas. Para mais informações sobre o uso do CMEK com o BigQuery, consulte Como proteger dados com chaves do Cloud KMS.

Criptografia em trânsito

O Google Cloud criptografa e autentica todos os dados em trânsito quando eles são movidos para fora dos limites físicos controlados pelo Google ou em nome do Google. Dentro desses limites, em geral os dados em trânsito são autenticados, mas não necessariamente criptografados.

A criptografia em trânsito tem o propósito de proteger os dados contra ataques após o estabelecimento e a autenticação de uma conexão das seguintes maneiras:

• Acabando com a necessidade de confiar nas camadas mais inferiores da rede, que normalmente são fornecidas por terceiros.
• Impedindo que invasores acessem os dados em caso de interceptação das comunicações.

Em um nível alto, a criptografia em trânsito funciona da seguinte maneira: seus dados são criptografados antes da transmissão, os endpoints são autenticados e, quando os dados chegam ao destino, são descriptografados e verificados. No entanto, os métodos de segurança usados dependem do tipo de conexão que está sendo protegida. Nesta seção, nos concentramos no uso de criptografia para proteger conexões de e para o BigQuery.

O BigQuery é um serviço do Google Cloud. Portanto, quando um usuário ou aplicativo envia uma solicitação, ela chega primeiro a um sistema distribuído globalmente chamado Google Front End (GFE). O GFE encerra o tráfego de solicitações recebidas de proxies HTTP(S), TCP e TLS, fornece contramedidas para prevenir ataques de DDoS, além de encaminhar o tráfego para qualquer serviço, fazendo o balanceamento da carga.

Você precisar considerar que o tráfego de ou para um serviço do Google Cloud pode precisar de medidas extras de segurança. Essas medidas são relevantes quando você está migrando seus processos de upstream e downstream. Por exemplo, as solicitações entre um usuário ou aplicativo para um aplicativo personalizado hospedado no Google Cloud podem ser roteadas de várias maneiras. Em geral, se você estiver usando o Cloud Load Balancing, o tráfego passa pelo GFE. Portanto, essa rota se enquadra na categoria anterior. Se você estiver usando o Cloud VPN, a conexão será protegida por IPsec. Por outro lado, se você estiver se conectando diretamente a uma VM usando um endereço IP externo, um endereço IP de balanceador de carga de rede ou por meio da Interconexão dedicada do Cloud, a conexão não será criptografada por padrão. Portanto, recomendamos o uso de um protocolo de segurança como o TLS.

Para mais informações sobre como o Google Cloud lida com a criptografia em trânsito de cada fluxo de conexão, consulte Criptografia em trânsito no Google Cloud.

Exclusão criptográfica

Além da criptografia fornecida por padrão pelo Google, seu aplicativo pode aplicar a própria criptografia, se necessário. Por exemplo, caso precisar fazer o mascaramento de dados de colunas específicas em uma tabela ou fazer exclusão criptográfica.

Exclusão criptográfica, ou trituração criptográfica (em inglês), é o processo de tornar os dados irrecuperáveis por meio da exclusão da chave usada para criptografá-los. Como os dados não podem mais ser descriptografados, eles são excluídos de maneira eficiente.

Como apenas a chave é excluída, e não todos os dados criptografados, esse método de exclusão é rápido, permanente e muito usado em casos como os mostrados abaixo:

• Quando os dados criptografados são muito maiores que a chave. Por exemplo, em discos criptografados, telefones e registros de banco de dados.
• Quando a exclusão dos dados criptografados é muito cara, complexa ou inviável. Por exemplo, em dados distribuídos por muitos repositórios ou em armazenamento não modificável.

O BigQuery fornece funções para criar chaves, assim como para criptografar e descriptografar dados em consultas usando os conceitos de criptografia AEAD.

Descoberta de dados

O volume, a variedade e a velocidade dos dados disponíveis para organizações de todos os tamanhos estão aumentando. Essa proliferação de dados pode apresentar vários desafios, como os seguintes:

• Os dados que você precisa são difíceis de encontrar porque estão distribuídos, não organizados ou duplicados em vários repositórios de dados.
• Mesmo quando você encontra alguns dados, não está claro de onde eles vieram, se representam o que você está procurando e se são confiáveis o suficiente para que uma decisão de negócios seja tomada.
• Os dados são difíceis de gerenciar. Não está claro quem é o proprietário de um dado, quem tem acesso aos dados e qual é o processo para ganhar acesso aos dados.

Os metadados consistem em atributos que descrevem os dados e ajudam a atender aos desafios anteriores. A coleta de metadados é semelhante à criação de um catálogo de cartões para uma biblioteca, em que cada livro tem um cartão físico que indica informações como autor, ano de publicação, edição e assunto. Como um livro, um dado pode ter um conjunto de atributos anexados, como proprietário, origem, data de processamento ou classificação de qualidade.

Tradicionalmente, as empresas tentam capturar e organizar os metadados usando vários métodos, como planilhas, páginas wiki, sistemas desenvolvidos internamente e software de terceiros. Problemas comuns são a necessidade de entrada manual, curadoria e manutenção, além de escopo e compatibilidade do sistema. Um problema final é que a descoberta de dados e a coleta de metadados geralmente são processos orgânicos que dependem do conhecimento tribal transmitido de pessoa para pessoa, o que não é escalonável para uma organização em crescimento. Nesse contexto, como um analista que não faz parte desse grupo de pessoas encontra dados que eles podem acessar e como dá sentido a eles?

Além desses desafios internos, as empresas enfrentam um aumento nos requisitos regulatórios e de conformidade, como o Regulamento geral de proteção de dados (GDPR, na sigla em inglês), o Comitê de supervisão bancária da Basileia 239 (BCBS239, na sigla em inglês) e a Lei de portabilidade e responsabilidade de seguros de saúde (HIPAA, na sigla em inglês), que exigem que elas rastreiem, protejam e gerem relatórios para seus dados.

A resposta do Google Cloud a essas necessidades dos clientes é o Data Catalog, um serviço de gerenciamento de metadados totalmente gerenciado e escalonável para descobrir, classificar e entender os dados no Google Cloud.

A arquitetura do Data Catalog é baseada nos itens a seguir:

• Armazenamento de metadados: desenvolvido no Cloud Spanner, o banco de dados com consistência forte e distribuído globalmente para armazenar todas as entradas de metadados.
• Sincronizadores em tempo real e em lote: para a ingestão automática de metadados técnicos.
• Índice de pesquisa Google: com a mesma tecnologia que possibilita a pesquisa no Gmail e no Google Drive, é um sistema escalonável e de alto desempenho com listas de controle de acesso (ACLs, na sigla em inglês) incorporadas.

O Data Catalog oferece uma visualização unificada de todos os seus ativos de dados. Portanto, fornece uma base para a criação de um processo de governança de dados sólido.

No diagrama a seguir, uma arquitetura simplificada é exibida, com o Data Catalog fornecendo recursos de metadados, pesquisa e prevenção contra perda de dados para BigQuery, Cloud Pub/Sub e Cloud Storage. Esses recursos serão discutidos nas seções posteriores.

Metadata

A capacidade de encontrar os dados certos para tomar decisões está no centro do processo de descoberta de dados. Assim como metadados sobre livros disponíveis são necessários para encontrar um livro em uma biblioteca, você também precisa de metadados sobre seus recursos de dados para encontrá-los em um ambiente de Big Data.

O Data Catalog pode ingerir automaticamente metadados do BigQuery, Pub/Sub e Cloud Storage. Ele também distingue entre dois tipos diferentes de metadados: técnicos e comerciais.

Por um lado, os metadados técnicos incluem informações como nomes de tabelas, nomes de colunas, descrições e datas criadas. Esse tipo de metadado já está presente no sistema de origem. O Data Catalog ingere automaticamente metadados técnicos no índice, sempre que esses ativos são criados, sem que você precise registrar ativos de dados novos de maneira manual.

Por outro lado, os ativos de dados têm um contexto comercial implícito associado a eles, como, por exemplo, se uma coluna contém informações de identificação pessoal (PII, na sigla em inglês), quem é o proprietário do ativo de dados, uma data de exclusão ou retenção e um índice de qualidade dos dados. Esse tipo é chamado de metadados comerciais.

Os metadados comerciais são mais complexos que os técnicos, porque usuários em diferentes papéis estão interessados em diferentes subconjuntos do contexto comercial. Por exemplo, um analista de dados pode ter interesse no status de um job de ETL, como, por exemplo, se ele foi executado com sucesso, quantas linhas foram processadas ou se houve algum erro ou aviso. Um gerente de produtos pode ter interesse em saber qual é a classificação de dados (se ela é pública ou particular), em saber onde os dados estão no ciclo de vida (produção, teste ou controle de qualidade), se os dados são de qualidade e completos etc.

Para lidar com essa complexidade, o Data Catalog permite agrupar metadados comerciais em modelos. Um modelo é um grupo de pares de chave-valor de metadados chamados atributos. Ter um conjunto de modelos é semelhante a ter um esquema de banco de dados para os metadados.

Tags de metadados são instâncias dos modelos que podem ser aplicadas a tabelas e colunas. Quando essas tags são aplicadas a colunas, os usuários podem determinar se uma coluna específica contém PII, se a coluna está obsoleta e qual fórmula foi usada para calcular uma determinada quantidade. Em essência, os metadados comerciais fornecem o contexto necessário para usar seus dados de maneira significativa.

No diagrama a seguir, mostramos um exemplo de tabela de clientes (cust_tbl) e várias tags de metadados comerciais anexadas a ela e às colunas dela.

Além de uma interface de usuário intuitiva, o Data Catalog também fornece uma API para usuários técnicos anotarem ou recuperarem metadados em massa. As linguagens compatíveis são Python, Java e NodeJS. A API não permite apenas que você escalone as tarefas de metadados, mas também se integre de maneira programática ao Data Catalog, o que abre a porta para a criação de aplicativos empresariais personalizados que usam o Data Catalog como parte do back-end.

Pesquisa

Adicionar metadados aos seus ativos de dados é a base da descoberta de dados, mas é apenas metade da história. A outra metade é a capacidade de descobrir um ativo por meio de uma funcionalidade de pesquisa robusta que usa metadados técnicos e comerciais para retornar resultados relevantes.

O Data Catalog indexa todos os metadados das fontes e os disponibiliza por meio de uma IU fácil de usar e de uma API para integração programática. Ele funciona no estilo da pesquisa Google usando palavras-chave correspondentes aos metadados. Também fornece pesquisa de atributos para usuários avançados. Com filtros intuitivos e predicados qualificados, a pesquisa de atributos permite que os usuários reduzam os resultados, por exemplo, pesquisando apenas tabelas, conjuntos de dados ou arquivos, ou pesquisando apenas em um projeto, uma organização ou um produto do Google Cloud específico.

Na IU, o Data Catalog também mostra uma lista de tabelas do BigQuery que são pesquisadas com frequência. Essa funcionalidade fornece acesso rápido e prático aos detalhes da tabela, ao esquema e ao console do BigQuery.

Controle de acesso

Ao permitir que seus usuários pesquisem metadados e descubram ativos de dados, você os capacita a serem mais produtivos, independentes e engajados. No entanto, nem todos precisam ter acesso a todos os metadados. Quando as pessoas certas têm acesso aos dados certos, você permite que seus funcionários se concentrem em um subconjunto de ativos de dados relevantes para os papéis que têm e ajuda a evitar exfiltração de dados ou metadados.

O Data Catalog é integrado ao IAM, permitindo controlar quais usuários podem encontrar ativos de dados selecionados nas pesquisas que fizerem ou criar metadados comerciais para os ativos.

Para metadados técnicos, a fim de simplificar o gerenciamento de acesso, a ingestão automática aplica o mesmo conjunto de permissões aos metadados concedidas aos dados que têm inclusão de tags. Se um usuário tiver acesso aos dados, ele também terá acesso aos metadados técnicos extraídos e poderá encontrar os recursos de dados em uma pesquisa do Data Catalog. Esse método fornece um padrão razoável que não requer intervenção manual, em vez de aguardar o registro de um ativo de dados e a concessão de um conjunto separado de permissões.

Você define quais usuários ou grupos de usuários têm acesso aos metadados comerciais. Alguns desses usuários têm acesso aos metadados e aos dados, a apenas um deles ou a nenhum dos dois.

• Se não tiverem acesso aos metadados, não poderão encontrar os recursos de dados na pesquisa do Data Catalog.
• Se eles tiverem acesso aos metadados, mas não aos dados, poderão encontrar o recurso de dados, mas não poderão ler os dados. Esse recurso permite que os usuários descubram conjuntos de dados úteis sem expor os dados subjacentes, o que aumenta a usabilidade dos ativos de dados de uma organização sem comprometer a segurança. Os usuários podem então fazer solicitações de acesso aos proprietários dos dados, que podem ser aprovadas ou negadas, dependendo do caso de uso comercial, da confidencialidade dos dados e de outros fatores.

Nesta seção, apresentamos como o Data Catalog se integra ao IAM para aplicar o controle de acesso aos metadados. Além disso, é possível controlar quem tem acesso ao Data Catalog por meio da concessão de papéis do Data Catalog aos seus usuários. Para controlar o acesso aos ativos de dados, use uma combinação de IAM e VPC Service Controls. Para mais informações, consulte a documentação do Data Catalog IAM.

Linhagem

No contexto de armazenamento de dados, linhagem refere-se ao caminho que um ativo de dados leva da origem até o destino. A origem de um recurso de dados pode ser uma fonte externa (como dados de mercado fornecidos por terceiros) ou interna (como um banco de dados relacional que armazena transações do cliente). O destino do ativo de dados pode ser um painel, um relatório ou um feed de dados exposto como uma API.

Em todos esses casos, é importante saber que os dados apresentados no destino refletem com precisão as transformações aplicadas aos dados originais. É importante que os consumidores dos dados possam confiar nos dados que recebem, que os reguladores verifiquem e entendam os dados que estão sendo informados e que as partes interessadas internas identifiquem lacunas nos processos de negócios e inter-relações nos pipelines de processamento de dados.

Saber quais dados precisam ser capturados depende do escopo do seu caso de negócios. Ele pode incluir metadados, como a fonte de dados de origem, os proprietários dos dados, o processo de negócios em que o ativo de dados é transformado ou os aplicativos e serviços envolvidos durante as transformações.

A captura manual dessas informações é suscetível a erros e não é escalonável em casos de negócios não triviais. Portanto, recomendamos que você aborde a linhagem de dados de uma perspectiva programática:

• Determine o conjunto de atributos de metadados que você precisa capturar para atender às suas necessidades comerciais ou regulatórias.
• Crie modelos para capturar esses metadados comerciais. O Data Catalog é compatível com cinco tipos de dados que podem ser combinados para a criação de tags avançadas: double, string, boolean, datetime e enum. Esse último tipo pode usar um conjunto de valores personalizados para descrever um estágio na transformação de dados ou valores enumerados semelhantes.
• Use a API Data Catalog para registrar os metadados de linhagem relevantes em cada etapa pertinente do seu pipeline de dados.

Como uma alternativa ao Data Catalog, use o Cloud Data Fusion, a versão gerenciada do Google do CDAP (em inglês), para implementar a transformação de dados. O Cloud Data Fusion encapsula o ambiente de processamento de dados em um único ambiente controlado, permitindo que a linhagem seja registrada automaticamente no nível de campo e conjunto de dados. Para mais informações, consulte a documentação do CDAP sobre linhagem (em inglês) de código aberto.

Classificação e gerenciamento de dados

Em um armazenamento de dados empresarial, o volume, a velocidade e a variedade dos dados que estão sendo ingeridos podem criar desafios para a classificação e o gerenciamento de dados.

Classificação de dados é o processo de categorizar dados em tipos, formulários ou categorias usando as características distintas deles. A capacidade de classificar os dados com eficiência é essencial para você aplicar políticas de governança apropriadas a diferentes tipos de dados.

Por exemplo, dependendo do conteúdo de um documento comercial, é possível classificá-lo com um nível de confidencialidade, como não seguro ou confidencial. Cada um desses tipos pode ter políticas específicas para o gerenciamento. Por exemplo, documentos confidenciais são acessíveis apenas para um determinado grupo de usuários e são mantidos por sete anos.

No gerenciamento de dados, você tem vários aspectos a considerar:

• Gerenciamento da alteração de dados: controle dos efeitos quando as dimensões dos dados são alteradas. Elas são alteradas com pouca frequência, mas a modificação pode ter um efeito cascata porque os dados nas tabelas de fatos podem não ser mais verdadeiros para as dimensões atualizadas.
• Gerenciamento de dados de referência: garantia de que todos os sistemas da organização têm uma visualização precisa e consistente dos dados de referência.
• Retenção e exclusão: como impedir que usuários modifiquem ou excluam dados e como expirar dados automaticamente.

Ao migrar para o BigQuery, aproveite os recursos automatizados de classificação de dados, como a Prevenção contra perda de dados (DLP, na sigla em inglês) do Cloud. Nas seções a seguir, apresentamos recursos e técnicas para você lidar com esses desafios de classificação e gerenciamento de dados no Google Cloud.

Prevenção da perda de dados

Muitas organizações têm milhares de tabelas com centenas de colunas. Algumas delas ainda têm nomes de colunas como Column_5, que não são corretas ou descritivas, mas contêm informações de identificação pessoal. Esses fatos dificultam a identificação das PII e, subsequentemente, a aplicação de políticas aos dados.

O DLP do Cloud oferece acesso a uma plataforma poderosa de inspeção, classificação e desidentificação de dados. A API DLP verifica automaticamente os dados e cria tags do Data Catalog para identificar dados confidenciais. Ele pode ser usado nas tabelas atuais do BigQuery, nos buckets do Cloud Storage ou nos fluxos de dados.

O Cloud DLP verifica os dados e identifica as PII, como e-mail, números de cartão de crédito e CPF ou CNPJ, e as informa com um nível de confiança. Por exemplo, se o nível de confiança dos dados for 99%, será possível processar grandes quantidades de dados automaticamente. Para otimizar o reconhecimento de PII em seu pipeline de ETL/ELT, realize as instruções a seguir:

• Faça a ingestão de dados em um bucket de quarentena.
• Execute o Cloud DLP para identificar as PII. Isso pode ser feito verificando todo o conjunto de dados ou criando uma amostra dos dados. A API DLP pode ser chamada pelas etapas de transformação do seu pipeline ou por scripts independentes, como o Cloud Functions. Neste artigo, apresentamos um exemplo usando a segunda opção.
• Mova os dados para o armazenamento.

O Cloud DLP vem com mais de 100 detectores predefinidos para identificar padrões, formatos e somas de verificação. Ele também fornece um conjunto de ferramentas para tornar seus dados anônimos, incluindo mascaramento, tokenização, pseudonimização, troca de datas e muito mais. Ela também permite criar detectores personalizados usando um dicionário ou uma expressão regular. É possível adicionar regras de hotword para aumentar a precisão das descobertas e definir regras de exclusão para reduzir o número de falsos positivos.

O uso do Cloud DLP leva a uma melhor governança de dados, ajudando a classificar os dados e dar o acesso certo às pessoas certas.

Segurança no nível da coluna

Com base no conceito de classificação de dados, o BigQuery fornece acesso detalhado a colunas com dados confidenciais usando tags de política, uma classificação dos dados com base no tipo. Usando a segurança no nível da coluna do BigQuery, é possível criar políticas que verifiquem no momento da consulta se o usuário tem o acesso adequado.

Consulte Introdução à segurança no nível da coluna do BigQuery para mais informações sobre como usar tags de política para segurança no nível da coluna.

Segurança no nível da linha

A segurança no nível da linha permite filtrar dados e acessar linhas específicas em uma tabela, com base nas condições de qualificação do usuário. A segurança no nível da linha amplia o princípio de privilégio mínimo ao ativar o controle de acesso detalhado a um subconjunto de dados em uma tabela do BigQuery, usando políticas de acesso no nível da linha. As políticas de acesso no nível da linha podem coexistir em uma tabela com segurança no nível da coluna.

Consulte Introdução à segurança no nível da linha do BigQuery para mais informações sobre como usar políticas de acesso de linha para segurança no nível da linha.

Gerenciamento de dados mestres

Os dados mestres, também conhecidos como dados de referência, são dados usados em toda a organização. Exemplos comuns de ativos de dados mestres incluem clientes, produtos, fornecedores, locais e contas. O Gerenciamento de dados mestres (MDM, na sigla em inglês) é um conjunto de procedimentos que garantem que os dados mestres sejam precisos e consistentes em toda a organização.

Para que diferentes sistemas e divisões funcionem e interajam de maneira adequada, a precisão e a consistência dos dados são essenciais. Caso contrário, divisões diferentes de uma organização podem ter registros diferentes para a mesma entidade, o que pode levar a erros caros. Por exemplo, quando um cliente atualiza o endereço no site da empresa, se o departamento de cobrança recebe a informação de um repositório de clientes diferente, as contas futuras podem não chegar a esse cliente.

No MDM, um sistema autoritativo é a fonte da verdade para ativos de dados mestres específicos. O ideal é que outros sistemas da organização consumam os dados mestres do sistema autoritativo desse ativo. No entanto, isso nem sempre é possível, como se vê nos cenários a seguir.

Comunicação direta com o sistema autoritativo

Nesse cenário, os sistemas se comunicam diretamente com o sistema autoritativo responsável por um determinado ativo de dados mestres. Os sistemas autoritativos criam e atualizam os dados mestres, enquanto outros sistemas da organização sempre os consomem dos respectivos sistemas autoritativos.

Por exemplo, no diagrama, um sistema de Gerenciamento de informações do produto (PIM, na sigla em inglês) é o sistema autoritativo da empresa para produtos. Quando outro sistema, como um sistema de gestão de relacionamento com o cliente (CRM, na sigla em inglês), precisa de dados mestres do produto, ele recupera os dados do PIM. O sistema CRM pode ser ele próprio um sistema autoritativo de um ativo de dados diferente, como os clientes da empresa.

Esse cenário é ideal porque mantém os ativos de dados mestres nos respectivos sistemas autoritativos sem a necessidade de pipelines de transformação complexos. Se o sistema do consumidor precisar apenas de um determinado subconjunto dos dados mestres ou dados em um formato diferente, é responsabilidade desse sistema filtrá-los ou convertê-los.

Cópia dourada de uma única fonte

Neste cenário, o sistema do consumidor não consegue se comunicar diretamente com o sistema autoritativo. Os motivos por trás dessas restrições podem variar. Por exemplo:

• O sistema autoritativo pode não ter capacidade ou disponibilidade suficiente para lidar com o volume de solicitações de toda a organização.
• A comunicação entre os sistemas pode ser restrita por políticas de segurança ou ser inviável devido a limitações de infraestrutura.

Para superar essas restrições, use seu armazenamento de dados para disponibilizar os dados mestres para os sistemas do consumidor. Ao migrar para a nuvem, o BigQuery fornece para você um repositório que é altamente disponível, pode lidar com níveis altos de simultaneidade e pode ser amplamente acessível em sua organização, seguindo as regras do IAM. Portanto, o BigQuery é o principal candidato para hospedar a cópia dourada.

Recomendamos que você crie um pipeline de dados ELT para ler os dados mestres do sistema autoritativo, carregá-los no seu armazenamento de dados e depois distribuí-los aos consumidores. É preferível ter um pipeline ELT em vez de um pipeline ETL porque diferentes consumidores podem ter necessidades diferentes para o mesmo recurso de dados mestres. Portanto, primeiro carregue o recurso inalterado em seu armazenamento de dados e, em seguida, crie transformações especializadas para os consumidores. No Google Cloud, é possível usar o Dataflow para criar pipelines que possam se conectar ao BigQuery de forma nativa. Depois, é possível usar o Cloud Composer para orquestrar esses pipelines.

O sistema autoritativo permanece a fonte da verdade para o ativo de dados, enquanto os dados mestres copiados no armazenamento de dados são chamados de cópia dourada. Seu armazenamento de dados não se torna um sistema autoritativo.

Por exemplo, no diagrama, o sistema CRM não pode solicitar dados do produto diretamente do sistema PIM. Você cria um pipeline ETL que extrai os dados do sistema PIM, os copia no armazenamento de dados, realiza transformações e os distribui para outros sistemas, um deles o sistema CRM.

Se os sistemas recuperam os dados mestres em lotes ou para fins analíticos, o BigQuery é o lugar ideal para sua cópia dourada. No entanto, se a maioria dos acessos aos seus dados mestres vier de sistemas que fazem pesquisas em uma única linha, considere um repositório diferente otimizado para essas condições, como o Cloud Bigtable. Também é possível encontrar um equilíbrio usando os dois repositórios. Aquele com mais tráfego mantém a cópia dourada. Recomendamos que você sempre extraia os dados do sistema da cópia doutada e os sincronize com o outro repositório. Faça isso usando um pipeline de dados.

Cópia dourada de várias fontes

Os cenários anteriores usavam um único sistema autoritativo para um determinado ativo de dados mestres. No entanto, na prática, vários sistemas podem ser usados em uma organização para manter características diferentes do mesmo ativo. Por exemplo, um sistema PIM pode ser a fonte da verdade para informações técnicas e logísticas do produto, como dimensões, peso e proveniência. No entanto, um sistema de Gerenciamento de catálogo de produtos pode ser a fonte da verdade para informações sobre produtos relacionados a vendas, como cores, canais de vendas, preço e sazonalidade. Também é comum ter sistemas diferentes com atributos sobrepostos para o mesmo ativo. Por exemplo, de sistemas que anteriormente não faziam parte do MDM ou que foram incorporados à organização por meio de aquisições e fusões.

Nesses casos, é necessário um pipeline mais complexo para mesclar os dados mestres de várias origens em uma única cópia dourada no armazenamento de dados, conforme mostrado no diagrama a seguir. Os dados são então distribuídos aos sistemas do consumidor de maneira semelhante à da seção anterior. O armazenamento de dados ainda não é um sistema autoritativo, mas simplesmente um repositório para a cópia dourada dos dados mestres.

No Google Cloud, o Dataflow está bem posicionado como uma ferramenta para criar pipelines complexos representados por um gráfico acíclico direcionado (DAG, na sigla em inglês). Esses pipelines leem de várias fontes e gravam os resultados mesclados no BigQuery. Outra opção é usar uma ferramenta visual, como o Cloud Data Fusion, para criar o pipeline. O Cloud Data Fusion também oferece muitos plug-ins para fontes de dados e coletores.

Alterações lentas das dimensões

Espera-se que os atributos nas tabelas de dimensão em um esquema em estrela ou em floco de neve (links em inglês) nunca mudem ou raramente se alterem. Um atributo que nunca muda é chamado de original. Alguns exemplos são data de nascimento e pontuação de crédito original. Se um atributo mudar com pouca frequência, ele pertence a uma dimensão que muda lentamente (SCD, na sigla em inglês). Quando uma SCD é alterada, os dados que já estão na tabela de fatos precisam se referir à versão anterior do SCD. Portanto, você precisa de um método para manter o histórico de SCDs.

Ao migrar o armazenamento de dados, considere a oportunidade de incorporar um método de tratamento de SCD ou melhorar os atuais nestes casos:

• Ao evoluir seu esquema durante a fase de esquema e transferência de dados para garantir que os SCDs sejam contabilizados.
• Durante o estágio de migração do pipeline para garantir que você mantenha o histórico da SCD e o use de maneira reproduzível em cenários como recomputação de saídas para preenchimentos, reprocessamento devido a alterações lógicas e rastreamento de linhagem.

Métodos tradicionais de manipulação de SCD

Os métodos tradicionais de manipulação de alterações de SCD são chamados de tipos de SCD de 0 a 6. O método mais comum é o SCD tipo 2 (em inglês), em que os dados históricos são rastreados por meio da criação de mais colunas na tabela de dimensões. As outras colunas são uma chave alternativa e uma das seguintes opções: uma versão, as datas de início/término de validade ou uma data atual mais uma sinalização para indicar qual das linhas é atual. Para mais informações sobre como essa e outras técnicas podem ser aplicadas no BigQuery, consulte Como manipular alterações.

Engenharia de dados funcionais

Outro método para lidar com SCDs foi apresentado por Maxime Beauchemin, criador do Apache Airflow, no artigo Engenharia de dados funcionais (links em inglês). Este artigo propõe um paradigma em que um pipeline de dados é composto por uma coleção de tarefas determinísticas e idempotentes organizadas em um DAG para refletir as interdependências direcionais.

Uma tarefa é determinística quando a saída dela depende apenas das entradas, e não de qualquer estado local ou global, seguindo assim os conceitos da programação funcional (em inglês). Uma tarefa é considerada idempotente quando pode ser executada mais de uma vez com os mesmos parâmetros de entrada e ainda produzir a mesma saída. Em outras palavras, não causa outros efeitos. Um exemplo disso na computação é a operação REST PUT. Uma execução de tarefa é chamada de instância da tarefa. Instâncias de tarefas com entradas diferentes gravam dados em partições diferentes da mesma tabela de saída.

Como uma das entradas para tarefas são as dimensões, Beauchemin defende a criação de snapshots de dimensão sempre que uma execução de ETL é acionada. Um snapshot de dimensão duplica todas as linhas de dimensão necessárias para a execução do ETL, juntamente com um carimbo de data/hora. As tabelas de dimensão se tornam uma coleção de snapshots em diferentes momentos. Esses snapshots mantêm o histórico de alterações nas SCDs e permitem executar novamente qualquer instância de tarefa e conseguir saídas reproduzíveis consistentes.

Esse método é um desvio da maneira tradicional de lidar com SCDs, como SCD tipo 2. Ele evita a complexidade de gerenciar chaves alternativas e mais colunas, reduzindo o tempo de engenharia, ao custo de um armazenamento relativamente barato. O artigo reconhece que os dois métodos podem coexistir.

Como manipular SCDs no BigQuery

O BigQuery aceita esquemas em estrela e floco de neve, incluindo tabelas de dimensão. Portanto, qualquer um dos dois métodos anteriores é aplicável.

O BigQuery vai um passo além, promovendo a desnormalização do esquema com compatibilidade nativa com campos aninhados e repetidos. Esses campos podem ser usados em tabelas de fatos quando o atributo no momento do evento é importante. Eles também podem ser usados em tabelas de dimensão para registrar valores históricos com uma abordagem de tipo 2 ou de snapshot apenas para os atributos alterados, em vez de toda a linha de dimensão.

Retenção e exclusão de dados

Em situações específicas, convém impedir que os usuários modifiquem ou excluam dados no BigQuery. É possível aplicar essa restrição a esses usuários por meio da remoção de papéis que incluam permissões a essas operações. Esses papéis são roles/bigquery.dataOwner, roles/bigquery.dataEditor, e roles/bigquery.admin. Outra opção é criar papéis personalizados do IAM que não incluam permissões específicas de edição e exclusão.

Se for necessário atender a regulamentações para retenção de registros eletrônicos, recomendamos que você exporte os dados para o Cloud Storage e use o recurso bloqueio de buckets, que ajuda a lidar com determinadas regulamentações de armazenamento de registros.

Em outras situações, pode ser necessário excluir os dados automaticamente após um determinado período. O BigQuery pode atender a essa necessidade por meio de uma data de validade configurável. É possível aplicar a data de validade a um conjunto de dados, uma tabela ou partições de tabela específicas. A expiração de dados desnecessários é uma medida de controle de custos e otimização de armazenamento. Para mais informações, consulte Práticas recomendadas do BigQuery. Para uma visão geral mais ampla da exclusão de dados no Google Cloud, consulte esta página de documentação.

Se um cliente do Google Cloud determinar que um regulamento é aplicável, ele precisará concluir a própria avaliação de conformidade com os requisitos específicos sob a supervisão de seu próprio advogado e do regulador correspondente.

Gerenciamento da qualidade de dados

Os processos de gerenciamento da qualidade de dados incluem os itens a seguir:

• Criar controles para validação.
• Ativar relatórios e monitoramento de qualidade.
• Auxiliar o processo de triagem para avaliar o nível de gravidade do incidente.
• Ativar a análise de causa raiz e recomendação de soluções para problemas com dados.
• Rastrear incidentes de dados.

Consumidores de dados diferentes podem ter requisitos de qualidade de dados diferentes. Por isso, é importante documentar as expectativas de qualidade de dados, bem como técnicas e ferramentas para auxiliar o processo de validação e monitoramento de dados. Estabelecer bons processos para o gerenciamento da qualidade de dados ajuda a fornecer dados mais confiáveis para análise.

Metadados de qualidade

Um armazenamento de dados fornece aos tomadores de decisão acesso a uma imensa quantidade de dados com curadoria. No entanto, nem todos os dados no armazenamento de dados serão tratados igualmente:

• No contexto de tomada de decisões, dados de alta qualidade precisam ter mais influência nas decisões, e dados de qualidade inferior, menos influência.
• No contexto do monitoramento da qualidade de dados, dados de baixa qualidade podem ser usados para acionar alertas automáticos ou manuais a fim de verificar os processos que os estão produzindo, mesmo antes deles chegarem ao armazenamento de dados.

Além disso, partes diferentes da organização podem ter limites diferentes para a qualidade de dados. Por exemplo, dados de baixa qualidade podem ser perfeitamente utilizáveis para desenvolvimento e teste, mas podem ser considerados inutilizáveis para finanças ou conformidade.

Nesta seção, apresentamos os metadados como um mecanismo para fornecer aos tomadores de decisão e processamos o contexto necessário para avaliar os dados que estão sendo apresentados a eles.

Estrutura e formato

Os metadados são informações estruturadas anexadas a um dado para qualificá-lo. No contexto da qualidade de dados, os metadados permitem coletar atributos relevantes, como precisão, atualização e integridade.

A semântica e os atributos específicos capturados nos seus metadados de qualidade de dados (DQM, na sigla em inglês) dependem do contexto de negócios que estão qualificando. É altamente recomendável adotar um conjunto padrão de atributos em toda a empresa para facilitar a comunicação e o gerenciamento. O conjunto de atributos escolhido pode ser derivado de padrões do setor, como Modelo de qualidade de dados ISO/IEC 25012:2008 ou recomendações de organizações profissionais, como a comunidade Data Management (DAMA) (link em inglês).

O formato em que seu DQM é armazenado e apresentado aos tomadores de decisão também é uma consideração importante. Diferentes formatos podem ser adequados para diferentes tarefas de tomada de decisão. Por exemplo, Moges, et al. (em inglês) compila e apresenta uma lista dos seguintes formatos para DQM:

• Ordinal de nível N: um conjunto finito de valores como excelente, bom e médio.
• Intervalo: uma escala numérica com limites inferior e superior, como 0-100, para representar o nível de qualidade com mais flexibilidade que um ordinal.
• Probabilidade: a qualidade dos dados em uma escala de 0 a 1, indicando a probabilidade de que os dados estejam corretos.
• Gráfico: listas visuais, como cores, para indicar o nível de qualidade.

Metadados de qualidade na nuvem

Tradicionalmente, as empresas não mantêm um repositório de DQM consistente, dependendo, em vez disso, do conhecimento compartilhado. Às vezes, esse conhecimento é capturado em repositórios separados, como planilhas, páginas da Intranet e tabelas de banco de dados ad hoc. O esforço para descobrir, pesquisar, entender e manter essas fontes diferentes de DQM dificulta a colaboração e pode superar o valor de apoio à decisão.

O Data Catalog oferece uma maneira centralizada de gerenciar seus metadados:

• Tags de metadados personalizados, também conhecidos como metadados comerciais, são compatíveis com todos os atributos de qualidade de dados que você quiser que façam parte das definições padrão, e agrupam-se em modelos lógicos que podem ser personalizados para cada contexto de negócios.
• Ele aceita tipos enumerados personalizados para representar atributos ordinais e tipos duplos e de string para representar intervalos, probabilidades e valores numéricos que podem ser usados para diferentes representações gráficas. É possível acessar esses valores de metadados pela IU do Data Catalog ou das APIs e bibliotecas de clientes que permitem criar aplicativos personalizados para as pessoas responsáveis pelas decisões.
• É possível usar a API Data Catalog nos seus processos upstream. Quando a qualidade dos dados de uma determinada fonte cai abaixo de um limite, o processo marca os dados de baixa qualidade dessa maneira e dispara um alerta antes que eles cheguem ao BigQuery. Os dados em si podem ser enviados para um bucket de quarentena no Cloud Storage para verificação e, possivelmente, correção e reprocessamento.

Considerações sobre DQM

É possível supor que, sem o DQM, seja mais provável que os tomadores de decisão usem dados de baixa qualidade e produzam más decisões. Na realidade, adicionar o DQM ao conjunto pode sobrecarregar os tomadores de decisão devido à quantidade de informações que eles precisam absorver para gerar alternativas. Ter muitas informações pode afetar negativamente a pontualidade e a qualidade das decisões.

Portanto, é essencial que os tomadores de decisão sejam treinados sobre a semântica e as práticas recomendadas do DQM. Moges et al. sugere que fornecer DQM e treinamento é benéfico para tarefas essenciais em que as consequências do uso de dados de baixa qualidade são altas. No entanto, o DQM pode ser contraproducente para tarefas que precisam de alta eficiência ou quando a equipe não está treinada adequadamente.

Auditoria

As organizações precisam conseguir auditar os sistemas para garantir que eles estejam funcionando conforme foram projetados. O monitoramento, a auditoria e o rastreamento ajudam as equipes de segurança a coletar dados, identificar ameaças e agir sobre elas antes que gerem danos ou perdas à empresa. É importante que você realize auditorias regulares, porque elas verificam a eficácia dos controles a fim de reduzir rapidamente as ameaças e avaliar a integridade geral da segurança. A auditoria também pode ser necessária para demonstrar conformidade regulamentar com auditores externos.

Uma primeira etapa para garantir controles de acesso a dados íntegros é auditar periodicamente os usuários e grupos associados ao projeto do Google Cloud e aos conjuntos de dados individuais do BigQuery. Esses usuários precisam ser Proprietários ou Administradores ou um papel mais restritivo seria suficiente para as tarefas deles? Também é importante auditar quem consegue alterar as políticas do IAM nos seus projetos.

Uma segunda etapa na análise de registros é responder às perguntas: "Quem fez o quê, onde e quando?" com dados e metadados do BigQuery.

• Para os dados, o BigQuery inclui no Cloud Logging, por padrão, dois fluxos de registros imutáveis: atividade do administrador e registros de auditoria de acesso a dados.
• Para seus metadados, o Data Catalog também aceita os dois fluxos de registro de auditoria, mas, diferentemente do BigQuery, o registro do Data Access precisa ser ativado de maneira manual.

Os registros de Atividade do administrador contêm entradas de registro para chamadas de registro ou outras ações administrativas que modificam a configuração ou os metadados de recursos. Por exemplo, a criação de novas contas de serviço ou alterações nas permissões do IAM, como a concessão de um acesso de leitura a um novo usuário para os conjuntos de dados do BigQuery, são gravadas nos Registros de atividade do administrador.

Os Registros de acesso a dados gravam chamadas de API autenticadas pelo usuário que criam, modificam ou leem dados fornecidos por ele. Por exemplo, os registros do Data Access gravam se um usuário consultou um conjunto de dados do BigQuery ou solicitou os resultados da consulta. Atribuir consultas a um usuário em vez de uma conta de serviço facilita a auditoria de acesso a dados.

Para os dois tipos de registros, é possível criar alertas do Cloud Monitoring que são acionados quando as condições que você determinar forem atendidas. Quando acionados, esses alertas podem enviar notificações por vários canais, incluindo e-mail, SMS, serviços de terceiros e até webhooks para um URL personalizado.

Esteja ciente de que os registros de auditoria podem incluir informações confidenciais. Portanto, convém restringir o acesso a eles. O acesso aos registros de auditoria pode ser restrito com o uso de papéis do IAM.

Recomendamos exportar registros de auditoria do BigQuery do Cloud Logging para um conjunto de dados do BigQuery pelos seguintes motivos:

• O Cloud Logging mantém os registros de auditoria apenas por um período de armazenamento de registros limitado. A exportação para outro local de armazenamento seguro, como o BigQuery ou o Cloud Storage, permite que você tenha um período de armazenamento a longo prazo.
• No BigQuery, é possível executar consultas SQL nos registros, permitindo filtragem complexa para análise.
• Além disso, é possível criar painéis (em inglês) com o uso de ferramentas de visualização, como o Data Studio.

Para mais informações, consulte a postagem do blog "Práticas recomendadas para trabalhar com registros de auditoria do Google Cloud".

A seguir

• Assista o vídeo e leia mais sobre as práticas recomendadas em Como organizar recursos do BigQuery
• Confira o conteúdo de arquiteturas, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira nossa série Estrutura de arquitetura, no Centro de arquitetura do Cloud.

Qual o serviço que determina quais recursos os usuários podem acessar além das operações que podem executar?

Quais são os três serviços de segurança de controle de acesso?

Quais são os três estados dos dados escolha três?

Quais são os dois métodos que ajudam a garantir a integridade de dados escolher dois Select one or more?