Enmascaramiento de datos y acceso detallado mediante Amazon Macie y AWS Lake Formation

Por Iris Ferreira, Arquitecta de Soluciones, AWS
Paulo Aragão, Arquitecto Principal de Soluciones, AWS

Cada vez son más las empresas que buscan datos de sus usuarios para poder ofrecer nuevos productos, recomendar opciones que se ajusten mejor al perfil del usuario o, en el mundo financiero, poder liberar el acceso a créditos más altos o tasas de interés más bajas. Sin embargo, estos datos son personales y se consideran sensibles, es decir, al obtenerlos podemos identificar quién es la persona detrás del usuario del sistema. Estos datos, si están en malas manos, pueden usarse con fines ilegales. Con este fin, el gobierno federal de Brasil ha establecido la Ley General de Protección de Datos (LGPD) que determina qué son los datos confidenciales y cómo deben tratarlos las empresas. Una de estas disposiciones es la anonimización de los datos recopilados, además del consentimiento para acceder a estos datos.

En esta introducción de blog, explicaremos cómo es posible construir una arquitectura que anonimiza los datos y permite el acceso granular a los mismos de acuerdo con reglas bien definidas. También cubriremos el escenario en el que un usuario puede no tener acceso para ver los datos, pero una aplicación sí lo tiene. Un caso de uso para este escenario sería un científico de datos que trabaje con datos confidenciales para entrenar modelos de aprendizaje automático. El algoritmo de entrenamiento tiene acceso a los datos en sí, pero el científico de datos durante el análisis de datos no puede ver cierta información. Esto evita posibles escenarios de fuga de datos, al tiempo que permite la innovación mediante el uso de datos.

Resumen de la solución

La solución propuesta utiliza los servicios Amazon Macie, AWS Glue y AWS Lake Formation. Tenemos en cuenta que los lectores ya están familiarizados con la LGPD. Si quieres saber más sobre esta ley, te sugerimos leer este y este enlace.

La arquitectura propuesta permite que varias fuentes de datos envíen información al entorno del lago de datos en AWS, donde Amazon S3 será el almacenamiento central de los datos. Una vez que los datos se introducen en Amazon S3, Amazon Macie analiza la información almacenada e identifica qué datos confidenciales se almacenan. A continuación, AWS Glue utiliza esta información para ejecutar un flujo de trabajo que anonimizará los datos. Utilizaremos dos técnicas: una para enmascarar y cifrar estos datos. Después de ejecutar este flujo de trabajo, los datos se almacenan en otro depósito de Amazon S3. Esta jerarquía de depósitos será fundamental para que podamos segregar el acceso a los datos a usuarios específicos. Por último, AWS Lake Formation nos ayudará a implementar reglas de acceso a los datos.

El siguiente diagrama ilustra la arquitectura de la solución:

La fuente de información será una base de datos, como Amazon RDS en nuestro caso. Puede ser una base de datos en una instancia de Amazon EC2, que se ejecuta en un centro de datos local o incluso en otras nubes públicas;
El AWS Database Migration Service (DMS) realiza un cambio continuo de captura de datos (CDC) en esta base de datos, llevando la información al bucket «dcp-macie» que almacenará los datos sin procesar aún;
A continuación, se inicia una canalización de detección de datos confidenciales (PII). Amazon Macie analiza los archivos e identifica los campos que se consideran confidenciales. Puede personalizar estos campos y, en este caso, lo haremos para identificar el número de cuenta bancaria;
Los campos identificados por Amazon Macie se envían a Amazon EventBridge, que llamará al servicio Amazon Kinesis Data Firehose para almacenarlos en el bucket «dcp-glue». AWS Glue utilizará estos datos para saber qué campos enmascarar o cifrar con una clave almacenada en AWS Key Management Service (KMS)

I. El uso de Amazon EventBridge permite una arquitectura basada en eventos. Se utiliza como puente entre Amazon Macie y Amazon Kinesis Firehose, integrando los dos servicios;

II. Amazon Kinesis Firehose permite el almacenamiento en búfer de datos, lo que evita la pérdida de información enviada por Macie y reduce el costo de almacenarla en S3. También permite que los datos se envíen a otras ubicaciones, como Amazon Redshift o Splunk, lo que también permite el análisis por parte de otras herramientas;

5. Al final de este paso, Amazon S3 se activa desde una función de AWS Lambda que inicia el flujo de trabajo de AWS Glue que enmascarará y cifrará los datos identificados;

I. AWS Glue inicia un rastreador en el bucket «dcp-macie» (a) y el bucket «dcp-glue (b) para llenar dos tablas, respectivamente;

II. A continuación, se ejecuta un script de Python (c) que consulta los datos de estas tablas. Utiliza esta información para enmascarar y cifrar los datos y luego almacenarlos en los prefijos «dcp-masked» (d) y «dcp-encripted» (e) dentro del bucket «dcp-athena»;

III. El último paso de este flujo es rastrear cada uno de estos prefijos (f y g) mediante la creación de sus tablas respectivas en el catálogo de AWS Glue.

6. Para permitir un acceso detallado a los datos, AWS Lake Formation asignará los permisos de acuerdo con las etiquetas definidas. Veremos cómo implementar esta parte en etapas posteriores;

7. Para consultar los datos, utilizaremos Amazon Athena. Se podrían utilizar otras herramientas, como Amazon Redshift o Amazon Quicksight, así como herramientas de terceros.

Para el escenario en el que un usuario no puede ver los datos confidenciales en sí, pero puede usarlos para entrenar modelos de aprendizaje automático, utilizaremos AWS Key Management Service (AWS KMS). En este servicio almacenaremos las claves de cifrado que se utilizarán para enmascarar los datos y daremos acceso solo a los algoritmos de entrenamiento. Los usuarios verán los datos enmascarados, pero solo los algoritmos podrán ver los datos en su forma natural y utilizarlos para crear los modelos de aprendizaje automático.

En esta solución, estamos considerando 3 tipos de personas:

secure-lf-admin: administrador del lago de datos. Responsable de configurar el lago de datos y asignar administradores de datos;
secure-lf-business-analyst: analista de negocios, sin acceso a cierta información confidencial;
secure-lf-data-scientist: científico de datos, sin acceso a cierta información confidencial.

Requisitos previos

Para poder implementar esta solución, asegúrese de que su cuenta de AWS esté activa y de que su usuario de IAM tenga permiso para los siguientes servicios:

Amazon Virtual Private Cloud (Amazon VPC)

Es importante validar que haya una configuración de AWS Lake Formation preexistente. Si existe, puede haber problemas con los permisos. Sugerimos que esta solución se pruebe en una cuenta de desarrollo sin formación de lagos activa todavía. Si esto no es posible, consulte más detalles sobre los permisos necesarios en su función en la documentación de AWS Lake Formation.
AWS DMS requiere permiso para crear los recursos necesarios, como la instancia de EC2 en la que se ejecutarán las tareas de DMS. Si en algún momento ha trabajado con el DMS, este permiso ya debe existir. De lo contrario, AWS Clouformation puede crearlo. Para validar que este permiso ya existe, vaya al servicio de AWS IAM, haga clic en Roles y compruebe si hay un rol con el nombre `dms-vpc-role`. Si no es así, elija crear la función durante la implementación.
Usamos la biblioteca Faker para crear datos no reales que constan de las siguientes tablas:
- Customer
- Bank
- Card

Implementación de la solución

Para facilitar esta implementación, creamos una plantilla de AWS CloudFormation. Este modelo y otros artefactos que produjimos se pueden encontrar en este repositorio de GitHub. A continuación, puede revisar la salida de las funciones que se han implementado.

Para implementar la solución, simplemente haga clic en el siguiente enlace:

[Botón Iniciar pila]

Paso 1: Implementar la plantilla de CloudFormation

Cuando hagas clic en el botón de arriba e inicies sesión en tu cuenta, verás la siguiente pantalla. Simplemente haz clic en Siguiente.

2. En la siguiente sección, escribe tu nombre preferido para Stack. Debe introducir una contraseña en el campo TestUserPassword para que las personas de Lake Formation inicien sesión en la consola de administración de AWS. Cuando haya terminado de rellenar los campos, haga clic en Next.

3. En la siguiente sección, deje las opciones como están y haga clic en Next.

4. En la última sección, revise la información y seleccione la opción I acknowledge that Aws CloudFormation might create IAM resources with custom names. Por último, haz clic en Create Stack.

‘5. Espere hasta que la pila muestre el estado CREATE_COMPLETE

La siguiente captura de pantalla muestra los valores clave que creó la pila.

La pila tarda aproximadamente 15 minutos en completarse.

Paso 2: Ejecución de una tarea de AWS DMS

Para extraer datos de la instancia de Amazon RDS, debe ejecutar una tarea de AWS DMS. Esto hace que los datos estén disponibles para Amazon Macie en un bucket de Amazon S3 en formato Parquet.

Vaya a la consola de AWS DMS.
En el menú izquierdo, selecciona Tareas de migración de bases de datos.
Seleccione la task con el nombre rdstos3task.
Selecciona Actions.
Seleccione la opción Restart/Resume. La carga debería tardar alrededor de 1 minuto.

Cuando el estado cambia a Load Complete, la tarea se completa y puedes ver los datos migrados en tu bucket(dcp-macie). Dentro de cada prefijo, verá archivos de parquet con nombres similares a LOAD00000001.parquet. Después de este paso, utilizaremos Macie para averiguar si hay datos confidenciales en estos archivos.

Paso 3: Ejecute un trabajo de clasificación con Amazon Macie

Ahora necesita crear un trabajo de clasificación de datos antes de poder evaluar el contenido del depósito. El trabajo que cree ejecutará y evaluará todo el contenido de su depósito de S3 para determinar si tiene información de identificación personal (PII) entre los datos. Este trabajo utiliza los identificadores gestionados disponibles en Macie y un identificador personalizado.

Vaya a la consola de Amazon Macie, en el menú de la izquierda elija jobs.
Selecciona Create job.
Elija el bucket de dcp-macie S3 que contiene la salida de la tarea de DMS. Selecciona Next para continuar.
En la página Review Bucket, compruebe que el depósito seleccionado sea dcp-macie y haga clic en Next.
En el paso Refine the scope, cree un trabajo con el siguiente ámbito.
1. Sensitive data Discovery options: One-time job (con fines de demostración, será un trabajo de descubrimiento único. Para entornos productivos, recomendamos seleccionar la opción Scheduled job, de modo que Macie analice los objetos con una frecuencia programada)
2. Sampling Depth: 100%
3. Deje los valores predeterminados de los demás ajustes.
En el paso Select managed data identifiers, seleccione All para que Macie utilice todos los identificadores de datos gestionados, que son un conjunto de criterios internos que detectan un tipo específico de datos confidenciales. Selecciona Next para continuar.
En la pantalla Custom data identifiers, selecciona account_number y elige Next. Con el identificador personalizado, puede crear una lógica empresarial personalizada para buscar ciertos patrones en los archivos almacenados en S3. En este ejemplo, la tarea genera una búsqueda para cualquier archivo que contenga datos con el siguiente formato de expresión regular «XYZ-» seguido de números, que es el formato predeterminado del account_number falso generado en el conjunto de datos. La lógica para crear un identificador de datos personalizado se encuentra en la plantilla de CloudFormation.
Escriba un nombre y una descripción para el trabajo.
Selecciona Next para continuar.
Compruebe los detalles del trabajo que creó y seleccione Submit para continuar.

La cantidad de datos que se comprueban determina cuánto tardará el trabajo en ejecutarse. Puede elegir el botón Update en la parte superior de la pantalla para ver el estado actualizado del trabajo. Este trabajo, basado en el tamaño del conjunto de datos de prueba, tardará unos 10 minutos en completarse.

Paso 4: Ejecute el canal de transformación de datos de AWS Glue

Al final del trabajo de Macie, los resultados del descubrimiento se incorporarán al bucket dcp-glue-<AWS_REGION><ACCOUNT_ID>, iniciando el flujo de trabajo (SecureGlueWorkflow) en AWS Glue. La finalización completa de esta canalización tarda aproximadamente 11 minutos. Para revisar el progreso, vaya al servicio AWS Glue y haga clic en Flujos de trabajo.
El trabajo de AWS Glue, que se activa como parte del flujo de trabajo (ProcessSecureData), leerá los hallazgos de Macie para conocer la ubicación exacta de los datos confidenciales. Por ejemplo, en la tabla de clientes tenemos el nombre y la fecha de nacimiento. En la tabla Bank, tenemos account_number, iban y bban. Y en la tabla card, tenemos card_number, card_expiration y card_security_code. Una vez que se encuentran estos datos, el trabajo los enmascara y los cifra.
El texto se cifra con una clave de AWS Key Management Service (KMS). He aquí el extracto del código sobre este punto:

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'

Si su aplicación requiere acceso al texto descifrado y considera que tiene acceso a la clave de cifrado de KMS, siga el ejemplo del fragmento de código:

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

Después de realizar todos los pasos anteriores, obtenemos conjuntos de datos totalmente anonimizados. Las tablas se crearon en el catálogo de Glue y los datos se almacenaron en sus respectivos depósitos en S3. Estos depósitos son donde se aplicarán controles de acceso detallados a través de Lake Formation:

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

Ahora que se han definido las tablas, refinaremos los permisos con Lake Formation.

Paso 5: Habilitar el acceso detallado a Lake Formation

Una vez que los datos se hayan procesado y almacenado, utilizaremos Lake Formation para definir y hacer cumplir permisos de acceso detallados a fin de proporcionar un acceso seguro a los analistas y científicos de datos.
Para habilitar el acceso detallado, primero agregamos un usuario administrador de Lake Formation (secure-lf-admin).

En la consola de Lake Formation, anule la selección de Add myself y seleccione Add other AWS users or roles.
En el menú desplegable, selecciona secure-lf-admin.
Elige Get started.

Paso 6: Otorgar acceso a diferentes personas

Antes de conceder permisos a diferentes personas de usuario, registremos las ubicaciones de S3 con Lake Formation para que esas personas puedan acceder a los datos. Todos los depósitos se habrán creado con el predeterminado <prefixo>- <nombre_del_bucket><aws_region>-<account_id>, donde <prefixo> corresponde al prefijo seleccionado al implementar la plantilla de Cloudformation, <aws_region> corresponde a la región seleccionada (por ejemplo, sa-east-1) y <account_id> son los 12 números correspondiente a su cuenta de AWS (p. ej.: 123456789012). Para que sea más fácil de leer, solo dejamos la parte inicial del nombre del depósito en las instrucciones a continuación.

En la consola de Lake Formation, elija Register and ingest en el menú lateral y seleccione Data lake locations.
Elige Register locations.
Elija el bucket dcp-glue y haga clic en Register Location.
Repita esta operación para los prefijos dcp-macie/dataset y también para los prefijos dcp-athena-/masked y dcp-athena/encrypted.

Ahora estamos listos para conceder acceso a nuestros diferentes usuarios.

Concesión de acceso granular por usuario

Conceder acceso de solo lectura a todas las tablas para secure-lf-admin

Antes de continuar, tendremos que iniciar sesión como usuario de secure-lf-admin. Para hacerlo, cierre la sesión del usuario actual de la consola de AWS y vuelva a iniciarla, pero ahora utilice la credencial y la contraseña de secure-lf-admin que definió en la plantilla de Cloudformation.
Ahora que hemos iniciado sesión como el usuario que administra el lago de datos, otorguemos acceso de solo lectura a todas las tablas de la base de datos del conjunto de datos al usuario secure-lf-admin.

En la sección Permissions, seleccione Data lake permissions y haga clic en Grant.
Seleccione IAM users and roles.
Elija el usuario secure-lf-admin.
En LF-Tags or catalog resources, seleccione Named data catalog resources.
Seleccione el dataset de base de datos.
Para Tablas, elija All tables.
En la sección Table permissions, seleccione Alter y Super.
En Grantable permissions, selecciona Alter y Super.
Elige Grant.

Puede confirmar sus permisos de usuario en la página Data lake permissions.

Creación de las etiquetas para el permiso de acceso

Volvamos a la consola de Lake Formation para definir el control de acceso basado en etiquetas para los usuarios. Puede asignar etiquetas de política a los recursos del catálogo de datos de Glue (bases de datos, tablas y columnas) para controlar el acceso a esos recursos. Solo los usuarios que reciben la etiqueta de formación de lagos correspondiente (y los que reciben acceso con el método de recurso indicado) pueden acceder a los recursos.

En el panel de navegación, en Permissions, elija LF-Tags.
Haz clic en Add LF tag. En el cuadro de diálogo Add LF-tag, añada el valor «data» en la tecla key y el valor «mask» en la clave value. Haga clic en Add y, a continuación, en Add LF-tag.
Siga los mismos pasos para añadir una segunda etiqueta en la que la clave key tenga el valor «segment» y la clave value tenga el valor «campaign”.

Asignación de etiquetas a los usuarios y la base de datos

Otorgaremos acceso de solo lectura a los datos enmascarados al usuario secure-lf-data-scientist.

En el menú lateral de la sección Permissions, haz clic en Data lake permissions.
Haz clic en Grant.
En IAM users and role, seleccione secure-lf-data-scientist como usuario.
En la sección LF-tags or catalog resources, seleccione Resources matched by LF-Tags, y haga clic en add LF-tag y agregue como Clave el valor “data” y como Valor el valor ”mask”.
En la sección Database permissions, en la parte Database permissions y en Grantable permissions, seleccione Describe.
En la sección Table permissions, en la parte Database permissions y en Grantable permissions, seleccione Select.
Al final, haz clic en Grant.

Hasta ahora, ha aplicado el acceso basado en etiquetas de Lake Formation a ciertas funciones para el usuario secure-lf-data-scientist. El usuario aún no tiene acceso a la base de datos dataset_masked. Para ello, necesitamos asignar la etiqueta que creamos a estos bancos para que el usuario pueda tener acceso.

En el panel de navegación, en Data Catalog, elija Databases.
Seleccione dataset_masked y haga clic en la opción Actions. En el menú desplegable, selecciona Edit LF-tags.
En la sección Edit LF-Tags: dataset_masked y agregue en el campo Key el valor «data» y el campo Value el valor «mask”.
Haz clic en Save.

Otorgue acceso de solo lectura a secure-lf-business-analyst

Ahora otorgaremos al usuario secure-lf-business-analyst acceso de solo lectura a ciertas columnas cifradas mediante permisos basados en columnas.

En la consola de Lake Formation, en Data Catalog, elija Databases.
Seleccione la base de datos dataset_encrypted.
En la opción Actions del menú desplegable, selecciona Grant.
Seleccione IAM users and roles.
Elija la función secure-lf-business-analyst.
En la parte de LF-Tags or catalog resources, seleccione Named data catalog resources.
En la sección Database permissions, en la parte Database permissions, así como en Grantable permissions, seleccione Describe y Alter.
Y selecciona el botón Grant.

Ahora vamos a dar acceso al usuario secure-lf-business-analyst en la tabla Customer, excepto a la columna username.

En la consola de Lake Formation, en Data Catalog, elija Databases.
Seleccione la base de datos dataset_encrypted y elija View tables.
Seleccione la tabla de customer.
En la opción Actions del menú desplegable, selecciona Grant.
Seleccione IAM users and roles.
Elija la función de secure-lf-business-analyst.
En la parte de LF-Tags or catalog resources, seleccione Named data catalog resources.
Seleccione la base de datos dataset_encrypted.
En la parte de tablas, deje seleccionada la opción de customer.
En la parte Table Permissions y permisos concedibles, seleccione Select
En la parteData Permissions, seleccione Column-based access.
Seleccione la opción Include columns y elija las columnas username, mail, gender e id que son las columnas sin datos cifrados para que el usuario secure-lf-business-analyst tiene acceso.
Y selecciona el botón Grant.

Ahora vamos a dar acceso al usuario secure-lf-business-analyst en la tabla Card, solo para las columnas que no contienen información de PII.

Seleccione la base de datos dataset_encrypted y elija View tables.
Selecciona la tabla Card y haz clic en ella.
En la parte Schema, haz clic en Edit schema.
Seleccione la columna cred_card_provider, que es la columna que no tiene datos de PII.
Haz clic en Edit tags.
Haz clic en Assign new LF-Tag.
Agregue un segment como Clave y “campaign” en el campo de “value”. Como se muestra en la imagen de abajo:

Haz clic en Save.
Haz clic en Save as new version.

En este paso, agregamos la etiqueta de segment en la columna cred_card_provider a la tabla Card. Ahora, para que el usuario secure-lf-business-analyst tenga acceso, necesitamos configurar esta etiqueta para el usuario.

En la sección Permisos, seleccione Data lake permissions.
Haz clic en Grant.
En IAM users and role, seleccione secure-lf-business-analyst como usuario.
En la sección LF-Tags or catalog resources, selecciona Resources matched by LF-Tags y haz clic en add LF-tag y agrega como segment clave y campaign para obtener valor.
En la sección Database permissions, seleccione Describe en ambas opciones.
En la sección Table permissions, selecciona Select entre ambas opciones.
Haz clic en Grant.

Revocar el acceso SUPER al grupo IAMAllowedPrincipals

El grupo IAMAllowedPrincipals incluye todos los usuarios y roles de IAM a los que se les permite el acceso a los recursos del catálogo de datos de Glue mediante políticas de IAM. El permiso Super permite a un director realizar todas las operaciones admitidas por Lake Formation en la base de datos o tabla en la que se concede. Esta configuración permite el acceso a los recursos del catálogo de datos de Glue y a las ubicaciones de Amazon S3 controladas únicamente por las políticas de Amazon Identity and Access Management (IAM). Por lo tanto, no se tienen en cuenta los permisos individuales configurados por Lake Formation, por lo que eliminaremos las subvenciones ya configuradas por el grupo IAMAllowedPrincipals, para que solo tengamos la configuración de Lake Formation.

En la sección Databases, seleccione el dataset de base de datos y haga clic en la opción Actions. En el menú desplegable, selecciona Revoke.
En la sección Principals, seleccione IAM users and role y seleccione el grupo IAMAllowedPrincipals como usuario.
En Etiquetas LF o recursos de catálogo, seleccione Named data catalog resources.
En Tables, selecciona las siguientes tables: bank, card y customer.
En la sección Table permissions, selecciona Super.
Al final, haz clic en Revoke.

Vamos a repetir los mismos pasos para la base de datos dataset_encrypted y para dataset_masked.

Puede confirmar todos los permisos del usuario en la página Data Permissions.

Consulta del lago de datos mediante Amazon Athena con diferentes personas

Para validar los permisos de diferentes personas, utilizaremos Amazon Athena para consultar el lago de datos de S3.

Asegúrese de establecer la ubicación del resultado de la consulta en la ubicación creada como parte de la pila de CloudFormation (secure-athena-query- <ACCOUNT_ID>-<AWS_REGION>).

Inicie sesión en la consola con secure-lf-admin (utilice el valor de contraseña para testUserPassword de la pila de CloudFormation) y compruebe que se encuentra en la misma región.
Navega hasta la consola de Athena.
Ejecute una consulta SELECT en el conjunto de datos.

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

El usuario secure-lf-admin debe ver todas las tablas del conjunto de datos y la base de datos dcp. En cuanto a las bases de datos dataset_encrypted y dataset_masked, el usuario no debería tener acceso a las tablas.

Finalmente, validemos los permisos de secure-lf-data-scientist.

Inicie sesión en la consola con secure-lf-data-scientist (use el valor de contraseña para testUserPassword de la pila de CloudFormation) y compruebe que se encuentra en la misma región.
Navega hasta la consola de Athena.
Ejecute una consulta SELECT en el conjunto de datos.

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

El usuario de secure-lf-data-scientist solo podrá ver todas las columnas de la base de datos dataset_masked.

Ahora vamos a validar los permisos del usuario secure-lf-business-analyst.

Inicie sesión en la consola con secure-lf-business-analyst (utilice el valor de contraseña para testUserPassword de la pila de CloudFormation) y compruebe que se encuentra en la misma región.
Navega hasta la consola de Athena.
Ejecute una consulta SELECT en el conjunto de datos.

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

El usuario secure-lf-business-analyst solo podrá ver las tablas card y customer de la base de datos dataset_encrypted. En la tabla card, solo tendrá acceso a la columna cred_card_provider y en la tabla Customer, el usuario ahora solo tiene acceso a las columnas username, mail y gender, como se configuró previamente en Lake Formation.

Limpiar el medio ambiente

Después de probar la solución, si lo desea, elimine las funciones para evitar gastos innecesarios. Complete los siguientes pasos:

Vaya a la consola de Amazon S3.
Navegue hasta cada uno de los depósitos que se enumeran a continuación y elimine todos sus objetos:

- dcp-assets
- dcp-athena
- dcp-glue
- dcp-macie

3. Vaya a la consola de CloudFormation.
4. Selecciona la opción Stacks en el menú de la izquierda.
5. Elija la pila que creó en el Paso 1: Implementación de la plantilla de CloudFormation.
6.Selecciona Excluir y, a continuación, selecciona Excluir pila en la ventana emergente.
7. Si también desea eliminar el depósito que se creó, vaya a Amazon S3 y elimínelo
8. Para eliminar la configuración que realizó en Lake Formation, vaya al panel de Lake Formation y elimine las ubicaciones de los lagos de datos, así como el administrador de Lake Formation.

Conclusión

Ahora que la solución está implementada, tiene un flujo automático de anonimización de datos. Esta solución demuestra cómo puede crear fácilmente una solución con los servicios sin servidor de AWS, en los que solo paga por la cantidad que usa y sin preocuparse por los servidores. Además, esta solución se puede personalizar fácilmente para cumplir con otros requisitos de la LGPD.

Implementamos Amazon Macie que nos ayuda a identificar los datos confidenciales almacenados en Amazon S3. También utilizamos AWS Glue para utilizar estos informes de Amazon Macie para anonimizar los datos confidenciales encontrados. Por último, utilizamos AWS Lake Formation para analizar el acceso a los datos de ciertos usuarios y demostramos cómo se puede conceder acceso mediante código a las aplicaciones que necesitan trabajar con los datos desenmascarados.

Links relacionados

Este artículo fue traducido del Blog de AWS en Portugués

Acerca de los autores

Iris Ferreira es arquitecta de soluciones en AWS y apoya a los clientes en su viaje de innovación y transformación digital en la nube. En su tiempo libre, le gusta ir a la playa, viajar, hacer senderismo y estar siempre en contacto con la naturaleza.

Paulo Aragão es Arquitecto Principal de Soluciones y apoya a los clientes del sector financiero para recorrer el nuevo mundo de DeFi, web3.0, Blockchain, DApps y Smart Contracts. Además, tiene una amplia experiencia en computación de alto rendimiento (HPC) y aprendizaje automático. Apasionado por la música y el buceo, devora libros, juega a World of Warcraft y New World y cocina para sus amigos.

Blog de Amazon Web Services (AWS)