Si tratta di una affermazione che spesso sento: "SAP traccia tutto". 

Ma è davvero così? Posso davvero garantire un tracciamento delle attività e risalire a chi ha fatto cosa nel sistema? Oppure ci sono dei metodi per bypassare questi log?

Cosa sono i log in SAP e perché sono così importanti?

Potremmo metaforicamente far riferimento alle nostre impronte digitali. Infatti, ogni oggetto o superficie che tocchiamo lasciamo, senza volerlo, delle tracce.

Queste tracce possono essere analizzate per ottenere una identità specifica. Ecco, mentre una impronta digitale è difficile, se non impossibile, probabilmente al momento, da camuffare, nei sistemi informatici, questo aspetto potrebbe non essere così solido.

I log sono di fatto delle tracce di tutte (vedremo poi quali in realtà) le azioni che una persona (nel gergo tecnico un utente) ha svolto all'interno del sistema. Se parliamo di un sistema gestionale, ad esempio SAP ERP, un ordine di acquisto, una fattura, un documento contabile e così via.

Il grado di log e le tipologie di questi log, sono definiti dal sistema stesso. Se un determinato sistema non prevede un meccanismo di logging, chiaramente non è possibile avere queste tracce. Ad esempio, per analisi detective o forensi.

SAP possiede un ottimo meccanismo di logging. Attenzione però, non significa che traccia tutto. Quindi questa affermazione non è tecnicamente corretta. Ma la ritendo comunque, colloquialmente valida.

Perché non traccia tutto? Per diverse ragioni, ad esempio le seguenti

• Non c'è sempre la reale necessità di avere queste tracce
  • Ha senso tenere traccia del cambiamento che avviene quando un utente si modifica le proprie impostazioni personali (ad esempio se vuole stampare su un dispositivo oppure su un altro?) forse no. Mentre se un utente modifica un documento contabile o un documento di acquisto, evidentemente sì. Ma anche in quel caso non è detto serva tracciare qualsiasi modifica, magari alcune informazioni di un documento contabile non sono così rilevanti
• Perché comunque è un costo tracciare tutto
  • Per il sistema che deve tracciare (performance)
  • Per i dati che devono essere archiviati (storage). I due opposti. Se traccio tutto dovrò gestire un archivio molto grande, se non traccio nulla non avrò questo problema (ma evidentemente ne avrò altri in casi di verifiche a posteriori, non avendo a disposizione nulla)

Attenzione, nei sistemi SAP esiste, per garantire la continuità di business, la separazione tra gli ambienti. Ovvero esiste un sistema chiamato di sviluppo, un sistema di test ed infine il sistema di produzione.

Questo perché chiaramente nel sistema di produzione le modifiche devono essere apportate solo se testate e collaudate (è il meccanismo dei trasporti SAP che consente di spostare una modifica fatta in sviluppo nei vari sistemi, senza doverla replicare manualmente). Specialmente le modifiche alla configurazione del sistema stesso.

Quindi in questo caso di fatto ci sono due divere tipologie di log.

• Log delle azioni che avvengono direttamente nel sistema produttivo e qui ci sono moltissime famiglie di log esempio:
  • SAP Audit Log (da attivare)
  • SAP Change Log (attivo da standard, su determinate tabelle)
  • Table change Log (da attivare)
  • Application Log (attivo, in alcuni casi da attivare esplicitamente)
  • System Log (attivo da standard)
• Log delle azioni che sono state fatte nel sistema di sviluppo e poi trasportate nel sistema di produzione
  • Sistema dei trasporti (Transport Management System)

SAP e la sicurezza by default (Security By Design o Security By Default)

La SAP sta progressivamente adottando questo approccio, ovvero rilasciare i propri software, che vengono installati presso i clienti già configurati correttamente dal punto di vista security (quindi anche per gli aspetti di trace e logging del sistema).

Il processo tuttavia è ancora lungo, in quanto moltissime funzioni (tra cui anche molte legate alla tracciatura delle attività), nel passato non erano (in alcuni casi non sono ancora oggi) attive by default.

Questo comporta che tra tutti i possibili meccanismi di log attivabili, alcuni non lo siano, da subito attivi. Questo aspetto chiaramente deve essere, in fase di installazione o gestione del sistema definito con il cliente stesso.

Un provider può chiaramente proporre di attivare alcuni di questi servizi di default spenti, ma ci deve essere la volontà e possibilità di poterli/doverli gestire a seguito nel modo corretto.

Ma allora attivando tutti i log sono "tranquillo"

Ecco questo è un ulteriore aspetto che merita qualche considerazione. Se leggi i nostri contenuti sai che il termine SAP Security, una nicchia di tutti gli aspetti legati ai sistemi SAP, in realtà è un piccolo mondo. Formato da tante sfaccettature. 

L'essere "tranquillo", quindi, non è così facile da raggiungere. Premesso che nella sicurezza informatica in generale è difficile essere sicuri che un sistema (soprattutto se complesso) sia totalmente esente da debolezze. 

Ci sono molti aspetti da considerare. Se hai sistemato la parte di protezione dei dati e tracciatura nella parte applicativa, non puoi dimenticati degli aspetti legati al database (ovvero cosa "sta sotto" la parte applicativa) così come devi proteggere anche gli aspetti legati alla comunicazione delle informazioni e così via.

Non per ultimo l'aspetto delle personalizzazioni. Infatti, queste possono spesso rappresentare delle lacune. Ovvero lo sviluppo di funzionalità specifiche per il cliente (fuori dallo standard SAP) che tuttavia non contemplano i meccanismi di tracciatura. Quindi eventuali azioni svolte tramite queste funzionalità non erediterebbero i meccanismi di tracciatura standard (se non esplicitamente inseriti).

Ma cosa a proposito di super user o amministratori?

Anche loro rientrano in quanto sopra oppure gli amministratori sono "esonerati"?

In questo articolo "Amministratore di sistema" abbiamo affrontato l'argomento. Ovvero come posso tracciare "tutte" le azioni svolte da queste tipologie di utenti. Attenzione, ancora una volta, devo capire quali sono i log attivi (altrimenti non avverrà nessun tipo di tracciatura)

Così come è importante sapere e conosce che chi ha accessi amministrativi al sistema può di fatto anche cancellare le tracce. Purtroppo, è possibile, esistono infatti degli strumenti (del tutto leciti) che possono essere usati appositamente per cancellare i log (chiaramente con finalità di retention, quindi raggiunti i termini temporali di archiviazione questi possono essere distrutti).

Ecco un amministratore potrebbe chiaramente utilizzare impropriamente questi strumenti, potrebbe essere quindi a maggior ragione attuare delle politiche di separazione dei compiti anche tra gli amministratori del sistema (Segregation Of Duties)

Potenzialmente, in alcuni casi, cancellando le tracce dei log (come abbiamo visto in questo ulteriore articolo legato ad una funzionalità amministrativa del sistema chiamata SE16).

Come potrei in parte tutelarmi? Ad esempio, attivando degli ulteriori meccanismi/sistemi di correlazione di log ed eventi chiamati SIEM.

In questo caso alcuni log selezionati (solitamente quelli più critici) non solo verrebbero registrati nel sistema SAP (dove potrebbero essere cancellati lecitamente o anche illecitamente) ma inviati anche ad un sistema di correlazione eventi terzo. 

In questo caso l'eventuale amministratore non dovrebbe solo far perdere le proprie tracce in un sistema ma agire su sistemi diversi. Quindi più complesso.

In altre parole, dobbiamo cercare di far in modo che sia più complesso riuscire a "cancellare" le proprie tracce. Ma questo richiede comunque un notevole investimento, non solo in aspetti tecnologici ma anche di processo ed organizzativi. Questi a mio avviso determinati tramite una ponderata valutazione del rischio.

Esistono ulteriori casi subdoli?

Che cosa intendo? Una brutta abitudine, per fortuna poco diffusa, di condividere le utenze oppure di avere una utenza condivisa da più persone.

Ecco in queste situazioni chiaramente, molti dei log attivi nel sistema potrebbero essere meno efficaci. Se una utenza intestata a mio nome fosse condivisa con altre persone, in questo caso le modifiche a sistema risulteranno comunque intestate alla mia utenza, ma nella realtà non svolte dalla mia persona.

Qui purtroppo l'aspetto organizzativo e del modello di accountability dell'azienda risulta ancora più importante, rispetto agi aspetti prettamente tecnologici.

La tecnologia, infatti, non può essere disaccoppiata dagli aspetti organizzativi e della formazione del personale. Nonostante ci siano modi per potersi (in alcuni casi) accorgersi di queste tipologie di comportamenti potrebbe non essere così facile ed immediato.