Data Protection Officer (Responsabile della Protezione dei Dati), cosa deve fare nei sistemi SAP?
Il Data Protection Officer (DPO), tradotto nella normativa italiana come Responsabile per la Protezione dei Dati(RPD) è una figura che è stata introdotta dal GDPR (il regolamento europeo per la gestione dei dati personali).
È una figura che supporta il titolare del trattamento, in maniera indipendente, a proteggere e gestire i dati personali. Gli articoli 37, 38 e 39 del regolamento europeo definisco questa figura.
Uno degli obiettivi della figura del DPO è quello di condurre degli audit periodici per verificare che i dati personali siano gestiti correttamente.
Ma cosa fare all'interno di SAP per svolgere questa verifica? Ecco un elenco di attività da svolgere.
Può essere molto semplice esportare dei dati da SAP. Uno degli aspetti di verifica potrebbe essere proprio quello di capire quanto il sistema SAP permetta o meno o come sia protetto rispetto all'esportazione di dati.
Ne abbiamo parlato anche in questo articolo dedicato: come esportare i dati da SAP?
L'utilizzo di strumenti come il SAP DAM Dynamic Authorization Management di NextLabs possono essere un ulteriore aiuto.
Ricorda che anche tramite il SAP Security Audit Log puoi vedere chi ha scaricato cosa da SAP.
Una nuova funzionalità introdotta da SAP è l'UCON ovvero Unified Connectivity.
Questo strumento permette di andare a ragionare in maniera diversa, dall'attuale comportamento di default sulla gestione delle chiamate verso SAP da parte di un sistema terzo.
Di default infatti i servizi esposti da SAP sono richiamabili, a seguito dell'autenticazione e della fase di controllo autorizzativo è possibile eseguire una certa funzionalità ad esempio interrogare o estrapolare dei dati (tramite il richiamo di function o BAPI).
Tramite questo strumento, incluso nella suite SAP, è possibile attivare un log per capire quali siano le chiamate effettuate e creare a seguito una whitelist di funzioni ammesse per essere richiamate e da chi.
Oltre agli aspetti di sicurezza e sviluppo sicuro, leggi qui le 10 regole base per lo sviluppo sicuro in SAP anche la minimizzazione dei dati personali è importante.
In altre parole tutti i report devono esporre solamente i dati personali strettamente correlati alla fruizione della funzionalità.
Tutti i dati personali eventualmente presenti ma non strettamente necessari dovrebbero essere rimossi.
Questo principio viene anche chiamato Data Minimization.
È sicuramente un aspetto fondamentale per garantire che solo le persone formalmente autorizzate ad accedere a determinati dati (in questo caso quelli personali) siano autorizzate a farlo.
In questo caso anche la sola lettura può essere critica.
Tramite questo strumento chiamato SAP Field Masking è possibile utilizzare due strumenti:
Che permettono rispettivamente di, mascherare o nascondere con * (asterischi) un certo campo oppure indicando le transazioni ed i campi interessati porre sotto "trace" chi ha visto un determinato dato.
Solitamente nei landscape SAP esistono almeno tre ambienti, ovvero quello di sviluppo, il test e la produzione.
Più o meno frequentemente il sistema di produzione viene copiato nel sistema di test o pre-produzione.
In questi ultimi sistemi la profilazione può essere più lasca rispetto a quella della produzione. Vanificando eventuali segregazioni gestite nell'ambiente produttivo. Nel caso in cui un utente in ambiente di test abbiamo permessi più ampi rispetto alla produzione.
Per questo motivo è necessario valutare se porre in essere delle logiche di copia dei dati che tengano conto di:
Nel sistema di produzione la mia utenza si chiama "Massimo Manara" nel sistema di test una volta copiato mi chiamerò Renato Rossi. Attenzione non ha caso sarò sempre maschio, questo per garantire ad esempio la coerenza del dato e della popolazione (nel caso in cui si stia parlando di persone).