È davvero possibile fare in modo che i consulenti esterni non abbiano l’accesso ai sistemi produttivi SAP? 

Chiaramente ci sono diverse casistiche, consulenze occasionali oppure consulenze continuative, ad esempio i contratti di manutenzione.

È davvero necessario rilasciare l’accesso ai sistemi produttivi anche in questo ultimo caso? Riusciamo a controllare cosa avviene e perché viene richiesto?

1. Che tipo di accesso e per quanto?

Una prima discriminante potrebbe essere quella di evitare, ovviamente, di rilasciare delle utenze di consulenti esterni con SAP_ALL ma assegnando delle autorizzazioni specifiche e limitate al tipo di lavoro da svolgere.

Ricordiamo tuttavia che non è sempre immediato ritagliare un ruolo “da consulente” infatti, per la natura di SAP, un sistema fortemente integrato, è difficile stabilire i confini di lavoro.

Inoltre, è corretto immagine anche i vantaggi e svantaggi:

• Limito fortemente le autorizzazioni? Probabilità di maggiori errori autorizzativi da gestire. Ho un team sufficientemente pronto e preparato a rispondere?
• Lascio troppo aperto? Rischio di danni, anche involontari o principio del minimo privilegio non applicato

Una volta definite le corrette abilitazioni, che spesso in questi casi potrebbero non essere un elenco di transazioni definito ma un range molto ampio di transazioni, è importante stabiliture una durata di accesso.

2. L’importanza degli accordi di non divulgazione o riservatezza

Di fondamentale importanza è quello di definire degli accordi di non divulgazione o NDA (Non Disclosure Agreement) con i propri partner commerciali, quindi anche con società di consulenza che hanno accesso ai nostri sistemi informatici. In particolare SAP. Senza dimenticare l'applicazione delle politiche di sicurezza dei dati per i fornitori. Ad esempio richiedendo la crittografia dei dati aziendali (verificando tramite audit che questo avvenga).

3. Attenzione soprattutto durante i progetti

Il momento del rilascio e supporto post go-live del progetto rappresenta sempre un momento molto critico. Se la tematica di gestione delle autorizzazioni in questi momenti non viene delineata per tempo, sarà difficile all’ultimo momento affrontare questa situazione.

Il risultato sarà l’attribuzione di abilitazioni SAP_ALL (le quali non hanno una scadenza automatica, a differenza dei ruoli dove è possibile stabilire a priori un periodo di validità, scaduto il quale vengono automaticamente rimossi).

4. Come tracciare queste attività e queste tipologie di accessi?

Di fondamentale importanza è il tracciare cosa avviene nell’ambiente produttivo durante l’utilizzo. La soluzione GRC Access Control nel modulo Emergency Access Management può essere una soluzione. Ricorda che i caricamenti massivi devono essere fatti con una utenza dedicata e non una utenza di emergenza (questo per non appesantire troppo i log). Diverse sono le possibilità la più comune è quella di attivare il Security Audit Log (leggi qui per ulteriori approfondimenti).

5. L’uso del DEBUG

Spesso può succedere che i consulenti richiedano l’utilizzo di questa particolare funzionalità. Il DEBUG in produzione è una delle attività più critiche in quanto permette di bypassare qualsiasi controllo (impostato da SAP o di security).

Ogni azione di questo tipo dovrebbe essere classificata, catalogata e individuata la motivazione dell’utilizzo. Per porre in essere delle alternative che evitino l’utilizzo di questa modalità.

Se ti viene richiesto il rilascio del DEBUG più di cinque volte all’anno, potrebbe essere il momento di indagare meglio sulle motivazioni dell’utilizzo.