Unidad 5.2: Object Storage

Introducción

Object Storage es el respaldo de la arquitectura de datos. Es donde las exportaciones de registros de auditoría de la Unidad 2.3 aterrizan para su vida a largo plazo, con evidencia de manipulación, donde los volcados de bases de datos y Backup Service llegan a REST, donde los conjuntos de datos de ML y los artefactos de compilación se encuentran, y donde se acumulan las letras muertas de transmisión de eventos. Obtiene esta posición porque es duradero, compatible con S3 y tiene un precio para grandes cantidades. Las dos decisiones que lo hacen o lo rompen, sin embargo, se toman una vez y no se pueden deshacer: el tipo de cubo y la región, y si el bloqueo de objeto está activado. Esta unidad trata esas decisiones primero, luego crea el cubo en el Data Center Designer con los bloqueos y las reglas de ciclo de vida que convierten el almacenamiento bruto en un nivel de retención conforme.

1. Qué es Object Storage y los roles que desempeña

IONOS Cloud Object Storage se adhiere al protocolo S3 API de AWS (versión 2 del protocolo S3), por lo que las mismas herramientas, SDK y aplicaciones que se dirigen a plataformas compatibles con S3 funcionan con él. Los datos viven en un espacio de nombres plano: objetos (cada uno con metadatos y una clave única) dentro de cubos, sin un árbol de directorios real debajo. La autenticación se realiza mediante un par de Clave de acceso y Clave secreta generada por usuario (92 y 64 caracteres en el formato actual, hasta 5 claves por usuario); el DCD utiliza estas credenciales para impulsar la interfaz web, y el mismo par es lo que cualquier cliente S3 o SDK presenta. Un objeto único puede tener hasta 5 TiB, y la única clase de almacenamiento es STANDARD. El precio es pago por uso en almacenamiento y transferencia saliente por gigabyte sin cargo por solicitud, lo que explica por qué las cargas de trabajo de bulk y archivo aterrizan aquí en lugar de en Block Storage.

Estas propiedades deciden dónde se ajusta Object Storage en la arquitectura de FinCorp:

• Archivo de auditoría. Los Activity Logs son por contrato, de solo lectura y se conservan durante solo 35 días (Unidad 2.3). Exportarlos a un cubo antes de que se cierre esa ventana da a FinCorp la retención de varios años, con evidencia de manipulación, que esperan sus reguladores. El bloqueo de objeto (Sección 2) es lo que hace que ese archivo sea con evidencia de manipulación.
• Objetivo de copia de seguridad. Los Backup Service y la salida de volcado y restauración de base de datos (Unidades 5.3, 5.7) se escriben aquí. Tenga en cuenta el límite honesto: el alcance de Backup Service (Acronis) es máquinas virtuales y Block Storage, no respalda bases de datos gestionadas y no proporciona copias de seguridad inmutables por sí mismo. El bloqueo de objeto en el cubo de destino es cómo FinCorp agrega la inmutabilidad que Backup Service no proporciona.
• Almacén de conjuntos de datos y artefactos. El nivel de inteligencia artificial (Módulo 6) lee su corpus de entrenamiento y almacena artefactos de modelo aquí; un corpus de generación aumentada de recuperación construido por el cliente también vive en Object Storage. El espacio de nombres plano es adecuado para grandes volúmenes de datos no estructurados fuera de una base de datos.
• Destino de carta muerta. El Kafka gestionado (Unidad 5.6) escribe su archivo y cola de carta muerta a un cubo, donde los registros no procesados se acumulan baratos para una inspección posterior.

Los casos de uso documentados de la plataforma también incluyen almacenamiento de activos web, alojamiento de sitios web estáticos, alojamiento de activos multimedia y almacenamiento de archivos privados; para FinCorp, la copia de seguridad/restauración y el almacenamiento de datos no estructurados son los usos principales.

2. Las dos decisiones irreversibles: tipo de cubo, región y bloqueo de objeto

2.1 El tipo de cubo y la región están vinculados en el momento de la creación

Un cubo es de tipo propiedad del contrato o propiedad del usuario, y el tipo también restringe qué regiones están disponibles. Esto cambia la propiedad, la visibilidad y qué puntos de conexión sirven el cubo.

• Los cubos de propiedad del contrato hacen que el propietario del contrato sea el dueño de cada cubo. Cada usuario en el contrato puede ver la lista completa de cubos, y el propietario del contrato o un administrador otorga acceso y define permisos a través de la configuración de la política del cubo. Este es el modelo adecuado para una sola organización como FinCorp que desea una gobernanza centralizada.
• Los cubos de propiedad del usuario son propiedad de cada usuario de manera independiente, quien los crea y gestiona sin la aprobación del propietario del contrato, sin una lista combinada entre usuarios. Esto precede a los cubos de propiedad del contrato y se adapta a casos en los que los usuarios son entidades separadas.

La selección de la región está restringida por el tipo. Las dos tablas a continuación son las listas de regiones autorizadas por tipo de cubo.

Los cubos de propiedad del contrato solo se pueden crear en las siguientes regiones:

Los cubos de propiedad del usuario solo se pueden crear en las siguientes regiones:

Cada región tiene su propia URL de punto de conexión, y un nombre de cubo debe ser únicamente global en todo Object Storage (3 a 63 caracteres). La región es importante para la proximidad (latencia y costo de salida cerca de la aplicación o los usuarios) y para la redundancia (una copia de seguridad o archivo debe estar en una región geográficamente separada de la principal para que sobreviva a una interrupción local). Para FinCorp bajo GDPR y BSI, esta es la decisión de residencia de la Unidad 1.4 aplicada en la práctica: mantener el archivo de auditoría y las copias de seguridad de la base de datos en centros de datos alemanes (de, eu-central-3 o eu-central-4) en lugar de us-central-1. El servicio S3 Object Storage está cubierto por la acreditación de tipo 1 de BSI C5 (otorgada el 2023-11-07, centros de datos alemanes) y el certificado ISO 27001 basado en IT-Grundschutz (otorgado el 2022-09-14); colocar el archivo en una región alemana es lo que lo mantiene dentro de ese alcance. La durabilidad entre regiones se logra a través de la replicación que usted diseña, no como una propiedad automática de un cubo.

2.2 Bloqueo de objeto y ciclo de vida: evidencia de manipulación y control de costos

Bloqueo de objeto implementa Write Once Read Many (WORM): un objeto no se puede borrar o modificar durante un período de retención. Tiene dos modos:

• El modo GOBERNANZA protege los objetos de la eliminación ordinaria, mientras que aún permite que los usuarios privilegiados anulen el bloqueo.
• El modo CUMPLIMIENTO es absoluto: hasta que pasa la fecha de retención, el objeto es inmutable, el modo no se puede deshabilitar y el período de retención no se puede acortar, ni siquiera por el propietario del cubo. Este es el modo para el archivo regulatorio de FinCorp, donde el requisito es que nadie, incluido un administrador, pueda manipular la evidencia.

La retención se puede configurar hasta 365 días a través de DCD; API admite hasta 100 años. La restricción decisiva es la temporización: el bloqueo de objeto solo se puede habilitar cuando se crea el cubo, nunca se puede agregar después. Habilitarlo también activa la versión y, una vez habilitado, ninguno de los dos se puede deshabilitar. Un límite de composición importa: un cubo con el bloqueo de objeto habilitado no puede ser una fuente para la replicación o la jerarquía, aunque puede ser un destino. Si FinCorp necesita tanto un archivo bloqueado como una replicación saliente desde los mismos datos, la replicación debe originarse desde un cubo desbloqueado y apuntar al bloqueado.

Las reglas de ciclo de vida abordan el costo. Una configuración puede contener hasta 1,000 reglas, cada una con un alcance para todos los objetos o para un prefijo único (una regla por prefijo). Las acciones son: expirar las versiones actuales después de un número de días o en una fecha; eliminar permanentemente las versiones no actuales; eliminar los marcadores de eliminación de objetos expirados; y eliminar las cargas de subida de partes incompletas. Dado que solo hay una clase de almacenamiento STANDARD, el ciclo de vida no puede transitar objetos a un nivel más barato; aquí es una herramienta de expiración y limpieza, no una herramienta de jerarquía. Se empareja naturalmente con el bloqueo de objeto: el bloqueo COMPLIANCE garantiza que los datos sobreviven al menos el período de retención, mientras que una regla de expiración del ciclo de vida garantiza que no persisten y acumulan costos una vez que caduca la obligación. Establezca la expiración en o más allá del período de retención del bloqueo para que los dos nunca entren en conflicto.

3. DCD Implementación paso a paso

Usted creará el archivo de auditoría y copia de seguridad de FinCorp: un cubo propiedad de un contrato en una región alemana, con Object Lock habilitado en modo COMPLIANCE en el momento de la creación, y una regla de ciclo de vida que caduca los objetos una vez que ha transcurrido su obligación de retención. Esto realiza el nivel de retención que muestra la integridad y que dependen la exportación de auditoría de la Unidad 2.3 y las copias de seguridad de la Unidad 5.7.

Objetivo de creación: Crear un cubo, establecer el bloqueo de objetos y una política de ciclo de vida.

Requisitos previos: Un usuario con el privilegio de usar Object Storage (otorgado a través de la membresía en un grupo, Unidad 2.2), y una clave Object Storage generada para ese usuario. La primera generación de claves también es lo que muestra la ID de usuario canónica necesaria para otorgar acceso entre usuarios más adelante.

Pasos (en el Data Center Designer):

1. Abra la sección Object Storage del DCD y vaya a la pestaña Cubos. Elija crear un cubo propiedad de un usuario o un contrato; para el archivo de FinCorp, cree un cubo propiedad de un contrato para que la gobernanza permanezca con el propietario del contrato.
2. Introduzca un nombre de cubo único a nivel global (3 a 63 caracteres) y seleccione la región. Para el archivo de FinCorp, elija una región alemana dentro del conjunto permitido del tipo de cubo (para un cubo propiedad de un contrato, eu-central-4 Frankfurt o eu-central-3 Berlin), manteniendo el archivo dentro del C5 y el alcance de IT-Grundschutz.
3. Active Object Lock durante este paso de creación. Esta es la única oportunidad para activarlo; no se puede agregar después, y activarlo también activa la versión. Cree el cubo.
4. Después de la creación, abra el cubo, haga clic en Configuración del cubo y vaya a la configuración de Object Lock en la sección Administración de datos. Establezca el modo en COMPLIANCE y el período de retención en el horizonte regulatorio (hasta 365 días a través del DCD). Estos valores predeterminados se aplican a los objetos cargados recientemente; los objetos ya presentes siguen los valores aplicados en el momento de la creación.
5. Todavía en Configuración del cubo, vaya a la configuración de ciclo de vida en Administración de datos y haga clic en Agregar una regla.
6. Asigne un nombre único a la regla de ciclo de vida y establezca su alcance: todos los objetos o objetos limitados a un prefijo único (cada prefijo solo puede llevar una regla).
7. Seleccione las acciones de ciclo de vida. Para el archivo, elija Caducar las versiones actuales después de un número de días que cumpla o supere la retención del bloqueo, y agregue Eliminar permanentemente las versiones no actuales y Eliminar cargas de subida de partes incompletas para controlar el costo de la versión y las cargas de subida fallidas. Guarde la regla.
8. Verifique en la lista de cubos que el cubo muestra el tipo correcto, la región y la fecha de creación, y confirme que las configuraciones de Object Lock y ciclo de vida están presentes en Configuración del cubo.

Errores comunes:

• Olvidar Object Lock en el momento de la creación. No se puede habilitar en un cubo existente. Si lo olvida, debe crear un nuevo cubo y migrar los datos. Decida sobre WORM antes de hacer clic en Crear.
• Elegir el modo COMPLIANCE sin certeza. En el modo COMPLIANCE, no se puede acortar la retención ni deshabilitar el bloqueo, incluso como propietario del cubo. Use GOVERNANCE mientras prueba y reserve COMPLIANCE para los datos cuya obligación de retención es firme.
• Elegir la región incorrecta para la residencia. La región está fija en el momento de la creación y dicta el punto de conexión. Una región de EE. UU. (us-central-1) coloca el archivo de auditoría de una empresa alemana fuera del alcance del centro de datos alemán de las credenciales BSI. Decida la residencia antes de nombrar el cubo.
• Suponer que un nombre de cubo no único funcionará. Los nombres son únicos a nivel global en todos los Object Storage, no solo en su contrato. Asígnelos con un espacio de nombres (por ejemplo, prefijándolos con la organización) para evitar colisiones.
• Esperar que el ciclo de vida se transfiera a un almacenamiento más barato. Solo existe la clase ESTÁNDAR, por lo que las reglas de ciclo de vida caducan y limpian; no mueven objetos a un nivel más frío. El control de costos proviene de la eliminación, no del nivel.
• Conectar la replicación fuera de un cubo bloqueado. Un cubo con Object Lock habilitado no puede ser una fuente de replicación o nivelación. Si necesita replicación, origínela desde un cubo desbloqueado y haga que el archivo bloqueado sea el destino.

Un equivalente corto del cliente S3 hace que la naturaleza de la creación del Object Lock sea concreta; la marca se establece en create-bucket y no tiene un homólogo para agregar más adelante:

aws s3api create-bucket \
  --bucket fincorp-audit-archive \
  --object-lock-enabled-for-bucket \
  --region=eu-central-4 --create-bucket-configuration LocationConstraint=eu-central-4 \
  --endpoint-url https://s3.eu-central-4.ionoscloud.com

Resumen

Object Storage es la arquitectura de almacenamiento duradero, compatible con S3, y con precios por bulk: archivo de auditoría, objetivo de copia de seguridad, almacenamiento de conjuntos de datos y artefactos, y cola de cartas muertas. Su poder como nivel de cumplimiento normativo proviene de dos decisiones tomadas una vez durante la creación, el tipo de cubo con su restricción de región, y el bloqueo de objetos, y de las reglas de ciclo de vida superpuestas en la parte superior para el control de costes. Obtenga el tipo, región y bloqueo correctos durante la creación, porque ninguno de ellos puede ser cambiado después.

Puntos clave:

• Object Storage utiliza el S3 de AWS API (v2), un espacio de nombres plano de objetos y cubos, y autenticación con Clave de acceso y Clave secreta (92 y 64 caracteres; hasta 5 claves por usuario); los objetos pueden alcanzar 5 TiB y la única clase es STANDARD.
• El tipo de cubo (de propiedad del contrato vs de propiedad del usuario) está vinculado durante la creación y restringe las regiones disponibles; la propiedad del contrato es adecuada para la gobernanza centralizada, y los nombres de los cubos son únicos a nivel global.
• El bloqueo de objetos ofrece WORM en modo GOBERNANZA o CUMPLIMIENTO, debe estar habilitado durante la creación (no se puede agregar más tarde), también habilita la versión y en modo CUMPLIMIENTO es irreversible; la retención de DCD es de hasta 365 días, la de API es de hasta 100 años.
• Las reglas de ciclo de vida (hasta 1.000, con alcance para todos los objetos o un prefijo) expiran y limpian los objetos para el control de costes, pero no pueden pasar a una clase más barata, ya que solo existe la clase STANDARD.
• Coloque el archivo de auditoría y copia de seguridad de FinCorp en una región alemana con bloqueo de objetos en modo CUMPLIMIENTO para mantenerlo a prueba de manipulaciones y dentro del alcance del servicio BSI C5 y IT-Grundschutz.

Terminología importante:

• Bloqueo de objetos (WORM): Retención de Escritura una vez, Lectura muchas veces aplicada a los objetos; GOBERNANZA permite anular con privilegios, CUMPLIMIENTO es inmutable hasta la fecha de retención y no se puede acortar o deshabilitar.
• Regla de ciclo de vida: Una acción automatizada (expirar versiones actuales, eliminar versiones no actuales, eliminar marcadores de eliminación expirados, eliminar subidas de multipartes incompletas) con alcance para un cubo o un prefijo de objeto único.
• Cubo de propiedad del contrato vs cubo de propiedad del usuario: El modelo de propiedad y visibilidad, fijo durante la creación, que también determina qué regiones y puntos de conexión están disponibles.

Lectura adicional

• Unidad 2.3, Activity Logs y el registro de auditoría (el plazo de exportación de 35 días que satisface este archivo).
• Unidad 5.7, Protección de datos y ciclo de vida (componiendo copia de seguridad, instantáneas, PITR y archivo de Object-Storage en un plano de continuidad).
• Unidad 5.1, Almacenamiento en bloque y de archivos (cuando el almacenamiento de archivos compartidos regional o un bloque de VM individual se adapta mejor que el objeto).