Almacenar datos de blobs críticos para la empresa con almacenamiento inmutable en un estado de escribir una vez, leer muchas (WORM)
El almacenamiento inmutable de Azure Blob Storage permite a los usuarios almacenar los datos críticos para la empresa en un estado WORM (escribir una vez, leer muchas). Mientras se encuentren en un estado WORM, los datos no se podrán modificar ni eliminar durante el tiempo especificado por el usuario. Con la configuración de directivas de inmutabilidad para los datos de blobs, puede impedir que sus datos se sobrescriban y eliminen.
El almacenamiento inmutable para Azure Blob Storage admite dos tipos de directivas de inmutabilidad:
Directivas de retención con duración definida: Con una directiva de retención con duración definida, los usuarios pueden establecer directivas para almacenar datos durante un intervalo especificado. Cuando se establece una directiva de retención con duración definida, se pueden crear y leer objetos, pero no se pueden modificar ni eliminar. Una vez transcurrido el período de retención, los objetos se pueden eliminar, pero no sobrescribir.
Directivas de suspensión legal: Una suspensión legal almacena datos inmutables hasta que la suspensión se borra explícitamente. Cuando se establece una suspensión legal, los objetos se pueden crear y leer, pero no modificar ni eliminar.
Estas directivas se pueden establecer al mismo tiempo que otras. Por ejemplo, un usuario puede tener una directiva de retención basada en el tiempo y una suspensión legal establecida en el mismo nivel y al mismo tiempo. Para que una escritura se realice correctamente, debe tener habilitado el control de versiones o no tener ninguna directiva de suspensión legal ni de retención basada en el tiempo en los datos. Para que una eliminación se realice correctamente, no debe haber una directiva de suspensión legal ni una directiva de retención basada en el tiempo en los datos.
En el diagrama siguiente se muestra cómo las directivas de retención basadas en el tiempo y la conservación por razones legales evitan las operaciones de escritura y eliminación mientras están en vigor.
Hay dos características bajo el paraguas de almacenamiento inmutable: WORM de nivel de contenedor y WORM de nivel de versión. WORM de nivel de contenedor permite establecer directivas solo en el nivel de contenedor, mientras que WORM de nivel de versión permite establecer directivas en el nivel de cuenta, contenedor o versión.
Acerca del almacenamiento inmutable de blobs
El almacenamiento inmutable ayuda a las organizaciones sanitarias, las instituciones financieras y las industrias relacionadas (sobre todo las organizaciones de intermediación comercial) a almacenar los datos de forma segura. El almacenamiento inmutable puede usarse en cualquier escenario para proteger datos críticos e impedir que se eliminen o modifiquen.
Las aplicaciones típicas son:
Cumplimiento de reglamentaciones: el almacenamiento inmutable para Azure Blob Storage ayuda a las organizaciones a cumplir SEC 17a-4(f), CFTC 1.31(d), FINRA y otras regulaciones.
Protección de la retención de documentos: El almacenamiento inmutable de blobs garantiza que ningún usuario pueda modificar ni eliminar datos, ni siquiera los usuarios que tienen privilegios administrativos en la cuenta.
Suspensión legal: El almacenamiento inmutable de blobs permite a los usuarios almacenar información confidencial crítica para procedimientos judiciales o uso empresarial en un estado a prueba de manipulación durante el tiempo deseado hasta que se elimina la suspensión. Esta característica no se limita solo a los casos de uso legales, sino que también puede considerarse una suspensión basada en eventos o un bloqueo de la empresa, donde es necesario proteger los datos en función de desencadenadores de eventos o directivas corporativas.
Cumplimiento de normativas
Microsoft ha usado una de las principales empresas de valoración independiente especializada en la administración de registros y la gobernanza de la información, Cohasset Associates. Dicha empresa se ha encargado de evaluar el almacenamiento inmutable de blobs y el cumplimiento con los requisitos específicos del sector de servicios financieros. Cohasset ha validado que el almacenamiento inmutable, cuando se ha usado para conservar los blobs en un estado WORM, cumplía los requisitos de almacenamiento pertinentes de las reglas CFTC 1.31(c)-(d), FINRA 4511 y SEC 17a-4(f). Microsoft se centró en este conjunto de reglas, ya que representan la guía más prescriptiva globalmente para la retención de registros en las instituciones financieras.
El informe de Cohasset está disponible en el Centro de confianza de servicios de Microsoft. El Centro de confianza de Azure contiene información detallada sobre las certificaciones de cumplimiento de Microsoft. Para solicitar una carta de certificación de Microsoft con respecto al cumplimiento de inmutabilidad de WORM, póngase en contacto con el Soporte técnico de Azure.
Directivas de retención con duración definida
Una directiva de retención basada en el tiempo almacena datos de blob en un formato WORM para un intervalo especificado. Cuando se establece una directiva de retención con duración definida, los clientes pueden crear y leer blobs, pero no pueden modificarlos ni eliminarlos. Una vez transcurrido el intervalo de retención, los blobs se pueden eliminar pero no sobrescribir.
Ámbito
Se puede configurar una directiva de retención basada en el tiempo en cualquiera de los ámbitos siguientes:
- Directiva WORM de nivel de versión: se puede configurar una directiva de retención basada en el tiempo en el nivel de cuenta, contenedor o versión. Si está configurada en el nivel de cuenta o contenedor, todos los blobs de la cuenta o contenedor correspondientes la heredarán. Si hay una suspensión legal en un contenedor, no se puede crear WORM de nivel de versión para el mismo contenedor. Esto se debe a que las versiones no se pueden generar debido a la suspensión legal.
- Directiva WORM de nivel de contenedor: una directiva de retención basada en el tiempo que está configurada en el nivel de contenedor se aplica a todos los blobs de ese contenedor. Los blobs individuales no se pueden configurar con sus propias directivas de inmutabilidad.
Intervalo de retención para una directiva con duración definida
El intervalo de retención mínimo para una directiva de retención con duración definida es de un día y el máximo es de 146 000 días (400 años). Cuando configure una directiva de retención basada en el tiempo, los objetos afectados permanecen en el estado inmutable durante el período de retención efectivo. El período de retención efectivo para los objetos es igual a la diferencia entre la hora de creación del blob y el intervalo de retención especificado por el usuario. Debido a que se puede ampliar el intervalo de retención de una directiva, el almacenamiento inmutable usa el valor más reciente del intervalo de retención especificado por el usuario para calcular el período de retención efectivo.
Por ejemplo, supongamos que un usuario crea una directiva de retención de duración definida con un intervalo de retención de cinco años. Un blob existente en ese contenedor, testblob1, se ha creado hace un año; por tanto, el período de retención efectivo para testblob1 es de cuatro años. Cuando se carga un nuevo blob, testblob2, en el contenedor, el período de retención efectivo de testblob2 es de cinco años a partir de su creación.
Comparación de directivas bloqueadas y desbloqueadas
Cuando se configura por primera vez una directiva de retención con duración definida, la directiva está desbloqueada con fines de prueba. Cuando termine de realizar las pruebas, puede bloquear la directiva para que sea totalmente compatible con SEC 17a-4(f) y otro tipo de cumplimiento normativo.
Tanto las directivas bloqueadas como las desbloqueadas protegen contra eliminaciones y sobrescrituras. Sin embargo, puede acortar o ampliar el período de retención para modificar una directiva desbloqueada. Las directivas desbloqueadas también se pueden eliminar. No es posible eliminar una directiva de retención con duración definida que esté bloqueada. Puede ampliar el período de retención, pero no puede acortarlo. Puede aumentar hasta cinco veces el período de retención efectivo durante la vigencia de una directiva bloqueada que esté definida en el nivel de contenedor. En el caso de una directiva configurada para una versión de blob, no hay ningún límite en el número de aumentos del período efectivo.
Importante
Una directiva de retención con duración definida debe estar bloqueada para que el blob esté en estado inmutable (protegido frente a escritura y eliminación) y, por consiguiente, se cumplan SEC 17a-4(f) y otras regulaciones. Microsoft recomienda bloquear la directiva en un período razonable, normalmente antes de 24 horas. Si bien el estado desbloqueado proporciona protección de inmutabilidad, no se recomienda utilizarlo para otros fines que no sean las pruebas a corto plazo.
Registro de auditoría de directivas de retención
Cada contenedor con una directiva de retención con duración definida habilitada proporciona un registro de auditoría de directivas. El registro de auditoría incluye hasta siete comandos de retención con duración definida para directivas de retención con duración definida bloqueadas. El registro se suele iniciar una vez que se ha bloqueado la directiva. Las entradas de registro incluyen el identificador de usuario, el tipo de comando, las marcas de tiempo y el intervalo de retención. El registro de auditoría se conserva mientras durante la vigencia de la directiva, de acuerdo con las directrices de cumplimiento SEC 17a-4(f).
El registro de actividad de Azure ofrece un registro más completo de todas las actividades del servicio de administración. Los registros de recursos de Azure conservan información sobre las operaciones de datos. Es responsabilidad del usuario almacenar dichos registros de forma persistente, ya que podrían ser obligatorios por ley o con otros fines.
No se auditan los cambios en las directivas de retención con duración definida en el nivel de versión.
Retenciones legales
Una suspensión legal es una directiva de inmutabilidad temporal que se puede aplicar con fines de investigación jurídica o con directivas de protección generales. Una suspensión legal almacena los datos de blob en un formato WORM (escribir una vez, leer muchas) hasta que la suspensión se borra explícitamente. Cuando hay en vigor una suspensión legal, los blobs se pueden crear y leer, pero no modificar ni eliminar. Use una suspensión legal cuando se desconozca el período de tiempo durante el cual los datos deben mantenerse en un estado WORM.
Ámbito
Una directiva de suspensión legal se puede configurar en cualquiera de los ámbitos siguientes:
Directiva WORM de nivel de versión: se puede configurar una suspensión legal en un nivel de versión de blob individual para la administración pormenorizada de datos confidenciales.
Directiva WORM de nivel de contenedor: se aplica una suspensión legal configurada a nivel de contenedor a todos los blobs de ese contenedor. Los blobs individuales no se pueden configurar con sus propias directivas de inmutabilidad.
Etiquetas
Una suspensión legal a nivel de contenedor debe estar asociada a una o varias etiquetas alfanuméricas definidas por el usuario que sirven como cadenas de identificador. Por ejemplo, una etiqueta puede incluir un identificador de caso o un nombre de evento.
Registro de auditoría
Cada contenedor con una suspensión legal en vigor proporciona un registro de auditoría de directivas. El registro contiene el Id. de usuario, el tipo de comando, las marcas de tiempo y las etiquetas de suspensión legal. El registro de auditoría se conserva mientras durante la vigencia de la directiva, de acuerdo con las directrices de cumplimiento SEC 17a-4(f).
El registro de actividad de Azure ofrece un registro más completo de todas las actividades del servicio de administración. Los registros de recursos de Azure conservan información sobre las operaciones de datos. Es responsabilidad del usuario almacenar dichos registros de forma persistente, ya que podrían ser obligatorios por ley o con otros fines.
Los cambios en las suspensiones legales en el nivel de versión no se auditan.
Opciones de características de almacenamiento inmutable
En la tabla siguiente se muestra un desglose de las diferencias entre WORM de nivel de contenedor y WORM de nivel de versión:
| Category | WORM de nivel de contenedor | WORM de nivel de versión |
|---|---|---|
| Nivel de granularidad de la directiva | Las directivas solo se pueden configurar en el nivel de contenedor. Cada objeto que se carga en el contenedor hereda el conjunto de directivas inmutable. | Las directivas se pueden configurar en el nivel de cuenta, contenedor o blob. Si una directiva se establece en el nivel de cuenta, todos los blobs que se cargan en esa cuenta heredan la directiva. Se sigue la misma lógica con los contenedores. Si una directiva se establece en varios niveles, el orden de prioridad siempre es Blob -> Contenedor -> Cuenta. |
| Tipos de directivas disponibles | Se pueden establecer dos tipos diferentes de directivas en el nivel de contenedor: directivas de retención basadas en el tiempo y suspensiones legales. | En el nivel de cuenta y contenedor, solo se pueden establecer directivas de retención basadas en el tiempo. En el nivel de blob, se pueden establecer directivas de retención basadas en el tiempo y suspensiones legales. |
| Dependencias de características | Ninguna otra característica es un requisito previo o requisito para que esta característica funcione. | El control de versiones es un requisito previo para que se pueda usar esta característica. |
| Habilitación para cuentas o contenedores existentes | Esta característica se puede habilitar en cualquier momento para los contenedores existentes. | En función del nivel de granularidad, es posible que esta característica no esté habilitada para todas las cuentas o contenedores existentes. |
| Eliminación de una cuenta o contenedor | Una vez que una directiva de retención basada en el tiempo está bloqueada en un contenedor, los contenedores solo se pueden eliminar si están vacíos. | Una vez que WORM de nivel de versión está habilitado en un nivel de cuenta o contenedor, solo se pueden eliminar si están vacíos. |
| Compatibilidad con Azure Data Lake Storage (cuentas de almacenamiento que tienen habilitado un espacio de nombres jerárquico) | Las directivas WORM de nivel de contenedor se admiten en cuentas que tienen un espacio de nombres jerárquico. | Las directivas WORM de nivel de versión aún no se admiten en las cuentas que tienen un espacio de nombres jerárquico. |
Para obtener más información sobre WORM de nivel de contenedor, consulte Directivas WORM de nivel de contenedor. Para obtener más información sobre WORM de nivel de versión, visite Directivas WORM de nivel de versión.
WORM de nivel de contenedor frente a WORM de nivel de versión
La tabla siguiente le ayuda a decidir qué tipo de directiva WORM se va a usar.
| Criterios | Uso de WORM de nivel de contenedor | Uso de WORM de nivel de versión |
|---|---|---|
| Organización de datos | Quiere establecer directivas para conjuntos de datos específicos, que se pueden clasificar por contenedor. Todos los datos de ese contenedor deben conservarse en un estado WORM durante la misma cantidad de tiempo. | No se pueden agrupar los objetos por períodos de retención. Todos los blobs deben almacenarse con un tiempo de retención individual basado en los escenarios de ese blob, o bien el usuario tiene una carga de trabajo mixta para que algunos grupos de datos se puedan agrupar en contenedores, mientras que otros blobs no. También puede establecer directivas de nivel de contenedor y directivas de nivel de blob dentro de la misma cuenta. |
| Cantidad de datos que requieren una directiva inmutable | No es necesario establecer directivas en más de 10 000 contenedores por cuenta. | Quiere establecer directivas en todos los datos o grandes cantidades de datos que se pueden delimitar por cuenta. Sabe que si usa WORM de nivel de contenedor, tendrá que superar el límite de 10 000 contenedores. |
| Interés en habilitar el control de versiones | No quiere tratar con la habilitación del control de versiones debido al costo o porque la carga de trabajo crearía numerosas versiones adicionales con las que tratar. | Querrá usar el control de versiones o no se molestará en usarlo. Sabe que si no se habilita el control de versiones, no podrá conservar las modificaciones ni sobrescribir en blobs inmutables como versiones independientes. |
| Ubicación de almacenamiento (Blob Storage frente a Data Lake Storage) | La carga de trabajo se centra completamente en Azure Data Lake Storage. No tiene ningún interés inmediato ni tiene previsto cambiar al uso de una cuenta que no tenga habilitada la característica de espacio de nombres jerárquico. | La carga de trabajo se encuentra en Blob Storage en una cuenta que no tiene habilitada la característica de espacio de nombres jerárquico y ahora puede usar WORM de nivel de versión o está dispuesto a esperar a que el control de versiones esté disponible para las cuentas que tienen habilitado un espacio de nombres jerárquico (Azure Data Lake Storage). |
Niveles de acceso
Todos los niveles de acceso a blobs admiten almacenamiento inmutable. Puede cambiar el nivel de acceso de un blob con la operación Set Blob Tier. Para obtener más información, consulte Niveles de acceso para los datos del blob.
Configuraciones de redundancia
Todas las configuraciones de redundancia admiten almacenamiento inmutable. Para obtener más información sobre la configuración de redundancia, consulte la Redundancia de Azure Storage.
Tipos de blob recomendados
Microsoft recomienda configurar directivas de inmutabilidad principalmente para blobs en bloques y blobs en anexos. No se recomienda configurar una directiva de inmutabilidad para un blob en páginas que almacene un disco VHD para una máquina virtual activa, ya que se bloquearán las escrituras en el disco o, si el control de versiones está habilitado, cada escritura se almacena como una nueva versión. Microsoft recomienda revisar exhaustivamente la documentación y probar los escenarios antes de bloquear las directivas de duración definida.
Almacenamiento inmutable con eliminación temporal de blobs
Cuando se configura la eliminación temporal de blobs para una cuenta de almacenamiento, se aplica a todos los blobs dentro de la cuenta, independientemente de si hay en vigor una suspensión legal o una directiva de retención con duración definida. Microsoft recomienda habilitar la eliminación temporal para lograr una protección adicional antes de aplicar las directivas de inmutabilidad.
Si habilita la eliminación temporal de blobs y, a continuación, configura una directiva de inmutabilidad, los blobs que ya se hayan eliminado temporalmente se eliminarán de manera permanente una vez que la directiva de retención de eliminación temporal haya expirado. Los blobs eliminados temporalmente se pueden restaurar durante el período de retención de eliminación temporal. Un blob o una versión que aún no se han eliminado temporalmente están protegidos por la directiva de inmutabilidad, y no se pueden eliminar temporalmente hasta que la directiva de retención basada en el tiempo haya expirado o se haya quitado la suspensión legal.
Uso del inventario de blobs para hacer un seguimiento de las directivas de inmutabilidad
El inventario de blobs de Azure Storage brinda información general de los contenedores en las cuentas de almacenamiento, y los blobs, las instantáneas y las versiones de blob dentro de ellas. Puede usar el informe de inventario de blobs para comprender los atributos de blobs y contenedores, incluido si un recurso tiene configurada una directiva de inmutabilidad.
Al habilitar el inventario de blobs, Azure Storage genera un informe de inventario a diario. El informe proporciona información general de los datos para los requisitos empresariales y de cumplimiento.
Para más información sobre el inventario de blobs, consulte Inventario de blobs de Azure Storage.
Nota:
No se puede configurar una directiva de inventario en una cuenta si la compatibilidad con la inmutabilidad de nivel de versión está habilitada en esa cuenta o si la compatibilidad con la inmutabilidad de nivel de versión está habilitada en el contenedor de destino definido en la directiva de inventario.
Configuración de directivas a escala
Puede usar una tarea de almacenamiento para configurar directivas de inmutabilidad a escala en varias cuentas de almacenamiento en función de un conjunto de condiciones que defina. Una tarea de almacenamiento es un recurso disponible en Acciones de almacenamiento de Azure; un marco sin servidor que puede usar para realizar operaciones de datos comunes en millones de objetos en varias cuentas de almacenamiento. Para más información, consulte ¿Qué es Acciones de almacenamiento de Azure?
Precios
No hay ningún cargo de capacidad adicional por el uso del almacenamiento inmutable. El precio de los datos inmutables es el mismo que el de los datos mutables. Si usa WORM de nivel de versión, es posible que la factura sea mayor porque ha habilitado el control de versiones y hay un costo asociado a las versiones adicionales que se almacenan. Revise la directiva de precios de control de versiones para obtener más información. Para información detallada sobre los precios de Azure Blob Storage, consulte la página de precios de Azure Storage.
La creación, modificación o eliminación de una directiva de retención con duración definida o una suspensión legal en una versión de blob generan un cargo por transacciones de escritura.
Si no paga la factura y su cuenta tiene en vigor una directiva de retención basada en el tiempo activa, las directivas de retención de datos normales se aplican según lo previsto en los términos y condiciones del contrato con Microsoft. Para obtener información general, consulte Administración de datos en Microsoft.
Compatibilidad de características
Esta característica es incompatible con la restauración puntual y el seguimiento del último acceso. Esta característica es compatible con la conmutación por error no planeada administrada por el cliente; sin embargo, los cambios realizados en la directiva inmutable después de la última hora de sincronización (por ejemplo, bloquear una directiva de retención basada en tiempo, extenderla, etcetera) no se sincronizarán con la región secundaria. Una vez completada la conmutación por error, puede volver a realizar los cambios en la región secundaria para asegurarse de que está actualizada con sus requisitos de inmutabilidad. Las directivas de inmutabilidad no se admiten en las cuentas que tienen habilitado el protocolo Network File System (NFS) 3.0 o el protocolo de transferencia de archivos SSH (SFTP).
Algunas cargas de trabajo, como Copia de seguridad de SQL a URL, cree un y agréguela. Si un contenedor tiene una directiva de retención basada en el tiempo activa o hay en vigor una suspensión legal, este patrón no funcionará. Para más información, consulte Permitir escrituras de blob en anexos protegidos.
Para obtener más información, consulte Compatibilidad con características de Blob Storage en cuentas de Azure Storage.
Pasos siguientes
- Información general sobre la protección de datos
- Directivas WORM de nivel de contenedor para datos de blobs inmutables
- Directivas WORM de nivel de versión para datos de blobs inmutables
- Configuración de directivas de inmutabilidad para versiones de blobs
- Configuración de directivas de inmutabilidad para contenedores