Conviene cancellare dal sistema le utenze che non devono più accedere?
Oppure è meglio lasciarle impedendone l'accesso? Quali pro e contro e cosa suggerisce di fare SAP?
Esistono diversi modi e termini, spesso utilizzati come sinonimi, per impedire l'accesso ai sistemi SAP a persone che, ad esempio hanno lasciato l'azienda.
Per accedere ad un sistema, anche SAP, come sappiamo serve avere una utenza, più in generale delle credenziali (dirette, ad esempio password, oppure indirette token o simili). Per poter effettuare la fase di autenticazione.
Le modalità possono essere diverse:
Le azioni sopra di fatto impediscono l'accesso da parte di un utente, ma hanno impatti diversi. Inoltre, non sono sempre tutte disponibili. In alcuni sistemi può non esserci un concetto di delimitazione temporale (es. utente valido dalla data o utente valido fino alla data).
Nel caso dei sistemi SAP è possibile impostare quindi una data di validità dell'utenza (iniziale o finale). Utile nel caso debba essere creata una utenza in anticipo rispetto all'ingresso/utilizzo effettivo dell'utente oppure nel caso in cui l'utenza (quindi la persona) lasci l'azienda (o la collaborazione) in una data pre-stabilita (eventualmente prorogabile).
Nel caso sotto un esempio di questa funzione tramite la transazione SU01 dei sistemi ABAP.
Ma quali sono le transazioni security? Scaricale qui.
Allo stesso modo, sempre utilizzando la medesima transazione lo stato di blocco utente
Qui in realtà possono esserci diversi stati di blocco:
Altri eventuali stati nella tabella USR02 campo UFLAG (nel caso dei sistemi ABAP) non sono leciti e quindi rappresentano di fatto una inconsistenza da indagare (vedi anche OSS note 1887820 - Incorrect User Lock Status (UFLAG) in table USR02 - SAP ONE Support Launchpad).
Tips. Se usi SAP GRC Access Control e vuoi gestire questi stati, dai una occhiata a questa nota OSS 2791368 - How to customize what UFLAG lock codes should be considered valid lock codes, when synchronizing users? - SAP ONE Support Launchpad
Infine la disattivazione della password, che tuttavia, non rappresenta un metodo ideale per impedire l'accesso ai sistemi.
Ma cosa conviene fare quindi?
Tecnicamente questa opzione è prevista, chiaramente, e possibile. Senza particolari controindicazioni. Ovvero cancellando l'utenza non vengono cancellati anche i dati che ha gestito. Tutte le azioni che ha svolto a sistema rimangono come traccia (logs).
Esiste una procedura segnalata da SAP in due passaggi
Attraverso il programma: RSUSR_LOCK_USERS è possibile effettuare diverse selezioni per individuare delle utenze che non usano il sistema (o volutamente scadute/bloccate)
Dettaglio delle selezioni:
Proseguendo poi tramite la transazione SU10DELETE alla loro cancellazione.
Solo una scomodità (che può essere, in parte mitigata), dopo la cancellazione di una utenza può esserci, ovvero in tutti i documenti di modifica rimarrà solo l'utenza (USERID) non sarà possibile risalire (direttamente) al nome e cognome della persona, una volta cancellata. Vedi anche "OSS 2793595 - What is best practice to deal with terminated SAP users?"
Questo può non essere un grande problema, soprattutto se la naming delle utenze è "parlante" (leggi qui come scegliere la naming delle userid). Ma nel caso in cui sia stata scelta una naming non parlante, ad esempio la matricola aziendale, può non essere così semplice.
Dicevamo, direttamente. Infatti SAP conserva anche queste informazioni, ma in tabelle secondarie (del SAP Office) che sarebbero da interrogare ad hoc per recuperare queste informazioni. Vedi tabelle seguenti, inserendo l'utenza nel campo USRNAM della tabella SOUD è possibile recuperane il nome e cognome.
Ti segnalo anche questa nota che permette di vedere le modifiche fatte su nome e cognome di una certa utenza (3015177 - How to check when First Name or Last Name was changed in SU01)
Rimane, alla fine, una scelta di ogni cliente. SAP non suggerisce di farlo in quanto
In generale un utente potrebbe essere cancellato se tutte le azioni svolte da questo utente in termini di transazioni a sistema (qui intendo ad esempio documenti creati a sistema) o configurazioni svolte (o anche logs), non siano più attive o comunque siano state cancellate.
In questo caso allora anche l'utente potrebbe essere cancellato (o archiviato). Un aiuto su questa parte potrebbe avvenire tramite l'uso della transazione SE16SL (se disponibile nel tuo sistema).
Ultima considerazione legata al GDPR. Anche nel caso delle utenze ovviamente dovrebbe essere tenuto conto di questo aspetto.
Tramite l'utilizzo del prodotto SAP Information Lifecycle Management è possibile attivare degli ulteriori controlli proprio su questo aspetto. Ad esempio introducendo un ulteriore oggetto autorizzativo S_USER_BLK che permette di controllare l'accesso ai dati archiviati (dell'anagrafica utente).
Una volta gestito il periodo di retention ed anche l'eventuale Veto Checks, se presente.