¿Sabías que existen muchos métodos de aplicar seguridad a un Lakehouse? Disponemos de diferentes métodos como son los permisos del área de trabajo, permisos del propio lakehouse, la seguridad a nivel de fila (RLS), la seguridad a nivel de columna (CLS) o la enmascaración de datos. Vamos a ver cada uno de ellos para conseguir proteger nuestros datos.
Especificaciones del entorno
- Windows 11
- Servicio de Fabric (Abril 2024)
Punto de conexión de SQL
El punto de conexión de SQL de un Lakehouse es de solo lectura por lo que por sí mismo ya tiene cierta seguridad. Además, puedes otorgar permisos haciendo clic en administrar seguridad y agregar usuarios y grupos. Antes de nada, debes saber que no es necesario otorgar permisos al área de trabajo donde está ubicado el lakehouse ya que puedes usar la opción compartir y el usuario podrá visualizarlo desde el centro de datos de OneLake.
Para compartir el Lakehouse haz clic en los tres puntos situados a la derecha del nombre del Lakehouse y pulsa en compartir. Aparece una ventana donde puedes incluir el nombre del usuario o un grupo y una serie de permisos adicionales.
- Si compartes y no seleccionas permisos adicionales: proporciona permisos de “Lectura” que permiten al destinatario conectarse al endpoint SQL. Es el equivalente a los permisos de conexión en SQL Server. Esta opción puede ser útil si desea proporcionar acceso granular utilizando la sentencia T-SQL GRANT.
- Leer todos los datos utilizando SQL: esta opción proporciona permisos de “ReadData” que permite el acceso de lectura a todas las tablas y vistas dentro del almacén de datos. Es el equivalente al rol db_datareader en SQL Server. Esta opción puede ser útil para los usuarios que deseen leer a través de T-SQL (si quieres proporcionar acceso granular, puede mantener esta opción deseleccionada y hacer clic en “Compartir”. Utilice GRANT/REVOKE/DENY en T-SQL para la seguridad a nivel de objeto.)
- Leer todos los datos utilizando Apache Spark: esta opción proporciona permisos “ReadAll” que permite el acceso de lectura a los archivos subyacentes del Almacén en One Lake para que pueda leer a través de Apache Spark. Esta opción puede ser útil para sus científicos de datos que deseen leer utilizando Spark.
- Generar informes en el conjunto de datos por defecto: esta opción proporciona permisos de “Build” en el conjunto de datos por defecto que está conectado a su Almacén. Esto le permite crear informes de Power BI sobre el conjunto de datos predeterminado. Esta opción puede ser útil para que sus desarrolladores de BI creen informes.
Seguridad a nivel de fila
Cuando usas la seguridad a nivel de fila, también conocido por sus siglas en inglés RLS (Row Level Security) te estas asegurando que cada usuario solo puede ver la información que le corresponde. Vamos a realizar un simple ejemplo donde crearemos una función que nos devuelva un 1 cuando el valor del email sea el mismo de quien lanza la consulta y después crearemos una política de seguridad para que el email del usuario conectado sea el mismo al email que tenemos en la tabla. El objetivo final es que un usuario llamado Jeff solo pueda ver sus datos en la siguiente tabla:
Crear función
Ejecuta el siguiente código para crear un esquema llamado seg. y dentro de él crear una función llamada validar_email. Si observas el código leemos el email del usuario que ejecuta la consulta por medio de USER_NAME() que lo convertimos todo a minusculas para mayor seguridad.
CREATE SCHEMA seg;
GO
CREATE FUNCTION seg.validar_email(@email as VARCHAR(500))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS validar_email_resultado
WHERE LOWER(@email) = LOWER(USER_NAME())
GO
Crear política de seguridad
En esta política de seguridad llamada FiltroEmailUsuario que crearemos filtrará la tabla del esquema dbo.seguridad por el campo email y activaremos la política con el comando STATE=ON. Ejecuta la siguiente sentencia en las consultas de tu Lakehouse:
CREATE SECURITY POLICY FiltroEmailUsuario ADD FILTER PREDICATE seg.validar_email(email) ON dbo.seguridad WITH (STATE=ON); GO
Comprobar funcionamiento
Ahora solo queda comprobarlo. Inicia sesión con otro usuario y comprueba que solo ve su información:
Además esto funciona para el resto de componentes de Fabric, por ejemplo, si el usuario Jeff se crea un informe en Power BI solo verá sus datos pero ten en cuenta que la seguridad a nivel de fila forzará al modelo a ser Direct Query sino escoger el modo de importación.
Desactivar política de seguridad
Si quieres desactivar en algún momento la política de seguridad tan solo tienes que ejecutar este comando desde un usuario con permisos para hacerlo:
ALTER SECURITY POLICY FiltroEmailUsuario WITH (STATE = OFF);
Seguridad a nivel de columna
Otra opción es ocultar ciertas columnas de una tabla a un usuario. A esta funcionalidad se le conoce por las siglas CLS (Column Level Security). Es tan sencillo como ejecutar una consulta. En el siguiente ejemplo prohibiremos a Jeff consultar la columna nombre de la tabla seguridad:
GRANT SELECT ON seguridad(email) TO [jeff@migueltroyano.onmicrosoft.com]
Si ahora accedemos con el usuario de Jeff obtendremos un mensaje de error si intentamos consultar toda la tabla. Ten en cuenta que CLS obliga a los usuarios ha realizar un select con el nombre de las columnas que quiere visualizar (Power BI incluido)
Enmascarar datos
Otra opción de seguridad es la enmascaración de datos. Podemos enmascarar datos con diferentes funciones (leer documentación oficial). En el siguiente ejemplo vamos a enmascarar el campo email de la tabla email con la función email(). Lanzamos la siguiente sentencia:
ALTER TABLE dbo.email ALTER COLUMN email ADD MASKED WITH (FUNCTION = 'email()');
Y ahora comprobamos el resultado y vemos como los datos de la columna email están codificados:
Ten en cuenta que el usuario podría llegar adivinar el contenido de un campo si filtra por él y consigue que le devuelva datos.
¿te ha gustado? Dejame un comentario…