Creación de firmas de acceso compartido

  • 5 minutos

Una firma de acceso compartido (SAS) es un identificador uniforme de recursos (URI) que concede derechos de acceso restringidos a los recursos de Azure Storage. Una SAS es una forma segura de compartir los recursos de almacenamiento sin poner en peligro las claves de cuenta.

Puede proporcionar una SAS a los clientes que no deben tener acceso a la clave de la cuenta de almacenamiento. Mediante la distribución de un URI de SAS entre estos clientes, les concede acceso a un recurso durante un período de tiempo específico. UnaSAS normalmente se usaría para un servicio en el que los usuarios leyeran y escribieran sus datos en la cuenta de almacenamiento.

  • Una delegación SAS de usuario está protegida con las credenciales de Microsoft Entra y por los permisos especificados para la SAS. Se admite una SAS de delegación de usuarios para Blob Storage y Data Lake Storage,

  • Una SAS de nivel de cuenta para permitir el acceso a todo lo que una SAS de nivel de servicio pueda permitir, además de otros recursos y capacidades. Por ejemplo, puede usar una SAS de nivel de cuenta para permitir la creación de sistemas de archivos.

  • Una SAS de nivel de servicio para permitir el acceso a recursos específicos de una cuenta de almacenamiento. Este tipo de SAS se usaría, por ejemplo, para permitir que una aplicación recuperara una lista de archivos de un sistema de archivos o para descargar un archivo.

  • Una directiva de acceso almacenada puede proporcionar otro nivel de control cuando se utiliza una SAS de nivel de servicio en el lado servidor. Puede agrupar SAS y proporcionar otras restricciones mediante una directiva de acceso almacenada.

Recomendaciones para administrar riesgos

Echemos un vistazo a algunas recomendaciones que pueden ayudar a mitigar los riesgos al trabajar con una SAS.

Recomendación Descripción
Uso siempre de HTTPS para la creación y distribución Si se pasa una SAS a través de HTTP, un atacante podría interceptarla y usarla. Estos ataques de tipo Man in the middle pueden poner en peligro los datos confidenciales o permitir que un usuario malintencionado dañe los datos.
Haga referencia a las directivas de acceso almacenadas cuando sea posible. Las directivas de acceso almacenadas le ofrecen la posibilidad de revocar permisos sin tener que volver a generar las claves de cuenta de almacenamiento. Establezca una fecha de expiración futura para la clave de la cuenta de almacenamiento.
Establecer tiempos de expiración a corto plazo para una SAS no planeada Si una SAS está en peligro, puede mitigar los ataques limitando la validez de SAS a un breve tiempo. Este procedimiento es importante si no puede hacer referencia a una directiva de acceso almacenada. Las expiraciones a corto plazo también limitan la cantidad de datos que puede escribirse en un blob mediante la limitación del tiempo disponible para cargarlos.
Requerir que los clientes renueven automáticamente la SAS. Requiera a los clientes que renueven la SAS antes de la fecha de expiración. Al renovar anticipadamente, da margen para diversos reintentos si el servicio que proporciona la SAS no está disponible.
Planear cuidadosamente la hora de inicio de SAS Si establece la hora de inicio de la SAS en ahora, pueden producirse errores intermitentes durante los primeros minutos debido al sesgo del reloj (diferencias en la hora actual según las distintas máquinas). En general, establezca la hora de inicio sea al menos 15 minutos en el pasado. O bien, no establezca una hora de inicio específica, lo que hace que la SAS sea válida inmediatamente en todos los casos. Las mismas condiciones se aplican generalmente a la hora de expiración. Puede observar hasta 15 minutos de sesgo del reloj en cualquier dirección de cualquier solicitud. Para los clientes con una versión API REST anterior a 2012-02-12, la duración máxima de una SAS que no hace referencia a una directiva de acceso almacenada es de 1 hora. Se produce un error en las directivas que especifican un período más largo.
Definir los permisos de acceso de los recursos Un procedimiento recomendado de seguridad es proporcionar al usuario los privilegios mínimos necesarios. Si un usuario solo necesita acceso de lectura en una única entidad, concédale acceso de lectura a esa única entidad y no acceso de lectura, escritura o eliminación a todas las entidades. Esta práctica también ayuda a reducir los daños si se pone en peligro una SAS porque esta tiene menos poder en manos de un atacante.
Validar los datos escritos mediante una SAS Cuando una aplicación cliente escribe datos en la cuenta de almacenamiento de Azure, tenga en cuenta que pueden existir problemas con esos datos. Si la aplicación requiere datos validados o autorizados, valide los datos después de escribirlos, pero antes de usarlos. Esta práctica también le protege frente a los datos erróneos o malintencionados que se escriben en la cuenta, ya sea mediante un usuario que adquirió correctamente la SAS o un usuario que aproveche una SAS errónea.
No dar por sentado que una SAS siempre será la opción correcta En algunas ocasiones, los riesgos asociados a una operación determinada en la cuenta de almacenamiento superan las ventajas del uso de una SAS. Para esas operaciones, cree un servicio de nivel medio que escriba en la cuenta de almacenamiento después de llevar a cabo una auditoría, autenticación o validación de la regla de negocio. A veces también es más sencillo administrar el acceso de otras formas. Si desea que todos los blobs de un contenedor puedan leerse públicamente, puede hacer que el contenedor sea público en lugar de proporcionar un SAS a cada cliente para obtener acceso.