Consulta Blob Storage

Question

Estoy evaluando dos arquitecturas distintas en Azure Blob Storage para almacenamiento de información sensible de salud (videos de telemedicina, fichas clínicas, exámenes, etc.) y me gustaría conocer opiniones o buenas prácticas de quienes hayan implementado algo similar.

Escenario 1: proveedor externo que necesita almacenar y reproducir contenido

En este escenario tenemos un proveedor SaaS externo que necesita:

• almacenar videos en nuestro Azure Blob Storage
• posteriormente generar reproducción/descarga desde navegador

La arquitectura actual quedó así:

• Azure Blob Storage
• Container privado (Private / no anonymous access)
• Allow Blob anonymous access = Disabled
• Public Network Access = Enabled from all networks
• El proveedor utiliza Connection String + Account Key
• El proveedor genera SAS temporales para reproducción
• Los usuarios finales acceden al blob mediante SAS desde navegador
• El acceso directo sin SAS devuelve: PublicAccessNotPermitted

Entiendo que aquí el storage debe permanecer accesible públicamente a nivel de red (All networks) porque el navegador del usuario final descarga directamente desde Azure usando SAS, y por lo tanto Azure verá la IP pública del usuario y no la del proveedor.

Preguntas:

• ¿Este modelo es considerado adecuado para datos sensibles/médicos si se usan SAS de corta duración, containers privados y logging?
• ¿Qué controles adicionales recomiendan?
• ¿Es buena práctica usar un Storage Account dedicado exclusivamente para este proveedor externo?
• ¿Qué tan recomendable es restringir por IP si los consumidores finales son navegadores de usuarios externos?

Escenario 2: arquitectura completamente propia (AKS + Blob privado)

En este segundo escenario todo el ecosistema es propio:

• frontend propio
• backend propio
• AKS propio
• Blob Storage propio

La idea sería:

• Blob Storage completamente privado
• Public Network Access = Disabled
• acceso mediante Private Endpoint
• AKS integrado a la VNet
• Pods accediendo al Blob mediante IP privada
• autenticación usando Managed Identity/RBAC en vez de Access Keys
• el usuario final nunca accede directamente al Blob
• el backend/pod actúa como proxy/autorizador para descargar o visualizar fichas clínicas

Flujo:

Paciente → Frontend → API en AKS → Blob privado vía Private Endpoint

En este caso entiendo que el nivel de seguridad y aislamiento sería bastante mayor, especialmente para fichas clínicas o documentos médicos sensibles.

Preguntas:

• ¿Esta arquitectura es la recomendada actualmente para workloads regulados o de salud?
• ¿Vale la pena eliminar completamente SAS públicos en este modelo?
• ¿Qué tradeoffs reales han visto en costo/performance al usar backend proxy para archivos grandes o streaming?
• ¿Managed Identity + Private Endpoint sería hoy la práctica más recomendada en Azure para este tipo de escenarios?

Agradezco cualquier experiencia o recomendación práctica de arquitectura, compliance o seguridad.

Gracias!

Answer 1

Hola Sebastian Pacheco,

He traducido esto del inglés al español, así que disculpen cualquier error gramatical.

Gracias por contactarnos a través del foro de preguntas y respuestas de Microsoft.

En entornos sanitarios regulados, el almacenamiento de datos confidenciales, como vídeos de telemedicina, historiales clínicos y exámenes, en Azure Blob Storage debe seguir un enfoque de defensa en profundidad que combine controles de identidad robustos, aislamiento de red y una estricta gestión de claves y tokens SAS.

Para el escenario 1 (SaaS de terceros que utiliza SAS), este modelo puede ser aceptable si:

• Utiliza tokens SAS de corta duración, solo HTTPS y con permisos de alcance limitado.
• Almacena las claves de cuenta en una ubicación segura (por ejemplo, Azure Key Vault) y las rota periódicamente.
• Evita reutilizar las mismas claves o cuentas en otras cargas de trabajo.
• Deshabilita la autenticación con clave compartida siempre que sea posible y prioriza el control de acceso basado en roles (RBAC) de Microsoft Entra ID para cualquier acceso del lado del servicio.

Sin embargo, permitir el acceso a la cuenta de almacenamiento a través de la red pública, incluso cuando se trata de una cuenta SAS, amplía la superficie de ataque y, por lo general, no es lo más adecuado para datos de salud altamente sensibles. Restringir el acceso por IP a los navegadores de los usuarios finales no es práctico; si se aplican controles basados ​​en IP, conviene hacerlo en la capa de interfaz/puerta de enlace de la API.

Para el escenario 2 (arquitectura privada de extremo a extremo con AKS, Private Endpoint e identidad administrada), el patrón se ajusta a las directrices de seguridad y arquitectura de Microsoft para cargas de trabajo reguladas.

• Mantener la cuenta de almacenamiento completamente privada (con el acceso a la red pública deshabilitado) y accesible solo a través de un Private Endpoint en la VNet de AKS reduce la exposición a internet.
• El uso de identidad administrada para los pods de AKS, en lugar de claves de acceso o cadenas de conexión de cuenta, elimina las credenciales persistentes de la aplicación y simplifica la autorización basada en RBAC.
• Enrutar todo el tráfico de usuario a través del backend (frontend → API de AKS → almacenamiento) permite aplicar lógica de acceso granular, controles de auditoría y comportamiento de transmisión sin exponer los tokens SAS a los navegadores de los usuarios finales.

Si bien el patrón de proxy de backend introduce un salto adicional y algunas consideraciones sobre el costo de salida, la ventaja es una postura de cumplimiento significativamente más sólida y un mayor control sobre datos altamente sensibles como la información de salud protegida (PHI). Para cargas de trabajo reguladas o del sector sanitario, este es el patrón de referencia recomendado; el escenario 1 debe reservarse para proveedores externos o integraciones heredadas donde el acceso completo al punto final privado no sea factible.

Enlaces a la documentación oficial de Microsoft:

• Recomendaciones de seguridad para Blob Storage - Azure Storage | Microsoft Learn
• Procedimientos recomendados de arquitectura para Azure Blob Storage - Microsoft Azure Well-Architected Framework | Microsoft Learn
• Ofertas de cumplimiento de Azure Storage | Microsoft Learn
• Configuración de Private Link para Azure Health Data Services | Microsoft Learn

Por favor, háganos saber si lo anterior le resulta útil o si necesita más ayuda con este tema.

Por favor, no olvide marcar como "Aceptar respuesta" y "Votar positivamente" la información proporcionada, ya que esto puede beneficiar a otros miembros de la comunidad.