Uno scenario che ricorre con una certa frequenza durante i progetti di upgrade SAP (anche in SAP Cloud ERP Private - "RISE with SAP") è la copia del sistema produttivo sull'ambiente di sviluppo, effettuata subito dopo l'aggiornamento. È una pratica comprensibile: dopo l'upgrade si vuole ripartire da un ambiente di sviluppo allineato al nuovo produttivo, evitando disallineamenti di customizing, versioni di programmi o configurazioni.
C'è però un effetto collaterale che viene spesso sottovalutato, e che riguarda direttamente la gestione dei ruoli (PFCG) e la loro tracciabilità: i change document dei ruoli creati o modificati in sviluppo dopo l'ultimo trasporto vengono persi.
I change document (le informazioni di tracciamento generate dal sistema ogni volta che un oggetto viene creato, modificato o eliminato, chi ha fatto cosa e quando) legati ai ruoli PFCG risiedono fisicamente nel sistema in cui la modifica è stata effettuata. Quando un ruolo viene creato o modificato in sviluppo, il change document nasce e vive in sviluppo.
Il trasporto (la richiesta di trasporto, o transport request) porta con sé la definizione del ruolo, le sue autorizzazioni, il profilo generato, le assegnazioni, ma non porta con sé lo storico delle modifiche.
I change document non sono un oggetto trasportabile: non fanno parte del contenuto della request e quindi non vengono replicati sul sistema di destinazione (qualità, produzione).
Questo significa che, in condizioni normali, lo storico completo delle modifiche a un ruolo esiste solo in sviluppo, mentre in produzione si ha visibilità solo del contenuto finale arrivato tramite trasporto, senza il dettaglio di come si è arrivati a quel contenuto lungo il percorso.
Significa che è corretto quindi apportare le modifiche ai ruoli direttamente in produzione? Certamente no! Ma durante i momenti di aggiornamento del sistema ci sono dei punti di attenzione sul tema se il sistema di sviluppo è coinvolto.
Fin qui si tratta di un comportamento noto e in qualche modo "fisiologico" dell'architettura a tre sistemi. Il problema si aggrava in modo evidente nel momento in cui, dopo l'upgrade, il sistema produttivo viene copiato sopra l'ambiente di sviluppo (un system copy, o refresh).
In quel momento:
Il risultato è una perdita silenziosa e spesso non percepita nell'immediato: il team se ne accorge solo quando, mesi dopo, viene richiesto di ricostruire lo storico di un ruolo per un audit, una verifica di compliance o un'indagine su un incidente di sicurezza, e si scopre che quello storico semplicemente non c'è più.
Nei contesti di compliance (SOX, D.Lgs. 231/2001, ma anche più in generale nei controlli interni su GRC e segregazione dei compiti) uno degli elementi che viene tipicamente richiesto è la dimostrazione di chi ha modificato cosa, quando e con quale autorizzazione, in particolare per i ruoli che veicolano autorizzazioni critiche o sensibili.
Se lo storico delle modifiche ai ruoli sviluppati direttamente in ambiente di sviluppo viene periodicamente azzerato da un refresh, si crea un vuoto documentale che può tradursi in:
Va inoltre considerato che il problema non riguarda solo i ruoli non ancora trasportati al momento del refresh. Anche per ruoli già trasportati regolarmente, lo storico dettagliato delle modifiche intermedie (le versioni succedutesi prima del trasporto finale) resta comunque solo in sviluppo, e viene perso allo stesso modo.
Questo non è solo un'osservazione empirica: è un comportamento che SAP stessa documenta esplicitamente nelle proprie note di consulenza sulla gestione dei change document dell'area BC-SEC (user e authorization management).
La nota (419933) a chiarisce che il concetto di autorizzazione viene tipicamente mantenuto nel sistema di sviluppo, che il trasporto di ruoli e profili non genera change document nel sistema di destinazione, e che di conseguenza questi change document vanno amministrati in modo audit-relevant proprio in sviluppo. Con tanto di concetto di archiviazione dedicato, protezione da manipolazioni indesiderate e authorization concept specifico per l'accesso in lettura/amministrazione.
La stessa documentazione, nella sezione dedicata alla gestione dei change document in caso di system copy o client copy, è ancora più esplicita: quando si crea un nuovo client a partire da una copia, i change document preesistenti prima della creazione del client non sono più rilevanti e vanno riorganizzati (cancellati senza creazione di archivio).
È la conferma, da fonte SAP, che il refresh è un'operazione strutturalmente distruttiva per questo tipo di tracciabilità, se non gestita con un passaggio preventivo di esportazione.
SAP stessa descrive una procedura "tried and tested" per sincronizzare un client di sviluppo con i dati transazionali del client live, proprio per gestire questo tipo di refresh in modo controllato.
Uno dei punti è quello che riguarda direttamente il tema di questo articolo: l'archiviazione preventiva dei change document è il passaggio che, se saltato, comporta la perdita definitiva dello storico. Tuttavia, anche seguendo correttamente questa procedura, esiste un'insidia ulteriore, documentata da SAP in una nota correttiva dedicata ( 2943757): i change document già archiviati prima del refresh possono risultare illeggibili dopo la system copy o client copy, anche se i file di archivio sono fisicamente ancora presenti nella storage directory.
La causa è che le informazioni di amministrazione dell'archivio (l'indice che lega i file di archivio al sistema) non contengono più i riferimenti agli archivi creati prima della copia, il collegamento si perde, pur restando intatto il contenuto.
Per questo scenario specifico SAP fornisce un tool di backup/ripristino dedicato, il programma SUIM_REPAIR_CHDOC, da eseguire prima dell'importazione del client di produzione: trasferisce i dati di amministrazione degli archivi esistenti su file locale, in modo che, se i range di numerazione degli archivi tra sistema sorgente e sistema target non si sovrappongono, possano essere ricaricati dopo la copia, ripristinando l'accessibilità agli archivi preesistenti.
Il tool segue un principio "tutto o niente": se viene rilevato un problema di coerenza durante il ricaricamento, non avviene alcun trasferimento. Copre gli archivi US_PASS, US_USER, US_PROF, US_AUTH, BC_SU2X, BC_SAL e CHANGEDOCU (per quest'ultimo, limitatamente agli object class IDENTITY, PFCG, SECURITY_POLICY e SUSR_PROF).
In pratica, questo significa che una checklist di refresh davvero robusta non può limitarsi a "archiviare prima di copiare", ma deve includere anche il salvataggio esplicito dei metadati di amministrazione dell'archivio, altrimenti anche i change document diligentemente archiviati in anticipo rischiano di trasformarsi in dati orfani, tecnicamente presenti ma non più consultabili tramite i normali strumenti di analisi (RSUSR100N, RSSCD100_PFCG e simili).
In sintesi, una checklist operativa completa dovrebbe includere:
La copia del produttivo su sviluppo dopo un upgrade è una pratica tecnicamente utile, ma ha un impatto diretto e spesso trascurato sulla tracciabilità delle modifiche ai ruoli.
I change document non viaggiano con i trasporti e non sopravvivono a un refresh: se non vengono esportati preventivamente, lo storico va perso in modo definitivo.
È SAP stessa, nella propria documentazione di consulenza sulla gestione dei change document BC-SEC, a raccomandare l'archiviazione preventiva come parte di una procedura strutturata di sincronizzazione tra client live e client di sviluppo. In un'ottica di audit e compliance, vale la pena trattare questo passaggio come parte integrante del processo di change management sui ruoli, e non come un semplice dettaglio tecnico lasciato al team Basis.