La necesidad de compartir datos entre múltiples fuentes y departamentos en las organizaciones lleva a la construcción de data lakes corporativos, los cuales son lugares donde se almacena de manera centralizada toda la información de las distintas fuentes de la compañía con el fin poder ser consumidos por los distintos departamentos.

Un aspecto muy importante para la gestión correcta del data lake es asegurar una correcta gobernanza poniendo foco en puntos como: la calidad de los datos, almacén de metadatos o la seguridad y control de acceso a nuestros datos.

Conscientes de la necesidad de garantizar un eficiente control de acceso a nuestros datos, AWS dispone de varios servicios a partir de los cuales se puede gestionar el control de acceso a los datos, y, en este post explicaremos cómo controlar el acceso a los datos mediante IAM y Lake Formation

IAM (Identity and Access Management) nos permite administrar las identidades y gestionar el acceso de las mismas a los recursos y servicios de la nube, mientras que Lake Formation es un servicio diseñado para la creación y gestión simple de data lakes.

Partiendo de un almacenamiento de objetos para persistir todos los datos de nuestro data lake, éste podría estructurarse en las siguientes capas:

  • Capa raw, capa de ingesta que almacenará los datos en bruto: No debe ser visualizable por el usuario, pero estará estructurada y no todos los elementos de procesamiento deberían poder procesar todas las entidades.
  • Capa Standard o cleaned: datos limpios y transformados listos para para su análisis, los datos pueden ser consumidos por parte de los usuarios y otros procesos.
  • Capa Enriquecida, capa final de enriquecimiento y agregación con el fin de aplicar cierta lógica de negocio y disponibilizar análisis y visualización.

Como se observa en la imagen se distinguen dos tipos de accesos:

  • Accesos de otros servicios para la transformación de los datos
  • Accesos de herramientas de analítica/visualización para disponibilizar los datos a los usuarios.

En ambos casos, es crítico que los datos expuestos tanto a usuarios como para transformación, sean únicamente los necesarios para evitar fugas de información que hagan perder confianza al data lake y no se considere una herramienta confiable.

Un punto muy importante a la hora de comenzar nuestro data lake es la estructuración de la información en el almacenamiento de manera correcta (grupos de negocio, entidades funcionales, …) y el correcto etiquetado. Ambas medidas nos permitirán realizar diversos ejercicios de gestión de permisos, de una manera efectiva, así como mejorar el gobierno del almacenamiento.

IAM – Políticas basadas en recursos y tags

Imaginemos múltiples equipos de desarrollo trabajando sobre una misma plataforma para disponibilizar los datos de su área o departamento. Los equipos de desarrollo y sus procesos de transformación trabajan a bajo nivel sobre los objetos almacenados en S3 (Simple Storage Service) en la capa de ingesta (raw) y por tanto necesitan tener acceso únicamente a sus objetos.

Para este permisionado se pueden emplear dos features de IAM las cuales nos permitirán restringir el acceso a los objetos de s3 en función de reglas de negocio como podría ser el departamento del desarrollador o proceso.

Políticas basadas en recursos

Un almacenamiento de los objetos con una estructura funcionalmente correcta nos permitiría hacer un control de accesos a los objetos de manera óptima y ajustándose a premisas funcionales.

Pongamos por ejemplo, los datos de usuarios provenientes del sistema origen web. Estos datos podrían almacenarse en la capa de ingesta bajo la siguiente estructura s3://raw-bucket/web/users, lo cual nos permitiría otorgar permisos jerárquicamente a los usuarios/procesos a todo los datos del sistema web, los datos de usuarios únicamente o incluso subconjuntos de datos dentro de la entidad de usuarios.

Un ejemplo de política de accesos que podríamos asociar a un recurso o usuario/grupo sería la siguiente:


{
    "Version": "2012-10-17",
    "Statement": [
        {
           "Sid": "WebUsersViewer",
           "Effect": "Allow",
           "Action": "s3:GetObject",
           "Resource": "arn:aws:s3:::raw-bucket/web/users/*"
        }
    ]
}

En la cual concedemos, partiendo de la base de que los objetos son privados, el acceso de lectura a todos los objetos almacenados en web/users.

Otra opción para asignar varios permisos sobre la misma estructura manteniendo las restricciones y evitando duplicar las políticas sería usar condicionales en la política.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "WebViewer",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::raw-bucket",
            "Condition":{"StringLike":{"s3:prefix":
                [
                    "web/users/*",
                    "web/clients/*"
                ]
                }
            }
        }
    ]
}

Políticas basadas en tags

Una opción que nos permite bajar de grano en el nivel de permisionado sobre los objetos de S3 son las políticas basadas en tags. Si bien el tagear los objetos en S3 puede ser un proceso más complejo que la estructuración de la información, este permisionado puede ser mucho más flexible y completo que las políticas basadas en recursos.

Como el caso anterior, requiere de un ejercicio de definición inicial de los procesos y estándares de etiquetado para garantizar un eficiente control de accesos. Un ejemplo de política donde permitiremos a un usuario ver los objetos de usuarios y clientes pertenecientes a web sería el siguiente:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "WebViewer",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::raw-bucket",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "s3:ResourceTag/entity": ["users", "clients"]
                }
            }
        }
    ]
}

Pero también nos permitirá bajar el permisionado a nivel de objeto sin penalizar el particionado de nuestros datos manteniendo una estructura funcionalmente coherente.

Lakeformation

Con IAM podemos garantizar un control de accesos de grano fino a los propios objetos en S3, pero cuando tenemos la necesidad de restringir el acceso a los datos contenidos en nuestros ficheros necesitamos otro tipo de servicio. En este sentido, Lake Formation es un servicio ideal que nos permite de manera sencilla la creación de un data lake, así como la gestión y securización del mismo.

 

Centrándonos en el aspecto de la seguridad, partiremos de la premisa de que con nuestros datos almacenados en S3 con formatos admitidos, ya se han descubierto los datos y se han generado las correspondientes bases de datos, esquemas y tablas en el catálogo de datos. Lake Formation nos permite gestionar los accesos a estos datos de una manera muy sencilla y eficiente.

Para ello los permisos que se permiten otorgar son a nivel de:

  • Base de datos: permisos de creación, actualización, consulta de detalles y eliminación de la base de datos.
  • Tabla: permisos de actualización, consulta de detalles, eliminación de la tabla, y a nivel de fila de inserción, eliminación y consulta.
  • Columna: restringe el acceso a determinadas columnas de una tabla.

Los permisos pueden ser conceder y revocar, y estos pueden asignarse a Usuarios/Roles/Grupos del servicio de IAM, usuarios del servicio de visualización de QuickSight así como acceso federado mediante SAML o Active Directory con servicios de consulta como Athena. Para la gestión de los permisos se puede hacer uso del CLI de aws, la interfaz web de consola y el API.

Como en ejemplos anteriores, disponemos de una tabla users ya en el catálogo de datos, la cual está formada por las columnas nombre, logins y email. El grupo de usuarios de marketing deberían ver el campo email, mientras que el grupo de analytics no requiere de ver ese email.

 

Imagen: Unsplash | Rawpixel