Este documento aborda a utilização da proteção de dados sensíveis para criar um pipeline de transformação de dados automatizado para desidentificar dados sensíveis, como informações de identificação pessoal (IIP). As técnicas de desidentificação, como a tokenização (pseudonimização), permitem-lhe preservar a utilidade dos seus dados para a união ou a análise, ao mesmo tempo que reduzem o risco de processamento dos dados através da ocultação dos identificadores confidenciais não processados. Para minimizar o risco de processamento de grandes volumes de dados sensíveis, pode usar um pipeline de transformação de dados automatizado para criar réplicas anonimizadas. A proteção de dados confidenciais permite transformações como ocultação, mascaramento, tokenização, agrupamento em intervalos e outros métodos de desidentificação. Quando um conjunto de dados não foi caraterizado, a Proteção de dados confidenciais também pode inspecionar os dados para verificar a existência de informações confidenciais através de mais de 100 classificadores incorporados.
Este documento destina-se a um público técnico cujas responsabilidades incluem a segurança dos dados, o tratamento de dados ou a análise de dados. Este guia pressupõe que tem conhecimentos sobre o tratamento e a privacidade de dados, sem ter de ser especialista.
Arquitetura de referência
O diagrama seguinte mostra uma arquitetura de referência para usar os Google Cloud produtos para adicionar uma camada de segurança a conjuntos de dados confidenciais através de técnicas de desidentificação.
A arquitetura consiste no seguinte:
Pipeline de streaming de desidentificação de dados: desidentifica dados confidenciais em texto através do Dataflow. Pode reutilizar o pipeline para várias transformações e exemplos de utilização.
Gestão da configuração (modelo e chave de proteção de dados confidenciais): uma configuração de desidentificação gerida que só é acessível a um pequeno grupo de pessoas, por exemplo, administradores de segurança, para evitar a exposição de métodos de desidentificação e chaves de encriptação.
Pipeline de validação de dados e reidentificação: valida cópias dos dados anonimizados e usa um pipeline do Dataflow para reidentificar dados em grande escala.
Ajudar a proteger dados confidenciais
Uma das principais tarefas de qualquer empresa é ajudar a garantir a segurança dos dados dos respetivos utilizadores e funcionários.O Google Cloud oferece medidas de segurança integradas para facilitar a segurança dos dados, incluindo a encriptação dos dados armazenados e a encriptação dos dados em trânsito.
Encriptação em repouso: Cloud Storage
A manutenção da segurança dos dados é fundamental para a maioria das organizações. O acesso não autorizado a dados, mesmo que moderadamente sensíveis, pode prejudicar a confiança, as relações e a reputação que tem junto dos seus clientes. A Google encripta os dados armazenados em repouso por predefinição. Por predefinição, qualquer objeto carregado para um contentor do Cloud Storage é encriptado através de uma Google-owned and Google-managed encryption key. Se o seu conjunto de dados usar um método de encriptação pré-existente e exigir uma opção não predefinida antes do carregamento, existem outras opções de encriptação fornecidas pelo Cloud Storage. Para mais informações, consulte as Opções de encriptação de dados.
Encriptação em trânsito: fluxo de dados
Quando os seus dados estão em trânsito, a encriptação em repouso não está em vigor. Os dados em trânsito estão protegidos por protocolos de rede seguros denominados encriptação em trânsito. Por predefinição, o Dataflow usa Google-owned and Google-managed encryption keys. Os tutoriais associados a este documento usam um pipeline automatizado que usa o valor Google-owned and Google-managed encryption keyspredefinido.
Transformações de dados da Proteção de dados confidenciais
Existem dois tipos principais de transformações realizadas pela proteção de dados confidenciais:
Ambos os métodos recordTransformations e infoTypeTransformations podem remover a identificação e encriptar informações confidenciais nos seus dados. Por exemplo, pode transformar os valores na coluna US_SOCIAL_SECURITY_NUMBER para que fiquem não identificáveis ou usar a tokenização para ocultá-los, mantendo a integridade referencial.
O método infoTypeTransformations permite-lhe inspecionar dados confidenciais
e transformar a descoberta. Por exemplo, se tiver dados não estruturados ou de texto livre, o método infoTypeTransformations pode ajudar a identificar um NISS numa frase e encriptar o valor do NISS, deixando o resto do texto intacto. Também pode definir infoTypes métodos personalizados.
O método recordTransformations permite aplicar uma configuração de transformação por campo quando usa dados estruturados ou tabulares. Com o método recordTransformations, pode aplicar a mesma transformação a todos os valores nesse campo, como aplicar hash ou tokenizar todos os valores numa coluna com a coluna SSN como o nome do campo ou do cabeçalho.
Com o método recordTransformations , também pode misturar o método infoTypeTransformations que se aplica apenas aos valores nos campos especificados. Por exemplo, pode usar um método infoTypeTransformations dentro de um método recordTransformations para ocultar todas as descobertas para US_SOCIAL_SECURITY_NUMBER que se encontram no texto no campo denominado comments.
Por ordem crescente de complexidade, os processos de desidentificação são os seguintes:
- Ocultação: remova o conteúdo confidencial sem substituição do conteúdo.
- Ocultação: substitua o conteúdo sensível por carateres fixos.
- Encriptação: substitua o conteúdo sensível por strings encriptadas, possivelmente reversíveis.
Trabalhar com dados delimitados
Muitas vezes, os dados consistem em registos delimitados por um caráter selecionado, com tipos fixos em cada coluna, como um ficheiro CSV. Para esta classe de dados, pode aplicar transformações de desidentificação (recordTransformations) diretamente, sem inspecionar os dados. Por exemplo, pode esperar que uma coluna etiquetada como SSN contenha apenas dados de NISS. Não precisa de inspecionar os dados para saber que o detetor infoTypeUS_SOCIAL_SECURITY_NUMBER. No entanto, as colunas de formato livre etiquetadas como Additional Details podem conter informações confidenciais, mas a classe infoType é desconhecida antecipadamente. Para uma coluna de forma livre, tem de inspecionar o detetor infoTypes (infoTypeTransformations) antes de aplicar transformações de desidentificação. A proteção de dados confidenciais permite que estes dois tipos de transformação coexistam num único modelo de desidentificação.
A proteção de dados confidenciais inclui
mais de 100 detetores infoTypesintegrados.
Também pode criar tipos personalizados ou modificar detetores incorporados para encontrar dados confidenciais exclusivos da sua organização.infoTypes
Determinar o tipo de transformação
A determinação de quando usar o método recordTransformations ou infoTypeTransformations
depende do seu exemplo de utilização. Uma vez que a utilização do método infoTypeTransformations
requer mais recursos e, por conseguinte, é mais dispendiosa, recomendamos a utilização deste método apenas para situações em que o tipo de dados é desconhecido. Pode avaliar
os custos de execução da Proteção de dados confidenciais através da
Google Cloud calculadora de preços.
Para ver exemplos de transformação, este documento refere-se a um conjunto de dados que contém ficheiros CSV com colunas fixas, conforme demonstrado na tabela seguinte.
| Nome da coluna | Inspeção infoType (personalizada ou integrada) |
Tipo de transformação da Proteção de dados confidenciais |
|---|---|---|
Card Number
|
Não aplicável | Encriptação determinística (DE) |
Card Holder's Name
|
Não aplicável | Encriptação determinística (DE) |
Card PIN
|
Não aplicável | Hash de criptomoedas |
SSN (Social Security Number)
|
Não aplicável | Máscara |
Age
|
Não aplicável | Segmentação |
Job Title
|
Não aplicável | Segmentação |
Additional Details
|
Integrado:IBAN_CODE, EMAIL_ADDRESS,
PHONE_NUMBER
Personalizado:
ONLINE_USER_ID
|
Substituição |
Esta tabela apresenta os nomes das colunas e descreve o tipo de transformação necessário para cada coluna. Por exemplo, a coluna Card Number contém números de cartões de crédito que têm de ser encriptados. No entanto, não têm de ser inspecionados, porque o tipo de dados (infoType) é conhecido.
A única coluna em que se recomenda uma transformação de inspeção é a coluna Additional Details. Esta coluna é de forma livre e pode conter PII, que, para efeitos deste exemplo, devem ser detetadas e anonimizadas.
Os exemplos nesta tabela apresentam cinco transformações de desidentificação diferentes:
Tokenização bidirecional: substitui os dados originais por um token determinístico, preservando a integridade referencial. Pode usar o token para juntar dados ou usar o token na análise agregada. Pode reverter ou remover a tokenização dos dados através da mesma chave que usou para criar o token. Existem dois métodos para tokenizações bidirecionais:
- Encriptação determinística (DE): Substitui os dados originais por um valor encriptado codificado em base64 e não preserva o conjunto de carateres nem o comprimento originais.
- Encriptação de preservação do formato com FFX (FPE-FFX): Substitui os dados originais por um token gerado através da encriptação de preservação do formato no modo FFX. Por predefinição, o FPE-FFX preserva o comprimento e o conjunto de carateres do texto de entrada. Não tem autenticação nem um vetor de inicialização, o que pode causar uma expansão do comprimento no token de saída. Outros métodos, como a DE, oferecem uma segurança mais forte e são recomendados para exemplos de utilização de tokenização, a menos que a preservação do comprimento e do conjunto de carateres sejam requisitos rigorosos, como a retrocompatibilidade com sistemas de dados antigos.
Tokenização unidirecional, através de hash criptográfico: substitui o valor original por um valor com hash, preservando a integridade referencial. No entanto, ao contrário da tokenização bidirecional, um método unidirecional não é reversível. O valor hash é gerado através de um código de autenticação de mensagens baseado em SHA-256 (HMAC-SHA-256) no valor de entrada.
Ocultação: substitui os dados originais por um caráter especificado, parcial ou totalmente.
Agrupamento: substitui um valor mais identificável por um valor menos distintivo.
Substituição: Substitui os dados originais por um token ou o nome do
infoType, se detetado.
Seleção do método
A escolha do melhor método de desidentificação pode variar consoante o exemplo de utilização. Por exemplo, se uma app antiga estiver a processar os registos anonimizados, a preservação do formato pode ser importante. Se estiver a lidar com números de 10 dígitos rigorosamente formatados, a FPE preserva o comprimento (10 dígitos) e o conjunto de carateres (numérico) de uma entrada para compatibilidade com sistemas antigos.
No entanto, se não for necessária uma formatação rigorosa para compatibilidade com versões anteriores, como é o caso dos valores na coluna Card Holder's Name, então DE é a escolha preferencial porque tem um método de autenticação mais forte. Tanto a FPE como a DE permitem que os tokens sejam invertidos ou descaracterizados. Se não precisar de anular a tokenização, a aplicação de hash criptográfico garante a integridade, mas não é possível reverter os tokens.
Outros métodos, como a ocultação, a agrupagem, a alteração de datas> e a substituição, são adequados para valores que não precisam de manter a integridade total. Por exemplo, agrupar um valor de idade (por exemplo, 27) numa faixa etária (20-30) pode continuar a ser analisado, ao mesmo tempo que reduz a singularidade que pode levar à identificação de um indivíduo.
Chaves de encriptação de tokens
Para as transformações de desidentificação criptográfica, é necessária uma chave criptográfica, também conhecida como chave de encriptação de tokens. A chave de encriptação de tokens usada para a encriptação de desidentificação também é usada para reidentificar o valor original. A criação e a gestão seguras de chaves de encriptação de tokens estão fora do âmbito deste documento. No entanto, existem alguns princípios importantes a ter em conta que são usados posteriormente nos tutoriais associados:
- Evite usar chaves de texto simples no modelo. Em alternativa, use o Cloud KMS para criar uma chave envolvida.
- Use chaves de encriptação de tokens separadas para cada elemento de dados para reduzir o risco de comprometer as chaves.
- Alterne as chaves de encriptação de tokens. Embora possa alternar para a chave envolvida, alternar para a chave de encriptação de tokens quebra a integridade da tokenização. Quando a chave é rodada, tem de voltar a tokenizar todo o conjunto de dados.
Modelos de proteção de dados confidenciais
Para implementações em grande escala, use os modelos de proteção de dados confidenciais para realizar o seguinte:
- Ative o controlo de segurança com a gestão de identidade e de acesso (IAM).
- Desacople as informações de configuração e a forma como as anula, das informações de implementação dos seus pedidos.
- Reutilizar um conjunto de transformações. Pode usar os modelos de anonimização e reidentificação em vários conjuntos de dados.
BigQuery
O componente final da arquitetura de referência é a visualização e o trabalho com os dados anonimizados no BigQuery. O BigQuery é a ferramenta de armazém de dados da Google que inclui uma infraestrutura sem servidor, o BigQuery ML e a capacidade de executar o Sensitive Data Protection como uma ferramenta nativa. Na arquitetura de referência de exemplo, o BigQuery funciona como um armazém de dados para os dados anonimizados e como um back-end para um pipeline de dados de reidentificação automatizado que pode partilhar dados através do Pub/Sub.
O que se segue?
- Saiba como usar a proteção de dados confidenciais para inspecionar o armazenamento e as bases de dados em busca de dados confidenciais.
- Saiba mais sobre outras soluções de reconhecimento de padrões.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.