Neste documento, você verá como usar a proteção de dados confidenciais para criar um pipeline de transformação de dados automatizado para desidentificar dados confidenciais, como informações de identificação pessoal (PII, na sigla em inglês). Com técnicas de desidentificação, como tokenização (pseudonimização), é possível preservar a utilidade dos dados para mesclar ou analisar e, ao mesmo tempo, reduzir o risco de manipular os dados, ofuscando os identificadores confidenciais brutos. Para minimizar o risco de manipular grandes volumes de dados confidenciais, use um pipeline de transformação de dados automatizado para criar réplicas anônimas. A proteção de dados confidenciais permite transformações como edição, mascaramento, tokenização, agrupamento por classes e outros métodos de desidentificação. Quando um conjunto de dados não foi caracterizado, a proteção de dados confidenciais também pode inspecionar os dados em busca de informações confidenciais usando mais de 100 classificadores integrados.
Este documento destina-se a um público-alvo técnico com responsabilidades que incluem segurança, processamento ou análise de dados. Neste guia, consideramos que você já conhece o processamento e a privacidade de dados, sem a necessidade de ser um especialista.
Arquitetura de referência
No diagrama a seguir, mostramos uma arquitetura de referência que usa produtos do Google Cloud para adicionar uma camada de segurança a conjuntos de dados sensíveis usando técnicas de desidentificação.
A arquitetura consiste no seguinte:
O pipeline de streaming de desidentificação de dados: desidentifica dados confidenciais no texto usando o Dataflow. É possível reutilizar o pipeline para várias transformações e casos de uso.
Gerenciamento de configurações (modelo e chave de proteção de dados confidenciais): uma configuração de desidentificação gerenciada que pode ser acessada apenas por um pequeno grupo de pessoas, como administradores de segurança, para evitar a exposição de métodos de desidentificação e chaves de criptografia.
O pipeline de validação e reidentificação de dados: valida cópias dos dados desidentificados e usa um pipeline do Dataflow para reidentificar dados em grande escala.
Como ajudar a proteger dados confidenciais
Uma das principais tarefas de qualquer empresa é ajudar a garantir a segurança dos dados dos usuários e dos funcionários. O Google Cloud fornece medidas de segurança integradas para facilitar a segurança dos dados, incluindo a criptografia de dados armazenados e a criptografia de dados em trânsito.
Criptografia em repouso: Cloud Storage
Manter a segurança dos dados é fundamental para a maioria das organizações. O acesso não autorizado até mesmo a dados moderadamente confidenciais pode prejudicar a confiança, os relacionamentos e a reputação que você tem com seus clientes. O Google criptografa dados armazenados em repouso por padrão. Por padrão, qualquer objeto enviado para um bucket do Cloud Storage é criptografado usando uma chave de propriedade do Google e gerenciada pelo Google. Há outras opções de criptografia fornecidas pelo Cloud Storage, caso o conjunto de dados use um método de criptografia pré-existente e necessite de uma opção não padrão antes de fazer o upload. Para mais informações, consulte Opções de criptografia de dados.
Criptografia em trânsito: fluxo de dados
Quando seus dados estão em trânsito, a criptografia em repouso não está em vigor. Os dados em trânsito são protegidos por protocolos de rede segura, conhecidos como criptografia em trânsito. Por padrão, o Dataflow usa chaves de propriedade e gerenciadas pelo Google. Os tutoriais associados a este documento usam um pipeline automatizado que utiliza as chaves padrão de propriedade e gerenciadas pelo Google.
Transformações de dados da proteção de dados confidenciais
Há dois tipos principais de transformações realizadas pela proteção de dados confidenciais:
Os métodos recordTransformations e infoTypeTransformations podem
desidentificar e criptografar informações confidenciais nos dados. Por exemplo, é possível
transformar os valores na coluna US_SOCIAL_SECURITY_NUMBER para não serem
identificáveis ou usar a tokenização para ocultá-los e manter a integridade
referencial.
O método infoTypeTransformations permite que você inspecione dados confidenciais
e transforme a descoberta. Por exemplo, se você tiver dados não estruturados ou de texto livre,
o método infoTypeTransformations poderá ajudar a identificar um SSN dentro
de uma frase e criptografar o valor do SSN, mantendo o restante do texto intacto. Também é possível definir métodos infoTypes personalizados.
O método recordTransformations permite aplicar uma configuração
de transformação por campo ao usar dados estruturados ou tabelados. Com o método recordTransformations, é possível aplicar a mesma transformação a todos os valores nesse campo, como hash ou tokenização de cada valor em uma coluna com a coluna SSN como o nome do campo ou cabeçalho.
Com o método recordTransformations, também é possível misturar no método
infoTypeTransformations que só se aplica aos valores nos campos
especificados. Por exemplo, é possível usar um método infoTypeTransformations dentro de um método recordTransformations para o campo denominado comments visando editar as descobertas de US_SOCIAL_SECURITY_NUMBER encontradas no texto no campo.
Em ordem crescente de complexidade, os processos de desidentificação são os seguintes:
- Edição: remover o conteúdo confidencial sem substituí-lo.
- Mascaramento: substituir o conteúdo confidencial por caracteres fixos.
- Criptografia: substituir o conteúdo confidencial por strings criptografadas, possivelmente de maneira reversível.
Como trabalhar com dados delimitados
Geralmente, os dados consistem em registros delimitados por um caractere selecionado, com tipos
fixos em cada coluna, como um arquivo CSV. Para essa classe de dados, aplique transformações de desidentificação (recordTransformations) diretamente, sem inspecionar os dados. Por exemplo, é possível que uma coluna denominada SSN tenha apenas dados SSN. Você não precisa inspecionar os dados para saber se o detector infoType é US_SOCIAL_SECURITY_NUMBER. No entanto, as colunas de formato livre denominadas Additional Details podem conter informações confidenciais, mas a classe infoType é desconhecida. Para uma coluna de formato livre, você precisa inspecionar o detector infoTypes (infoTypeTransformations) antes de aplicar transformações de desidentificação. A proteção de dados confidenciais permite que esses dois tipos de transformação coexistam em um único modelo de desidentificação.
A proteção de dados confidenciais inclui
mais de 100 detectores infoTypes integrados.
Também é possível criar tipos personalizados ou modificar os detectores infoTypes integrados para encontrar dados confidenciais exclusivos da sua organização.
Como determinar o tipo de transformação
A decisão sobre usar o método recordTransformations ou infoTypeTransformations
depende do seu caso de uso. Como o uso do método infoTypeTransformations
requer mais recursos e, portanto, é mais caro, recomendamos usá-lo apenas
nas situações em que o tipo de dados é desconhecido. É possível avaliar os custos de execução da Proteção de dados confidenciais usando a calculadora de preços do Google Cloud.
Neste exemplo de transformação, este documento se refere a um conjunto de dados que contém arquivos CSV com colunas fixas, conforme demonstrado na tabela a seguir.
| Nome da coluna | infoType de inspeção (personalizada ou integrada) |
Tipo de transformação da proteção de dados confidenciais |
|---|---|---|
Card Number
|
Não relevante | Criptografia determinística (DE, na sigla em inglês) |
Card Holder's Name
|
Não relevante | Criptografia determinística (DE, na sigla em inglês) |
Card PIN
|
Não relevante | Hash de criptografia |
SSN (Social Security Number)
|
Não relevante | Mascaramento |
Age
|
Não relevante | Agrupamento por classes |
Job Title
|
Não relevante | Agrupamento por classes |
Additional Details
|
Integrado:IBAN_CODE, EMAIL_ADDRESS,
PHONE_NUMBER
Personalizado:
ONLINE_USER_ID
|
Substituição |
Nessa tabela, listamos os nomes das colunas e descrevemos qual tipo de transformação é
necessária para cada coluna. Por exemplo, a coluna Card Number contém números de cartão de crédito
que precisam ser criptografados. No entanto, eles não precisam ser
inspecionados, porque o tipo de dados (infoType) é conhecido.
A única coluna em que uma transformação de inspeção é recomendada é a coluna
Additional Details. Essa coluna é de formato livre e pode conter PII, que, para os fins deste exemplo, precisa ser detectada e desidentificada.
Nos exemplos nesta tabela, você vê cinco transformações de desidentificação diferentes:
Tokenização bidirecional: substitui os dados originais por um token determinista, preservando a integridade referencial. Use o token para unir dados ou use o token na análise agregada. É possível reverter ou destokenizar os dados usando a mesma chave usada para criar o token. Há dois métodos de tokenização bidirecional:
- Criptografia determinística (DE, na sigla em inglês): substitui os dados originais por um valor criptografado codificado em base64 e não preserva o comprimento ou o conjunto de caracteres original.
- Criptografia de preservação de formato com FFX (FPE-FFX, na sigla em inglês): substitui os dados originais por um token gerado usando a criptografia de preservação de formato no modo FFX. Por design, a FPE-FFX preserva o comprimento e o conjunto de caracteres do texto de entrada. A autenticação e um vetor de inicialização estão faltando nesse método, o que pode causar uma expansão de comprimento no token de saída. Outros métodos, como o DE, oferecem segurança mais forte e são recomendados para casos de uso de tokenização, a menos que o tamanho e a preservação do conjunto de caracteres sejam requisitos rigorosos, como compatibilidade com versões anteriores com sistemas de dados legados.
Tokenização unidirecional, usando o hash criptográfico: substitui o valor original por um valor de hash, preservando a integridade referencial. No entanto, ao contrário da tokenização bidirecional, um método unilateral não é reversível. O valor de hash é gerado usando um código de autenticação de mensagem baseado em SHA-256 (HMAC-SHA-256, em inglês) no valor de entrada.
Mascaramento: substitui os dados originais por um caractere específico parcial ou completo.
Agrupamento por classes: substitui um valor mais identificável por um valor menos distintivo.
Substituição: substitui os dados originais por um token ou pelo nome do
infoType, se detectado.
Seleção de método
A escolha do melhor método de desidentificação pode variar de acordo com seu caso de uso. Por exemplo, se um aplicativo legado estiver processando os registros desidentificados, a preservação do formato poderá ser importante. Se você estiver lidando com números de 10 dígitos estritamente formatados, o FPE preservará o comprimento (10 dígitos) e o conjunto de caracteres (numérico) de uma entrada do suporte do sistema legado.
No entanto, se a formatação estrita não for necessária para a compatibilidade legada, como é o caso dos valores na coluna Card Holder's Name, a DE será a escolha recomendada, porque ela tem um método de autenticação mais forte. Tanto a FPE quanto a DE permitem que os tokens sejam revertidos ou destokenizados. Se você não precisar de destokenização, o hash criptográfico fornecerá integridade, mas os tokens não poderão ser revertidos.
Outros métodos, como mascaramento, agrupamento por bucket, mudança de data e substituição, são bons para valores que não precisam manter a integridade total. Por exemplo, o agrupamento por buckets de um valor de idade (por exemplo, 27) para uma faixa etária (20-30) ainda pode ser analisado, reduzindo a exclusividade que pode levar à identificação de um indivíduo.
Chaves de criptografia de token
Para transformações criptográficas de desidentificação, é necessária uma chave criptográfica, também conhecida como chave de criptografia do token. A chave de criptografia do token usada para desidentificar a criptografia também é usada para reidentificar o valor original. A criação e o gerenciamento seguros de chaves de criptografia de token estão fora do escopo deste documento. No entanto, há alguns princípios importantes a serem considerados que serão usados posteriormente nos tutoriais associados:
- Evite usar chaves de texto sem formatação no modelo. Em vez disso, use o Cloud KMS para criar uma chave encapsulada.
- Use chaves de criptografia de token separadas para cada elemento de dados a fim de reduzir o risco de comprometimento de chaves.
- Faça o revezamento das chaves de criptografia do token. Mesmo que seja possível revezar a chave encapsulada, o revezamento da chave de criptografia do token corrompe a integridade da tokenização. Quando a chave é revezada, é necessário tokenizar novamente todo o conjunto de dados.
Modelos de proteção de dados confidenciais
Para implantações em grande escala, use os modelos de proteção de dados confidenciais para realizar o seguinte:
- Ative o controle de segurança com o gerenciamento de identidade e acesso (IAM).
- Separar as informações de configuração e como desidentificar essas informações da implementação das solicitações.
- Reutilizar um conjunto de transformações. É possível usar os modelos de desidentificação e reidentificação em vários conjuntos de dados.
BigQuery
O componente final da arquitetura de referência é visualizar e trabalhar com os dados não identificados no BigQuery. O BigQuery é a ferramenta de armazenamento de dados do Google que inclui infraestrutura sem servidor, BigQuery ML e a capacidade de executar a proteção de dados confidenciais como uma ferramenta nativa. Na arquitetura de referência de exemplo, o BigQuery é exibido como um armazenamento de dados para os dados desidentificados e como um back-end para um pipeline de dados de reidentificação automatizado que pode compartilhar dados por meio do Pub/Sub.
A seguir
- Saiba como usar a proteção de dados confidenciais para inspecionar armazenamento e bancos de dados em busca de dados confidenciais.
- Saiba mais sobre outras soluções de reconhecimento de padrão (em inglês).
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.