Planteamiento y contexto
Construye un servicio de objetos WORM multiinquilino. Los objetos tienen versiones, pueden tener un período de retención fijo y pueden protegerse indefinidamente mediante una retención legal. Los clientes exigen el rechazo de eliminaciones y sobrescrituras durante la retención, modos de gobernanza y de cumplimiento, y rutas de auditoría que no puedan ser eludidas por administradores, la replicación o la limpieza del ciclo de vida. Explica los flujos de escritura, lectura, eliminación, replicación, recuperación y auditoría.
Qué está evaluando el entrevistador
- Si distingues entre versiones de objetos, períodos de retención, modo de gobernanza, modo de cumplimiento y retenciones legales.
- Si la inmutabilidad se aplica mediante la ejecución del almacenamiento y no por convención del cliente.
- Si diseñas permisos, bypass de gobernanza, límites de cuentas raíz y aprobación dual.
- Si manejas la replicación, los reintentos, los marcadores de eliminación y la consistencia del reloj.
- Si cada cambio de política y rechazo es demostrablemente auditable.
Preguntas para aclarar primero
- ¿Las políticas se definen por bucket, prefijo, versión del objeto o contrato del inquilino?
- ¿El modo de cumplimiento debe impedir la eliminación por parte de la cuenta raíz antes del vencimiento?
- ¿Quién inicia, elimina y aprueba las retenciones legales, y se requiere la aprobación de cuatro ojos?
- ¿Las réplicas deben preservar el estado de bloqueo y las fechas, y qué retraso entre regiones es aceptable?
- ¿Los clientes necesitan lecturas fuertemente consistentes, listado de versiones, exportación de pruebas o solo el rechazo de eliminaciones?
Una respuesta de 30 segundos
“Separaría los datos del objeto, los índices de versiones y la política de retención mientras confirmo su estado de forma atómica. Una escritura crea una versión inmutable; el motor de políticas calcula retainUntil, el modo y el estado de la retención legal, y cada ruta de eliminación verifica esos hechos dentro del mismo límite de autorización. El modo de gobernanza permite un bypass explícitamente autorizado, mientras que el modo de cumplimiento rechaza toda eliminación antes del vencimiento; una retención legal no tiene fecha y solo se puede eliminar mediante un flujo de trabajo de aprobación. La replicación transfiere los metadatos de versión y de bloqueo. Las escrituras, las eliminaciones rechazadas, los bypasses y los cambios de política van a un registro de auditoría de solo anexión que puede generar evidencia.”
Análisis detallado paso a paso
1. Modelar versiones y el estado de bloqueo
Una clave de objeto no es la entidad protegida; objectVersionId lo es. Almacena el digest del contenido, la hora de escritura, retainUntil, el modo, la retención legal, el inquilino y la versión de la política. Una eliminación simple crea un marcador de eliminación en lugar de eliminar físicamente una versión protegida; la eliminación permanente debe nombrar una versión y pasar la verificación de bloqueo.
2. Diseñar escrituras y retención predeterminada
La política del bucket o del inquilino puede proporcionar el modo y la duración predeterminados, mientras que una escritura puede solicitar un valor a nivel de objeto. Valida la duración máxima, la fuente de tiempo y los permisos, y luego vincula atómicamente los metadatos calculados a la versión. Los cambios de política afectan a versiones futuras y no pueden acortar retroactivamente la retención existente.
{
"objectVersionId": "v_91c2",
"retention": {"mode": "COMPLIANCE", "retainUntil": "2027-01-01T00:00:00Z"},
"legalHold": "OFF",
"policyVersion": 18
}3. Aplicar controles de eliminación y sobrescritura
La eliminación, la sobrescritura, el acortamiento de la retención y la remoción de una retención legal utilizan un único servicio de autorización. Este lee la versión más reciente y verifica condicionalmente la hora, el modo, los permisos del principal y el estado de retención. El modo de gobernanza requiere un permiso de bypass explícito y un marcador de solicitud; el modo de cumplimiento rechaza todas las eliminaciones antes del vencimiento, incluidos los administradores. Los rechazos devuelven un error estable y un ID de auditoría.
4. Diseñar retenciones legales y aprobación
Una retención legal es independiente de la retención y protege una versión hasta que se elimine explícitamente. El flujo de trabajo de eliminación vincula un caso o contrato, motivo, actor, aprobador y autenticación reforzada; los inquilinos de alto riesgo pueden requerir dos personas. Tras la eliminación, un retainUntil no vencido todavía protege la versión, por lo que una retención no anula la retención temporal.
5. Manejar replicación, recuperación y relojes
La replicación transfiere el contenido, el ID de versión, el digest y los metadatos de bloqueo completos; el destino verifica la firma de origen y la versión de la política antes de confirmar. El origen sigue rechazando eliminaciones hasta que el destino las confirme, y el destino no puede declarar el cumplimiento antes de la verificación del bloqueo. La recuperación crea una nueva versión y nunca muta la anterior. Compara fechas utilizando un servicio de tiempo controlado y marcas de tiempo de auditoría monotónicas, no el reloj de una sola máquina.
6. Construir auditoría y pruebas
Audita escrituras, creación de versiones, eliminaciones exitosas o rechazadas, bypasses, cambios en retenciones legales, confirmación de replicación y publicación de políticas. Almacena los eventos en un registro separado de solo anexión con una cadena de hash o firmas y acceso de consulta restringido. Exporta periódicamente el inventario de versiones, el estado de bloqueo y los digests de auditoría para que el cliente pueda demostrar la protección en un momento determinado.
Ejemplo de una respuesta sólida
“Trato los metadatos de versión y bloqueo como hechos inmutables, y cada ruta de eliminación lee el estado actual y realiza una comprobación condicional. En la escritura, el motor de políticas calcula la retención, el modo y la retención legal, y los vincula atómicamente a la versión. El modo de gobernanza permite un bypass explícitamente autorizado; el modo de cumplimiento rechaza toda eliminación antes del vencimiento. Una retención legal se elimina únicamente con un caso, un motivo y una aprobación. La replicación transfiere la versión, el digest y los metadatos de bloqueo, y solo pasa a ser conforme tras la confirmación del destino. Los rechazos, bypasses, cambios de política y la replicación ingresan a un registro de auditoría firmado de solo anexión, del cual los clientes pueden exportar el inventario de versiones y los digests de prueba.”
Errores comunes
- Verificar bloqueos solo en la capa de API → las rutas de limpieza o replicación los eluden → volver a verificar en la ejecución de eliminación del almacenamiento.
- Aplicar un cambio de política de bucket a versiones antiguas → la retención existente puede acortarse ilegalmente → versionar las políticas y afectar solo a futuras escrituras.
- Tratar una retención legal como una fecha fija → la eliminación automática tras el vencimiento puede infringir un caso → mantener las retenciones independientes con remoción explícita.
- Hacer que el bypass de gobernanza sea implícito → el uso indebido privilegiado no se puede explicar → requerir permiso explícito, marcador y auditoría de aprobación.
- Declarar el cumplimiento cuando se envía la replicación → el destino puede perder los metadatos de bloqueo → confirmar primero la versión y el estado de bloqueo del destino.
Preguntas de seguimiento y respuestas
¿Por qué un DELETE simple puede tener éxito sin eliminar una versión?
Con objetos versionados, un DELETE simple puede crear un nuevo marcador de eliminación que oculta la versión actual mientras la versión protegida permanece. La eliminación permanente debe especificar el ID de versión y superar el control de bloqueo.
¿Por qué el modo de cumplimiento necesita un límite de cuenta más estricto?
Su significado es que ningún principal, incluida una cuenta raíz o un administrador de almacenamiento, puede eliminar antes de la fecha de retención. La eliminación debe estar aislada de las concesiones habituales de superusuario de IAM para que un rol privilegiado no pueda invalidar el cumplimiento.
¿Cómo demuestras que una eliminación rechazada no se perdió de la auditoría?
Utiliza un único ID de solicitud para la decisión de autorización, el estado de la versión y el evento de auditoría, y luego escribe el evento en un registro separado de solo anexión. Concilia periódicamente las solicitudes de eliminación, el inventario de versiones y los eventos de rechazo, y congela las operaciones de alto riesgo ante cualquier discrepancia.
¿Se puede eliminar el origen mientras la replicación está retrasada?
No. El bloqueo de origen permanece hasta que el destino confirme el digest del contenido, el ID de versión y los metadatos de retención; de lo contrario, un fallo de replicación crea una ventana sin una copia que cumpla las normativas.