Concetti di utenti di emergenza SAP: si deve assegnare SAP_ALL?
Ruoli di emergenza differenziati o semplicemente SAP_ALL? Per noi la graduazione colloca il controllo nel posto sbagliato. Decisivo è che le emergenze restino rare e ogni intervento sia verificato senza lacune.
Questo articolo tratta della configurazione delle autorizzazioni all’interno dei concetti di utenti di emergenza SAP. In concreto: si deve assegnare il profilo SAP_ALL, o i ruoli di utente di emergenza differenziati sono la via migliore?
Perché i revisori contabili guardano più da vicino
Il tema degli utenti di emergenza è arrivato nelle medie imprese. I revisori contabili attribuiscono sempre più importanza a una configurazione tecnica degli interventi a prova di audit, soprattutto in vista di un’informativa finanziaria integra e tracciabile. Il motivo è evidente: gli interventi diretti nel sistema produttivo con autorizzazioni estese violano la separazione delle funzioni tra IT e processo di business e il principio dell’assegnazione minima delle autorizzazioni (need-to-know), anche se solo per breve tempo.
Che cosa fa parte di un concetto di utenti di emergenza
Per Maxim Chuprunov, una gestione conforme degli utenti di emergenza inizia da un concetto documentato e applicato nella pratica. Secondo la sua esposizione, ne fanno parte:
- un accesso limitato alle credenziali, nessun accesso condiviso (shared access),
- requisiti definiti in anticipo per un intervento,
- un processo di approvazione e di notifica,
- una registrazione senza lacune degli interventi e
- un’analisi periodica dei registri. [1]
Fin qui c’è accordo. Le strade si dividono sulla domanda di quali autorizzazioni riceva l’utente di emergenza.
Ruoli differenziati: il desiderio più ovvio
Chuprunov ritiene auspicabile una limitazione tecnica delle autorizzazioni degli utenti di emergenza secondo i diversi scenari di intervento e gruppi di utenti. Questo desiderio lo sentiamo ripetutamente anche dai nostri clienti: un ruolo per la contabilità finanziaria, uno per la logistica, uno per SAP Basis, uno per gli sviluppatori con diritti di visualizzazione.
L’idea è comprensibile. Ma ha un prezzo: accanto al concetto autorizzativo vero e proprio ne nasce un secondo, che deve essere mantenuto, verificato e documentato, e che proprio nell’emergenza può diventare un ostacolo, quando il ruolo su misura in quel momento non basta.
La nostra posizione: poche emergenze, autorizzazione completa, revisione completa
Sosteniamo che gli interventi di utenti di emergenza debbano limitarsi alle vere emergenze. Un numero elevato di interventi indica, secondo la nostra esperienza, carenze nei processi e nelle integrazioni di sistema sottostanti, e queste andrebbero risolte tempestivamente e con priorità, invece di rendere più comodi gli utenti di emergenza.
Se il numero delle emergenze resta basso, non vediamo alcuna necessità di autorizzazioni di emergenza graduate. Vediamo piuttosto il pericolo che per questa via si affermi un concetto autorizzativo ombra. La nostra soluzione ISPICIO_E assegna quindi semplicemente SAP_ALL.
L’integrità dei dati e la tracciabilità degli interventi le garantisce altrove: con una revisione obbligatoria di tutte le attività nel Security Audit Log. Subito dopo ogni intervento, il registro individuale viene assegnato a un revisore per il commento e la decisione: approvare o respingere. Tutti gli interventi si trovano così, insieme alla motivazione (per esempio il riferimento a un ticket), al file di registro e all’esito della revisione, in una banca dati che in sede di audit si può analizzare comodamente.
Conclusione
La domanda «SAP_ALL o no?» è, a nostro avviso, la domanda sbagliata. Decisivo è quanto raramente serva l’utente di emergenza e quanto completamente venga verificato ogni intervento. Chi ha entrambe le cose sotto controllo può concedere l’autorizzazione completa in caso di emergenza, e l’auditor ottiene ciò che vuole vedere: ogni intervento, ogni motivazione, ogni esito.
[1] Cfr. Chuprunov, Maxim: Handbuch SAP-Revision. Internes Kontrollsystem und GRC. Rheinwerk, Bonn 2012, p. 242 s. (in tedesco).