¿Los backups de producción necesitan credenciales separadas?

Un backup solo es una copia de recuperación si un incidente que dañe producción no puede borrar también esa copia. Parece obvio hasta que revisas las credenciales que hay detrás de un trabajo automatizado. En muchas configuraciones, un mismo token lee datos activos, escribe un backup, enumera backups antiguos, los borra para aplicar la retención, cambia el destino e inicia restauraciones. Si entregas ese token a un agente autónomo, una llamada API equivocada o comprometida puede convertir una interrupción de producción en un fallo de recuperación.

La solución no consiste en redactar una política de permisos más grande con un lenguaje más ingenioso. Da a los datos activos y a los datos de recuperación límites de acción separados. La credencial que opera producción no debería poder eliminar copias de recuperación. La credencial que escribe un backup no debería poder cambiar su retención. Una restauración debería tener su propia aprobación porque devuelve datos sensibles a un entorno activo. Cada límite debe hacer que una solicitud incorrecta falle antes de causar consecuencias.

Es un problema de diseño, no de proveedor. El mismo patrón se aplica tanto si las copias terminan en almacenamiento de objetos, una bóveda de backups gestionada, instantáneas, un dispositivo físico o una segunda cuenta en la nube. La inmutabilidad del almacenamiento importa. La administración separada también. Pero ninguna de las dos sirve si la identidad de trabajo normal de un agente todavía puede ejercer los controles destructivos que las rodean.

Una copia de backup no está separada si una identidad puede borrarla

Una copia de recuperación debe sobrevivir a los fallos que esperas de producción, incluido el uso indebido de una credencial privilegiada. Si la misma identidad de agente puede llamar tanto a delete production database como a delete recovery vault, tienes datos duplicados, no una recuperación aislada.

Los equipos suelen llamar a esto separación porque producción y los backups utilizan buckets, carpetas, regiones o nombres de recursos diferentes. Eso es distribución del almacenamiento. No es separación de acceso. Una sola entidad con acceso amplio puede atravesar todos esos límites en unas pocas solicitudes.

La prueba es sencilla: toma la credencial disponible para el agente de producción y pregunta qué puede hacer sin otra persona, otra identidad o un plano de control físicamente distinto. Si puede hacer cualquiera de las siguientes cosas, tiene demasiada influencia sobre la recuperación:

• Borrar de forma permanente un punto de recuperación o una versión de objeto.
• Acortar la retención, omitirla o eliminar una retención legal.
• Desactivar la replicación o redirigir las copias futuras.
• Cambiar el acceso de cifrado para que la restauración falle.
• Borrar una bóveda de backups, un proyecto, una cuenta o un contenedor de almacenamiento.

La parte incómoda es que un agente quizá nunca reciba una instrucción explícita para borrar backups. Un modelo puede seleccionar un comando de limpieza demasiado amplio. Un adaptador de herramientas puede asociar una operación de nombre inocente con un endpoint destructivo. Un repositorio comprometido puede convencer al agente de usar las credenciales que ya tiene. La protección debe funcionar cuando la solicitud es incorrecta, no solo cuando la instrucción era razonable.

Hay dos radios de impacto diferentes que controlar. El primero es el daño al plano de datos: un agente modifica o borra datos empresariales. El segundo es el daño al plano de recuperación: un agente elimina las copias, desactiva el acceso a ellas o hace imposible descifrarlas. La mayoría de los equipos se esfuerza en controlar el primero y deja el segundo unido al mismo rol de administrador.

Esa decisión suele nacer de la comodidad. La limpieza por retención necesita permiso para borrar backups caducados, así que el trabajo de backup recibe permisos de borrado amplios. Una prueba de restauración necesita un rol privilegiado, así que la misma integración lo recibe. Un ingeniero quiere un solo secreto en CI, así que el rol acumula todos los permisos. Cada atajo es comprensible. Juntos dan a una credencial de automatización rutinaria autoridad sobre la última línea de recuperación.

Escribir un backup y gestionar su ciclo de vida son trabajos distintos

El escritor de backups necesita una ruta limitada y repetible. El administrador de retención necesita autoridad para cambiar o eliminar copias. Un operador de recuperación necesita autoridad para leer una copia seleccionada e introducirla en un destino controlado. Tratarlo todo como un único trabajo es lo que convierte una identidad de backup en algo peligroso.

Una separación útil tiene cuatro clases de acción:

1. Captura lee la fuente de producción indicada y crea un nuevo artefacto de recuperación.
2. Depósito escribe ese artefacto en un destino definido con los atributos de retención necesarios.
3. Recuperación lee un artefacto seleccionado y lo restaura únicamente en un destino permitido.
4. Administración cambia la retención, las retenciones legales, la configuración de la bóveda, la replicación, el acceso de cifrado o las reglas de borrado.

La captura y el depósito suelen poder ejecutarse sin supervisión. La recuperación normalmente debería exigir una aprobación nueva porque puede trasladar una gran cantidad de información sensible a un runtime nuevo. La administración debería quedar completamente fuera de la ruta habitual del agente, salvo en procedimientos de emergencia muy concretos y aprobados por separado.

No confundas la limpieza con la captura. La expiración automatizada es útil, pero no significa que el escritor deba tener autoridad permanente para borrar. Prefiere reglas de ciclo de vida gestionadas por el sistema de recuperación o por un rol de retención separado. Si la plataforma obliga al escritor a borrar sus propias copias antiguas, dale permisos solo dentro de un área de staging breve y dedicada. Replica las copias completadas en un destino protegido donde ese escritor no pueda borrarlas ni modificarlas.

Esta distinción detecta un fallo conocido. Un agente de base de datos ejecuta una exportación cada hora. Su rol puede escribir en recovery/incoming/, enumerar el prefijo y borrar archivos antiguos. Meses después, el equipo de almacenamiento cambia el destino a recovery/. Desaparece el límite del prefijo y el agente obtiene permisos de borrado sobre todos los datos de recuperación actuales. El trabajo sigue apareciendo como correcto. El problema solo se descubre cuando alguien necesita la copia.

Usa nombres separados que expresen la intención en los propios permisos. backup-writer, backup-retention-admin y restore-operator son más claros que un único rol llamado backup-service. Los nombres claros no hacen cumplir el acceso, pero dificultan mucho aprobar una revisión sin examinarla.

Las credenciales separadas deben conducir a autoridades separadas

Crear dos claves API para el mismo rol de administrador amplio no sirve de nada. Las credenciales separadas solo importan cuando conducen a autoridades diferentes de una forma que un atacante, un script defectuoso o un agente no puedan volver a unir.

Empieza con un mapa de acceso pequeño. Anota cada fuente, destino, credencial y operación destructiva. Incluye la cuenta o suscripción en la nube, no solo la ruta de almacenamiento. El mapa debe responder preguntas que los diagramas de aplicaciones suelen omitir:

• ¿Qué identidad crea la copia?
• ¿Qué identidad puede borrar una copia existente antes de su expiración programada?
• ¿Qué identidad puede reducir la retención o invocar una omisión?
• ¿Qué identidad puede modificar la replicación, el bloqueo de una bóveda o las claves de cifrado necesarias para restaurar?
• ¿Qué identidad puede restaurar datos en una red con acceso a producción?

Si la respuesta a tres o más preguntas es la misma identidad de servicio, separa las acciones antes de añadir más automatización.

Un diseño mínimo y práctico sería este:

Al principio, las identidades pueden vivir en el mismo proveedor, pero deben tener roles, credenciales y rutas de aprobación distintos. Una separación mejor coloca el destino protegido en otra cuenta controlada por un grupo administrativo diferente. Una separación más sólida añade un proveedor de identidad independiente o un entorno de recuperación que los administradores de producción no puedan modificar en silencio. No retrases la primera separación mientras esperas la estructura perfecta de cuentas.

Una cuenta separada también falla si un superadministrador de producción puede asumir el rol de administrador de recuperación cuando quiera. Puede ser aceptable para una organización pequeña sin otra opción, pero llámalo por su nombre: separación administrativa por convención. Es más débil que un límite que requiera a otra persona, un factor físico o una aprobación externa.

La inmutabilidad detiene una clase de borrado, no todos los fallos de recuperación

El almacenamiento inmutable protege las copias existentes contra modificaciones o borrados durante un periodo de retención. No demuestra que sigan llegando copias nuevas, que contengan los datos correctos, que las claves de cifrado sigan disponibles ni que un operador pueda restaurarlas. Es un control importante, pero no puede sostener por sí solo todo el plan de recuperación.

La guía StopRansomware de CISA recomienda mantener los backups sin conexión y garantizar que los datos de backup estén cifrados e inmutables. La recomendación es acertada porque los atacantes suelen perseguir los sistemas de backup después de acceder a producción. No debe interpretarse como permiso para colocar una credencial de administrador de bóveda en la misma automatización que opera la aplicación.

Amazon S3 Object Lock hace concreta esta diferencia. En modo compliance, ninguna persona, incluido el usuario root de la cuenta, puede sobrescribir ni borrar una versión de objeto protegida antes de su fecha de retención. En modo governance, una persona o proceso con s3:BypassGovernanceRetention puede anular la protección si solicita explícitamente esa omisión. La documentación de Amazon incluso señala que la consola incluye automáticamente ese encabezado de omisión para quien tiene permiso.

El modo governance resulta útil, especialmente mientras descubres qué periodo de retención puedes asumir. No equivale a un límite estricto si la credencial del agente tiene permisos de omisión. No entregues a un agente s3:BypassGovernanceRetention porque alguien quiera que una tarea de limpieza deje de fallar. Corrige el diseño del ciclo de vida.

La retención en modo compliance tiene un coste: un periodo incorrecto puede conservar los datos más tiempo del previsto y no podrás acortarlo. Decide esto de forma deliberada. Elige la duración a partir de las necesidades de recuperación, las obligaciones legales, la sensibilidad de los datos, el coste y el tiempo que se tarda en descubrir una intrusión. Copiar una configuración genérica de otro equipo no es un plan.

Hay otra trampa en el almacenamiento de objetos con versionado. Una solicitud de borrado sencilla puede crear un marcador de borrado en lugar de eliminar de forma permanente una versión anterior. Esto puede hacer que la restauración parezca rota para quien navega por la vista más reciente, aunque la versión protegida siga existiendo. El procedimiento de recuperación debe explicar cómo identificar y obtener la versión necesaria. Un objeto imborrable que nadie puede encontrar durante un incidente solo está protegido a medias.

Coloca los controles destructivos de backup detrás de otra aprobación

La creación rutinaria de backups debería ser aburrida. Una sesión nueva del agente puede necesitar aprobación para usar una credencial de escritura de backups, pero las llamadas individuales de captura y depósito no deberían requerir atención humana si están limitadas a su fuente y destino previstos. La gente aprende rápidamente a aprobar solicitudes repetitivas sin leerlas.

Las acciones destructivas o irreversibles merecen otro tratamiento. Eliminar una copia de recuperación, acortar la retención, cambiar el destino de replicación, desactivar un bloqueo de bóveda, exportar material de descifrado o restaurar en un entorno accesible desde producción debería detenerse para obtener una aprobación nueva y específica. La aprobación debe describir la acción solicitada en lenguaje claro e identificar la credencial, el destino y el impacto.

Mala aprobación: ¿Permitir la operación de backup?

Aprobación útil: ¿Permitir que backup-retention-admin elimine 14 puntos de recuperación caducados de archive-vault? Esta acción no se puede revertir para las copias que no estén bajo retención inmutable.

Las palabras importan porque permiten rechazar una solicitud técnicamente autorizada pero incorrecta desde el punto de vista operativo. Un agente de producción que de repente solicita modificar una bóveda de recuperación debería resultar extraño antes de que alguien tenga que interpretar el nombre de una acción IAM.

La aprobación no sustituye a los permisos. Una persona puede aprobar la solicitud equivocada, sobre todo a las 2 de la madrugada, cuando un incidente ya ha llenado la pantalla de alertas. El límite de permisos debe hacer que las acciones peligrosas no estén disponibles para el escritor normal. La aprobación se ocupa del conjunto más pequeño de acciones que siguen siendo posibles de forma intencionada.

Sallyport encaja en este patrón cuando un agente de programación necesita llamar a una API de backup o ejecutar una tarea de backup basada en SSH: guarda la credencial en la bóveda de la aplicación, permite que la sesión normal use solo la credencial de escritura y marca las credenciales de administración de recuperación para que requieran aprobación en cada uso. El agente recibe el resultado de la acción, no el secreto.

Esta disposición también resuelve un problema práctico de los agentes de larga duración. No apruebes un proceso una vez y supongas que todas sus acciones futuras merecen la misma confianza. Un proceso nuevo debe iniciar su propia sesión. Una credencial sensible debe exigir consentimiento en cada llamada, aunque el proceso ya tenga acceso rutinario a los backups.

Un fragmento de política debería hacer imposible la llamada incorrecta

Las revisiones de permisos son mucho más claras cuando pruebas la solicitud que nunca quieres que tenga éxito. El siguiente ejemplo muestra un rol de depósito con estilo S3. Solo puede colocar un objeto nuevo bajo un prefijo asignado. No tiene DeleteObject, capacidad para omitir la retención, autoridad sobre la política del bucket ni permiso para volver a leer el archivo.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteNewRecoveryArtifacts",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::recovery-archive-prod/incoming/database/*"
    },
    {
      "Sid": "DenyRecoveryAdministration",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:BypassGovernanceRetention",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold",
        "s3:PutBucketPolicy",
        "s3:DeleteBucket"
      ],
      "Resource": "*"
    }
  ]
}

Este es un ejemplo de estructura, no una política para pegar sin revisarla. Una implementación real puede necesitar encabezados de cifrado, acciones de carga multiparte, una restricción del bucket o un rol separado para un servicio de replicación. La idea es que nadie que lo lea deba preguntarse si esta identidad puede borrar un artefacto de recuperación. La respuesta debe estar a la vista.

Ejecuta una prueba negativa después de cada cambio de permisos. Con la credencial de depósito activa, el borrado debería fallar de una forma que tus registros puedan guardar:

aws s3api delete-object \
  --bucket recovery-archive-prod \
  --key incoming/database/2026-07-22/backup.sql.zst

Un resultado correcto se parecería a este:

An error occurred (AccessDenied) when calling the DeleteObject operation:
User is not authorized to perform: s3:DeleteObject on resource:
arn:aws:s3:::recovery-archive-prod/incoming/database/2026-07-22/backup.sql.zst

Después prueba la acción que el rol sí debería realizar. Carga un artefacto canario inofensivo, verifica que su configuración de retención aparezca como esperas y confirma que el agente no pueda modificarla después. Un diseño de permisos que no ha superado una prueba negativa sigue siendo solo un diagrama.

No guardes la credencial del administrador de retención junto a la del escritor «por si hay emergencias». Las emergencias son precisamente el momento en que más presión existe para usar el secreto amplio. Mantén esa credencial en un almacén separado y exige una ruta de aprobación independiente o un segundo operador.

La recuperación puede filtrar datos aunque el borrado esté bloqueado

Los equipos suelen describir la restauración como el sentido seguro del proceso. Es más segura que borrar un backup, pero sigue siendo una acción privilegiada. Restaurar una base de datos de clientes en un entorno de desarrollo improvisado puede exponer secretos de producción, datos personales, registros de pagos o tokens internos. Restaurar una imagen en una red conectada con producción también puede introducir credenciales antiguas y servicios inseguros.

Una acción de restauración necesita límites que encajen con el sistema recuperado. Como mínimo, especifica el punto de recuperación de origen, la cuenta o el proyecto de destino, la red de destino y el grupo de acceso previsto. Si la plataforma admite un sandbox de restauración, úsalo. Si no, crea un destino restringido con controles de salida y sin ruta a producción de forma predeterminada.

Separa la aprobación de restauración de la aprobación de backup por otro motivo: el operador de recuperación puede necesitar acceso para leer datos protegidos, mientras que el escritor de backups no debería tenerlo. Esa capacidad de lectura puede ser más sensible que la de escritura. Un trabajo de exportación puede producir datos cifrados sin ver nunca el texto plano. Un trabajo de restauración suele materializarlo.

Un buen simulacro de restauración responde a algo más que «¿terminó el comando?». Comprueba si:

• La marca de tiempo seleccionada coincide con el escenario del incidente.
• El artefacto puede descifrarse con la identidad de recuperación prevista.
• La aplicación se inicia con una configuración aislada.
• Aparecen los registros y el esquema esperados.
• El entorno restaurado temporal se destruye o se conserva con sus propias reglas de acceso.

No hagas simulacros solo contra la copia más fácil del día anterior. Elige puntos de recuperación antiguos, fuentes de datos distintas y situaciones en las que haya que seleccionar deliberadamente una versión de objeto o una clave de cifrado. La restauración difícil es la que te enseña si el procedimiento describe la realidad.

El camino del fallo suele empezar con una solicitud inofensiva

Imagina un agente de programación con acceso a una base de datos de producción y a la CLI de un proveedor cloud. Recibe una solicitud para reducir los costes de almacenamiento después de que un entorno de pruebas acumule exportaciones antiguas. El agente enumera un prefijo de almacenamiento amplio, encuentra objetos grandes y envía un comando de borrado. El ingeniero quería limpiar archivos de staging. La credencial alcanza tanto staging como el archivo porque un comodín resultaba cómodo.

Si el archivo usa versionado normal, el comando puede añadir marcadores de borrado y hacer que las copias actuales desaparezcan de una enumeración normal. Si utiliza retención governance y la credencial incluye permisos de omisión, la solicitud puede eliminar las versiones por completo. Si utiliza retención compliance, la solicitud de borrado falla, que es exactamente el tipo de fallo que quieres.

Ahora cambia únicamente el diseño de las credenciales. El agente puede usar una credencial staging-cleaner para la ruta de pruebas y una credencial de solo depósito para escribir nuevos archivos. Ninguna puede enumerar ni borrar objetos de recuperación protegidos. La solicitud falla antes de convertirse en un incidente. Más tarde, un administrador de recuperación puede revisar el problema de costes con una aprobación independiente y decidir si hay que ajustar las reglas del ciclo de vida.

Por eso las credenciales de almacenamiento amplias son peores de lo que parecen. El comando puede ser normal. El resultado destructivo procede de una identidad que atraviesa límites que la tarea nunca necesitó cruzar.

Conserva un registro de auditoría de las acciones de recuperación permitidas y rechazadas. El registro de rechazos demuestra que un control se activó. El registro de acciones permitidas muestra qué proceso utilizó qué credencial, qué tocó y cuándo. En Sallyport, el diario de sesiones y el diario de actividad proporcionan esos dos niveles de evidencia, y sp audit verify puede comprobar la cadena hash sin conexión y sin acceso a la bóveda. Es útil después de un incidente porque un informe de backup que dice «correcto» no puede explicar una solicitud administrativa sospechosa.

Los informes de backup deberían mostrar la autoridad, no solo el éxito

La mayoría de los paneles de backup indican si un trabajo terminó y cuántos datos copió. Añade una segunda vista: qué autoridad realizó el cambio, qué operación intentó y si el sistema la aceptó. La seguridad de recuperación falla en silencio cuando todos los informes reducen la autorización a una insignia verde o roja.

En cada ejecución de backup, registra el identificador de origen, el identificador de destino, la versión del artefacto o el ID del punto de recuperación, la clase de credencial, el estado de retención y el resultado. Para cada acción rechazada, registra suficiente contexto para investigar sin guardar secretos ni cargas útiles sensibles. El registro debe permitir distinguir un backup completo de una carga fallida, una expiración rutinaria del ciclo de vida de un borrado manual y una llamada destructiva bloqueada de un permiso ausente que requiere revisión.

No concedas acceso de lectura amplio al almacenamiento de recuperación solo para que un agente pueda producir un informe detallado. Muchos proveedores ofrecen endpoints de metadatos, informes de inventario o llamadas de estado con alcance limitado. Si el agente debe leer un manifiesto, escribe uno separado que contenga identificadores, sumas de comprobación, horas de captura y estado de retención, en lugar de un catálogo de datos de clientes.

Una revisión semanal útil hace cuatro preguntas:

1. ¿Cada fuente prevista creó un artefacto recuperable?
2. ¿Alguna identidad intentó cambiar la retención, el borrado o la replicación?
3. ¿La credencial de escritura actual puede acceder a acciones de administración de recuperación?
4. ¿Un simulacro de restauración demostró que una copia antigua seleccionada puede iniciar la aplicación de forma aislada?

Si el equipo no puede responder a estas preguntas a partir de sus registros, mejora los registros antes de asumir que el diseño de backup funciona.

Crea el límite antes de automatizarlo más

Empieza con la credencial que ya tiene tu agente o tu trabajo de CI. Elimina su capacidad para borrar copias de recuperación, omitir la retención, cambiar las retenciones legales, modificar la replicación, cambiar la configuración de la bóveda y administrar la cuenta de recuperación. Después crea una identidad de depósito que solo pueda escribir donde corresponde. Ese cambio cierra una ruta habitual entre una instrucción incorrecta y un daño irreversible.

A continuación, traslada los controles del ciclo de vida y la retención a una identidad administrativa distinta. Añade retención inmutable para el periodo de recuperación que tu organización pueda defender. Coloca la restauración en un destino restringido y exige una aprobación específica antes de que los datos sensibles vuelvan a aparecer fuera de su runtime normal. Por último, realiza un simulacro que intente tanto el backup esperado como el borrado prohibido.

Tu diseño de backups estará listo para los agentes cuando un agente pueda crear una copia de recuperación sin tener autoridad para destruirla. Hasta entonces, la automatización solo hará más rápido el mismo error compartido.