Unidad 2.3: Activity Logs y el registro de auditoría

Introducción

Para una empresa regulada, el registro de auditoría no es una comodidad operativa; es una prueba, y la prueba tiene que sobrevivir a cualquier ventana de 35 días y tiene que ser resistente a la manipulación. El Registro de Actividad de IONOS es intencionalmente estrecho: le dice quién hizo qué dentro de un contrato, no puede ser alterado y solo mantiene 35 días. Esas limitaciones no son brechas de las que quejarse; definen el diseño. La arquitectura de auditoría que satisface a un revisor de BSI o GDPR se construye alrededor del registro, no dentro de él, tratando su ventana de retención como una fecha límite de exportación a un almacenamiento inmutable. Esta unidad describe la forma exacta del registro y luego el patrón de retención externa que FinCorp debe adoptar.

1. La forma fija del Registro de Actividades

El Registro de Actividades permite a los propietarios de contratos y administradores ver el historial de acciones realizadas en recursos dentro de un contrato único: inicio de sesión de usuarios, aprovisionamiento de recursos, cambios de configuración, acceso a datos, recuperación de recursos, modificaciones y eliminaciones. Cuatro propiedades fijan su forma y dirigen cada decisión descendente.

Por contrato. El registro está limitado a un contrato y se consulta por contrato, contra el punto de conexión https://api.ionos.com/activitylog/v1/contracts/{contractNumber}. No hay una vista entre contratos; una organización extendida en varios contratos tiene varios registros independientes.
De solo lectura. El registro está diseñado para ser de solo lectura. Las entradas no pueden ser editadas ni eliminadas por nadie, lo que hace que el registro en vivo sea confiable como un registro a corto plazo, pero también significa que el registro en sí no es donde se produce la retención a largo plazo, legalmente defendible.
Retención de 35 días. Las entradas se retienen durante 35 días; los datos más antiguos de 35 días se purgan. La ventana no se puede configurar hacia arriba, por lo que cualquier cosa que necesite más allá de 35 días debe salir del registro antes de que expire.
Sólo GET API. Cada llamada al Registro de Actividades API es un GET. No hay POST, PUT ni DELETE: no puede escribir en él, no puede mutarlo, y, lo que es importante, no puede pedirle que envíe eventos a 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 con límite y desplazamiento. El acceso está gobernado por el derecho de capacidad de Acceso al Registro de Actividades cubierto en la Unidad 2.2.

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

2. Diseñando la agregación y retención externamente

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

La agregación es un diseño de extracción y distribución. Un trabajo programado (que se ejecuta bajo un usuario de servicio con acceso a la actividad de registro y un token de API de duración limitada, según la Unidad 2.2) llama al punto de conexión GET de cada contrato con una cadencia cómodamente dentro de la ventana de 35 días, y luego envía los registros a un destino central: un archivo Object Storage, y típicamente hacia adelante en un SIEM externo para la correlación entre contratos y con fuentes no IONOS. La plataforma nunca iniciará esta transferencia, por lo que el calendario es el control; si el trabajo se detiene, la evidencia envejece silenciosamente a los 35 días sin alerta 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 registro de actividad y almacenarlos en un almacenamiento diferente, con IONOS Cloud Object Storage como el objetivo recomendado explícitamente. Para hacer que este archivo sea defensible, el bucket de destino utiliza Object Lock, que aplica la protección WORM (write-once-read-many) para que los objetos no puedan ser eliminados o modificados durante un período de retención especificado; habilitar Object Lock habilita automáticamente la versión del bucket, y el modo de cumplimiento evita que el período de retención se acorte o que el objeto se sobrescriba durante ese período. El resultado es un archivo que muestra evidencia de manipulación, cuya inmutabilidad es impuesta por la capa de almacenamiento, lo que compensa el hecho de que el registro en vivo solo conserva 35 días. Object Lock debe estar habilitado en el momento de la creación del bucket (no se puede agregar a un bucket existente y no se puede deshabilitar más adelante), por lo que el bucket de archivo se diseña desde el principio, no se adapta posteriormente.

Para FinCorp, esto convierte el número 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 en un bucket Object Storage de la región alemana creado con Object Lock en modo de cumplimiento, establecido en el período de retención que requieren los reguladores de FinCorp (a menudo años). El registro en vivo sigue siendo la vista de trabajo; el bucket bloqueado es el sistema de registro. Si FinCorp alguna vez divide su patrimonio entre contratos, el mismo trabajo simplemente itera 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 el registro de auditoría como una fuente de vida corta que alimenta un archivo externo inmutable.

Requisito de auditoría	Lo que le proporciona el Registro de actividad	El diseño que debe agregar
¿Quién hizo qué, recientemente, en un contrato	Registro de solo lectura por contrato, retención de 35 días	Úselo directamente como la vista en vivo; conceda el acceso al Registro de actividad de forma limitada
Retención más allá de 35 días	Nada; los datos con más de 35 días se purgan	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 resistente a manipulaciones	Registro en vivo de solo lectura, pero solo 35 días	Bloqueo de objeto (WORM, modo de cumplimiento) en el bucket de archivo, habilitado en la creación
Auditoría entre contratos o correlacionada	No hay vista entre contratos, solo GET, no hay push	Extraiga cada contrato y lo conecte a un SIEM externo; el programa es el control

Resumen

El Registro de Actividades es por contrato, de solo lectura, se mantiene durante 35 días y se expone a través de un API de solo lectura y 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 porque la plataforma no ofrece una vista entre contratos y no admite push. La retención a largo plazo, con evidencia de manipulación, se logra exportando antes de la purga de 35 días a un bucket Object Storage creado con Bloqueo de Objeto, por lo que la ventana se convierte en una fecha límite de exportación en lugar de un límite de retención.

Puntos clave:

El Registro de Actividades es por contrato, de solo lectura, se mantiene durante 35 días y es de solo lectura; los datos con más de 35 días se purgan y la ventana no se puede ampliar.
No hay agregación entre contratos y no hay entrega push; ambas se crean por el cliente como una extracción programada y de ventilador, a menudo en un SIEM externo.
La retención a largo plazo es una exportación a Object Storage con Bloqueo de Objeto (WORM); el modo de Cumplimiento hace que el archivo sea inmutable, y el Bloqueo de Objeto debe estar habilitado en el momento de la creación del bucket.
Trate los 35 días como una fecha límite de exportación firme: si el trabajo de exportación se detiene, la evidencia caduca sin alerta desde el registro.

Terminología importante: