Unidad 5.2: Object Storage

Introducción

Object Storage es el último recurso de la arquitectura de datos. Es el lugar donde las exportaciones de registros de auditoría de la Unidad 2.3 se almacenan para su vida a largo plazo, con evidencia de manipulación, donde se asientan las copias de seguridad de Backup Service y las volcadas de bases de datos, donde se encuentran los conjuntos de datos de aprendizaje automático y los artefactos de compilación, y donde se acumulan las cartas muertas de la transmisión de eventos. Esta posición se debe a que es duradero, compatible con S3 y tiene un precio adecuado para el almacenamiento masivo. Sin embargo, las dos decisiones que determinan su éxito o fracaso se toman una sola vez y no pueden revertirse: el tipo y la región del cubo, y si Object Lock está activado. Esta unidad aborda esas decisiones primero y, a continuación, crea el cubo en Data Center Designer con los bloqueos y las reglas de ciclo de vida que convierten el almacenamiento crudo en un nivel de retención conforme.

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

IONOS Cloud Object Storage se adhiere a la API de AWS S3 (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 se encuentran en un espacio de nombres plano: objetos (cada uno con metadatos y una clave única) dentro de cubetas, sin un árbol de directorios real en su interior. La autenticación se realiza mediante un par de Access Key y Secret Key generado por usuario (92 y 64 caracteres en el formato actual, hasta 5 claves por usuario); el DCD utiliza estas credenciales para operar la interfaz web, y el mismo par es lo que presenta cualquier cliente o SDK de S3. Un objeto individual puede tener hasta 5 TiB, y la única clase de almacenamiento es STANDARD. La facturación es de pago por uso en almacenamiento y transferencia saliente por gigabyte, sin cargo por solicitud, razón por la cual las cargas de trabajo masivas y de archivo se ubican aquí en lugar de en Block Storage.

Estas propiedades determinan dónde encaja Object Storage en la arquitectura de FinCorp:

• Archivo de auditoría. Activity Logs son por contrato, de solo lectura y se conservan durante solo 35 días (Unidad 2.3). Exportarlos a una cubeta antes de que se cierre ese período otorga a FinCorp la retención a varios años y con evidencia de manipulación que sus reguladores esperan. Object Lock (Sección 2) es lo que hace que ese archivo tenga evidencia de manipulación.
• Destino de copia de seguridad. Backup Service y la salida de volcado/restauración de bases de datos (Unidades 5.3, 5.7) escriben aquí. Observe el límite honesto: el alcance de Backup Service (Acronis) son las VM y Block Storage, no realiza copias de seguridad de bases de datos administradas, y no proporciona copias de seguridad inmutables por sí mismo. Object Lock en la cubeta de destino es cómo FinCorp añade la inmutabilidad que Backup Service no ofrece.
• Almacén de conjuntos de datos y artefactos. La capa de IA (Módulo 6) lee su corpus de entrenamiento y almacena artefactos de modelos aquí; un corpus de generación aumentada por recuperación construido por un cliente también se encuentra 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 mensajes no procesados. Kafka administrado (Unidad 5.6) escribe su archivo y cola de mensajes no procesados en una cubeta, donde los registros no procesados se acumulan de forma económica para una inspección posterior.

Los casos de uso documentados de la plataforma también incluyen el almacenamiento de activos de sitios web, la hospedaje de sitios web estáticos, la hospedaje de activos multimedia y el almacenamiento privado de archivos; 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 bucket, región y Object Lock

2.1 El tipo de bucket y la región quedan vinculados en el momento de la creación

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

• Los buckets de contrato hacen que el propietario del contrato sea el propietario de cada bucket. Cada usuario del contrato puede ver la lista completa de buckets, y el propietario del contrato o un administrador otorga el acceso y define los permisos a través de la configuración de Bucket Policy. Este es el modelo adecuado para una única organización como FinCorp que desea una gobernanza centralizada.
• Los buckets de usuario son propiedad independiente de cada usuario, quien los crea y gestiona sin la aprobación del propietario del contrato, y no existe una lista combinada entre usuarios. Este modelo precede a los buckets de contrato y se adapta a casos en los que los usuarios son entidades separadas.

La selección de región está restringida por el tipo. Las dos tablas siguientes son las listas autoritativas de regiones por tipo de bucket.

Los buckets de contrato solo pueden crearse en las siguientes regiones:

Los buckets de usuario solo pueden crearse en las siguientes regiones:

Cada región tiene su propia URL de punto de acceso, y el nombre de un bucket debe ser único a nivel global en todo Object Storage (de 3 a 63 caracteres). La región es importante por cercanía (latencia y costo de salida cerca de la aplicación o de los usuarios) y por redundancia (una copia de seguridad o archivo debe ubicarse en una región geográficamente separada de la principal para que sobreviva a una interrupción local). Para FinCorp bajo el RGPD y el 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 tanto por la atestación BSI C5 Tipo 1 (otorgada el 2023-11-07, centros de datos alemanes) como por 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 mediante una replicación que usted diseña, no es una propiedad automática de un solo bucket.

2.2 Object Lock y ciclo de vida: evidencia de manipulación y control de costos

Object Lock implementa Write Once Read Many (WORM): un objeto no puede borrarse ni modificarse durante un período de retención. Tiene dos modos:

• El modo GOVERNANCE protege los objetos de la eliminación ordinaria, pero aún permite a usuarios con privilegios anular el bloqueo.
• El modo COMPLIANCE es absoluto: hasta que pase la fecha de retención, el objeto es inmutable, el modo no puede desactivarse y el período de retención no puede acortarse, ni siquiera por el propietario del bucket. 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 puede configurarse hasta 365 días a través de DCD; la API admite hasta 100 años. La restricción decisiva es el momento: Object Lock solo puede activarse cuando se crea el bucket, nunca puede agregarse después. Activarlo también activa la versionado, y una vez activado, ninguno de los dos puede desactivarse. Un límite de composición es importante: un bucket con Object Lock activado no puede ser una fuente para replicación o escalonamiento, 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 en un bucket sin bloqueo y dirigirse al bloqueado.

Las reglas de ciclo de vida abordan el costo. Una configuración puede contener hasta 1.000 reglas, cada una con alcance para todos los objetos o para un único prefijo (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 marcadores de eliminación de objetos expirados; y eliminar cargas multipart incompletas. Dado que la única clase de almacenamiento es STANDARD, el ciclo de vida no puede transicionar objetos a un nivel más barato; aquí es una herramienta de expiración y limpieza, no una herramienta de escalonamiento. Se combina de forma natural con Object Lock: el bloqueo COMPLIANCE garantiza que los datos sobrevivan al menos el período de retención, mientras que una regla de expiración del ciclo de vida garantiza que no permanezcan y acumulen costos una vez que la obligación caduca. Establezca la expiración en o después de la retención del bloqueo para que ambos no entren en conflicto.

3. Recorrido de implementación de DCD

Creará el archivo de auditoría y copia de seguridad de FinCorp: un bucket propiedad del 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 expira los objetos una vez que ha transcurrido su obligación de retención. Esto materializa la capa de retención con evidencia de manipulación en la 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 construcción: Crear un bucket, configurar object lock y una política de ciclo de vida.

Requisitos previos: Un usuario con el privilegio Use Object Storage (concedido mediante membresía de grupo, Unidad 2.2) y una clave de Object Storage generada para ese usuario. La primera generación de clave también es lo que permite obtener el Canonical User ID necesario para conceder acceso entre usuarios más adelante.

Pasos (en el Data Center Designer):

1. Abra la sección de Object Storage del DCD y vaya a la pestaña Buckets. Elija crear un bucket propiedad de un usuario o un bucket propiedad del contrato; para el archivo de FinCorp, cree un bucket propiedad del contrato para que la gobernanza permanezca con el propietario del contrato.
2. Introduzca un nombre de bucket globalmente único (de 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 bucket (para un bucket propiedad del contrato, eu-central-4 Frankfurt o eu-central-3 Berlin), manteniendo el archivo dentro del alcance de C5 e IT-Grundschutz.
3. Habilite Object Lock durante este paso de creación. Esta es la única oportunidad para habilitarlo; no se puede agregar después, y habilitarlo también habilita la versionado. Cree el bucket.
4. Después de la creación, abra el bucket, haga clic en Bucket settings y vaya a la configuración de Object Lock bajo la sección Data management. 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 recién cargados; los objetos ya presentes siguen las configuraciones aplicadas en la creación.
5. Aún en Bucket settings, vaya a la configuración de Lifecycle bajo Data management y haga clic en Add a rule.
6. Asigne un nombre único a la regla de ciclo de vida y establezca su alcance: todos los objetos, o objetos limitados a un único prefijo (cada prefijo solo puede tener una regla).
7. Seleccione las acciones de ciclo de vida. Para el archivo, elija Expire current versions after a number of days que cumpla o supere la retención del bloqueo, y agregue Permanently delete noncurrent versions y Delete incomplete multipart uploads para controlar el costo derivado del versionado y las cargas fallidas. Guarde la regla.
8. Verifique en la lista de Buckets que el bucket muestre el tipo, la región y la fecha de creación correctos, y confirme que las configuraciones de Object Lock y de ciclo de vida están presentes bajo Bucket settings.

Errores comunes:

• Olvidar Object Lock en la creación. No se puede habilitar en un bucket existente. Si lo omite, debe crear un nuevo bucket y migrar los datos. Decida sobre WORM antes de hacer clic en Create.
• Elegir el modo COMPLIANCE sin certeza. En el modo COMPLIANCE no puede acortar la retención ni deshabilitar el bloqueo, incluso como propietario del bucket. Use GOVERNANCE durante las pruebas y reserve COMPLIANCE para datos cuyo requisito de retención sea firme.
• Elegir la región incorrecta para la residencia. La región es fija en la creación y determina el endpoint. Una región de EE. UU. (us-central-1) sitúa el archivo de auditoría de una empresa alemana fuera del alcance de centro de datos alemán de las credenciales de BSI. Decida la residencia antes de nombrar el bucket.
• Suponer que un nombre de bucket no único funcionará. Los nombres son globalmente únicos en todo Object Storage, no solo en su contrato. Use espacios de nombres (por ejemplo, prefije con la organización) para evitar colisiones.
• Esperar que el ciclo de vida jerarquice hacia un almacenamiento más barato. Solo existe la clase STANDARD, por lo que las reglas de ciclo de vida expiran y limpian; no mueven objetos a una capa más fría. El control de costos proviene de la eliminación, no de la jerarquización.
• Configurar la réplica desde un bucket bloqueado. Un bucket con Object Lock habilitado no puede ser una fuente de réplica o jerarquización. Si necesita réplica, inicie la operación desde un bucket sin bloqueo y haga que el archivo bloqueado sea el destino.

Un equivalente breve de cliente S3 hace concreta la naturaleza exclusiva de la creación de Object Lock; la bandera se establece en create-bucket y no tiene un equivalente para agregarla después:

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 el respaldo duradero, compatible con S3 y con precios por volumen de la arquitectura: archivo de auditoría, destino de copia de seguridad, almacén de conjuntos de datos y artefactos, y cola de mensajes no procesados. Su valor como nivel de cumplimiento normativo proviene de dos decisiones tomadas una sola vez al momento de la creación: el tipo de bucket con su restricción de región, y Object Lock, y de las reglas de ciclo de vida superpuestas para el control de costos. Defina correctamente el tipo, la región y el bloqueo al momento de la creación, ya que ninguno de ellos puede modificarse posteriormente.

Puntos clave:

• Object Storage utiliza la API de AWS S3 (v2), un espacio de nombres plano de objetos y buckets, y autenticación mediante Access Key y Secret Key (92 y 64 caracteres; hasta 5 claves por usuario); los objetos pueden alcanzar 5 TiB y la única clase disponible es STANDARD.
• El tipo de bucket (propiedad del contrato o propiedad del usuario) se fija en el momento de la creación y limita las regiones disponibles; el tipo de propiedad del contrato es adecuado para la gobernanza centralizada, y los nombres de bucket son únicos a nivel global.
• Object Lock proporciona WORM en modo GOVERNANCE o COMPLIANCE, debe activarse en el momento de la creación (no puede agregarse posteriormente), también habilita la versionado, y en modo COMPLIANCE es irreversible; la retención de DCD es de hasta 365 días, mientras que la API permite hasta 100 años.
• Las reglas de ciclo de vida (hasta 1.000, aplicables a todos los objetos o a un prefijo específico) vencen y limpian objetos para el control de costos, pero no pueden migrar a una clase más económica, ya que solo existe STANDARD.
• Coloque el archivo de auditoría y copia de seguridad de FinCorp en una región alemana con Object Lock en modo COMPLIANCE para mantenerlo con evidencia de manipulación y dentro del alcance de servicio de BSI C5 e IT-Grundschutz.

Terminología importante:

• Object Lock (WORM): Retención de tipo Write Once Read Many aplicada a objetos; GOVERNANCE permite la anulación por parte de usuarios con privilegios, mientras que COMPLIANCE es inmutable hasta la fecha de retención y no puede acortarse ni desactivarse.
• Regla de ciclo de vida: Una acción automatizada (vencer versiones actuales, eliminar versiones no actuales, eliminar marcadores de eliminación vencidos, eliminar cargas multipart incompletas) aplicada a un bucket o a un prefijo de objeto específico.
• Bucket de propiedad del contrato vs. bucket de propiedad del usuario: El modelo de propiedad y visibilidad, fijo en el momento de la creación, que también determina qué regiones y puntos de acceso están disponibles.

Lectura adicional

• Unidad 2.3, Activity Logs y la ruta de auditoría (el plazo de exportación de 35 días que cumple este archivo).
• Unidad 5.7, Protección de datos y ciclo de vida (componer la copia de seguridad, las instantáneas, PITR y el archivo de Object-Storage en un solo plano de continuidad).
• Unidad 5.1, Almacenamiento de bloques y archivos (cuando el archivo compartido regional o el almacenamiento de bloques de una sola VM encaja mejor que el almacenamiento de objetos).