Objetivo y alcance
Definir inmutabilidad efectiva considerando quién puede cambiar políticas, destruir infraestructura o comprometer credenciales.
Contexto técnico
Una copia es inmutable sólo dentro de un modelo de amenaza. Si la misma identidad puede cambiar retención, eliminar la cuenta o destruir el repositorio, la protección puede ser aparente.
La arquitectura debe separar planos, mantener copias independientes y conservar una ruta de recuperación documentada.
Arquitectura y criterios
- Separar identidades y dominios administrativos.
- Bloquear retención durante el período requerido.
- Mantener una copia fuera del entorno productivo.
- Proteger claves y cuentas de emergencia.
- Monitorear cambios y probar restauración limpia.
Implementación recomendada
- Modelar atacantes, fallas y rutas de eliminación.
- Elegir repositorios y controles de retención.
- Configurar acceso mínimo y alertas independientes.
- Probar pérdida de credenciales y entorno.
- Documentar recuperación, costos y responsabilidades.
Riesgos y controles
- Un administrador global puede seguir controlando recursos protegidos.
- Retención excesiva aumenta costo y obligaciones.
- Datos inmutables infectados siguen siendo datos no confiables.
Validación y evidencia
- Las cuentas productivas no pueden eliminar todas las copias.
- Cambios de retención generan alerta y control adicional.
- Una restauración limpia cumple integridad y tiempo esperado.
Operación continua
Revisar privilegios, retenciones, capacidad, alertas y pruebas. Cambios de plataforma requieren reevaluar el modelo de amenaza.
Próximo paso
Dibujar cada ruta que podría borrar las copias actuales y validar cuáles resisten una cuenta administrativa comprometida.