En los sectores regulados, una implementación nunca es solo una acción técnica: es un evento auditable. Los bancos, las aseguradoras, las organizaciones del sector público y cualquier empresa que opere bajo la Ley Sarbanes-Oxley, la Ley de Resiliencia Operativa Digital (DORA) de la UE, la norma ISO/IEC 27001 o los Requisitos de Supervisión de la BaFin para las Tecnologías de la Información en Instituciones Financieras (BAIT) comparten la misma expectativa básica: ninguna persona por sí sola debería poder trasladar código o configuraciones a un sistema de producción sin previo aviso y sin que se le cuestione. Esa es la idea central que subyace a la doble aprobación, y es uno de los controles más citados en las auditorías de TI de las plataformas de automatización. La parte 6 del 3C Release Manager para Automic Enablement Series se centra en cómo se implementa este control —y se aplica técnicamente— directamente dentro del flujo de trabajo de implementación.
Anteriormente en esta serie
Este artículo continúa3C Release Managerpara Automic Enablement Serie. Si te perdiste las partes anteriores, aquí es donde puedes ponerte al día:
- Parte 1 — Función de instantánea: captura del estado completo de un cliente Automic como una línea de base con marca de tiempo.
- Parte 2 — Función Diff: comparando instantáneas para detectar cambios de objetos y verificar la transparencia de la versión.
- Parte 3 — Creación de Entornos: definiendo las conexiones técnicas a los clientes Automic que hacen posibles las instantáneas, las diferencias y las implementaciones.
- **Parte 4 — Despliegues Controlados**: transporte de objetos entre clientes con copias de seguridad automáticas y una ruta de reversión definida.
- Parte 5 — Añadir elementos relacionados: recopilar las dependencias anidadas del flujo de trabajo hasta el nivel de los scripts en una sola acción.
Una vez que se han establecido transportes controlados y con todas las dependencias cubiertas, la siguiente pregunta pasa de ser «¿podemos realizar la implementación de forma segura?» a «¿podemos demostrar que el cambio fue autorizado?». Ahí es precisamente donde entra en juego este control.
Por qué es importante la doble aprobación en entornos regulados Automic
Automic Automation suele constituir el núcleo de las cargas de trabajo críticas para la misión: procesamiento de pagos, presentación de informes reglamentarios, coordinación de la cadena de suministro y ventanas de procesamiento por lotes de las que depende el resto de la empresa. Un cambio en un flujo de trabajo en este entorno no es un simple ajuste técnico aislado. Se trata de una modificación de un sistema cuyo fallo tiene consecuencias directas para el negocio y, en los sectores regulados, consecuencias normativas.
Los auditores lo saben, y sus preguntas suelen ser incómodamente concretas. ¿Quién aprobó este cambio? ¿Cuándo? ¿La persona que lo aprobó era diferente de la que lo preparó? ¿Dónde está la evidencia? Si esas preguntas solo pueden responderse con capturas de pantalla, enlaces a tickets pegados en correos electrónicos o con un “confiamos en nuestro equipo”, el control no es realmente un control, sino un sistema basado en la confianza. La segregación de funciones existe precisamente para eliminar esa ambigüedad, haciendo de la autorización independiente una condición previa para la ejecución, y no una recomendación de procedimiento.
En una configuración tradicional Automic, garantizar el cumplimiento de esto suele requerir una combinación de flujos de trabajo de gestión de incidencias externos, aprobaciones manuales en una herramienta de comité asesor de cambios y una disciplina operativa que depende por completo de que las personas se acuerden de seguir el proceso. La versión 3C Release Manager para Automic integra ese control de cumplimiento directamente en la propia implementación.
Cómo se aplica la doble aprobación en el 3C Release Manager
El mecanismo está integrado en la configuración del entorno. Para cualquier entorno de destino —normalmente los que representan entornos de preproducción y producción—, el número de aprobaciones necesarias se puede configurar en los ajustes adicionales. Al establecer este valor en dos, se activa el control para ese entorno: cada transporte destinado a ese cliente requerirá la aprobación de dos usuarios distintos antes de que pueda ejecutarse.
La aplicación de esta norma es de carácter técnico, no procedimental. Cuando se prepara una implementación y alcanza el estado “Preparación lista”, el botón «Ejecutar» no queda disponible hasta que se cumpla el umbral de aprobación. El usuario que ha creado y preparado el paquete puede dar su propia autorización, pero esa única aprobación no es suficiente para ejecutar la implementación. Es obligatoria una segunda confirmación, por parte de otro usuario. Hasta que no se registre esa segunda aprobación, la ejecución no puede continuar: no hay forma de anularla, ni solución alternativa, ni «solo por esta vez».
La breve demostración a continuación muestra el flujo completo de principio a fin: un transporte preparado por el Usuario A, el botón de Ejecutar bloqueado intencionalmente y la segunda aprobación del Usuario B desbloqueando la ejecución.
¿Qué cambia esto realmente para el cumplimiento y la auditoría?
Incrustar la aprobación independiente directamente en las herramientas de implementación cambia cuatro cosas que importan a los auditores, oficiales de riesgo y gerentes de lanzamiento:
- La separación de funciones pasa a ser verificable. La aprobación está vinculada a la identidad del usuario que la registró, y no a un campo de texto libre ni a un correo electrónico reenviado. Los registros de auditoría pueden mostrar, para cualquier transporte concreto, exactamente qué dos usuarios lo aprobaron y cuándo, así como que esos dos usuarios eran personas realmente distintas.
- El control no puede eludirse bajo presión. La presión de fin de trimestre, las correcciones urgentes y situaciones como “el otro responsable de la aprobación está de vacaciones” son precisamente los momentos en los que los procesos manuales se deterioran sin que nos demos cuenta. Un umbral impuesto técnicamente no se ve afectado. El cambio, o bien cuenta con dos aprobaciones, o bien no se ejecuta.
- Las pruebas de auditoría se convierten en un subproducto, no en un proyecto. Cuando un auditor solicita pruebas de que se aplicó la separación de funciones a los cambios de producción del último trimestre, la respuesta es una consulta al historial de implementaciones, no una carrera contrarreloj para reconstruir quién aprobó qué a partir de los archivos de correo electrónico.
- La gestión de las versiones se armoniza entre todos los equipos. A menudo, los distintos equipos presentan diferentes niveles de madurez en los procesos. La imposición de la doble aprobación a nivel de entorno implica que la norma se aplica de manera uniforme a todos los cambios destinados a ese entorno, independientemente del equipo que los haya elaborado.
Dónde encaja la doble firma en el marco general de lanzamiento
Este control no es una función independiente, sino una de las capas que conforman el modelo de gestión de versiones que 3C Release Manager integra de principio a fin. Las instantáneas proporcionan la referencia. Las comparaciones de diferencias hacen que los cambios sean transparentes. Las transferencias controladas añaden copias de seguridad y la posibilidad de revertir cambios. La recopilación recursiva de objetos relacionados garantiza la exhaustividad. La aplicación de aprobaciones añade la autorización.
En conjunto, estas fases responden a las preguntas que realmente se plantean los auditores: ¿Cuál era la situación anterior? ¿Qué ha cambiado? ¿Quién autorizó el cambio? ¿Se podría revertir en caso necesario? Cada fase es útil por sí sola; su valor se multiplica cuando se utilizan conjuntamente como un único proceso de lanzamiento coherente.
Para las organizaciones que operan bajo los requisitos de gestión del cambio en las TIC de DORA (véanse también las directrices del Deutsche Bundesbank sobre la transición de BAIT a DORA), las expectativas de BAIT en materia de separación de funciones, o cualquiera de los marcos comparables que rigen los sistemas críticos, esta es la diferencia entre afirmar que se cuenta con un proceso de lanzamiento controlado y demostrarlo.
Conclusiones clave
- La doble firma independiente es uno de los controles auditados con mayor frecuencia en entornos de TI regulados, y es una expectativa básica según marcos como SOX, DORA, ISO 27001 y BAIT.
- La versión 3C Release Manager para Automic lo impone técnicamente al exigir un número configurable de autorizaciones de usuarios diferentes por entorno antes de que se pueda ejecutar un transporte.
- La aplicación de la aprobación está integrada en el flujo de trabajo de implementación, no superpuesta a través de tickets externos: el botón Ejecutar no está disponible hasta que se cumpla el umbral.
- El resultado es una segregación de funciones verificable, evidencia de auditoría como subproducto del proceso y una gobernanza coherente en los equipos y los cambios.
- Combinado con instantáneas, diffs, transportes controlados y recopilación recursiva de objetos, este control completa un marco de lanzamiento que se alinea limpiamente con los requisitos de auditoría reales.
La gestión de lanzamientos conforme a los requisitos normativos no consiste en añadir más pasos, sino en garantizar que la plataforma aplique los pasos que realmente importan, que estos se registren automáticamente y que sea fácil demostrarlo a posteriori. La actualización de 3C Release Manager a Automic se basa precisamente en ese principio.
¿Quieres saber cómo se adapta el 3C Release Manager a los requisitos de auditoría y cumplimiento normativo de tu organización? Solicita una consulta gratuita para analizar tu panorama de gobernanza de lanzamientos, o explora el itinerario completo del curso Automic en Tricise University para desarrollar las competencias en materia de gobernanza de lanzamientos de todo tu equipo.
