Mascaramento de dados e acesso refinado usando o Amazon Macie e AWS Lake Formation

Por Iris Ferreira, Solutions Architect, AWS
Paulo Aragão, Principal Senior Solutions Architect, AWS

Cada vez mais as empresas vêm buscando dados de seus usuários para poder oferecer novos produtos, recomendar opções mais aderentes ao perfil do usuário, ou, no mundo financeiro, poder liberar acesso a maior crédito ou menores taxas de juros. Entretanto estes dados são pessoais e considerados sensíveis, ou seja, através da obtenção destes somos capazes de identificar quem é a pessoa por trás do usuário do sistema. Estes dados, caso em mãos erradas, podem ser utilizados para finalidades ilegais. Para isso, o governo federal dispôs da Lei Geral de Proteção de Dados (LGPD) que determina o que são dados sensíveis e como as empresas devem tratá-los. Uma destas disposições é a anonimização de dados coletados, além do consentimento ao acesso a estes dados.

Neste blog post vamos explicar como é possível construir uma arquitetura que faça a anomização dos dados e permita o acesso granular a estes conforme regras bem definidas. Também abordaremos o cenário onde um usuário pode não ter o acesso de visualizar o dado, mas uma aplicação sim. Um caso de uso para este cenário seria um Cientista de Dados trabalhando com dados sensíveis para treinar modelos de aprendizado de máquina. O algoritmo de treinamento tem acesso aos dados em si, porém o Cientista de Dados durante a análise dos dados não é capaz de ver certas informações. Isso evita possíveis cenários de vazamento de dados ao mesmo tempo que possibilita a inovação através do uso de dados.

Visão geral da solução

A solução proposta utiliza os serviços Amazon Macie, AWS Glue, e AWS Lake Formation. Levamos em consideração que os leitores já tem uma certa familiariedade com a LGPD. Caso queira conhecer mais sobre esta lei, sugerimos a leitura deste e deste link.

A arquitetura proposta permite que diversas fontes de dados enviem informações para o ambiente de data lake na AWS, onde o Amazon S3 irá ser o armazenamento central dos dados. Uma vez que os dados são inseridos no Amazon S3, o Amazon Macie analisa as informações armazenadas e identifica quais dados sensíveis estão armazenados. Estas informações são então utilizadas pelo AWS Glue para que ele execute um fluxo de trabalho que irá anonimizar os dados. Usaremos duas técnicas: uma de mascaramento e de criptografia destes dados. Depois que este fluxo de trabalho é executado, os dados então são armazenados em outro bucket do Amazon S3. Esta hierarquia de buckets vai ser fundamental para podermos segregar o acesso aos dados a específicos personagens. Por fim, o AWS Lake Formation nos ajudará a implementar as regras de acesso aos dados.

O diagrama a seguir ilustra a arquitetura da solução:

1. A fonte de dados será um banco de dados, como o Amazon RDS no nosso caso. Poderia ser um banco de dados em uma instância Amazon EC2, rodando em um datacenter on-premise, ou até em outras nuvens públicas;

2. O AWS Database Migration Service (DMS) faz um Capture-Data-Change (CDC) contínuo neste banco de dados, trazendo a informação para o bucket “dcp-macie” que armazenará os dados sem nenhum tratamento ainda;

3. Então um pipeline de detecção de dados sensíveis (PII, em inglês, Personal Identifiable Information) é iniciado. O Amazon Macie analisa os arquivos e identifica os campos que são considerados sensíveis. Você pode customizar quais são estes campos, e neste caso estamos fazendo isso para identificar o número da conta bancária;

4. Os campos identificados pelo Amazon Macie são enviados para o Amazon EventBridge que irá chamar o serviço Amazon Kinesis Data Firehose para armazená-los no bucket “dcp-glue“. Estes dados serão usados pelo AWS Glue para saber quais campos deverá mascarar ou criptografar usando uma chave armazenada no AWS Key Management Service (KMS)

I. O uso do Amazon EventBridge possibilita uma arquitetura baseada em eventos. Ele está sendo usado como uma ponte entre o Amazon Macie e o Amazon Kinesis Firehose, integrando os dois serviços;

II. O Amazon Kinesis Firehose permite uma bufferização dos dados evitando perdas de informações enviadas pelo Macie e reduzindo o custo de armazenamento das mesmas no S3. Ele também permite que os dados sejam enviados para outras localidades, como um Amazon Redshift ou Splunk, possibilitando a análise por outras ferramentas também;

5. No final desta etapa, o Amazon S3 é acionado a partir de uma função AWS Lambda que inicia o fluxo de trabalho do AWS Glue que irá mascarar e criptografar os dados identificados;

I. O AWS Glue inicia um crawler no bucket “dcp-macie” (a) e no bucket “dcp-glue (b) para popular duas tabelas, respectivamente;

II. Na sequência um script Python é executado (c consultando os dados dessas tabelas. Ele usa essas informações para mascarar e criptografar os dados e então armazená-los nos prefixos “dcp-masked” (d) e “dcp-encripted” (e) dentro do bucket “dcp-athena“;

III. O último passo deste fluxo é executar um crawler para cada um destes prefixos (f e g) criando suas respectivas tabelas no catálogo do AWS Glue.

6. Para permitir um acesso granular refinado aos dados, o AWS Lake Formation irá mapear os permissionamentos conforme as tags definidas. Veremos como implementar esta parte em etapas mais à frente;

7. Para consultar os dados, usaremos o Amazon Athena. Poderiam ser usadas outras ferramentas, como o Amazon Redshift ou o Amazon Quicksight, assim como ferramentas de terceiros.

Para o cenário onde um usuário não pode visualizar os dados sensíveis em si porém pode usá-los para o treinamento de modelos de aprendizado de máquina, iremos utilizar o AWS Key Management Service (AWS KMS). Neste serviço armazenaremos as chaves de criptografia que servirão para o mascaramento dos dados e daremos acesso de uso somente aos algoritmos de treinamento. Os usuários verão os dados mascarados, mas somente os algoritmos poderão ver os dados em sua forma natural e usá-los para criar os modelos de aprendizado de máquina.

Nessa solução, estamos considerando 3 tipos de personas:

secure-lf-admin: administrador do data lake. Responsável pela configuração do data lake e atribuir administradores de dados;
secure-lf-business-analyst: analista de negócios, sem acesso a certas informações confidenciais;
secure-lf-data-scientist: cientista de dados, sem acesso a certas informações confidenciais.

Pré-requisitos

Para conseguir implementar esta solução, certifique-se que sua conta AWS está ativa, e que seu usuário IAM possua permissão nos seguintes serviços:

É importante validar se há uma configuração pré-existente do AWS Lake Formation. Caso exista, pode haver problemas de permissionamento. Sugerimos que essa solução seja testada em uma conta de desenvolvimento sem o Lake Formation ativo ainda. Caso não seja possível, veja mais detalhes sobre permissões necessárias em sua Role na documentação do AWS Lake Formation.
Para o AWS DMS é necessário dar permissão para que ele crie os recursos necessários, como a instância EC2 onde vão rodar as tarefas do DMS. Se em algum momento você já trabalhou com o DMS, este permissionamento já deve existir. Caso contrário, o AWS Clouformation poderá criá-lo. Para validar se já existe esta permissão, navegue para o serviço AWS IAM, clique em Roles, e veja se existe uma role com o nome `dms-vpc-role`. Se não houver, escolha criar a role durante a implementação.
Utilizamos a biblioteca Faker para criar dados não reais e que consistem nas seguintes tabelas:
- Customer
- Bank
- Card

Implementando a solução

Para facilitar esta implementação criamos um modelo do AWS CloudFormation. Este modelo e outros artefatos que produzimos podem ser encontrados neste repositório do GitHub. Você pode então revisar a saída dos recursos que foram implantados.

Para implementar a solução basta clicar no link abaixo:

[Launch stack button]

Etapa 1 – Deploy do modelo do CloudFormation

Ao clicar no botão acima, e fazer login na sua conta, você verá a tela abaixo. Basta clicar em Next.

Na seção seguinte digite o nome de sua preferência para a Stack. É necessário digitar uma senha no campo TestUserPassword para que as personas do Lake Formation façam login no Console de gerenciamento da AWS. Ao terminar de preencher os campos, clique em Next.
Na seção seguinte, deixe as opções como estão e clique em Next;
Na última seção, revise as informações e selecione a opção I acknowledge that AWS CloudFormation might create IAM resources with custom names. Por fim, clique em Create Stack.

A captura de tela a seguir mostra os valores-chave que a stack criou.

Espere até que a stack mostre o status CREATE_COMPLETE.

A stack leva aproximadamente 15 minutos para ser concluída.

Etapa 2 – Executando uma task do AWS DMS

Para extrair os dados da instância do Amazon RDS, você precisa executar uma tarefa do AWS DMS. Isso disponibiliza os dados para o Amazon Macie em um bucket do Amazon S3 no formato Parquet.

Vá para o console do AWS DMS.
No menu esquerdo, selecione Database migration tasks.
Selecione a task com o nome rdstos3task.
Selecione Actions.
Selecione a opção Restart/Resume. A carga deverá demorar em torno de 1 minuto.

Quando o Status mudar para Load Complete, a task foi concluída e você poderá ver os dados migrados em seu bucket de destino (dcp-macie). Dentro de cada prefixo você verá os arquivos parquet com nomes semelhantes a LOAD00000001.parquet. Após esse passo, vamos usar o Macie para descobrir se há dados confidenciais nestes arquivos.

Etapa 3 – Executar um job de classificação com o Amazon Macie

Agora você precisa criar um job de classificação de dados para poder avaliar o conteúdo do bucket. O trabalho que você criar será executado e avaliará o conteúdo completo de seu bucket do S3 para determinar se ele possui Personal Identifiable Information (PII) entre os dados. Este trabalho usa os identificadores gerenciados disponíveis no Macie e um identificador customizado.

Vá para o https://console.aws.amazon.com/macie/, no menu esquerdo escolha jobs.
Selecione Create job.
Escolha o S3 bucket dcp-macie contendo o output da task do DMS. Selecione Next para continuar.
Na página de Review Bucket, verifique se o bucket selecionado é o dcp-macie, e clique em Next.
Na etapa de Refine the scope, crie um job com o seguinte scope.
1. Sensitive data Discovery options: One-time job (para fins de demonstração, este será um trabalho de descoberta único. Para ambientes produtivos, recomendamos selecionar a opção Scheduled job, para que o Macie analise os objetos em uma frequência programada)
2. Sampling Depth: 100%
3. Deixe as outras configurações com seus valores padrão.
Na etapa Select managed data identifiers, selecione All, para que o Macie use todos os managed data identifiers, que é um conjunto de critérios internos que detecta um tipo específico de dados confidenciais. Selecione Next para continuar.
Na tela Custom data identifiers, selecione account_number e escolha Next. Com o identificador personalizado, você pode criar uma lógica de negócios personalizada para procurar determinados padrões em arquivos armazenados no S3. Neste exemplo, a tarefa gera uma descoberta para qualquer arquivo que contenha dados com o seguinte formato de expressão regular “XYZ-” seguido por números, que é o formato padrão do account_number falso gerado no dataset. A lógica para criar um identificador de dados personalizado pode ser encontrada no modelo do CloudFormation.
Escreva um nome e sua descrição para o job.
Selecione Next para continuar.
Verifique os detalhes do job que você criou e selecione Submit para continuar.

A quantidade de dados que está sendo verificado determina quanto tempo o job levará para ser executado. Você pode escolher o botão Update na parte superior da tela para ver o status atualizado do job. Esse job, com base no tamanho do conjunto de dados de teste, levará cerca de 10 minutos para ser concluído.

Etapa 4 – Executado o pipeline de transformação de dados do AWS Glue

Ao final do job do Macie, os resultados das descobertas serão ingeridos no bucket dcp-glue-<AWS_REGION>-<ACCOUNT_ID>, dando início ao fluxo de trabalho (secureGlueWorkflow) no AWS Glue. A completa finalização desse pipeline leva aproximadamente 11 minutos. Para consultar o andamento, navegue até o serviço AWS Glue e clique em Workflows.

O job do AWS Glue, que é acionado como parte do fluxo de trabalho (ProcessSecureData), irá ler os findings do Macie para saber a localização exata dos dados sensíveis. Por exemplo, na tabela customer temos name e birthdate. Já na tabela bank, temos account_number, iban e bban. E na tabela card, temos card_number, card_expiration e card_security_code. Uma vez encontrados esses dados, o job faz o mascaramento e a criptografia deles.

A criptografia do texto está sendo feita usando uma chave do AWS Key Management Service (KMS). Segue o trecho do código sobre esse ponto:

def encrypt_rows(r):
    encrypted_entities = columns_to_be_masked_and_encrypted
    try:
        for entity in encrypted_entities:
            if entity in table_columns:
                encrypted_entity = get_kms_encryption(r[entity])
                r[entity + '_encrypted'] = encrypted_entity.decode("utf-8")
                del r[entity]
    except:
        print ("DEBUG:",sys.exc_info())
    return r

def get_kms_encryption(row):
    # Create a KMS client
    session = boto3.session.Session()
    client = session.client(service_name='kms',region_name=region_name)
   
    try:
        encryption_result = client.encrypt(KeyId=key_id, Plaintext=row)
        blob = encryption_result['CiphertextBlob']
        encrypted_row = base64.b64encode(blob)       
        return encrypted_row
       
    except:
        return 'Error on get_kms_encryption function'

Caso sua aplicação necessite de acesso ao texto descriptografado e considerando que a mesma possui acesso à chave de criptografia do KMS, segue o exemplo do trecho do código:

decrypted = client.decrypt(CiphertextBlob=base64.b64decode(data_encrypted))
print(decrypted['Plaintext'])

Após a execução de todos os passos acima, finalizamos com datasets totalmente anonimizados. As tabelas foram criadas no catálogo do Glue e os dados armazenados em seus respectivos buckets no S3. São nestes buckets onde os controles de acesso refinados serão aplicados por meio do Lake Formation:

Masked data – s3://dcp-athena-<AWS_REGION>-<ACCOUNT_ID>/mask/
Encrypted data –s3://dcp-athena-<AWS_REGION>-<ACCOUNT_ID>/encrypt/

Agora que as tabelas foram definidas, refinaremos as permissões usando o Lake Formation.

Etapa 5 – Habilitar o acesso refinado da Lake Formation

Depois que os dados foram processados e armazenados, usaremos o Lake Formation para definir e impor permissões refinadas de acesso para fornecer acesso seguro a analistas de dados e cientistas de dados.

Para habilitar o acesso refinado, primeiro adicionamos um usuário administrador (secure-lf-admin) do Lake Formation.

No console do Lake Formation, de-selecione Add myself e selecione Add other AWS users or roles.
No drop-down menu, escolha secure-lf-admin.
Escolha Get started.

Etapa 6 – Conceder acesso a diferentes personas

Antes de concedermos permissões a diferentes personas de usuário, vamos registrar os locais do S3 no Lake Formation para que essas personas possam acessar os dados. Todos os buckets terão sido criados com o padrão <prefixo>-<nome_do_bucket>-<aws_region>-<account_id>, onde <prefixo> corresponde ao prefixo selecionado ao implantar o modelo Cloudformation, <aws_region> corresponde à região selecionada (ex: sa-east-1) e <account_id> são os 12 números correspondentes à sua conta AWS (ex: 123456789012). Para facilitar a leitura, deixamos somente a parte inicial do nome do bucket nas instruções abaixo.

No console do Lake Formation, escolha Register and ingest no menu lateral e selecione Data lake locations.
Escolha Register location.
Escolha o bucket dcp-glue e clique em Register Location
Repita esta operação para os prefixos dcp-macie/dataset e também para os prefixos dcp-athena-/masked e dcp-athena/encrypted

Agora estamos prontos para conceder acesso aos nossos diferentes usuários.

Concedendo acesso granular por usuário

Conceda acesso somente leitura a todas as tabelas para secure-lf-admin

Antes de prosseguir precisaremos fazer login como o usuário secure-lf-admin. Para isso, faça o Sign-Out do usuário atual do console AWS e faça login novamente porém agora usando a credencial secure-lf-admin e a senha que você definiu no modelo do Cloudformation.

Agora que estamos logados como o usuário que administra o data lake, vamos conceder acesso somente leitura a todas as tabelas do banco dataset para o usuário secure-lf-admin.

Na seção Permissions, selecione Data lake permissions, clique em Grant.
Selecione IAM users and roles.
Escolha o usuário secure-lf-admin.
Em LF-Tags or catalog resources, selecione Named data catalog resources.
Selecione o database dataset.
Para Tables, choose All tables.
Na seção Table permissions, selecione Alter e Super.
Em Grantable permissions, selecione Alter e Super.
Escolha Grant.

Você pode confirmar suas permissões de usuário na página Data lake permissions.

Criando as tags para permissionamento de acesso

Vamos retornar ao console do Lake Formation para definir o controle de acesso baseado em tags para os usuários. Você pode atribuir tags de política a recursos do Glue Data Catalog (bancos de dados, tabelas e colunas) para controlar o acesso a esses recursos. Somente os usuários que recebem a tag do Lake Formation correspondentes (e os que recebem acesso com o método de recurso named) podem acessar os recursos.

No painel de navegação, em Permissions, escolha LF-tags.
Clique em Add LF tag. Na caixa de diálogo Add LF-tag, adicione o valor “data” na chave “Key” e o valor “mask” na chave “Value”. Clique em Add e depois clique em Add LF-tag.
Siga os mesmos passos para adicionar uma segunda tag onde a chave “Key” tem o valor “segment” e a chave “Value” tem o valor “campaign“.

Atribuindo as tags aos usuários e banco de dados

Vamos conceder acesso somente leitura aos dados mascarados ao usuário secure-lf-data-scientist.

No menu lateral na seção Permissions clique em Data lake permissions.
Clique em Grant.
Em IAM users and role, selecione secure-lf-data-scientist como o usuário.
Na seção LF-Tags or catalog resources selecione Resources matched by LF-Tags, e clique em add LF-tag e adicione como “Key” o valor “data” e como “Value” o valor “mask“.
Na seção Database permissions, na parte de Database permissions assim como em Grantable permissions, selecione Describe.
Na seção Table permissions, na parte de Database permissions assim como em Grantable permissions, selecione Select.
Ao final, clique em Grant.

Até agora, você aplicou o acesso baseado em tag do Lake Formation a certos recursos para o usuário secure-lf-data-scientist. O usuário ainda não tem acesso ao banco de dados dataset_masked. Para isso, precisamos atribuir a tag que criamos a esses bancos para que o usuário passe a ter acesso.

No painel de navegação, em Data Catalog, escolha Databases.
Selecione o dataset_masked e clique na opção Actions. No drop-down menu, escolha Edit LF-tags.
Na seção Edit LF-Tags: dataset_masked e adicione no campo “Key” o valor “data” e campo “Value” o valor “mask“.
Clique em Save.

Conceder acesso somente leitura ao secure-lf-business-analyst

Vamos agora conceder ao usuário secure-lf-business-analyst acesso somente leitura a determinadas colunas criptografadas usando Column-based Permissions.

No console do Lake Formation, em Data Catalog, escolha Databases.
Selecione o database dataset_encrypted.
Na opção Actions no drop-down menu, escolha Grant.
Selecione IAM users and roles.
Escolha a role secure-lf-business-analyst.
Na parte LF-Tags or catalog resources, selecione Named data catalog resources.
Na seção Database permissions, na parte Database permissions assim como em Grantable permissions, selecione Describe e Alter
E selecione o botão Grant.

Agora vamos dar acesso para o usuário secure-lf-business-analyst na table Customer, exceto a coluna de username.

No console do Lake Formation, em Data Catalog, escolha Databases.
Selecione o database dataset_encrypted e escolha View tables.
Selecione a table customer.
Na opção Actions no drop-down menu, escolha Grant.
Selecione IAM users and roles.
Escolha a role secure-lf-business-analyst.
Na parte LF-Tags or catalog resources, selecione Named data catalog resources.
Selecione o database dataset_encrypted
Na parte de tables, deixe a opção customer selecionada.
Na parte Table permissions assim como Grantable permissions, selecione Select
Na parte Data Permissions, selecione Column-based access.
Selecione a opção Include columns e escolha as colunas username, mail, gender, e id que são as colunas sem dados criptografados para que o usuário secure-lf-business-analyst tenha acesso.
E selecione o botão Grant.

Agora vamos dar acesso para o usuário secure-lf-business-analyst na table Card, somente para colunas que não contenham informações PII.

Selecione o database dataset_encrypted e escolha View tables.
Selecione a table card e clique nela.
Na parte Schema, clique em Edit schema.
Selecione a coluna cred_card_provider, que é a coluna que não tem dados PII.
Clique em Edit tags.
Clique em Assign new LF-Tag.
Adicione segment como a Key e campaign na campo de value. Conforme a imagem abaixo:

Clique em Save.
Clique em Save as new version.

Nesse passo adicionamos na tabela card, a tag segment na coluna cred_card_provider. Agora para que o user secure-lf-business-analyst tenha acesso, precisamos configurar essa tag para o usuário.

Na seção Permissions, selecione Data lake permissions.
Clique em Grant.
Em IAM users and role, selecione secure-lf-business-analyst como o usuário.
Na seção LF-Tags or catalog resources selecione Resources matched by LF-Tags, e clique em add LF-tag e adicione como key segment e campaign para value.
Na seção Database permissions, selecione Describe em ambas as opções.
Na seção Table permissions, selecione Select em ambas as opções.
Clique em Grant.

Revogar acesso SUPER ao grupo IAMAllowedPrincipals

O grupo IAMAllowedPrincipals inclui todos os usuários e funções do IAM que têm permissão de acesso aos recursos do Glue Data Catalog usando as políticas do IAM. A permissão Super permite que um principal execute todas as operações com suporte do Lake Formation no banco de dados ou tabela na qual ele é concedido. Essas configurações fazem com que o acesso aos recursos do Glue Data Catalog e aos locais do Amazon S3 sejam controlados exclusivamente pelas políticas do Amazon Identity and Access Management (IAM). Logo, as permissões individuais configuradas pelo Lake Formation não são consideradas, por isso vamos remover as concessões já configuradas pelo grupo IAMAllowedPrincipals, para que apenas tenhamos as configurações do Lake Formation.

Na seção Databases, selecione o database dataset e clique na opção Actions. No drop-down menu, escolha Revoke.
Na seção Principals selecione IAM users and role, e selecione o grupo IAMAllowedPrincipals como o usuário.
Em LF-Tags or catalog resources, selecione Named data catalog resources.
Em Tables, selecione as seguintes tables: bank, card e customer.
Na seção Table permissions, selecione Super.
Ao final, clique em Revoke.

Vamos repetir os mesmos passos para o database dataset_encrypted e para o dataset_masked.

Você pode confirmar todas as permissões do usuário na página Data Permissions.

Fazendo query no data lake usando o Amazon Athena com diferentes personas

Para validar as permissões de diferentes personas, usaremos o Amazon Athena para consultar o data lake do S3.

Certifique-se de definir o local do resultado da consulta para o local criado como parte da pilha do CloudFormation (secure-athena-query-<ACCOUNT_ID>-<AWS_REGION>).

Faça login no console com secure-lf-admin (use o valor de senha para TestUserPassword da pilha do CloudFormation) e verifique se você está na mesma região.
Navegue até o console do Athena.
Execute uma consulta SELECT no dataset.

SELECT * FROM “dataset”.”bank” limit 10;

O usuário secure-lf-admin deverá ver todas as tabelas do banco dataset e do dcp. Já dos bancos dataset_encrypted e dataset_masked, o usuário não deverá ter acesso as tabelas.

Por fim, vamos validar as permissões de secure-lf-data-scientist.

Faça login no console com secure-lf-data-scientist (use o valor de senha para TestUserPassword da pilha do CloudFormation) e verifique se você está na mesma região.
Navegue até o console do Athena.
Execute uma consulta SELECT no dataset.

SELECT * FROM “dataset”.”customer” limit 10;

O usuário secure-lf-data-scientist só poderá visualizar todas as colunas do banco de dados dataset_masked.

Agora vamos validar as permissões do usuário secure-lf-business-analyst.

Faça login no console com secure-lf-business-analyst (use o valor de senha para TestUserPassword da pilha do CloudFormation) e verifique se você está na mesma região.
Navegue até o console do Athena.
Execute uma consulta SELECT no dataset.

SELECT * FROM “dataset”.”card” limit 10;

O usuário secure-lf-business-analyst só poderá visualizar as tabelas card e customer do banco de dados dataset_encrypted. Na tabela card só terá acesso a coluna cred_card_provider e já na tabela Customer, o usuário passa a ter acesso apenas nas colunas username, mail e sex, como configurado anteriormente no Lake Formation.

Limpando o ambiente

Depois de testar a solução, caso queira, remova os recursos para evitar gastos desnecessários. Conclua as etapas a seguir:

Acesse o console do Amazon S3.
Navegue até cada um dos buckets listados abaixo e exclua todos os seus objetos:
1. dcp-assets
2. dcp-athena
3. dcp-glue
4. dcp-macie
Acesse o console do CloudFormation.
Selecione a opção Stacks no menu à esquerda.
Escolha a pilha que você criou na Etapa 1 – Implantando o modelo do CloudFormation.
Selecione Excluir e, em seguida, selecione Excluir pilha na janela pop-up.
Caso queira também excluir o bucket que foi criado, vá em Amazon S3 e delete-o
Para remover as configurações feitas no Lake Formation, vá ao painel do Lake Formation e remova as localidades do data lake assim como o adminitrador do Lake Formation.

Conclusão

Agora que a solução está implementada você tem um fluxo automático de anonimização de dados. Esta solução demonstra como é possível criar de forma fácil uma solução utilizando serviços AWS serverless, onde você só paga pelo quanto usa e sem se preocupar com servidores. Além disso, essa solução é facilmente customizável para atender outros requisitos da LGPD.

Implementamos o Amazon Macie que nos ajuda a identificar os dados sensíveis armazenados no Amazon S3. Também usamos o AWS Glue para utilizar esses relatórios do Amazon Macie para anonimizar os dados sensíveis encontrados. Por fim usamos o AWS Lake Formation para granularizar o acesso aos dados a certos personagens e demonstramos como é possível conceder acesso de forma programática para aplicações que precisem trabalhar com os dados desmascarados.

Links relacionados

Sobre os autores

Iris Ferreira é arquiteta de soluções na AWS, apoiando clientes em suas jornadas de inovação e transformação digital na nuvem. Em seu tempo livre, gosta de ir para praia, viajar, fazer trilhas e estar sempre em contato com a natureza.

Paulo Aragão é um Principal Solutions Architect e apoia clientes do setor financeiro a trilhar o novo mundo de DeFi, web3.0, Blockchain, dApps, e Smart Contracts. Além disso, tem ampla experiência em Computação de Alta Performance (HPC) e Machine Learning. Apaixonado por música e mergulho, devora livros, joga World of Warcraft e New World e cozinha para os amigos.

O blog da AWS