Cambios, versiones y respaldo de la orquestación

Lo que hace cómodo al orquestador es lo que lo hace peligroso: un cambio de política se publica de una vez en todos los bordes que alcanza. Un error de escritura o una cuenta comprometida tienen el mismo alcance que un cambio bien hecho. Por eso los controles son los de cualquier sistema de alto privilegio: cambio con ticket, aprobación de una segunda persona, cuentas personales con segundo factor y, cuando el producto lo permite, publicación por etapas (primero a unas pocas sucursales, luego al resto).

La política exige cuentas personales: así cada cambio lleva el nombre de quien lo hizo. Una cuenta compartida rompe la trazabilidad: si algo sale mal, el registro no dice quién fue, y tampoco permite quitar el acceso a una sola persona sin cortarlo a todas.

Consulta cambios y mira la columna tipo_de_cuenta.

Un cambio con ticket y con una persona que lo aprueba deja rastro de por qué se hizo y de quién lo vio. Un cambio sin ninguno de los dos es un cambio sin dueño, y si además amplía la superficie, merece mirarse primero. Revisa las columnas de ticket, aprobador y descripción.

Consulta cambios.

Un respaldo que nunca se ha restaurado es una suposición. La política pide probarlo cada 90 días. Se mide desde la última prueba hasta la fecha de la revisión, contando los días del calendario.

Consulta respaldo y politica.

El respaldo del orquestador contiene la configuración completa de la red y, según el producto, material de claves y certificados. Por eso se guarda cifrado y lejos del equipo que respalda: si el respaldo está en el mismo servidor que el orquestador, la pérdida de ese servidor se lleva las dos cosas, y un atacante que lo comprometa lee también el respaldo.