Consideraciones de Seguridad para los componentes en Azure

[[TOC]]

Azure Blob Storage y Azure Data Lake (Gen2)

Datos en transito siempre tienen la comunicación cifrada por protocolo https, internamente todos los comandos en Azure son llamadas a API REST y en casi la totalidad de los caso usan https
Los datos son tambien cifrados en "reposo", y las claves de encriptación son manejadas internamente por Microsoft.
Datos en reposo son cifrados usando AES 256 y son concordantes con el patrón de industria FIPS 140-2.
- Para mas detalles en AES 256
Para mas detalles en encriptación de storage
Componentes internos al ambiente en Azure deberán de utilizar Service Principals, con sus ids y contraseñas almacenados en Azure Keyvault para acceder a los recursos en Active Directory, así como en caso se usen claves compartidas, tambien deberán de almacenarse en Key Vault
Para todos los ambientes la comunicación de los repositorios (land, Data Lake o otros internos) estará restringida a la vnet asignada para la suscripción de Advanced Analytics

Autenticación está basada en Shared Access Signatures (claves compartidas), sin embargo deberán de ser almacenadas en Azure Key Vault. Aplicaciones clientes on premises también pueden buscar claves en Key Vault si necesario.
Cifrado de el contenido siempre en el lado de Event Hub es manejada por claves manejadas por Microsoft (el servicio es un PaaS)
Cifrado de datos en transito usando https o por una vnet por Express Route, o mismo de Vnet a Vnet con configurable internamente. La solución todavía no apalanca el uso de Vnet para comunicación pero utiliza un endpoint y la puerta 443 para la comunicación de sus clientes con Event Hubs
Para mas detalles sobre los controles de seguridad de Event Hubs

La autenticación en Databricks es por Active Directory, sin embargo la autorización de acceso a los recursos se hace internamente por Databricks.
Sin embargo, cada uno de los workspaces databricks nuevos usuarios deberán de ser invitados usando el contorl plane de Databricks
Databricks tiene distintos casos de uso para autenticación:
- Los Clusters tienen que autenticarse en el repositorio de datos (sea Azure Datalake store, Azure Storage, Event Hub, CosmosDB o otra fuente)
- Distintos perfiles de acceso de los usuarios pueden ser manejados por los service principals que cada uno de los clusters usan para autenticarse
- Cada usuario en Databricks puede tener un perfil adminsitrativo (Admin Console) en el workspace, tales como "Admin" y "Allow Cluster Creation"
  - admins
  - Contributor
  - Reader
- Cada usuario en Databricks debe de ser autorizado en los clusters
  - Can Attach
  - Can Restart
  - Can Manage
- Los bancos de datos y tablas en Databricks tabien tienen sus permisos asignados.
- Referencia de asignación de permisos en objetos Azure Databricks

La comunicación entre los compentes y la base de datos SQL DB es cifrada, todas las llamadas de clientes On Premises o Power BI internamente lo hacen por comunicación usando el certificado interno de Azure SQL DB por defecto, además es necesario habilitar la comunicación entre el IP del cliente, o de la aplicación a Azure SQL en su firewall interno.
Azure SQL DB usa encripación interna a nivel de disco para los datos en reposo. Además, cada banco de datos puede usar su encripación interna usando TDE - Transparent Data Encription, que puede ser habilitada en el panel de control de Azure. El certificado interno y la encripación usa algoritimo AES 256.
Transparent Data Encription
Otra referencia de TDE

Para el ambiente de producción se debe de considerar el uso de un Key Vault corporativo interno, las condiciones de el scope y permisos en Key Vault deberán de ser definidas por el equipo de Infraestructura y Seguiridad
Uso de Vnet con Azure Databricks