Approvazione degli interventi di utenti di emergenza SAP: ex ante o ex post?

La gestione dei super user, gli utenti di emergenza in SAP, è un tema ricorrente nella revisione del bilancio. Un concetto di utenti di emergenza deve quindi rispondere a due domande: che cos’è, in fondo, un’emergenza? E chi approva l’intervento, e quando: prima o dopo? Sulla seconda domanda esistono due scuole di pensiero.

Prima definire l’emergenza

La prima domanda nell’elaborare un concetto di utenti di emergenza è la definizione dell’emergenza stessa. Per noi un’emergenza è caratterizzata da due criteri:

1. Processi di business critici in termini di tempo non possono essere eseguiti. L’accento è su «critici in termini di tempo». Tutto ciò che può aspettare appartiene al processo standard con richiesta di modifica e trasporto, non a un intervento di utente di emergenza.
2. Amministratori o sviluppatori hanno bisogno di accesso diretto alle tabelle del sistema produttivo, aggirando il sistema di trasporti.

Definita l’emergenza e documentata la definizione, si pone la questione del processo di approvazione.

Due modelli di approvazione

Ex ante: approvazione prima dell’intervento

Nel primo approccio, ogni intervento di utente di emergenza deve essere approvato in anticipo da un approvatore, nel rispetto della separazione delle funzioni. Spesso questo approccio viene combinato con autorizzazioni graduate per gli utenti di emergenza, e ci sono buone ragioni per farlo. Per esempio, il primo intervento riceve un ruolo di utente di emergenza in cui l’oggetto di autorizzazione S_DEVELOP contiene solo diritti di visualizzazione, per circoscrivere l’errore e, se possibile, correggerlo già.

L’argomentazione: con «Debugging & Replace» uno sviluppatore potrebbe aggirare tutti i meccanismi di controllo del sistema. Un registro serve allora a poco, se al momento della revisione il danno si è già verificato da tempo.

Ex post: accesso immediato, revisione obbligatoria

Noi sosteniamo l’altro approccio e lo abbiamo realizzato nella nostra suite per utenti di emergenza ISPICIO_E. Come descritto all’inizio, siamo per una gestione molto restrittiva: interventi di utenti di emergenza solo in caso di vera emergenza. Ma quando processi di business critici in termini di tempo mettono a rischio gli obiettivi aziendali, non si dovrebbe perdere tempo a ottenere prima un’approvazione.

Per questo, in questo modello un collaboratore autorizzato riceve subito accesso completo al sistema produttivo (SAP_ALL). ISPICIO_E crea per ogni intervento un ID utente monouso nel sistema e lo collega al Security Audit Log. Al termine dell’intervento l’ID viene cancellato e le relative voci del SAL vengono estratte.

Come resta garantita l’integrità

Che l’accesso sia immediato e completo non significa che sia privo di controllo. Il controllo si trova altrove:

• Nel normale esercizio non esiste alcun utente di emergenza nel sistema produttivo. Non c’è alcun ID che possa essere usato inosservato.
• Ogni intervento viene verificato al 100 per cento. Dopo ogni intervento, la sezione corrispondente del Security Audit Log viene sottoposta automaticamente a un revisore, con notifica via e-mail e nel rispetto della separazione delle funzioni. Il revisore deve esaminare le voci del SAL e chiudere il ticket: approvare o respingere.
• L’intera catena è analizzabile. Richiesta, motivazione, registro, revisore, data e ora ed esito si trovano in una banca dati consultabile e su una dashboard: chi ha fatto la richiesta? Qual era la motivazione? Che cosa è stato fatto? Chi ha verificato, quando e con quale esito?

Che cosa ne ricava l’audit

Questa impostazione è particolarmente apprezzata dall’audit, interno ed esterno. Può estrarre campioni mirati e, per gli interventi respinti, chiedere quali misure correttive siano state adottate. Per noi la risposta a «ex ante o ex post?» è quindi: ex post, ma a ogni intervento e senza eccezioni.

Per saperne di più sul modello e sulla sua realizzazione: ISPICIO_E: accesso di emergenza ai sistemi SAP.