Unidad 2.3: Activity Logs y la pista de auditoría

Introducción

Para una empresa sujeta a regulación, la pista de auditoría no es una comodidad operativa; es evidencia, y la evidencia debe superar cualquier ventana de 35 días y debe ser resistente a la manipulación. El IONOS CLOUD Activity Log es deliberadamente limitado: indica quién hizo qué dentro de un contrato, no puede ser alterado y solo conserva 35 días. Esas restricciones no son deficiencias de las que quejarse; definen el diseño. La arquitectura de auditoría que satisface a un revisor de BSI o RGPD se construye en torno al registro, no dentro de él, tratando su ventana de retención como un plazo de exportación a un almacenamiento inmutable. Esta unidad establece la forma exacta del registro y, a continuación, el patrón de retención externa que FinCorp debe adoptar.

1. La forma fija del registro de actividad

El registro de actividad permite a los propietarios de contratos y a los administradores ver el historial de las acciones realizadas en los recursos dentro de un contrato único: inicios de sesión de usuarios, aprovisionamiento de recursos, cambios de configuración, acceso a datos, recuperaciones de recursos, modificaciones y eliminaciones. Cuatro propiedades fijan su forma y determinan cada decisión posterior.

Por contrato. El registro tiene un alcance limitado a un contrato y se consulta por contrato, contra el punto de acceso https://api.ionos.com/activitylog/v1/contracts/{contractNumber}. No existe una vista entre contratos; una organización distribuida en varios contratos tiene varios registros independientes.
Solo lectura. El registro es de solo lectura por diseño. Nadie puede editar ni eliminar las entradas, lo que hace que el registro en vivo sea confiable como registro a corto plazo, pero también significa que el propio registro no es el lugar donde se realiza la retención a largo plazo con validez legal.
Retención de 35 días. Las entradas se conservan durante 35 días; los datos con más de 35 días se eliminan. La ventana no es configurable hacia arriba, por lo que cualquier cosa que necesite más allá de 35 días debe salir del registro antes de que expire.
API solo GET. Cada llamada a la API del registro de actividad es un GET. No hay POST, PUT o DELETE: no se puede escribir en él, no se puede modificar y, lo que es importante, no se puede solicitar que emita eventos hacia usted. La recuperación es solo de extracción, utilizando autenticación básica o un token Bearer, con filtros de rango de fechas (startDate, endDate) y paginación por límite y desplazamiento. El acceso está gobernado por el derecho de capacidad Access Activity Log descrito en la Unidad 2.2.

La combinación es toda la historia: un registro confiable pero de vida corta, solo de extracción y de un solo contrato. Es excelente como fuente de verdad y no es adecuado, por sí solo, como sistema de registro.

2. Diseño de la agregación y retención externas

Dado que la plataforma no ofrece agregación entre contratos ni entrega por empuje, ambas capacidades son responsabilidad del cliente, y el patrón nativo se compone en torno al registro, sin esperar más de él.

La agregación es un diseño de extracción y convergencia. Un trabajo programado (ejecutado bajo un usuario de servicio con ámbito definido, con el derecho de Access Activity Log y un token de API de vida corta, según la Unidad 2.2) llama al punto final GET de cada contrato con una frecuencia que se mantenga cómodamente dentro de la ventana de 35 días, y luego reenvía los registros a un destino central: un archivo de Object Storage, y típicamente, a un SIEM externo para correlacionar entre contratos y con fuentes no pertenecientes a IONOS CLOUD. La plataforma nunca iniciará esta transferencia, por lo que la programación es el mecanismo de control; si el trabajo se detiene, la evidencia envejece silenciosamente y expira a los 35 días, sin ninguna alerta por parte del propio registro.

La retención a largo plazo es un diseño de exportación antes de la expiración. La recomendación documentada es descargar los datos del Activity Log y almacenarlos en un almacenamiento diferente, siendo IONOS Cloud Object Storage el destino explícitamente recomendado. Para hacer que ese archivo sea defendible, el cubo de destino utiliza Object Lock, que aplica protección WORM (write-once-read-many) para que los objetos no puedan ser eliminados ni modificados durante un período de retención especificado; la activación de Object Lock habilita automáticamente la versionado del cubo, y el modo Compliance impide que el período de retención se acorte o que el objeto se sobrescriba durante ese período. El resultado es un archivo con evidencia de manipulación cuya inmutabilidad es aplicada por la capa de almacenamiento, compensando el hecho de que el registro en vivo solo conserva 35 días. Object Lock debe habilitarse en la creación del cubo (no puede agregarse a un cubo existente ni deshabilitarse posteriormente), por lo que el cubo de archivo se diseña desde el inicio, no se adapta a posteriori.

Para FinCorp, esto convierte la cifra de 35 días en un plazo operativo en lugar de una política de retención. Un trabajo de exportación diario extrae el registro de cada contrato hacia un cubo de Object Storage en una región alemana, creado con Object Lock en modo Compliance, configurado con el período de retención que los reguladores de FinCorp exigen (a menudo, años). El registro en vivo sigue siendo la vista de trabajo; el cubo bloqueado es el sistema de registro. Si FinCorp dividiera su cartera entre contratos, el mismo trabajo simplemente iteraría más números de contrato, ya que la agregación siempre iba a ser externa de todos modos.

Resumen de la decisión

Diseñe la bitácora de auditoría como una fuente de vida corta que alimente un archivo externo inmutable.

Requisito de auditoría	Lo que le proporciona la Activity Log	El diseño que debe agregar
Quién hizo qué, recientemente, en un solo contrato	Bitácora de solo lectura por contrato, retención de 35 días	Úsela directamente como la vista en vivo; otorgue acceso a Access Activity Log de forma restringida
Retención por más de 35 días	Nada; los datos con más de 35 días se eliminan	Exportación programada a Object Storage antes de la expiración; trate los 35 días como un plazo límite
Evidencia a largo plazo con detección de manipulación	Bitácora en vivo de solo lectura, pero solo por 35 días	Object Lock (WORM, modo Compliance) en el bucket de archivo, habilitado en la creación
Auditoría entre contratos o correlacionada	Sin vista entre contratos, solo GET, sin empuje	Extraiga cada contrato y convérjalo en un SIEM externo; la programación es el control

Resumen

El Activity Log es por contrato, de solo lectura, se conserva durante 35 días y se expone a través de una API de solo GET y solo extracción, lo que lo convierte en una fuente confiable a corto plazo, pero nunca en un sistema de registro a largo plazo. La agregación entre contratos y cualquier correlación son diseños externos, ya que la plataforma no ofrece una vista entre contratos ni envío por empuje. La retención a largo plazo, con evidencia de manipulación, se logra exportando antes de la purga de 35 días a un cubo de Object Storage creado con Object Lock, de modo que la ventana se convierte en un plazo límite de exportación en lugar de un límite de retención.

Puntos clave:

El Activity Log es por contrato, de solo lectura, se conserva durante 35 días y es de solo GET; los datos con más de 35 días se purgan y la ventana no es extensible.
No hay agregación entre contratos ni entrega por empuje; ambas son construidas por el cliente como una extracción programada y consolidación, a menudo hacia un SIEM externo.
La retención a largo plazo es una exportación a Object Storage con Object Lock (WORM); el modo Compliance hace que el archivo sea inmutable, y Object Lock debe habilitarse en la creación del cubo.
Considere los 35 días como un plazo límite de exportación estricto: si la tarea de exportación se detiene, la evidencia caduca sin ninguna alerta del registro.

Terminología importante: