Data Protection Officer (Responsabile della Protezione dei Dati), cosa deve fare nei sistemi SAP? 

Data Protection Officer chi è?

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.

1 Come controllare i dati esportati da SAP?

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.

2 Come sono gestite e controllate le interfacce verso sistemi terzi?

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.

3 Il controllo dello sviluppo dei programmi

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.

4 La profilazione degli accessi

È 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.

• Come viene controllato che le persone non autorizzate ad accedere ai dati personali non possano accedere veramente?
• Nel registro di trattamento dei dati personali, sono state indicate anche a livello tecnico le tabelle ed i campi rilevanti in SAP per la gestione dei dati personali? Questo potrebbe aiutare a capire chi ha visto cosa, magari tramite lo strumento di SAP UI Logging (vedi punto successivo)
• Ancora dei SAP_ALL in giro nel sistema?

5 Il controllo di chi vede quale dato (Data Masking e Data Logging) e come

Tramite questo strumento chiamato SAP Field Masking è possibile utilizzare due strumenti:

• SAP UI Masking
• SAP UI Logging

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.

6 Gli ambienti di test come sono gestiti

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:

• Copiare selettivamente dei dati (magari solo l'ultimo anno oppure solo i dati di una certa società)
• Effettuare delle attività di scrambling dei dati. Ovvero durante la copia andare a modificare fisicamente i dati facendo in modo che i dati originali non siano più presenti. Garantendo se possibile la coerenza del dato stesso. Un esempio?

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).