Acceder de forma segura a Azure Blob Storage
Si estás usando Azure como tu principal plataforma de nube y has tenido requerimientos funcionales que demandaban la subida, almacenamiento y descarga de archivos, es muy probable que hayas utilizado el servicio de Azure especializado para este propósito: “Azure Blob Storage”.
Azure Blob Storage es un servicio diseñado para almacenar cantidades masivas de datos no estructurados, como PDFs, imágenes, videos, entre otros. Está diseñado para la alta disponibilidad y para el performance, ya que puede integrarse de forma muy amigable con otros servicios como Front Door/CDN para entregar archivos estáticos y cuenta con un nivel premium y tiers especializados para la performance que demanda la Web.
Sin entrar en mucho detalle y variantes, el concepto principal de este servicio es el de “Blob”, que representa a cualquier archivo almacenado. Como almacenar archivos en base de datos suele ser pesado, lo que se suele hacer es guardar la URL de referencia en algún campo lógico y luego poder buscar en Azure Blob Storage cuando se necesite recuperar.
Para realizar este propósito se requieren hacer los siguientes pasos.
- Conectarse al servicio de Azure Blob Storage.
- Realizar una subida o persistencia del archivo en Blob Storage.
- Descargar el archivo de Blob Storage con la ruta/URL del Blob.
Estos pasos pueden parecer sencillos en términos funcionales, pero en la parte técnica me he topado con implementaciones que descuidan las cuestiones de seguridad, como:
- Usan la clave de cuenta para conectarse al Blob Storage. En el mejor de los escenarios está en un vault de secretos, pero en implementaciones descuidadas puede estar en archivos de configuración.
- Para subir archivos se hacen operaciones a nombre de la clave de cuenta.
- Y la parte más delicada, para poder acceder a los archivos y descargar, habilitan el acceso público a los contenedores.
¿Cómo mejorar esta implementación desde la perspectiva de seguridad?
La respuesta está en el método de “delegación de usuario”. Este método está basado en “Azure Managed Identities”. En diagrama se puede representar de la siguiente manera:
Esta solución se explica de la siguiente manera:
- El servicio o aplicación debe tener configurada una “Identidad administrada”, ya sea generada por el sistema o asignada por el usuario (la lógica de elección está para otro post). Con esta identidad, los servicios de Azure se autentican/autorizan entre sí, pero antes, la identidad debe tener asignados los permisos y roles adecuados. Esta figura puede aplicarse a App Services, Container Apps, Azure Functions, entre otros.
- Con esta identidad, el código de la aplicación puede autenticarse sin necesidad de tener almacenada ni en propiedades ni secretos el Account Storage y solicitar claves de delegación y luego, con esta clave, solicitar SAS tokens de delegación de usuario.
- Con estos SAS tokens, el servicio o aplicación puede realizar la operación específica, que puede ser agregar o leer archivos (blobs). Estos tokens SAS deben ser generados con la menor cantidad de permisos que se requiera (privilegio mínimo), y su tiempo de vigencia debe ser el menor posible de acuerdo a la necesidad.
Dejo un repositorio de ejemplo en .NET para poder autenticarse usando la identidad administrada, pedir tanto claves y SAS token de delegación de usuario.
Repositorio de ejemplo - User delegation flow
Conclusión
User delegation flow es un mecanismo seguro para poder gestionar las operaciones en un servicio como Azure Blob Storage; te libra de la necesidad de gestionar secretos, reduciendo así los huecos de seguridad.
Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades