Nei settori regolamentati, un’implementazione non è mai solo un’operazione tecnica: è un evento soggetto a verifica. Banche, assicurazioni, enti pubblici e qualsiasi impresa che operi in conformità con il Sarbanes-Oxley Act, il Digital Operational Resilience Act (DORA) dell’UE, la norma ISO/IEC 27001 o i Requisiti di vigilanza per l’IT negli istituti finanziari (BAIT) della BaFin condividono la stessa aspettativa di base: nessuna singola persona dovrebbe essere in grado di trasferire codice o configurazioni in un sistema di produzione senza preavviso e senza essere messa in discussione. Questa è l'idea centrale alla base della doppia approvazione ed è uno dei controlli più frequentemente citati negli audit IT delle piattaforme di automazione. La Parte 6 del 3C Release Manager per Automic Enablement Series si concentra su come questo controllo viene implementato — e tecnicamente applicato — direttamente all'interno del flusso di lavoro di implementazione.
Precedentemente in questa serie
Questo articolo continua3C Release Managerper Automic Enablement Serie. Se ti sei perso le puntate precedenti, ecco dove recuperarle:
- **Parte 1 — Funzione Snapshot**: catturare lo stato completo di un client Automic come baseline datata.
- Parte 2 — Funzione Diff: confrontare snapshot per rilevare modifiche agli oggetti e verificare la trasparenza delle release.
- Parte 3 — Creazione di Ambienti: definizione delle connessioni tecniche ai client Automic che rendono possibili snapshot, diff e deployment.
- Parte 4 — Distribuzioni Controllate: trasporto di oggetti tra client con backup automatici e un percorso di rollback definito.
- Parte 5 — Aggiungi elementi correlati: raccolta delle dipendenze annidate del flusso di lavoro fino al livello dello script in un'unica operazione.
Una volta implementati i trasporti controllati e completi dal punto di vista delle dipendenze, la domanda successiva non è più «possiamo effettuare la distribuzione in sicurezza?», bensì «possiamo dimostrare che la modifica è stata autorizzata?». È proprio qui che entra in gioco questo controllo.
Perché la doppia approvazione è importante negli ambienti Automic regolamentati
Automic Automation è solitamente al centro dei carichi di lavoro mission-critical: elaborazione dei pagamenti, rendicontazione normativa, coordinamento della catena di approvvigionamento e finestre di elaborazione batch da cui dipende il resto dell'azienda. Una modifica al flusso di lavoro in questo contesto non è un semplice adeguamento tecnico isolato. Si tratta di un cambiamento a un sistema il cui malfunzionamento ha conseguenze dirette sul business e, nei settori regolamentati, anche sul piano normativo.
I revisori lo sanno bene, e le loro domande tendono ad essere scomode e molto precise. Chi ha approvato questa modifica? Quando? Chi l'ha approvata era una persona diversa da chi l'ha preparata? Dove sono le prove? Se a queste domande si può rispondere solo con screenshot, link a ticket incollati nelle e-mail o con un "ci fidiamo del nostro team", il controllo non è in realtà un controllo, ma un sistema basato sull'onestà. La separazione dei compiti esiste proprio per eliminare tale ambiguità, rendendo l'autorizzazione indipendente un prerequisito per l'esecuzione, non una raccomandazione procedurale.
In una configurazione tradizionale Automic, garantire il rispetto di tali procedure richiede solitamente un insieme eterogeneo di flussi di lavoro esterni basati su ticket, approvazioni manuali in uno strumento di comitato consultivo per le modifiche e una disciplina operativa che dipende interamente dalla capacità delle persone di ricordarsi di seguire il processo. La configurazione 3C Release Manager per Automic integra tale controllo direttamente nella procedura di implementazione stessa.
Come viene applicata la doppia approvazione nel 3C Release Manager
Il meccanismo è integrato nella configurazione dell'ambiente. Per ogni ambiente di destinazione — in genere quelli che rappresentano i clienti in fase di pre-produzione e produzione — è possibile impostare il numero di approvazioni richieste nelle impostazioni aggiuntive. Impostando questo valore su due si attiva il controllo per quell'ambiente: ogni trasporto destinato a quel cliente richiederà l'approvazione di due utenti distinti prima di poter essere eseguito.
L'applicazione di questa regola è di natura tecnica, non procedurale. Quando una distribuzione viene preparata e raggiunge lo stato "Pronto per l'esecuzione", il pulsante "Esegui" non diventa disponibile finché non viene soddisfatta la soglia di approvazione. L'utente che ha creato e preparato il pacchetto può fornire la propria approvazione, ma tale singola approvazione non è sufficiente per l'esecuzione. È obbligatoria una seconda conferma, da parte di un utente diverso. Finché non viene registrata quella seconda approvazione, l'esecuzione non può procedere: non ci sono deroghe, soluzioni alternative o "solo per questa volta".
La breve demo qui sotto mostra l'intero flusso end-to-end: un trasporto preparato dall'Utente A, il pulsante Esegui bloccato intenzionalmente e la seconda approvazione dell'Utente B che sblocca l'esecuzione.
Cosa cambia questo in termini di conformità e audit
L'incorporazione della firma indipendente direttamente negli strumenti di deployment modifica quattro aspetti a cui tengono auditor, responsabili del rischio e responsabili delle release:
- La separazione dei compiti diventa verificabile. L'approvazione è associata all'identità dell'utente che l'ha registrata, non a un campo di testo libero o a un'e-mail inoltrata. I registri di controllo possono indicare, per ogni singola operazione, esattamente quali due utenti l'hanno approvata e quando, nonché confermare che si trattava effettivamente di due utenti distinti.
- Il controllo non può essere aggirato quando la pressione aumenta. La pressione di fine trimestre, le correzioni urgenti e il fatto che “l’altro approvatore sia in ferie” sono proprio i momenti in cui i processi manuali subiscono un silenzioso deterioramento. Una soglia imposta tecnicamente non subisce alcun deterioramento. La modifica viene eseguita solo se ottiene due approvazioni, altrimenti non viene applicata.
- Le prove di audit diventano un risultato secondario, non un progetto a sé stante. Quando un revisore chiede prove che dimostrino l'applicazione della separazione dei compiti alle modifiche apportate alla produzione nell'ultimo trimestre, la risposta consiste in una ricerca nella cronologia delle implementazioni, non in una corsa frenetica per ricostruire chi abbia approvato cosa dagli archivi delle e-mail.
- La governance delle release diventa uniforme tra i vari team. Spesso i diversi team presentano livelli diversi di maturità dei processi. L'applicazione della doppia approvazione a livello di ambiente garantisce che lo standard venga applicato in modo uniforme a ogni modifica destinata a quell'ambiente, indipendentemente dal team che l'ha preparata.
Dove si inserisce la doppia firma nel quadro più ampio del rilascio
Questo controllo non è una funzionalità a sé stante, ma costituisce uno dei livelli di un modello di governance delle versioni che 3C Release Manager implementa end-to-end. Gli snapshot forniscono la baseline. I diff rendono trasparenti le modifiche. I trasporti controllati aggiungono backup e rollback. La raccolta ricorsiva degli oggetti correlati garantisce la completezza. L'applicazione delle approvazioni aggiunge l'autorizzazione.
Nel loro insieme, questi livelli rispondono alle domande che i revisori pongono effettivamente: qual era la situazione precedente? Cosa è cambiato? Chi ha autorizzato la modifica? È possibile annullarla, se necessario? Ogni livello è utile di per sé; il loro valore si moltiplica quando vengono utilizzati insieme come un unico processo di rilascio coerente.
Per le organizzazioni che operano in conformità con i requisiti di gestione del cambiamento ICT previsti dal DORA (si vedano anche le linee guida della Deutsche Bundesbank sulla transizione da BAIT a DORA), con i principi di separazione delle funzioni previsti dal BAIT o con qualsiasi altro quadro normativo analogo che disciplini i sistemi critici, questa è la differenza tra il semplice affermare di disporre di un processo di rilascio controllato e il dimostrarne l'effettiva esistenza.
Punti chiave
- La doppia firma indipendente è uno dei controlli sottoposti a revisione più frequentemente negli ambienti IT regolamentati ed è un'aspettativa di base secondo framework come SOX, DORA, ISO 27001 e BAIT.
- Il modello 3C Release Manager per Automic garantisce il rispetto di tale requisito a livello tecnico, richiedendo un numero configurabile di approvazioni da parte di utenti diversi per ogni ambiente prima che un trasporto possa essere eseguito.
- L'applicazione delle approvazioni è integrata nel flusso di lavoro di distribuzione, non sovrapposta tramite sistemi di ticketing esterni: il pulsante Esegui non è disponibile finché non viene raggiunta la soglia.
- Il risultato è la segregazione verificabile dei compiti, prove di audit come sottoprodotto del processo e una governance coerente tra team e modifiche.
- In combinazione con snapshot, diff, trasporti controllati e raccolta ricorsiva di oggetti, questo controllo completa un framework di rilascio che si allinea perfettamente ai requisiti di audit reali.
Una gestione delle versioni conforme ai requisiti normativi non significa aggiungere ulteriori passaggi. Significa invece garantire che i passaggi fondamentali siano applicati dalla piattaforma, registrati automaticamente e facilmente verificabili a posteriori. Il modello 3C Release Manager per Automic si basa proprio su questo principio.
Vuoi scoprire in che modo il corso 3C Release Manager risponde ai requisiti di audit e conformità della tua organizzazione? Fissa una consulenza gratuita per discutere del tuo panorama di governance delle versioni oppure esplora il percorso formativo completo Automic su Tricise University per sviluppare le competenze in materia di governance delle versioni all'interno del tuo team.
