Mappa Globale#
Cos'e il Change Management#
Il change management e il processo formale che governa ogni modifica a sistemi, applicazioni e infrastruttura di un'organizzazione. Non si tratta solo di sicurezza: riguarda l'impatto delle modifiche sull'intera organizzazione, dal business alla compliance, dal rischio operativo alla continuita del servizio.
Il principio base: ogni change porta valore ma anche rischio di disruption. Senza un processo formale, un aggiornamento non coordinato puo abbattere sistemi critici, creare configurazioni non sicure, o violare normative. Il change management trasforma il caos delle modifiche tecniche in un processo controllato, reversibile e documentato.
Dev parallel: Il change management e il processo aziendale di cui il tuo CI/CD pipeline e l'implementazione tecnica. Branch protection rules + required reviewers su GitHub sono il CAB tradotto in codice.
terraform plane l'impact analysis automatica. Un environment protection rule che richiede approvazione manuale prima del deploy in produzione e il formal approval process. Il rollback plan e ilgit revert- la differenza e che in production il rollback si pianifica PRIMA, non si improvvisa dopo.
Change Advisory Board (CAB)#
Il CAB e il comitato che approva le modifiche prima che vadano in produzione. Non e un ostacolo burocratico: e la difesa organizzativa contro i change non coordinati che causano outage o violazioni.
flowchart TB
REQ[Change Request\nSubmission]
IMPACT[Impact Analysis\n+ Risk Assessment]
CAB[CAB Review]
DEC{Decision}
APPROVE[Approved]
REJECT[Rejected - Revise]
BUILD[Build in Sandbox]
TEST[Testing in Staging]
WINDOW[Maintenance Window\n+ Deploy]
MONITOR[Monitor Post-Deploy]
DOC[Document + Close]
REQ --> IMPACT --> CAB --> DEC
DEC -->|Yes| APPROVE --> BUILD --> TEST --> WINDOW --> MONITOR --> DOC
DEC -->|No| REJECT --> REQ
| Ruolo CAB | Responsabilita |
|---|---|
| Change Manager | Coordina il processo, convoca il CAB |
| Change Owner | Accountability del change (non necessariamente chi lo esegue) |
| Technical Reviewer | Valuta rischi tecnici e dipendenze |
| Business Stakeholder | Valuta impatto sul business |
| Security Reviewer | Valuta implicazioni di sicurezza |
ECAB (Emergency CAB): per change urgenti che non possono aspettare il CAB ordinario. Processo piu rapido, spesso con un subset del CAB normale. In alcuni casi si applica retroapprovazione (il change viene eseguito, il CAB lo ratifica successivamente). Usato per patch critiche di sicurezza o fix di outage in corso.
Processo OABCTMD#
Il processo completo di un change segue sette fasi sequenziali. La sequenza non e opzionale: saltare una fase invalida il processo e puo rendere il change inammissibile a fini audit.
| Fase | Sigla | Cosa succede |
|---|---|---|
| Owner Assignment | O | Si assegna il responsabile del change (accountability) |
| Approval | A | Il CAB esamina e approva o respinge |
| Build | B | Il change viene costruito in ambiente sandbox (isolato dalla produzione) |
| Change Execution | C | Il change viene eseguito nella maintenance window |
| Testing | T | Verifica in staging prima del deploy finale |
| Monitoring | M | Monitoraggio post-deploy per rilevare regressioni |
| Documentation | D | Il change NON e chiuso finche la documentazione non e aggiornata |
Tipi di Change#
Esistono tre categorie di change con processi di approvazione diversi. La scelta del tipo non e a discrezione del tecnico: dipende da criteri oggettivi di rischio e urgenza.
| Tipo | Approvazione | Quando si usa | Esempio |
|---|---|---|---|
| Normal | CAB completo | Qualsiasi change non urgente e non standard | Aggiornamento di una libreria applicativa |
| Emergency | ECAB accelerato | Change urgente per ripristinare servizi o patchare vulnerabilita critiche | Patch per una RCE zero-day in produzione |
| Standard | Pre-approvato | Change a basso rischio, ripetitivo, con procedure documentate | Aggiunta di un account utente secondo procedura standard |
I change standard vengono pre-approvati periodicamente dal CAB: quando un tipo di modifica e stato eseguito molte volte senza problemi e il rischio e ben compreso, il CAB puo autorizzarne l'esecuzione senza revisione caso per caso.
Elementi Obbligatori di ogni Change#
Ogni change, indipendentemente dal tipo, deve includere cinque elementi fondamentali prima di essere considerato completo.
Backout Plan#
Il backout plan e la procedura dettagliata per tornare allo stato operativo precedente se il change fallisce. E obbligatorio anche per i change che hanno superato tutti i test: il sandbox non riproduce mai esattamente la produzione.
flowchart TD
DEPLOY[Deploy in Produzione]
CHECK{Deploy riuscito?}
OK[Monitoring continuato\nChange = chiuso]
FAIL[Esecuzione Backout Plan]
RESTORE[Restore allo stato precedente]
VERIFY[Verifica funzionamento]
REPORT[Report + root cause\ndel fallimento]
DEPLOY --> CHECK
CHECK -->|Si| OK
CHECK -->|No| FAIL --> RESTORE --> VERIFY --> REPORT
Un backout plan efficace contiene: checkpoint chiari per decidere se eseguire il rollback, procedura passo-passo per il restore, criteri di successo del rollback, chi e autorizzato a decidere il rollback, tempo massimo prima di decidere.
Maintenance Window#
La maintenance window e lo slot temporale - tipicamente off-hours - in cui i change vengono eseguiti. Tutti gli stakeholder la conoscono in anticipo, il che permette di consolidare piu change nella stessa finestra riducendo le comunicazioni.
Change Freeze: periodi in cui nessun change e permesso, indipendentemente dall'urgenza. Esempi classici:
- Periodo natalizio (ambienti retail)
- Periodo di audit finanziario
- Settimane pre-lancio prodotto
- Giorni vicini a scadenze regolamentari importanti
Separazione dei Ruoli#
Un principio fondamentale del change management e che chi sviluppa non puo approvare il deploy in produzione del proprio lavoro. Questo previene sia gli errori involontari (blind spots) sia le modifiche malevole non supervisionate.
| Ruolo | Puo sviluppare | Puo approvare | Puo deployare |
|---|---|---|---|
| Developer | Si | No (il proprio lavoro) | No |
| Change Manager / CAB | No | Si | No |
| Operations | No | No | Si (dopo approvazione) |
Dev parallel: E la stessa logica di "non puoi fare merge della tua PR". In GitHub con branch protection, il required reviewer non puo essere l'autore del PR. Il CAB e quel reviewer elevato a processo aziendale formale con implicazioni audit e compliance.
Documentazione e Version Control#
Il change non e considerato chiuso finche la documentazione non riflette lo stato post-change. Questo include diagrammi di architettura, runbook, configurazioni, e il change log stesso.
Version Control nel change management: sistemi come Git tracciano le versioni correnti del codice e delle configurazioni. Il VCS deconflict le modifiche parallele e permette di tornare a versioni precedenti. Punto critico: il VCS NON e un sistema di backup - e tracking delle versioni con deconflicting.
Config drift detection: AWS Config, Azure Policy e simili confrontano continuamente lo stato reale delle risorse con quello atteso (dichiarato nel repo IaC). Se la configurazione live diverge, scatta un alert. E il controllo detective che compensa la tendenza umana a saltare la documentazione.
Implicazioni Tecniche#
Ogni change ha conseguenze tecniche che devono essere gestite attivamente per prevenire disservizi non previsti.
| Area | Cosa fare | Esempio |
|---|---|---|
| Security controls update | Aggiornare firewall rules, ACL, allow list | Nuovo server richiede nuova regola in ingresso |
| Dependency tracking | Mappare sistemi downstream che dipendono dall'elemento modificato | Modifica al DB: tutti i servizi che lo interrogano devono essere notificati |
| Downtime communication | Comunicare la finestra di indisponibilita con anticipo (tipicamente 72h) | Email a tutti i reparti prima della maintenance |
| Restricted activities | Bloccare attivita incompatibili con il change in corso | Freeze inserimenti nel sistema finanziario per 48h durante upgrade |
| Scope expansion | Ri-approvare qualsiasi modifica non prevista nel change originale | Aggiornare il firmware del firewall ha richiesto prima aggiornare il management software: due change, non uno |
Legacy Applications nel Change Management#
Le applicazioni legacy (non piu supportate dal vendor) richiedono attenzione speciale perche l'organizzazione diventa il proprio team di supporto.
| Situazione | Approccio |
|---|---|
| App non patchabile | Allow list: blocca tutto, esegue SOLO processi approvati |
| App con comportamento impredittibile | Deny list: blocca solo il noto-malevolo |
| Sistema EOL critico | Isolamento di rete + compensating controls |
Ticketing e Tracciabilita#
Ogni change ha un ticket che documenta l'intero ciclo di vita. Il ticket contiene:
- Descrizione del change e motivazione (justification)
- Risk assessment: cosa puo andare storto, impatto stimato
- Rollback plan con procedura dettagliata
- Approval record con firma del CAB
- Test results dall'ambiente di staging
- Finestra di esecuzione pianificata
- Stato post-change e verifica del successo
Il ticketing e lo strumento che rende il change management verificabile in sede di audit. Un auditor che chiede "mostrami tutti i change degli ultimi 6 mesi" deve ricevere un elenco completo con tutto il tracciato.
Dev parallel: In Jira o ServiceNow, il change ticket e la pull request elevata a livello di processo aziendale. Non contiene solo il codice, ma tutto il contesto: perche il change, chi lo ha approvato, come tornare indietro, quando e avvenuto. Un PR senza descrizione e senza test e un change senza ticket - accettabile in un progetto personale, inaccettabile in produzione.
