Otorgar acceso limitado a recursos de Azure Storage con firmas de acceso compartido (SAS)

Artikulua
06/07/2023

Una Firma de acceso compartido (SAS) ofrece acceso delegado seguro a los recursos en la cuenta de almacenamiento. Con una SAS, tiene control granular sobre la forma en que un cliente puede tener acceso a los datos. Por ejemplo:

A qué recursos puede acceder el cliente.
Qué permisos tienen para esos recursos.
Cuánto tiempo es válida la SAS.

Tipos de firmas de acceso compartido

Azure Storage admite tres tipos de firmas de acceso compartido:

SAS de delegación de usuarios
SAS de servicio
SAS de cuenta

Importante

Para escenarios en los que se utilizan firmas de acceso compartido (SAS, por sus siglas en inglés), Microsoft recomienda usar una SAS de delegación de usuarios. Una SAS de delegación de usuarios se protege con credenciales de Microsoft Entra en lugar de la clave de cuenta, lo que proporciona una seguridad superior. Para más información sobre la autorización para el acceso a datos, consulte Autorización del acceso a datos en Azure Storage.

SAS de delegación de usuarios

Una SAS de delegación de usuarios está protegida con credenciales de Microsoft Entra y también con los permisos especificados para la SAS. Una SAS de delegación de usuarios solo se aplica a Blob Storage.

Para más información sobre la SAS de delegación de usuarios, consulte Create a user delegation SAS (REST API) (Creación de una SAS de delegación de usuarios [API REST]).

SAS de servicio

Una SAS de servicio está protegida con la clave de cuenta de almacenamiento. Una SAS de servicio administra el acceso a un recurso en solo uno de los servicios de Azure Storage: Blob Storage, Queue Storage, Table Storage o Azure Files.

Para más información sobre la SAS de servicio, consulte Create a service SAS (REST API) (Creación de una SAS de servicio [API REST]).

SAS de cuenta

Una SAS de cuenta está protegida con la clave de cuenta de almacenamiento. SAS de cuenta delega el acceso a los recursos en uno o varios de los servicios de almacenamiento. Todas las operaciones disponibles con una SAS de servicio o delegación de usuarios están también disponibles con una SAS de cuenta.

También puede delegar el acceso a lo siguiente:

Operaciones de nivel de servicio (por ejemplo, las operaciones Get/Set Service Properties y Get Service Stats).
Operaciones de lectura, escritura y eliminación que no se permiten con una SAS de servicio.

Para obtener más información sobre la SAS de cuenta, consulte Create an account SAS (REST API) (Creación de una SAS de cuenta [API REST]).

Una firma de acceso compartido puede presentar una de las dos formas siguientes:

SAS ad hoc. Cuando se crea una SAS ad hoc, la hora de inicio, la hora de finalización y los permisos se especifican en el URI de la SAS. Cualquier tipo de SAS puede ser una SAS ad-hoc.
SAS de servicio con directiva de acceso almacenada: se define una directiva de acceso almacenada en un contenedor de recursos, que puede ser un contenedor de blobs, tabla, cola o recurso compartido de archivos. Una directiva de acceso almacenada puede usarse para administrar las restricciones de una o varias firmas de acceso compartido de servicio. Cuando se asocia una SAS de servicio a una directiva de acceso almacenada, la SAS hereda las restricciones (hora de inicio, hora de expiración y permisos) definidas para la directiva de acceso almacenada.

Nota:

Una SAS de delegación de usuarios o una SAS de cuenta debe ser una SAS ad-hoc. Las directivas de acceso almacenadas no son compatibles con la SAS de delegación de usuarios ni de cuenta.

Funcionamiento de una firma de acceso compartido

Una firma de acceso compartido es un token que se anexa al URI de un recurso de Azure Storage. Token que contiene un conjunto especial de parámetros de consulta que indican cómo el cliente puede tener acceso a los recursos. Uno de los parámetros de consulta, la firma, se construye a partir de parámetros SAS y se firma con la clave que se usó para crear la SAS. Azure Storage utiliza esta firma para autorizar el acceso al recurso de almacenamiento.

Nota:

No es posible auditar la generación de tokens de SAS. Cualquier usuario que tenga privilegios para generar un token de SAS, ya sea mediante la clave de cuenta o a través de una asignación de roles de Azure, puede hacerlo sin el conocimiento del propietario de la cuenta de almacenamiento. Tenga cuidado al restringir los permisos que permiten a los usuarios generar tokens de SAS. Para evitar que los usuarios generen una SAS firmada con la clave de cuenta para cargas de trabajo de blobs y colas, puede impedir el acceso con clave compartida a la cuenta de almacenamiento. Para más información, consulte Evitar autorización con clave compartida.

Firma y autorización de SAS

Puede firmar un token de SAS con una clave de delegación de usuario o con una clave de cuenta de almacenamiento (clave compartida).

Firma de un token de SAS con una clave de delegación de usuario

Puede firmar un token de SAS con una clave de delegación de usuarios creada con las credenciales de Microsoft Entra. Una SAS de delegación de usuarios está firmada con la clave de delegación de usuarios.

Para obtener la clave y, luego, crear la SAS, una entidad de seguridad de Microsoft Entra debe tener asignado un rol de Azure que incluya la acción Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey. Para más información, vea Creación de SAS de delegación de usuarios (API de REST).

Firma de un token de SAS con una clave de cuenta

Tanto una SAS de servicio como una SAS de cuenta se firman con la clave de cuenta de almacenamiento. Para crear una SAS firmada con la clave de cuenta, una aplicación debe tener acceso a la clave de cuenta.

Cuando una solicitud incluye un token de SAS, esa solicitud se autoriza en función de cómo se firma el token de SAS. La clave de acceso o las credenciales que se usan para crear un token de SAS también se usan en Azure Storage para conceder acceso a un cliente que posea el token de SAS.

En la tabla siguiente se resume cómo se autoriza cada tipo de token de SAS.

Tipo de SAS	Tipo de autorización
SAS de delegación de usuarios (solo para Blob Storage)	Microsoft Entra ID
SAS de servicio	Clave compartida
SAS de cuenta	Clave compartida

Microsoft recomienda el uso de una SAS de delegación de usuario siempre que sea posible para mayor seguridad.

Token de SAS

El token de SAS es una cadena que se genera del lado cliente, por ejemplo, mediante una de las bibliotecas cliente de Azure Storage. Azure Storage no realiza un seguimiento del token de SAS de ninguna manera. Puede crear un número ilimitado de tokens de SAS en el cliente. Después de crear una SAS, puede distribuirla a las aplicaciones cliente que requieran acceso a los recursos de la cuenta de almacenamiento.

Las aplicaciones cliente proporcionan el URI de SAS para Azure Storage como parte de una solicitud. Después, el servicio comprueba la firma y los parámetros de SAS para comprobar su validez. Si el servicio confirma que la firma es válida, la solicitud se autoriza. De lo contrario, la solicitud se rechaza con el código de error 403 (prohibido).

Este es un ejemplo de un identificador URI de SAS de servicio que muestra el identificador URI del recurso, el carácter delimitador ("?") y el token de SAS.

Diagrama que muestra los componentes de un URI de recurso con token SAS.

Nota

El carácter delimitador ("?") de la cadena de consulta no forma parte del token de SAS. Si genera un token de SAS desde el portal, PowerShell, la CLI de Azure o uno de los SDK de Azure Storage, es posible que tenga que anexar el carácter delimitador a la dirección URL del recurso.

¿Cuándo debe usar una firma de acceso compartido?

Use una SAS para proporcionar acceso seguro a los recursos de la cuenta de almacenamiento a cualquier cliente que, de otro modo, no tenga permisos para esos recursos.

Un escenario común en el que es útil una SAS es un servicio en el que los usuarios leen y escriben sus propios datos en la cuenta de almacenamiento. Existen dos patrones de diseño típicos en los escenarios en los que una cuenta de almacenamiento guarda datos de usuario:

Los clientes cargan y descargan datos mediante un servicio de proxy front-end que realiza la autenticación. Este servicio de proxy de front-end permite la validación de reglas de negocio. Sin embargo, para grandes cantidades de datos o transacciones de gran volumen, la creación de un servicio que pueda escalarse para satisfacer la demanda puede ser complicada o costosa.
Un servicio ligero realiza la autenticación del cliente según sea necesario y, luego, genera una SAS. Una vez que la aplicación cliente recibe la SAS, puede acceder directamente a los recursos de la cuenta de almacenamiento. Los permisos de acceso se definen mediante la SAS y para el intervalo permitido por la SAS. La SAS mitiga la necesidad de enrutar todos los datos a través del servicio de proxy front-end.

Muchos servicios reales pueden usar una combinación de estos dos enfoques. Por ejemplo, algunos datos se pueden procesar y validar a través del proxy de front-end. Otros datos se guardan o leen directamente mediante la SAS.

Además, en ciertos escenarios, se requiere una SAS para autorizar el acceso al objeto de origen en las operaciones de copia:

Cuando copia un blob en otro blob que reside en otra cuenta de almacenamiento.

Si lo desea, también puede usar una SAS para autorizar el acceso al blob de destino.
Cuando copia un archivo en otro archivo que reside en otra cuenta de almacenamiento.

Si lo desea, también puede usar una SAS para autorizar el acceso al archivo de destino.
Cuando se copia un blob en un archivo o un archivo en un blob.

Debe usar una SAS incluso si los objetos de origen y destino residen en la misma cuenta de almacenamiento.

Procedimientos recomendados al usar SAS

Cuando use firmas de acceso compartido en sus aplicaciones, debe tener en cuenta dos posibles riesgos:

Si se perdió una SAS, cualquier persona que la consiga puede usarla, lo que puede poner en riesgo su cuenta de almacenamiento.
Si una SAS proporcionada para una aplicación cliente expira y la aplicación no puede recuperar una nueva SAS del servicio, la funcionalidad de la aplicación puede verse afectada.

Las siguientes recomendaciones para el uso de firmas de acceso compartido pueden ayudar a mitigar estos riesgos:

Siempre use HTTPS para crear una SAS o distribuirla. Si se pasa una SAS a través de HTTP y se intercepta, un atacante que realice un ataque intermediario puede leer la SAS. A continuación, puede usar esa SAS de la misma forma en que podría hacerlo el usuario previsto. Esto puede poner en peligro los datos confidenciales o permitir que los datos resulten dañados por el usuario malintencionado.
Use una SAS de delegación de usuarios siempre que sea posible. Una SAS de delegación de usuarios proporciona más seguridad que una SAS de servicio o a una SAS de cuenta. Una SAS de delegación de usuarios está protegida con credenciales de Microsoft Entra, por lo que no es necesario almacenar la clave de cuenta con el código.
Tenga un plan de revocación en vigor para una SAS. Asegúrese de que está preparado para responder si una SAS está en peligro.
Configure una directiva de expiración de SAS para la cuenta de almacenamiento. Una directiva de expiración de SAS especifica un intervalo recomendado durante el cual la firma SAS es válida. Las directivas de expiración de SAS se aplican a una firma SAS de servicio o de cuenta. Cuando un usuario genera una SAS de servicio o una SAS de cuenta con un intervalo de validez mayor que el intervalo recomendado, se muestra una advertencia. Si está habilitada la elaboración de registros de Azure Storage con Azure Monitor, se escribe una entrada en los registros de Azure Storage. Para obtener más información, vea Creación de una directiva de expiración para firmas de acceso compartido.
Creación de una directiva de acceso almacenada para un servicio SAS. Las directivas de acceso almacenadas le ofrecen la posibilidad de revocar permisos para una SAS de servicio sin tener que volver a generar las claves de cuenta de almacenamiento. Establezca su expiración en un futuro muy lejano (o infinito) y asegúrese de que se actualiza regularmente para trasladarla a un punto posterior en el tiempo. Hay un límite de cinco directivas de acceso almacenadas por contenedor.
Use horas de expiración a corto plazo en una SAS ad-hoc, SAS de servicio o SAS de cuenta. De esta manera, incluso si una SAS está en peligro, es válida solo durante un breve período. Esta práctica es especialmente 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.
Haga que los clientes renueven automáticamente la SAS si fuese necesario. Los clientes deben renovar la SAS correctamente antes de la expiración para que exista tiempo para los reintentos si el servicio que ofrece la SAS no está disponible. Esto puede ser innecesario en algunos casos. Por ejemplo, puede que desee usar la SAS para un pequeño número de operaciones inmediatas de corta duración. Se espera que estas operaciones se completen dentro del período de expiración. Como resultado, no espera que la SAS se renueve. Sin embargo, si dispone de un cliente que realice solicitudes de forma rutinaria a través de la SAS, existe la posibilidad de la expiración.
Tenga cuidado con la hora de inicio de la SAS. Si establece la hora de inicio de una SAS en la hora actual, pueden producirse errores intermitentes durante los primeros minutos. Esto se debe a que diferentes equipos tienen horas actuales ligeramente diferentes (lo que se conoce como sesgo del reloj). En general, establezca la hora de inicio sea al menos 15 minutos en el pasado. O, no establezca esta opción en absoluto, lo que hará que sea válido inmediatamente en todos los casos. Normalmente se aplica lo mismo a la hora de expiración. Recuerde que debe tener en cuenta hasta 15 minutos de desplazamiento del reloj en cualquier dirección en una solicitud. Para los clientes con una versión 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 producirá un error en las directivas que especifican un período más largo de 1 hora.
Tenga cuidado con el formato de fecha y hora de SAS. Para algunas utilidades (como AzCopy), los valores de fecha y hora deben tener el formato "+%Y-%m-%dT%H:%M:%SZ". Este formato incluye específicamente los segundos.
Conceda los privilegios mínimos posibles con SAS. Un procedimiento recomendado de seguridad consiste en proporcionar los privilegios mínimos necesarios a los menos usuarios posible. Utilice una firma de acceso compartido de solo lectura cuando sea posible. Si un usuario solo necesita acceso de lectura a un solo objeto, concédale acceso de lectura a ese único objeto y no acceso de lectura, escritura o eliminación a todos los objetos. Esto también ayuda a reducir los daños si se pone en peligro una SAS porque la SAS tiene menor menos poder en manos de un atacante.

No hay ninguna manera directa de identificar qué clientes han accedido a un recurso. Sin embargo, puedes usar los campos únicos en el SAS, los campos de IP firmada (sip), inicio firmado (st) y expiración firmada (se), para rastrear el acceso. Por ejemplo, puede generar un token de SAS con un tiempo de expiración único que, a continuación, puede correlacionar con el cliente al que se emitió.
Comprenda que se le hará un cargo en la cuenta por cualquier uso, incluido el realizado con la SAS. Si proporciona acceso de escritura a un blob, el usuario puede seleccionar cargar un blob de 200 GB. Si le proporciona también acceso de lectura, puede seleccionar descargarlo 10 veces, lo que le supone 2 TB de costos de salida. Proporcione de nuevo permisos limitados para ayudar a mitigar acciones potenciales de usuarios malintencionados. Use una SAS de corta duración para reducir esa amenaza (pero tenga en cuenta el desplazamiento del reloj y la hora final).
Valide los datos escritos mediante una SAS. Cuando una aplicación cliente escribe datos en la cuenta de almacenamiento, tenga en cuenta que pueden existir problemas con esos datos. Si tiene previsto validar datos, realice esa validación una vez escritos los datos y antes de que la aplicación los use. 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.
Sepa cuándo no usar una SAS. En 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. Por ejemplo, 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.
Use registros de Azure Monitor y Azure Storage para supervisar la aplicación. Pueden producirse errores de autorización debido a una interrupción en el servicio del proveedor de SAS. También se pueden producir a partir de una eliminación accidental de una directiva de acceso almacenada. Puede usar Azure Monitor y el registro de Storage Analytics para observar cualquier pico en estos tipos de errores de autorización. Para obtener más información, consulte Métricas de Azure Storage en Azure Monitor y Registro de Azure Storage Analytics.
Configure una directiva de expiración de SAS para la cuenta de almacenamiento. Los procedimientos recomendados sugieren limitar el intervalo de una SAS en caso de que se vea comprometida. Al establecer una directiva de expiración de SAS para las cuentas de almacenamiento, puede proporcionar un límite de expiración superior recomendado cuando un usuario crea una firma SAS de servicio o de cuenta. Para más información, consulte Creación de una directiva de expiración para las firmas de acceso compartido.

Nota:

El almacenamiento no realiza un seguimiento del número de firmas de acceso compartido que se han generado para una cuenta de almacenamiento y ninguna API puede proporcionar estos detalles. Si necesita conocer el número de firmas de acceso compartido que se han generado para una cuenta de almacenamiento, debe realizar un seguimiento manual del número.