Establecer directiva de inmutabilidad de blobs

La Set Blob Immutability Policy operación establece la directiva de inmutabilidad en un blob. Esta operación no actualiza la ETag del blob. Esta API está disponible a partir de la versión 2020-06-12.

Solicitud

La solicitud Set Blob Immutability Policy se puede construir como sigue. Se recomienda usar HTTPS. Reemplace myaccount por el nombre de la cuenta de almacenamiento y myblob por el nombre del blob para el que se va a cambiar la directiva de inmutabilidad.

Método	URI de solicitud	Versión de HTTP
PUT	https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=immutabilityPolicies	HTTP/1.1

Parámetros del identificador URI

Puedes especificar los siguientes parámetros adicionales en el URI de la solicitud:

Parámetro	Descripción
snapshot	Opcional. El parámetro snapshot es un valor opaco DateTime en el que, cuando está presente, especifica la instantánea de blob en la que establecer un nivel. Para más información sobre cómo trabajar con instantáneas de blob, consulte Create una instantánea de un blob.
versionid	Opcional para la versión 2019-12-12 y posteriores. El versionid parámetro es un valor opaco DateTime en el que, cuando está presente, especifica la versión del blob en la que establecer un nivel.
timeout	Opcional. El parámetro timeout se expresa en segundos. Para más información, consulte Establecimiento de tiempos de espera para las operaciones de Blob Storage.

Encabezados de solicitud

Los encabezados de solicitud obligatorios y opcionales se describen en la tabla siguiente:

Encabezado de solicitud	Descripción
Authorization	Necesario. Especifica el esquema de autorización, el nombre de la cuenta de almacenamiento y la firma. Para obtener más información, vea Autorización de solicitudes a Azure Storage.
Date o x-ms-date	Necesario. Especifica la hora universal coordinada (UTC) de la solicitud. Para obtener más información, vea Autorización de solicitudes a Azure Storage.
x-ms-immutability-policy-until-date	Necesario. Indica la retención hasta la fecha que se va a establecer en el blob. Esta es la fecha hasta la que se puede proteger el blob de que se va a modificar o eliminar. En el caso de la cuenta de blob Storage o de uso general v2, los valores válidos tienen RFC1123 formato. Los tiempos pasados no son válidos.
x-ms-immutability-policy-mode	Opcional. Si no se especifica, el valor predeterminado es Unlocked. Indica el modo de directiva de inmutabilidad que se va a establecer en el blob. En el caso de la cuenta de almacenamiento de blobs o de uso general v2, los valores válidos son Unlocked/Locked. unlocked indica que el usuario puede cambiar la directiva aumentando o disminuyendo la retención hasta la fecha. locked indica que estas acciones están prohibidas.
x-ms-version	Obligatorio para todas las solicitudes autorizadas. Especifica la versión de la operación que se utiliza para esta solicitud. Para obtener más información, vea Versiones de los servicios de Azure Storage.
x-ms-client-request-id	Opcional. Proporciona un valor opaco generado por el cliente con un límite de caracteres de 1 kibibyte (KiB) que se registra en los registros cuando se configura el registro. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes que recibe el servidor. Para obtener más información, vea Supervisar Azure Blob Storage.

Esta operación también admite el uso de encabezados condicionales para establecer el blob solo si se cumple una condición especificada. Para más información, consulte Especificación de encabezados condicionales para las operaciones de Blob Storage.

Cuerpo de la solicitud

Ninguno.

Response

La respuesta incluye un código de estado HTTP y un conjunto de encabezados de respuesta.

status code

Una operación correcta devuelve el código de estado 200 Correcto.

Para obtener información sobre los códigos de estado, vea Códigos de estado y de error.

Encabezados de respuesta

La respuesta de esta operación incluye los encabezados siguientes. La respuesta también puede incluir otros encabezados HTTP estándar. Todos los encabezados estándar se ajustan a la especificación del protocolo HTTP/1.1.

Encabezado de respuesta	Descripción
x-ms-request-id	Identifica de forma única la solicitud que se realizó y se puede usar para solucionar problemas de la solicitud. Para más información, consulte Solución de problemas de operaciones de API.
x-ms-version	Indica la versión de Blob Storage que se usó para ejecutar la solicitud. Se devuelve para las solicitudes realizadas en la versión 2009-09-19 y posteriores.
x-ms-client-request-id	Se puede usar para solucionar problemas de solicitudes y respuestas correspondientes. El valor de este encabezado es igual al valor del x-ms-client-request-id encabezado si está presente en la solicitud y el valor no contiene más de 1024 caracteres ASCII visibles. Si el x-ms-client-request-id encabezado no está presente en la solicitud, no estará presente en la respuesta.
x-ms-immutability-policy-until-date	Indica la fecha de retención hasta que se va a establecer en el blob. Esta es la fecha hasta la que se puede proteger el blob de que se va a modificar o eliminar.
x-ms-immutability-policy-mode	Indica el modo de directiva de inmutabilidad establecido en el blob. Los valores son unlocked y locked. Elunlocked valor indica que el usuario puede cambiar la directiva aumentando o disminuyendo la fecha de retención hasta la fecha, e locked indica que estas acciones están prohibidas.

Authorization

Se requiere autorización al llamar a cualquier operación de acceso a datos en Azure Storage. Puede autorizar la Set Blob Immutability Policy operación como se describe a continuación.

Importante

Microsoft recomienda usar Microsoft Entra ID con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona una mayor seguridad y facilidad de uso en comparación con la autorización de clave compartida.

Microsoft Entra ID (recomendado)

Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos de blobs. Con Microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad. La entidad de seguridad puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada de Azure. La entidad de seguridad se autentica mediante Microsoft Entra ID para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.

Para más información sobre la autorización mediante Microsoft Entra ID, consulte Autorización del acceso a blobs mediante Microsoft Entra ID.

Permisos

A continuación se enumeran las acciones de RBAC necesarias para un usuario, grupo, identidad administrada o entidad de servicio de Microsoft Entra para llamar a la Set Blob Immutability Policy operación y el rol RBAC integrado con privilegios mínimos que incluye esta acción:

• Acción RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/immutableStorage/runAsSuperUser/action
• Rol integrado con privilegios mínimos:Propietario de datos de Blob de Storage

Para más información sobre cómo asignar roles mediante RBAC de Azure, consulte Asignación de un rol de Azure para el acceso a datos de blobs.

Firmas de acceso compartido (SAS)

Una firma de acceso compartido (SAS) proporciona acceso delegado seguro a los recursos de una cuenta de almacenamiento. Con una SAS, tiene un control pormenorizado sobre cómo un cliente puede acceder a los datos. Puede especificar a qué recurso puede acceder el cliente, qué permisos tienen para esos recursos y cuánto tiempo es válido la SAS.

La Set Blob Immutability Policy operación admite tres tipos de firmas de acceso compartido: SAS de delegación de usuarios, SAS de servicio y SAS de cuenta.

Como procedimiento recomendado de seguridad, se recomienda usar Microsoft Entra credenciales en lugar de la clave de la cuenta de almacenamiento, que se puede poner en peligro más fácilmente. Si el diseño de la aplicación requiere firmas de acceso compartido, use Microsoft Entra credenciales para crear una SAS de delegación de usuarios, siempre que sea posible.

Cuando no se permite el acceso a la clave compartida para la cuenta de almacenamiento, no se permitirá un token de SAS de servicio o un token de SAS de cuenta en una solicitud a Blob Storage. Para más información, consulte Descripción de cómo no permitir la clave compartida afecta a los tokens de SAS.

SAS de delegación de usuarios

Una SAS de delegación de usuarios está protegida con credenciales de Microsoft Entra y también por los permisos especificados para la SAS.

La llamada a la Set Blob Immutability Policy operación mediante un token de SAS delegado en un recurso de contenedor o blob requiere el permiso de almacenamiento inmutable (i) como parte del token de SAS de delegación de usuarios.

Para más información sobre la SAS de delegación de usuarios, consulte Create una SAS de delegación de usuarios.

SAS de servicio

Una SAS de servicio está protegida con la clave de cuenta de almacenamiento. Una SAS de servicio delega el acceso a un recurso en un único servicio de Azure Storage, como Blob Storage.

La llamada a la Set Blob Immutability Policy operación mediante un token de SAS delegado en un recurso de contenedor o blob requiere el permiso de almacenamiento inmutable (i) como parte del token de SAS de servicio.

Para más información sobre la SAS de servicio, consulte Create una SAS de servicio.

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.

En la tabla siguiente se indica el tipo de recurso firmado y los permisos firmados que se especificarán al delegar el acceso:

Operación	Servicio firmado	Tipo de recurso firmado	Permiso firmado
Establecimiento de la directiva de inmutabilidad de blobs	Blob (b)	Objeto (o)	Almacenamiento inmutable (i)

Para más información sobre la SAS de cuenta, consulte Create una SAS de cuenta.

Clave compartida

La Set Blob Immutability Policy operación admite la autorización de clave compartida. No se recomienda autorizar con claves de cuenta para la mayoría de los escenarios, ya que es menos seguro.

Microsoft recomienda no permitir la autorización de clave compartida para la cuenta de almacenamiento siempre que sea posible. Para más información, consulte Evitar autorización con clave compartida.

Comentarios

La configuración de la directiva de inmutabilidad del blob en una cuenta de almacenamiento de blobs o de uso general v2 tiene las siguientes restricciones:

• Se permite establecer una directiva de inmutabilidad en una instantánea o una versión a partir de la versión REST 2020-06-12.
• Cuando la directiva de inmutabilidad está en unlocked modo, los usuarios pueden actualizar la retención hasta la fecha. Cuando la directiva de inmutabilidad está en locked modo, los usuarios solo pueden extender la retención hasta la fecha. El modo de directiva de inmutabilidad se puede cambiar de unlocked a locked, pero no de locked a unlocked.
• Cuando hay una directiva de inmutabilidad en un blob y también hay una directiva de inmutabilidad predeterminada en el contenedor o la cuenta, la directiva de inmutabilidad de blobs tiene precedentes.
• En el caso de una directiva de inmutabilidad de nivel de blob, PutBlockList/PutBlob/CopyBlob se permiten las operaciones, ya que estas operaciones generan una nueva versión.
• Cuando la directiva de inmutabilidad está en unlocked modo, los usuarios pueden eliminar la directiva de inmutabilidad mediante la SIGUIENTE API:

Método	URI de solicitud	Versión de HTTP
Delete	https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=immutabilityPolicies	HTTP/1.1

Nota

Para más información, consulte Almacenamiento inmutable.

Facturación

Las solicitudes de precios pueden originarse en clientes que usan API de Blob Storage, ya sea directamente a través de la API REST de Blob Storage o desde una biblioteca cliente de Azure Storage. Estas solicitudes acumulan cargos por transacción. El tipo de transacción afecta a cómo se cobra la cuenta. Por ejemplo, las transacciones de lectura se acumulan en una categoría de facturación diferente a las transacciones de escritura. En la tabla siguiente se muestra la categoría de facturación de Set Blob Immutability Policy las solicitudes basadas en el tipo de cuenta de almacenamiento:

Operación	Tipo de cuenta de almacenamiento	Categoría de facturación
Establecimiento de la directiva de inmutabilidad de blobs	Blobs en bloques Premium De uso general, estándar, v2 De uso general, estándar, v1	Otras operaciones

Para obtener información sobre los precios de la categoría de facturación especificada, consulte precios Azure Blob Storage.

Consulte también

Autorización de solicitudes a Azure Storage
Estado y códigos de error
Códigos de error de Blob Storage
Establecimiento de tiempos de espera para las operaciones de Blob Storage