Privacidad de datos para el análisis a escala de la nube en Azure
El análisis a escala de la nube permite a las organizaciones determinar los patrones óptimos de acceso a los datos que se adaptan a sus necesidades, salvaguardando al mismo tiempo los datos personales en múltiples niveles. Los datos personales incluyen cualquier información que pueda identificar de forma exclusiva a las personas, por ejemplo, números de carné de conducir, números de la seguridad social, detalles de cuentas bancarias, números de pasaporte, direcciones de correo electrónico, etc. Actualmente, existen muchas regulaciones para proteger la privacidad de los usuarios.
Para proteger la confidencialidad de los datos con un entorno de nube como Azure, puede empezar por crear un esquema de confidencialidad de datos que especifique las políticas de acceso a los datos. Estas políticas pueden definir la arquitectura subyacente en la que reside la aplicación de datos, definir cómo se autoriza el acceso a los datos y especificar a qué filas o columnas se puede acceder una vez concedido.
Crear un esquema de clasificación de la 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 ingestar los datos, debe clasificarlos como confidenciales o inferiores o sensibles (datos personales):
- Los datos pueden clasificarse en confidenciales o inferiores si no hay restricciones para qué columnas y filas son visibles para los distintos usuarios.
- Los datos pueden clasificarse como sensibles (datos personales) si existen restricciones para que las columnas y filas sean visibles para diferentes usuarios.
Importante
Un conjunto de datos puede pasar de confidencial o inferior a sensible (datos personales) cuando los datos se combinan con otros productos de datos que anteriormente tenían una clasificación inferior. Cuando los datos necesitan ser persistentes, deben moverse a una carpeta designada que se alinee con su nivel de confidencialidad y el proceso de incorporación.
Crear un conjunto de políticas Azure
Después de asignar su clasificación de datos, debe alinear la clasificación con los requisitos de la política regulada local del sector y las políticas internas de su empresa. Este paso le ayuda a crear un conjunto de políticas de Azure que rige qué infraestructura se puede implementar, la ubicación en la que se puede implementar y especifica los estándares de red y cifrado.
Para los sectores regulados, Microsoft ha desarrollado muchas Iniciativas de políticas de cumplimiento normativo que actúan como base para los marcos de cumplimiento.
Para la clasificación de datos, que sigue las mismas normas de cifrado y SKU de infraestructura permitidos, y las iniciativas de políticas los datos pueden ubicarse dentro de la misma zona de aterrizaje.
Para los datos restringidos, se recomienda alojar los datos en una zona de aterrizaje de datos dedicada bajo un grupo de administración en el que se puede definir un conjunto más elevado de requisitos para la infraestructura, como claves administradas por el cliente para el cifrado y restricciones de entrada o salida aplicadas a la zona de aterrizaje.
Nota:
La guía ha evaluado poner datos sensibles (datos personales) y confidenciales o inferiores de los datos en la misma zona de aterrizaje de datos pero en diferentes cuentas de almacenamiento. Sin embargo, esto podría complicar la solución en la capa de red, por ejemplo, con grupos de seguridad de red.
Cualquier solución de gobierno de datos que se implante debe limitar quién puede buscar datos restringidos en el catálogo.
También debe considerar implementar el acceso condicional de Microsoft Entra ID para todos los activos y servicios de datos, y el acceso justo a tiempo para los datos restringidos para mejorar la seguridad.
Cifrado
Además de definir políticas para la ubicación y los servicios Azure permitidos, debe considerar los requisitos de cifrado para cada una de las clasificaciones de datos.
- ¿Cuáles son sus requisitos para la administración de claves?
- ¿Cuáles son sus requisitos para el almacenamiento de esas claves?
- ¿Cuáles son sus requisitos, por clasificación, para el cifrado de datos en reposo?
- ¿Cuáles son sus requisitos, por clasificación, para el cifrado de datos en tránsito?
- ¿Cuáles son sus requisitos, por clasificación, para el cifrado de datos en uso?
Para la administración de claves, las claves de cifrado pueden ser administradas por la plataforma o por el cliente. Microsoft ha documentado la administración de claves en Azure para ayudarle a elegir una solución de administración de claves. Para obtener más información, consulte Introducción a la administración de claves en Azure y Cómo elegir la solución de administración de claves adecuada.
Microsoft publicó documentación que explica el Cifrado de datos en reposo de Azure y los modelos de cifrado de datos que le ayudan a comprender las opciones de cifrado disponibles.
Microsoft ofrece a los clientes la posibilidad de utilizar el protocolo Transport Layer Security (TLS) para proteger los datos cuando viajan entre los servicios en la nube y los clientes. Para obtener más información, consulte Cifrado de datos en tránsito.
Si su escenario requiere que los datos permanezcan cifrados durante su uso, el modelo de amenazas de la informática confidencial de Azure pretende minimizar la confianza o eliminar la posibilidad de que un operador del proveedor de la nube u otros actores del dominio del inquilino accedan al código y a los datos durante la ejecución.
Para conocer las últimas ofertas de informática confidencial de Azure, consulte Productos de informática confidencial de Azure.
Gobernanza de datos
Después de definir las políticas para la implementación de los servicios Azure permitidos, debe decidir cómo concede acceso al producto de datos.
Si dispone de una solución de gobernanza de datos como Microsoft Purview o Azure Databricks Unity Catalog, puede crear activos/productos de datos para capas de lago de datos enriquecidas y curadas. Asegúrese de establecer los permisos dentro del catálogo de datos para proteger esos objetos de datos.
Microsoft Purview proporciona una forma centralizada de administrar, proteger y controlar:
- Acceso a datos
- 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
Para obtener más información sobre la administración del acceso de lectura o modificación con Microsoft Purview, consulte Conceptos de políticas de propietarios de datos de Microsoft Purview.
Tanto si decide implementar Microsoft Purview como cualquier otra solución de gobierno de datos, es esencial utilizar los grupos de ID de Microsoft Entra para aplicar políticas a los productos de datos.
Es importante utilizar la API REST de las soluciones de gobierno de datos para dar de alta un nuevo conjunto de datos. Los equipos de aplicación de datos crean productos de datos y los registran en la solución de gobierno de datos para ayudar a identificar los datos sensibles (datos personales). La solución de gobernanza de datos importa la definición y deniega todo acceso a los datos hasta que los equipos establezcan sus políticas de acceso.
Uso de patrones para proteger los datos sensibles
Existen varios patrones que se pueden adoptar en función de los datos, servicios y políticas que se necesiten implementar para la protección de datos sensibles.
Múltiples copias
Para cada producto de datos clasificado como sensible (datos personales) se crean dos copias mediante su pipeline. La primera copia se clasifica como confidencial o inferior. Esta copia tiene todas las columnas sensibles (datos personales) eliminadas y se crea en la carpeta confidencial o inferior del producto de datos. La otra copia se crea en la carpeta sensible (datos personales) y tiene todos los datos sensibles incluidos. A cada carpeta se le asigna un lector de Microsoft Entra ID y un grupo de seguridad de escritor de Microsoft Entra ID.
Si se está usando Microsoft Purview, puede registrar ambas versiones del producto de datos y usar políticas para proteger los datos.
Este proceso separa los datos sensibles (personales) de los confidenciales o inferiores, pero un usuario con acceso a datos sensibles (personales) podrá consultar todas las filas. Es posible que su organización necesite buscar otras soluciones que proporcionen seguridad a nivel de fila para filtrar las filas.
Seguridad de nivel de fila y de nivel de columna
Si necesita filtrar las filas vistas por los usuarios, puede mover sus datos a una solución informática que use seguridad a nivel de fila.
Seleccionar el servicio Azure o la solución Microsoft Fabric adecuados para su caso de uso particular es esencial para evitar la reingeniería. Una base de datos OLTP es inadecuada para la analítica extensiva, del mismo modo que una solución adaptada para la analítica de macrodatos no puede alcanzar los tiempos de respuesta de milisegundos que requiere una aplicación de comercio electrónico.
Para trabajar con soluciones que admiten la seguridad a nivel de fila, los equipos de aplicación de datos crean diferentes grupos de Microsoft Entra ID y asignan permisos en función de la sensibilidad de los datos.
Elaboremos el escenario especificando que, junto con la seguridad a nivel de filas, existe la necesidad de restringir el acceso a determinadas columnas. Los equipos de aplicación de datos crearon los cuatro grupos de Microsoft Entra ID con acceso de solo lectura, como se muestra en la tabla siguiente:
| 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 de restricciones consiste en añadir seguridad a nivel de columna para restringir el acceso a los salarios a quienes no sean gestores de RR. HH. y seguridad a nivel de fila para restringir qué filas pueden ver los miembros de los equipos de Europa y Norteamérica.
Cifrado de columnas
Mientras que el enmascaramiento dinámico de datos enmascara los datos en el punto de presentación, algunos casos de uso requieren que la solución nunca tenga acceso a los datos en texto plano.
SQL Always Encrypted es una potente función introducida por Microsoft que mejora la seguridad de los datos sensibles almacenados en las bases de datos de SQL Server. SQL Always Encrypted garantiza que los datos sensibles almacenados en las bases de datos de SQL Server permanezcan seguros y protegidos de accesos no autorizados. Esta función ayuda a mantener la máxima confidencialidad de los datos y el cumplimiento de la normativa cifrando los datos tanto en reposo como en tránsito.
Al realizar las operaciones de cifrado y descifrado en el lado del cliente, Always Encrypted garantiza que los datos sensibles permanezcan protegidos de accesos no autorizados. Su facilidad de integración y sus ventajas en materia de cumplimiento de normativas lo convierten en una herramienta esencial para las organizaciones que desean salvaguardar sus activos de datos más valiosos.