Pseudonimização

A pseudonimização é uma técnica de desidentificação que substitui valores de dados confidenciais por tokens gerados criptograficamente. A pseudonimização é amplamente usada em setores como finanças e saúde para ajudar a reduzir o risco de dados em uso, restringir o escopo de conformidade e minimizar a exposição de dados confidenciais aos sistemas, preservando a utilidade e a precisão dos dados.

A proteção de dados confidenciais é compatível com três técnicas de pseudonimização de desidentificação e gera tokens aplicando um dos três métodos de transformação criptográfica aos valores de dados confidenciais originais. Cada valor confidencial original é substituído pelo token correspondente. Às vezes, a pseudonimização é chamada de tokenização ou substituição alternativa.

As técnicas de pseudonimização permitem tokens unidirecionais ou bidirecionais. Um token unidirecional foi transformado de forma irrevogável, enquanto um token bidirecional pode ser revertido. Como o token é criado usando criptografia simétrica, a mesma chave criptográfica que gera novos tokens também pode reverter tokens. Para situações em que você não precisa de reversão, é possível usar tokens unidirecionais que usam mecanismos de hash seguros.

É útil entender como a pseudonimização pode ajudar a proteger os dados confidenciais e, ao mesmo tempo, permitir que suas operações de negócios e fluxos de trabalho analíticos tenham fácil acesso e usem os dados de que precisam. Neste tópico, exploramos o conceito de pseudonimização e os três métodos criptográficos para transformar dados compatíveis com a proteção de dados sensíveis.

Para instruções sobre como implementar esses métodos de pseudonimização e mais exemplos de uso da proteção de dados sensíveis, consulte Como desidentificar dados sensíveis.

Métodos criptográficos com suporte na proteção de dados sensíveis

A proteção de dados confidenciais é compatível com três técnicas de pseudonimização, que usam chaves criptográficas. Veja a seguir os métodos disponíveis:

• Criptografia determinística usando AES-SIV: um valor de entrada é substituído por um valor que foi criptografado usando o algoritmo de criptografia AES-SIV com uma chave criptográfica, codificada com base64 e, em seguida, anexada com uma anotação alternativa, se especificada. Esse método produz um valor de hash. Portanto, ele não preserva o conjunto de caracteres ou o comprimento do valor de entrada. Os valores de hash criptografados podem ser reidentificados com a chave criptográfica original e todo o valor de saída, inclusive a anotação alternativa. Saiba mais sobre o formato dos valores tokenizados usando a criptografia AES-SIV.
• Criptografia com preservação de formato: um valor de entrada é substituído por um valor que foi criptografado usando o algoritmo de criptografia FPE-FFX por uma chave criptográfica. e, em seguida, anexada com uma anotação alternativa, se especificada. Por design, o conjunto de caracteres e o comprimento do valor de entrada são preservados no valor de saída. Os valores criptografados podem ser identificados novamente usando a chave criptográfica original e todo o valor de saída, incluindo anotação alternativa. Para algumas considerações importantes sobre o uso desse método de criptografia, consulte Como preservar a criptografia de formato neste tópico.
• Hash criptográfico: um valor de entrada é substituído por um valor criptografado e com hash usando o código de autenticação de mensagem baseado em hash (HMAC, na sigla em inglês) e algoritmo de hash seguro (SHA)-256 no valor de entrada com uma chave criptográfica. A saída com hash da transformação tem sempre o mesmo tamanho e não pode ser reidentificada. Saiba mais sobre o formato dos valores tokenizados usando hash criptográfico.

Esses métodos de pseudonimização estão resumidos na tabela a seguir. As linhas da tabela são explicadas após a tabela.

	Criptografia determinística usando AES-SIV	Criptografia com preservação de formato	Hash criptográfico
Tipo de criptografia	AES-SIV	FPE-FFX	HMAC-SHA-256
Valores de entrada compatíveis	Ter no mínimo um caractere; sem limitações de conjuntos de caracteres.	Ter pelo menos 2 caracteres; ser codificado como ASCII.	Precisa ser uma string ou um valor inteiro.
Anotação alternativa	Opcional.	Opcional.	N/A
Ajuste de contexto	Opcional.	Opcional.	N/A
Conjunto de caracteres e comprimento preservados	✗	✓	✗
Reversível	✓	✓	✗
Integridade referencial	✓	✓	✓

• Tipo de criptografia: o tipo de criptografia usado na transformação de desidentificação.
• Valores de entrada compatíveis: requisitos mínimos para valores de entrada.
• Anotação alternativa:uma anotação especificada pelo usuário que é anexada a valores criptografados para fornecer contexto aos usuários e fornecer informações para que a proteção de dados sensíveis use na reidentificação de um valor desidentificado. Uma anotação alternativa é necessária para a reidentificação de dados não estruturados. É opcional ao transformar uma coluna de dados estruturados ou tabulares com um RecordTransformation.
• Ajuste de contexto: uma referência a um campo de dados que ajuste o valor de entrada para que os valores de entrada idênticos sejam desidentificados para diferentes valores de saída. O ajuste de contexto é opcional ao transformar uma coluna de dados estruturados ou tabulares, com um RecordTransformation. Para mais informações, consulte Como usar os ajustes de contexto.
• Conjunto de caracteres e comprimento preservado: se um valor desidentificado é composto pelo mesmo conjunto de caracteres que o valor original e se o comprimento do valor desidentificado corresponde ao do valor original.
• Gravidade: pode ser reidentificada usando a chave criptográfica, a anotação alternativa e qualquer ajuste de contexto.
• Integridade de referência: a integridade referencial permite que os registros mantenham o relacionamento entre si, mesmo depois que os dados são desidentificados individualmente. Da mesma chave criptográfica e ajuste de contexto, uma tabela de dados será substituída pela mesma forma ofuscada sempre que ela for transformada. Isso garante que as conexões entre os valores (e com os dados estruturados e registros) sejam preservadas, mesmo entre tabelas.

Como a tokenização funciona na proteção de dados sensíveis

O processo básico de tokenização é o mesmo para os três métodos compatíveis com a proteção de dados sensíveis.

Etapa 1: a proteção de dados sensíveis seleciona os dados a serem tokenizados. A maneira mais comum de fazer isso é usar um detector de infoType integrado ou personalizado para corresponder aos valores de dados confidenciais desejados. Se você estiver verificando dados estruturados (como uma tabela do BigQuery), também será possível realizar a tokenização em colunas inteiras de dados usando transformações de registro.

Para mais informações sobre as duas categorias de transformações (infoType e transformações de registro), consulte Transformações de desidentificação.

Etapa 2: com uma chave criptográfica, a proteção de dados sensíveis criptografa cada valor de entrada. Há três maneiras de fornecer essa chave:

• Encapsulando-o usando o Cloud Key Management Service (Cloud KMS). Para ter o máximo de segurança, o Cloud KMS é o método preferido.
• Usando uma chave temporária, que a proteção de dados sensíveis gera no momento da desidentificação e, em seguida, descarta. Uma chave temporária mantém a integridade apenas por solicitação de API. Se você precisar de integridade ou planejar reidentificar esses dados, não use esse tipo de chave.
• Diretamente em formato de texto bruto. (Não recomendado.)

Para mais detalhes, consulte a seção Como usar chaves criptográficas, mais adiante neste tópico.

Etapa 3 (hash criptográfico e criptografia determinística somente com AES-SIV): a proteção de dados sensíveis codifica o valor criptografado usando base64. Com hash criptográfico, esse valor codificado é o token e o processo continua com a Etapa 6. Com a criptografia determinística usando o AES-SIV, esse valor criptografado e codificado é o valor alternativo, que é apenas um componente do token. O processo continua na Etapa 4.

Etapa 4 (preservação do formato e criptografia determinística com AES-SIV): a proteção de dados sensíveis adiciona uma anotação substituta opcional ao valor criptografado. A anotação alternativa ajuda a identificar valores alternativos criptografados anexando uma string descritiva definida por você. Por exemplo, sem uma anotação, talvez você não consiga distinguir um número de telefone desidentificado e um CPF desidentificado ou outro número de identificação. Além disso, para reidentificar valores em dados não estruturados que foram desidentificados usando o formato que preserva a criptografia ou a criptografia determinística, é preciso especificar uma anotação alternativa. As anotações alternativas não são necessárias ao transformar uma coluna de dados estruturados ou tabulares com um RecordTransformation.

Etapa 5 (preservação do formato e criptografia determinística com AES-SIV somente de dados estruturados): a proteção de dados sensíveis pode usar contexto opcional de outro campo para "ajustar" o token gerado. Isso permite que você altere o escopo do token. Por exemplo, suponha que você tenha um banco de dados de campanha de marketing que inclua endereços de e-mail e queira gerar tokens exclusivos para o mesmo endereço de e-mail "ajustado" pelo ID da campanha. Isso permite que alguém mescle dados do mesmo usuário na mesma campanha, mas não em diferentes campanhas. Se um ajuste de contexto for usado para criar o token, esse ajuste também será necessário para que as transformações de desidentificação sejam revertidas. Preservação de formato e criptografia determinística usando contextos de suporte AES-SIV. Saiba mais sobre como usar os ajustes de contexto.

Observação :para mais informações sobre o formato de valores tokenizados, incluindo anotações e contextos alternativos, consulte a próxima seção, "Comparação de valor tokenizado".

Etapa 6: a proteção de dados sensíveis substitui o valor original pelo valor desidentificado.

Comparação de valores tokenizados

Nesta seção, demonstramos como os tokens típicos parecem depois de serem desidentificados usando cada um dos três métodos discutidos neste tópico. O valor de dados confidenciais de exemplo é um número de telefone da América do Norte (1-206-555-0123).

Criptografia determinística usando AES-SIV

Com a desidentificação usando criptografia determinística e AES-SIV, um valor de entrada (e, opcionalmente, qualquer ajuste de contexto especificado) é criptografado usando AES-SIV com uma chave criptográfica, codificado usando base64 e, opcionalmente, anexado por uma anotação alternativa, se especificado. Esse método não preserva o conjunto de caracteres (ou "alfabeto") do valor de entrada. Para gerar a saída imprimível, o valor resultante é codificado em base64.

O token resultante, supondo que um InfoType alternativo tenha sido especificado, está no formato:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

O diagrama anotado a seguir mostra um token de exemplo: a saída de uma operação de desidentificação usando criptografia determinística com AES-SIV no valor 1-206-555-0123. O InfoType alternativo opcional foi definido como NAM_PHONE_NUMB:

1. Anotação alternativa
2. InfoType alternativo (definido pelo usuário)
3. Comprimento do caractere do valor transformado
4. Valor alternativo (transformado)

Se você não especificar uma anotação alternativa, o token resultante será igual ao valor transformado ou número 4 no diagrama anotado. Para reidentificar dados não estruturados, todo o token é obrigatório, incluindo a anotação alternativa. Ao transformar dados estruturados, como uma tabela, a anotação alternativa é opcional. A proteção de dados confidenciais pode realizar a desidentificação e a reidentificação em uma coluna inteira usando um RecordTransformation sem uma anotação alternativa.

Criptografia com preservação de formato

Com a desidentificação usando criptografia com preservação de formato, um valor de entrada (e, opcionalmente, qualquer ajuste de contexto especificado) é criptografado usando o modo FFX da criptografia de preservação de formato ("FPE-FFX") com uma chave criptográfica, e, opcionalmente, com uma anotação alternativa, se especificada.

Ao contrário dos outros métodos de tokenização descritos neste tópico, o valor alternativo de saída é o mesmo que o valor de entrada e não é codificado usando base64. Você define o conjunto de caracteres (ou "alfabeto") de que o valor criptografado é composto. Há três maneiras de especificar o alfabeto da proteção de dados sensíveis para usar no valor de saída:

• Use um dos quatro valores enumerados que representam os quatro conjuntos de caracteres/alfabetos mais comuns.
• Use um valor radix, que especifica o tamanho do alfabeto. Especificar o valor mínimo de radix de 2 resulta em um alfabeto que consiste apenas em 0 e 1. A especificação do valor máximo de radix de 95 resulta em um alfabeto que inclui todos os caracteres numéricos, caracteres alfanuméricos maiúsculos, caracteres alfanuméricos minúsculos e caracteres de símbolo.
• Crie um alfabeto listando os caracteres exatos que serão usados. Por exemplo, especificar 1234567890-* resultaria em um valor alternativo que é composto apenas de números, hífens e asteriscos.

Importante: ao escolher usar o método de criptografia de preservação de formato (FPE, na sigla em inglês), verifique se os valores originais que estão sendo transformados e o tamanho do alfabeto que você especificou para os valores transformados a serem usados (radix) têm tamanho suficiente para evitar a engenharia reversa da saída segura. Em situações em que o número de strings de caracteres possíveis é pequeno, aumente o radix do alfabeto ou use um ajuste de contexto.

Além disso, embora o comprimento do valor transformado seja preservado devido à falta de autenticação e vetor de inicialização, a FPE oferece menos garantias de segurança em comparação com outros métodos de criptografia determinísticos, como a criptografia determinística com AES-SIV.

A tabela a seguir lista quatro conjuntos de caracteres comuns pelo valor enumerado de cada um (FfxCommonNativeAlphabet), valor de radix e lista dos caracteres do conjunto. A linha final lista o conjunto completo de caracteres, que corresponde ao valor máximo de radix.

Nome do conjunto de caracteres/alfabeto	Radix	Lista de caracteres
NUMERIC	10	0123456789
HEXADECIMAL	16	0123456789ABCDEF
UPPER_CASE_ALPHA_NUMERIC	36	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
ALPHA_NUMERIC	62	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
-	95	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~`!@#$%^&*()_-+={[}]|\:;"'<,>.?/

O token resultante, supondo que um InfoType alternativo tenha sido especificado, está no formato:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

O diagrama com a anotação a seguir é o resultado de uma operação de desidentificação da proteção de dados sensíveis usando criptografia que preserva o formato no valor 1-206-555-0123 usando uma base de 95. O InfoType alternativo opcional foi definido como NAM_PHONE_NUMB:

1. Anotação alternativa
2. InfoType alternativo (definido pelo usuário)
3. Comprimento do caractere do valor transformado
4. Valor alternativo (transformado): igual ao valor de entrada

Se você não especificar uma anotação alternativa, o token resultante será igual ao valor transformado ou número 4 no diagrama anotado. Para reidentificar dados não estruturados, todo o token é obrigatório, incluindo a anotação alternativa. Ao transformar dados estruturados, como uma tabela, a anotação substituta é opcional. A proteção de dados confidenciais pode realizar a desidentificação e a reidentificação em uma coluna inteira usando um RecordTransformation sem um alternativo.

Observação: por design, a FPE-FFX preserva o comprimento e o conjunto de caracteres do texto de entrada. Isso significa que não há autenticação e um vetor de inicialização, o que causa uma expansão de comprimento no token de saída. Outros métodos, como a criptografia determinística usando AES-SIV, fornecem essas garantias de segurança mais fortes 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. Por exemplo, para compatibilidade com versões anteriores de um sistema de dados legado.

Hash criptográfico

Com a desidentificação com hash criptográfico, um valor de entrada é em hash usando HMAC-SHA-256 com uma chave criptográfica e codificado usando base64. O valor desidentificado sempre é um tamanho uniforme, dependendo do tamanho da chave.

Ao contrário dos outros métodos de tokenização discutidos neste tópico, o hash criptográfico cria um token unidirecional. Ou seja, não é possível reverter a desidentificação por hash criptográfico.

Veja a seguir o resultado de uma operação de desidentificação usando hash criptográfico no valor 1-206-555-0123. Essa saída é uma representação codificada em base64 do valor de hash:

XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=

Como usar chaves criptográficas

Há três opções de chaves criptográficas que podem ser usadas com os métodos de desidentificação criptográficos na proteção de dados sensíveis:

• Chave criptográfica encapsulada do Cloud KMS: é o tipo mais seguro de chave criptográfica disponível para uso com os métodos de desidentificação da proteção de dados confidenciais. Uma chave encapsulada do Cloud KMS consiste em uma chave criptográfica de 128, 192 ou 256 bits que foi criptografada usando outra chave. Você fornece a primeira chave criptográfica, que é encapsulada usando uma chave criptográfica armazenada do Cloud Key Management Service. Esses tipos de chaves são armazenados no Cloud KMS para reidentificação posterior. Para mais informações sobre como criar e encapsular uma chave para fins de desidentificação e reidentificação, consulte Guia de início rápido: como desidentificar e reidentificar texto confidencial.

  Observação:quando você usa o Cloud KMS para operações criptográficas, serão aplicadas cobranças. Além disso, ao usar uma chave do Cloud HSM ou do Cloud EKM, você consome a cota do Cloud KMS no projeto que contém a chave. Por outro lado, se você estiver usando uma chave do Cloud KMS de software com proteção de dados sensíveis, nenhum limite de cota será aplicado. Para mais informações, consulte Cotas na documentação do Cloud KMS.

• Chave criptográfica temporária: é gerada pela proteção de dados sensíveis no momento da desidentificação e depois descartada. Por isso, não use uma chave criptográfica transitória com nenhum método de desidentificação criptográfico que você queira reverter. As chaves criptográficas temporárias só mantêm a integridade por solicitação de API. Se você precisar de integridade em mais de uma solicitação de API ou planejar reidentificar os dados, não use esse tipo de chave.

• Chave criptográfica desencapsulada: uma chave desencapsulada é uma chave criptográfica codificada em base64 de 128, 192 ou 256 bits fornecida na solicitação de desidentificação para a API DLP. Você é responsável por manter esses tipos de chaves criptográficas seguros para reidentificação posterior. Devido ao risco de vazamento acidental da chave, esses tipos de chaves não são recomendados. Essas chaves podem ser úteis para testes, mas, para cargas de trabalho de produção, recomenda-se uma chave criptográfica encapsulada do Cloud KMS.

Para saber mais sobre as opções disponíveis ao usar chaves criptográficas, consulte CryptoKey na referência da API DLP.

Como usar ajustes de contexto

Por padrão, todos os métodos de transformação criptográfica de desidentificação têm integridade referencial, sejam tokens de saída unidirecionais ou bidirecionais. Ou seja, com a mesma chave criptográfica, um valor de entrada é sempre transformado para o mesmo valor criptografado. Em situações em que dados ou padrões de dados repetitivos podem ocorrer, o risco de reidentificação aumenta. Em vez disso, para que o mesmo valor de entrada seja sempre transformado em um valor criptografado diferente, é possível especificar um ajuste de contexto exclusivo.

Você especifica um ajuste de contexto (chamado apenas de uma context na API DLP) ao transformar dados tabulares, uma vez que o ajuste é efetivamente um ponteiro para uma coluna de dados, como um identificador. A proteção de dados sensíveis usa o valor no campo especificado pelo ajuste de contexto ao criptografar o valor de entrada. Para garantir que o valor criptografado seja sempre um valor exclusivo, especifique uma coluna para o ajuste que contenha identificadores exclusivos.

Considere este exemplo simples. A tabela a seguir mostra vários registros médicos, sendo que alguns incluem IDs de pacientes duplicados.

Observação :este exemplo é usado para ilustrar como os ajustes de contexto funcionam e não pode ser considerado uma prática recomendada para o uso da proteção de dados sensíveis.

record_id	patient_id	icd10_code
5437	43789	E11.9
5438	43671	M25.531
5439	43789	N39.0, I25.710
5.440	43766	I10
5441	43766	I10
5442	42989	R07.81
5443	43098	I50.1, R55
...	...	...

Se você instruir a proteção de dados sensíveis a desidentificar os IDs de pacientes na tabela, ela desidentificará os IDs de pacientes repetidos com os mesmos valores por padrão, conforme mostrado na tabela a seguir. Por exemplo, as duas instâncias do ID do paciente "43789" são desidentificadas para "47222." A coluna patient_id mostra os valores do token após a pseudonimização usando FPE-FFX e não inclui anotações alternativas. Consulte Criptografia com preservação de formato para mais informações.

record_id	patient_id	icd10_codes
5437	47222	E11.9
5438	82160	M25.531
5439	47222	N39.0, I25.710
5.440	04452	I10
5441	04452	I10
5442	47826	R07.81
5443	52428	I50.1, R55
...	...	...

Isso significa que o escopo da integridade referencial está em todo o conjunto de dados.

Para restringir o escopo para evitar esse comportamento, especifique um ajuste de contexto. É possível especificar qualquer coluna como um ajuste de contexto, mas, para garantir que cada valor desidentificado seja exclusivo, especifique uma coluna para que cada valor seja exclusivo.

Suponha que você queira ver se o mesmo paciente aparece por valor icd10_codes, mas não se o mesmo paciente aparece em valores icd10_codes diferentes. Para fazer isso, especifique a coluna icd10_codes como o ajuste de contexto.

Esta é a tabela após desidentificar a coluna patient_id usando a coluna icd10_codes como um ajuste de contexto:

record_id	patient_id	icd10_codes
5437	18954	E11.9
5438	33068	M25.531
5439	76368	N39.0, I25.710
5.440	29460	I10
5441	29460	I10
5442	23877	R07.81
5443	96129	I50.1, R55
...	...	...

Observe que os quartos e quintos valores patient_id desidentificados (29460) são os mesmos porque não só os valores originais de patient_id são idênticos, mas, também, os valores icd10_codes das duas linhas eram idênticos. Como você precisa executar uma análise com IDs de pacientes consistentes dentro do escopo do valor icd10_codes, esse comportamento é o que você está procurando.

Para separar completamente a integridade referencial entre os valores patient_id e icd10_codes, use a coluna record_id como um ajuste de contexto:

record_id	patient_id	icd10_code
5437	15826	E11.9
5438	61722	M25.531
5439	34424	N39.0, I25.710
5.440	02875	I10
5441	52549	I10
5442	17945	R07.81
5443	19030	I50.1, R55
...	...	...

Observe que cada valor patient_id desidentificado na tabela agora é exclusivo.

Para saber como usar os ajustes de contexto na API DLP, observe o uso de context nos seguintes tópicos de referência do método de transformação:

• Criptografia com preservação de formato: CryptoReplaceFfxFpeConfig
• Criptografia determinística usando AES-SIV: CryptoDeterministicConfig
• Mudança de data: DateShiftConfig

A seguir

• Analise um exemplo completo que demonstra como criar uma chave encapsulada, tokenizar o conteúdo e reidentificar o conteúdo tokenizado.

• Analise exemplos de código que demonstram como tokenizar dados confidenciais (em inglês).

• Saiba como desidentificar dados usando a API DLP.