L'utilizzo dei dati per controllare e governare la security SAP?

Bisogna averli e saperli gestire. Può essere possibile scoprire informazioni importanti una volta capito come interpretarli.

Tantissimi dati e log

Sarà sempre di più così. Da SAP ECC a SAP S/4HANA i meccanismi di log, segregazione dei dati e controllo si sono sempre più migliorati, generando tuttavia una enorme quantità di dati.

Quali sono i principali eventi e log disponibili:

• SAP Security Audit Log
• SAP Table Trace (Transazione SCU3)
• SAP Read Access Log (Transazione SRALMANAGER)
• SAP UI Logging and Masking
• SAP Transaction Log
• SAP Gateway log
• SAP Change Document
• SAP Router Log
• SAP HANA Audit Log

A che punto siamo sull'argomento oggi?

Non in tutti i casi avere molti SAP log e dati è sufficienti per analizzarli e capire cosa eventualmente fare.

In molte situazioni questi log vengono semplicemente archiviati senza aggiungere ulteriore valore. O meglio, vengono sfruttati nel momento in cui "accade" qualcosa.

Solitamente un problema, magari a distanza di mesi o anche ravvicinato. In altre parole per capire la causa di un certo problema è fondamentale avere le tracce per ricostruire l'accaduto.

Non che questo sia male, certo. Ma forse non è sufficiente.

Perché registrare e collezionare tutte queste informazioni per usarle, forse, solo per analisi forensi di fatto?

Possono essere utilizzati questi dati per capire cosa sta accadendo nel proprio sistema e trovare dei miglioramenti da apportare o comportamenti non corretti?

Come controllarli e come arrivare a poterlo fare?

Ancora una volta, a mio avviso, è un passaggio culturale che serve per poter arrivare a farlo. Non solo tecnologico quindi. Facendo ovviamente attenzione agli aspetti normativi.

In aggiunta alla gestione di dati personali devono essere tenute in considerazioni anche tematiche di salvaguardia dei lavoratori (ad esempio la Legge 300/1970, lo statuto dei lavoratori all'articolo 4) successivamente riformata dal c.d. “Jobs Act” (art. 23 del decreto legislativo n. 151/2015, in vigore dal 24 settembre 2015).

Può essere sicuramente alla portata di tutti a livello tecnologico, ma per sfruttarlo realmente bisogna essere pronti per farlo, a livello di maturità aziendale dei modelli adottati ed a livello di gestione.

Che cosa intendo?

1. Per poter controllare cosa accade nel sistema devi avere una struttura, in questo caso un concetto autorizzativo, che permetta di farlo. Banalmente il sapere chi può solo scrivere o solo leggere dati, può essere un controllo molto veloce da fare in alcuni modelli, in altri addirittura impossibile (nel caso di volumi di dati importanti da gestire)
2. Devi sapere cosa vuoi controllare. Sembra una domanda retorica tuttavia prima di poter fare è meglio porsi alcune domande e capire più del come, il cosa
3. Per realizzare una struttura di questo tipo va capito l'effort che richiede. Chi controlla è la stessa persona che opera a sistema? Al di là dell'aspetto di separazione dei compiti, chi è nella "delivery" potrebbe non avere il tempo necessario per occuparsi dei punti sopra (soprattutto in situazioni dove la maturità di queste tematiche non è elevata, vedi punto 1 sopra)
4. Infine devi avere gli strumenti. Per controllare quello che avviene a sistema servono degli strumenti in grado di uniformare, adattare, integrare consolidare dati, da fonti diverse e che permettano di eseguire delle interrogazioni o elaborazioni su questi dati.

Si tratta, probabilmente, di attività ad oggi ancora poco diffuse (in questo ambito), ma in futuro (forse non troppo lontano) potrebbero diventare dei lavori a pieno titolo. Identificare ed analizzare comportamenti migliorare algoritmi di identificazioni ed agire in concerto con le macchine.