Si tratta di uno strumento che permette di vedere le azioni fatte a sistema in situazione di emergenza. Chi dovrebbe ricevere i log di queste azioni?

A cosa fare attenzione? Ma chi riceve i log sa cosa controllare e cosa guardare? Riesce a capire cosa è stato fatto durante una sessione di PAM Privileged Access Management?

Che cosa significa Emergency Access Management?

Si tratta di un accesso, solitamente temporaneo, che permette di svolgere delle azioni che vanno al di fuori della normale operatività.

Per svariate esigenze:

• Problematiche in ambiente produttivo che richiedono accessi particolari, per la risoluzione
• Sostituzione momentanea di colleghi
• Controllo delle azioni svolte da fornitori

Normalmente questi accessi vengono assegnati a personale ICT. Ma potrebbero essere usati anche in contesti da utenti finali.

È necessario avere SAP GRC Access Control per gestire gli accessi privilegiati in SAP? Sicuramente è utile e molto comodo, indispensabile in contesti aziendali con un numero di sistemi elevato e molti accessi privilegiati da gestire.

Ma con qualche limite ed effort aggiuntivo, in contesti molto limitati è possibile sfruttare quanto SAP offre già, leggi qui.

Fornire una "super" utenza non è sufficiente per controllarne l'utilizzo. Diventa necessario gestire il processo end to end.

Ovvero:

• La richiesta dalla super-utenza (non dovrebbe essere sempre disponibile)
• Il rilascio al richiedente (non dovrebbero esserci password da condividere)
• Il controllo di ciò che è stato fatto, tramite un dashboard di controllo universale per tutti i log generati

Ecco perché in alcuni contesti è necessario avere uno strumento, ad esempio il GRC Access Control ovvero il modulo Emergency Access Management.

Come sono presentati i log nel GRC EAM?

Ad ogni owner o controller vengono inviati i dettagli di quanto fatto nelle sessioni di firefighting. I log vengono recuperati dalle seguenti fonti:

• SAP Security Audit Log
• SAP Statistic Action (ovvero le transazioni usate dalle statistiche)
• Change Document Log
• Table Trace Log
• System Log
• OS System Command

Non sono recuperati ulteriori log, questo significa che se eventuali transazioni custom utilizzano meccanismi di logging diversi da quelli standard potrebbero non essere recuperate dallo strumento.

In questo caso tuttavia è probabile che debba essere rivisto l'eventuale sviluppo (es. transazione custom) effettuato affinché utilizzi i meccanismi di log standard.

Ma cosa deve saper leggere chi riceve:

1. Verificare se ci sono transazioni critiche usate, in generale
2. Capire se ci sono azioni di forzatura es. Debug
3. Capire se le transazioni e le modifiche usate e fatte non siano coerenti con quanto dichiarato all'inizio oppure alla fine della sessione (tramite l'additional activity)
4. Verificare se quanto fatto poteva essere portato a termine anche senza l'utilizzo della super utenza. In questo caso istruire le persone all'utilizzo in reale bisogno

Ma cosa conviene controllare e come governare questi accessi?

• Fai la review delle descrizioni (reason code) che vengono usati come giustificativi?

• Fai delle statistiche di utilizzo delle super utenze? Quanto sono usate e per quale motivo?
• L'utilizzo che ne viene fatto è coerente con la descrizione fornita?
• Avviene una review delle utenze definite ed usate almeno annuale?
• Dove sono conservati i log e che periodo di retention è stato definito? Sono attivi dei processi di archiviazione?

La profilazione su GRC viene gestita correttamente. Quanto power user nel sistema GRC potrebbero cancellare o modificare dei log?