Compartir a través de

Privacidad de datos para el análisis a escala de la nube en Azure

  • Artículo

El análisis a escala de la nube permite a las organizaciones determinar los mejores patrones que se adapten a sus requisitos y, al mismo tiempo, protejan los datos personales en varios niveles. Los datos personales son datos que se pueden usar para identificar a las personas; por ejemplo, números de carné de conducir, números de seguridad social, números de cuenta bancaria, números de pasaporte, direcciones de correo electrónico, etc. Actualmente, existen muchas regulaciones para proteger la privacidad de los usuarios.

Esquema de clasificación de confidencialidad de los datos

clasificación Descripción
Público Cualquiera puede acceder a los datos y se pueden enviar a cualquiera. Por ejemplo, abra datos de gobierno.
Exclusivamente para uso interno Solo los empleados pueden acceder a los datos y no se pueden enviar fuera de la empresa.
Confidencial Los datos solo se pueden compartir si es necesario para una tarea específica. Los datos no se pueden enviar fuera de la empresa sin un acuerdo de no divulgación.
Altamente confidenciales (datos personales) Los datos contienen información privada que debe ocultarse y compartirse solo cuando sea necesario conocerla, durante un tiempo limitado. Los datos no se pueden enviar a personal no autorizado ni fuera de la empresa.
Restringidos Los datos solo se pueden compartir con personas con nombre responsables de su protección. Por ejemplo, documentos legales o secretos comerciales.

Antes de ingerir datos, debe clasificarlos como confidenciales o categorías inferiores o altamente confidenciales (datos personales) :

  • Los datos se pueden ordenar como confidenciales o categorías inferiores si un usuario obtiene acceso al recurso de datos en enriquecidos o mantenidos. Los usuarios pueden ver todas las columnas y filas.

  • Los datos se pueden ordenar como altamente confidenciales (datos personales) si hay restricciones para las que las columnas y filas sean visibles para distintos usuarios.

Importante

Un conjunto de datos puede cambiar de confidencial o categorías inferiores a altamente confidencial (datos personales) cuando se combinan datos. En situaciones en las que los datos deben ser persistentes, se deben copiar en una carpeta independiente que se alinee con la clasificación de confidencialidad de datos y el proceso para incorporarlos.

Confidencial o categorías inferiores

Para cada producto de datos incorporado, creamos dos carpetas de Data Lake en las capas enriquecidas y mantenidas: confidenciales o categorías inferiores y altamente confidenciales (datos personales). Después, usamos listas de control de acceso para habilitar la autenticación transferida de Microsoft Azure Active Directory (Microsoft Entra ID).

Si el equipo de aplicaciones de datos incorpora un recurso de datos confidenciales o de categoría inferior, los nombres principales de usuario y los objetos de entidad de servicio se pueden agregar a dos grupos de Microsoft Entra (uno para el acceso de lectura/escritura y otro para el acceso de solo lectura). Estos dos grupos de Microsoft Entra deben crearse durante el proceso de incorporación y ordenarse en la carpeta de productos de datos correspondiente con contenedores confidenciales o de categoría inferior para los datos sin procesar y enriquecidos.

Este patrón permite a cualquier producto de proceso que admita la autenticación transferida de Microsoft Entra conectarse al lago de datos y autenticar a los usuarios que han iniciado sesión. Si un usuario forma parte del grupo de recursos de datos de Microsoft Entra, puede acceder a los datos mediante la autenticación transferida de Microsoft Entra. Permite a los usuarios del grupo leer todo el recurso de datos sin filtros de directiva. A continuación, el acceso se puede auditar en detalle con los registros adecuados y Microsoft Graph.

Para obtener recomendaciones sobre el diseño del lago de datos, consulte Aprovisionamiento de tres cuentas de Azure Data Lake Storage Gen2 para cada zona de aterrizaje de datos.

Nota:

Algunos ejemplos de productos de proceso son los grupos a petición de Azure Databricks, Azure Synapse Analytics, Apache Spark y Azure Synapse SQL habilitados con la autenticación transferida de Microsoft Entra.

Altamente confidenciales (datos personales)

Para los datos altamente confidenciales (datos personales), la empresa debe restringir lo que los usuarios pueden ver mediante una directiva, copias de datos o proceso. En este caso, la organización debe considerar la posibilidad de mover o insertar el control de acceso en la capa de proceso. Hay cuatro opciones para abordar la seguridad de los datos dentro del análisis a escala de la nube.

Escenario de ejemplo

En el ejemplo siguiente se describen las opciones para proteger los datos altamente confidenciales (datos personales) :

Una aplicación de datos ingiere un producto de datos de personal de recursos humanos (RR. HH.) para Norteamérica y Europa. Llamadas de caso de uso para que los usuarios europeos solo vean registros de personal de Europa y los norteamericanos solo vean los del personal de Norteamérica. Se restringe aún más para que solo los administradores de RR. HH. vean las columnas que contengan datos de salario.

Las dos primeras opciones proporcionan una manera de controlar la información altamente confidencial (datos personales) y también conceden control a los equipos de operaciones de integración y productos de datos a fin de identificar y restringir el acceso. Puede ser suficiente para una plataforma de análisis de pequeña escala, pero se debe colocar un motor de directivas en la zona de aterrizaje de administración de datos para una gran empresa con cientos de productos de datos. Los motores de directivas admiten una manera centralizada de administrar, proteger y controlar lo siguiente:

  • Acceso a datos
  • Administración del ciclo de vida de los datos
  • Directivas y normativas internas y externas
  • Directivas de uso compartido de datos
  • Identificación de información altamente confidencial (datos personales)
  • Conclusiones sobre la protección y el cumplimiento
  • Directivas para informes de protección de datos

Normalmente, un motor de directivas se integraría con un catálogo de datos como Azure Purview. Azure Marketplace cuenta con soluciones de proveedores de terceros y algunos proveedores trabajan con Azure Synapse y Azure Databricks para cifrar y descifrar información, al mismo tiempo que proporcionan seguridad de nivel de fila y de columna. En enero de 2022, Azure Purview lanzó una versión preliminar pública de las directivas de acceso para controlar el acceso a los datos almacenados en Blob Storage y Azure Data Lake Storage (ADLS) Gen2. Consulte Aprovisionamiento de conjuntos de datos por propietario de datos para Azure Storage.

El motor de directivas debe usar grupos de Microsoft Entra para aplicar directivas a los productos de datos. La expectativa de cualquier solución de directiva que proporcione privacidad de datos es dividir en tokens la información altamente confidencial (datos personales) y comprobar siempre el control de acceso a atributos para que el usuario pueda revertir este proceso para las columnas a las que necesite acceder.

Como se mencionó, para que un motor de directivas tenga éxito, es importante integrarlo en el catálogo de datos y que DevOps use una API de REST para incorporar un nuevo conjunto de datos. A medida que los equipos de aplicaciones crean orígenes de datos de lectura, se registran en el catálogo de datos y ayudan a identificar la información altamente confidencial (datos personales). El motor de directivas debe importar la definición y denegar todo el acceso a los datos hasta que los equipos configuren sus directivas de acceso. Todo esto debe realizarse mediante un flujo de trabajo de la API de REST desde la solución de administración de servicios de TI.

Opción 2: Versiones confidenciales o inferiores y confidenciales (datos personales)

Para cada producto de datos que se clasifica como confidencial (datos personales) se crean dos copias mediante la canalización. Uno que se clasifica como confidencial o inferior que tiene todas las columnas confidenciales (datos personales) eliminadas y se crea en la carpeta confidencial o inferior del producto de datos. La otra copia se crea en la carpeta confidencial (datos personales), para el producto de datos, que tiene todos los datos confidenciales incluidos. A cada carpeta se le asignaría un grupo de seguridad lector de Microsoft Entra y un grupo de seguridad escritor de Microsoft Entra. Con Data Access Management, un usuario podría solicitar acceso al producto de datos.

Aunque esto cumple con la separación de datos confidenciales (personales) y confidenciales o inferiores, un usuario con acceso concedido a través de la autenticación de acceso directo de Active Directory a la información confidencial (datos personales) podría consultar todas las filas. Si necesita seguridad de nivel de fila, tendría que usar la Opción 1: Motor de directivas (recomendado) o la Opción 3: Grupos de SQL de Azure SQL Database, SQL Managed Instance o Azure Synapse Analytics.

Opción 3: grupos de SQL de Azure Synapse Analytics, Azure SQL Database o SQL Managed Instance

Una aplicación de datos usa grupos de SQL Database o SQL Managed Instance o Azure Synapse Analytics SQL, para cargar los productos de datos en una base de datos que admite la seguridad de nivel de fila, la seguridad de nivel de columna y el enmascaramiento dinámico de datos. Los equipos de aplicación de datos crean grupos de Microsoft Entra diferentes y asignan permisos que admiten la confidencialidad de los datos.

En el caso de uso de este escenario, los equipos de aplicación de datos tendrían que crear los cuatro grupos de Microsoft Entra siguientes con acceso de solo lectura:

Grupo Permiso
DA-AMERICA-HRMANAGER-R Ver el recurso de datos de personal de RR. HH. de Norteamérica con información de salario.
DA-AMERICA-HRGENERAL-R Ver el recurso de datos de personal de RR. HH. de Norteamérica sin información de salario.
DA-EUROPE-HRMANAGER-R Ver el recurso de datos de personal de RR. HH. de Europa con información de salario.
DA-EUROPE-HRGENERAL-R Ver el recurso de datos de personal de RR. HH. de Europa sin información de salario.

El primer nivel de restricciones admitiría el enmascaramiento dinámico de datos, que oculta la información confidencial a los usuarios sin privilegios. Una ventaja de este enfoque es que se puede integrar en la incorporación de un conjunto de datos con una API de REST.

El segundo nivel consiste en agregar seguridad de nivel de columna para impedir que los usuarios que no sean administradores de RR. HH. vean los salarios, y seguridad de nivel de fila para restringir las filas que pueden ver los usuarios europeos y norteamericanos.

Además del cifrado de datos transparente, la capa de seguridad consistiría en cifrar la columna de datos y descifrarla tras la lectura.

Las tablas pueden estar disponibles para Azure Databricks con el conector de Apache Spark: SQL Server y Azure SQL Database.

Opción 4: Azure Databricks

La opción cuatro es usar Azure Databricks para explorar la información altamente confidencial (datos personales). El uso de una combinación de bibliotecas de cifrado de Fernet, funciones definidas por el usuario (UDF), secretos de Databricks, control de acceso a tablas y funciones de vista dinámica ayuda a cifrar y descifrar columnas.

Como entrada de blog, en Aplicar el cifrado de nivel de columna y evitar la duplicación de datos, se describe lo siguiente:

El primer paso de este proceso es proteger los datos mediante su cifrado durante la ingesta y una posible solución es la biblioteca de Python de Fernet. Fernet usa el cifrado simétrico, que se ha creado con varias primitivas criptográficas estándar. Esta biblioteca se usa dentro de una UDF de cifrado que nos permitirá cifrar cualquier columna determinada en un dataframe. Para almacenar la clave de cifrado, usamos secretos de Databricks con controles de acceso para permitir que nuestro proceso de ingesta de datos solo pueda acceder a ella. Una vez que los datos se escriban en nuestras tablas de Delta Lake, los usuarios no autorizados no podrán leer las columnas de datos personales que contienen valores como el número del seguro social, el número de teléfono, el número de tarjeta de crédito y otros identificadores.

Una vez que los datos confidenciales se hayan escrito y estén protegidos, necesita una forma de que los usuarios con privilegios lean los datos confidenciales. Lo primero que se debe hacer es crear una UDF permanente para agregarla a la instancia de Hive que se ejecuta en Databricks. Para que una UDF sea permanente, debe estar escrita en Scala. Afortunadamente, Fernet también tiene una implementación de Scala que se puede usar para las lecturas descifradas. Esta UDF también accede al mismo secreto que se usa en la escritura cifrada para realizar el descifrado y, en este caso, se agrega a la configuración de Spark del clúster. Esto requiere que se agreguen controles de acceso al clúster para que los usuarios con privilegios y sin privilegios controlen su acceso a la clave. Una vez creada la UDF, podemos usarla en nuestras definiciones de vista para que los usuarios con privilegios vean los datos descifrados.

Con las funciones de vista dinámica, solo puede crear una vista y devolver los valores cifrados o descifrados en función del grupo de Databricks al que pertenecen.

En el ejemplo anterior, crearía dos funciones de vista dinámica, una para Norteamérica y otra para Europa, e implementaría las técnicas de cifrado en este cuaderno.

Vista de Norteamérica:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Vista de Europa:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

Para que funcione, tendría que habilitar el control de acceso a la tabla de Azure Databricks en el área de trabajo y aplicar los permisos siguientes:

  • Conceda a los grupos de Microsoft Entra DA-AMERICA-HRMANAGER-R y DA-AMERICA-HRGENERAL-R acceso a la vista vhr_us.
  • Conceda a los grupos de Microsoft Entra DA-EUROPE-HRMANAGER-R y DA-EUROPE-HRGENERAL-R acceso a la vista vhr_eu.

Puesto que las columnas están cifradas y no se pueden descifrar en el área de trabajo de información confidencial o de categorías inferiores, las áreas de trabajo de este nivel pueden seguir usando la autenticación transferida de Microsoft Entra y permitir a los usuarios explorar el lago, en función de sus permisos.

Cuando se usa el acceso a tablas, los equipos que requieren acceso se agregan al área de trabajo de Azure Databricks. Azure Databricks usaría entidades de servicio para asignarlas a Azure Data Lake Storage, pero los datos se protegerían con el control de acceso a tablas de Azure Databricks.

A medida que se implementen nuevos productos de datos, parte del proceso de DevOps tendría que ejecutar scripts para configurar los permisos de tabla en el área de trabajo de Azure Databricks y agregar los grupos de Microsoft Entra correctos a esos permisos.

Nota:

El control de acceso a tablas de Azure Databricks no se puede combinar con la autenticación transferida de Microsoft Entra. Por lo tanto, solo podría usar un área de trabajo de Azure Databricks y usar el control de acceso a tablas en su lugar.

Datos restringidos

Además de implementar opciones para datos confidenciales o restringidos, también se recomienda hospedar datos altamente confidenciales en una zona de aterrizaje de datos dedicada y una zona de aterrizaje de administración de datos.

Permite requisitos específicos, como el acceso Just-In-Time, las claves administradas por el cliente para el cifrado y las restricciones entrantes o salientes aplicadas a la zona de aterrizaje. La guía ha evaluado la colocación de datos de este tipo en la misma zona de aterrizaje de datos, pero en distintas cuentas de almacenamiento. Sin embargo, esto puede provocar que la solución resulte más complicada en el nivel de redes, por ejemplo, con grupos de seguridad de red y otros.

La zona de aterrizaje de administración de datos "restringidos" dedicados debe conectarse para catalogar los datos de la zona de aterrizaje de datos "restringidos". Debe restringir quién puede buscar estos datos en el catálogo.

Pasos siguientes