AGLEA SAP Security Blog

SAP GRC mail, cosa fare?

Scritto da Massimo Manara | Oct 6, 2020 10:00:00 PM

Ci si fa sempre prendere la mano delle notifiche ed e-mail da mandare. Ma spesso si viene sommersi e perdono il loro significato.

 

Ma siamo sicuri serva? Quale può essere il risultato nell'esagerare?

Quali sono le notifiche che puoi configurare in GRC?

Possono essere davvero molte, partendo da quelle standard (i workflow standard che in SAP GRC Access Control prendono il nome di ProcessID) previste dai seguenti processi:

 

  • SAP GRC Access request
    • Ovvero le notifiche per la gestione del ciclo di vita delle utenze (nuova utenza, modifica, dismissione etc)
  • SAP GRC Access Risk Analysis
    • Ovvero i workflow legati alla gestione delle modifiche ai rischi, function e controlli mitigativi (della matrice dei rischi)
  • SAP GRC EAM - Emergency Access Management
    • I log generati dalle super utenze che arrivano ai vari owner e controller
  • altri workflow come ad esempio quelli di User Access Review e SoD review

 

Inoltre tramite l'utilizzo della funzionalità di Business Rule Framework (BRF+) è possibile definite le più disparate regole per notificare gli attori presenti nel workflow ad esempio:

 

  • Tutti gli utenti che hanno un determinato ruolo
  • Tutti gli utenti che appartengono ad un certo gruppo utenti
  • Degli utenti indicati puntualmente
  • Definendo delle regole più complesse al di fuori da quelle proposte da SAP, es. tabelle decisionali (Decision Table) o ricerca su tabelle già presenti a sistema (es DB Lookup)

 

La specificità dell'Emergency Access Management

Nel caso del modulo per la gestione delle super-utenze, ovvero la possibilità di assegnare una super-utenza (ma è possibile usare anche un super ruolo) che permetta ad un certo utente di svolgere delle azioni al di fuori della sua normale operatività. In maniera tracciata e sotto controllo.

 

Sono presenti delle notifiche specifiche:

  • Ogni volta che viene effettuato il login da parte di una super utenza
  • L'invio della notifica dei log verso Firefighter ID owner e/o Firefighter ID Controller una volta completata la sessione di fire fighting
Il modulo sopra dovrebbe essere usato in situazioni di emergenza, per come è stato pensato.

Di conseguenza il numero di mail, di notifica, dovrebbe essere limitato. Tuttavia in alcuni contesti l'utilizzo delle super utenze avviene:

  • da parte di molte utenze, interne o esterne (consulenti)
  • con frequenza molto elevata

 

Quanto sopra porta ad avere una generazione di mail elevata e spesso, inutile per le finalità di controllo, in quanto:

 

  • chi riceve le mail spesso ne ha molte, forse troppe, da guardare (in quanto è owner di parecchie super-utenze), con il risultato che non riesce a controllare
  • l'utilizzo della super-utenza diventa di fatto la norma, quanto in realtà dovrebbe essere una eccezione
  • chi riceve le mail non conosce in alcuni casi (spesso in quanto i log sono troppo tecnici), leggendo i log, delle situazioni critiche sulle quali indagare

 

Qual è la differenza tra Alert ed E-mail?

Si tratta di notifiche ma può esserci una distinzione importante da fare a mio avviso:

 

  • Alert: arriva una notifica, di qualcosa da "gestire" ovvero qualcosa che potrebbe a seguito, nello strumento di gestione utilizzato, far scatenare un remediation plan
  • E-mail: arriva una notifica fine a se stessa, certo si può vedere a sistema cosa è accaduto ma non c'è modo di gestire un piano di rimedio o di scatenare automaticamente delle ulteriori attività e tenerle tracciate in un case specifico

 

Quali sono i punti di attenzione?

  1. Immagina l'utilità reale di mandare mail, valutando soprattutto se i destinatari riescono a "capire" di cosa si tratta
    • A cosa serve inviare mail dei log delle attività svolte da amministratori o super utenti a persone che non sanno leggerli?
  2. Effettua delle indagini periodiche per capire l'utilizzo che ne viene realmente fatto, magari chiedendo dei feedback
  3. Valuta se chi riceve può davvero svolgere azioni di controllo
  4. Valuta quante mail vengono inviate dagli approvatori, se rischiano di essere davvero troppe possono essere inutili