BULGARI

SECURITY: DATA ENCRYPT/DECRYPT

 SECURITY ENCRYPT/DECRYPT OVERVIEW DELLE REGOLE (OUR UNDERSTANDING)
Clienti con nessun Flag Autorizzativo
In COSMO attualmente sono presenti clienti che NON HANNO nessun flag autorizzativo (Marketing_Authorization = NO; Profiling_Authorization = NO)
Su tali clienti non possono essere fatte ne azioni di marketing ne di profilazione. Tali clienti sono in Cosmo per gestire attività di After Sales o perchè hanno
richiesto informazioni rispetto a un prodotto ad esempio;
Attualmente non è ancora definito  il tempo di permanenza nella base clienti di COSMO;
Bulgari sta definendo le politiche di persistenza del dato in COSMO

Clienti con Marketing_Authorization

Tutti i clienti che HANNO dato il consenso al contatto ma che NON HANNO  dato l'autorizzazione alla profilazione ( Marketing_Authorization = YES; 
Profiling_Authorization = NO), possono essere contattati ma non possono essere profilati (pertanto per questi clienti non può girare l'algoritmo del profiling e
non può essere calcolata la propensione all'acquisto)

Clienti con Profiling_Authorization

Tutti i clienti che NON HANNO dato il consenso al contatto ma che HANNO dato l'autorizzazione alla profilazione ( Marketing_Authorization =
NO;  Profiling_Authorization = YES), non possono essere contattati ma possono essere profilati

• un cliente che decide di dare il consenso successivamente a N acquisti, può essere contattato e profilato solo dalla data di sottoscrizione delle
autorizzazione e in nessun caso si potrà andare in dietro nel tempo per associare a lui precedenti acquisti
• le vendite per clienti superiori ai 10 anni devono essere cancellate, pertanto il calcolo Lifetime potrà avere una profondità massima di 10 anni.
 SECURITY ENCRYPT/DECRYPT

Requisito funzionale
Per tutti i clienti che non hanno dato il consenso al trattamento dei dati personali è necessario effettuare l’encrypt dei codice
cliente prima di salvarlo in Azure. Dovrà essere possibile on-demand effettuarne il decrypt solo su richiesta espressa ed
autorizzata

Requisito tecnico
Effettuare l’encrypt e il decrypt dei dati utilizzando due chiavi diverse, salvate in «luoghi» diversi

Finding
Utilizzare una metodologia di cifratura e decifratura del dato di tipo asimmetrico
 SECURITY ENCRYPT/DECRYPT

SCENARIO 1
Utilizzo Java Extension di Informatica Cloud delle librerie standard java.security che implementano l’algoritmo RSA a
chiave asimmetrica a 2048 bit con random padding

Pro
• Utilizzo di librerie java standard e certificate che non richiedono installazioni aggiuntive (out-of the-box con la jdk)
• Utilizzo di un algoritmo largamente diffuso
• Effort di implementazione Medio

Contro
• Richiesto il decrypting dell’ id Account per la gestione del delta nel caso in cui lo stesso è stato precedentemente
criptato per garantire la consistenza del dato
• Richiesta la possibilità di accedere alla chiave privata run-time ad ogni esecuzione

* Note
Necessità di un canale sicuro di comunicazione per l’accesso alla chiave privata
 SECURITY ENCRYPT/DECRYPT

SCENARIO 2
Utilizzo Java Extension di Informatica Cloud e librerie java bouncycastle che implementano l’algoritmo RSA a chiave
asimmetrica a 2048 eliminando il random padding

Pro
• Non richiesto utilizzo chiave privata
• Effort di implementazione Medio

Contro
• Utilizzo di librerie java certificate ma non standard
• Richiedono installazioni e configurazioni aggiuntive
• Livello di sicurezza minore rispetto allo scenario 1
• Verifica effettiva applicabilità no-padding in ambiente Bulgari
* Note
Verificare tramite test specifici all’interno dell’ environment Bulgari la fattibilità della soluzione (esempio: verifica
compatibilità con jdk secure agent ecc.)
 SECURITY ENCRYPT/DECRYPT

SCENARIO 3

Utilizzo Java Extension di Informatica Cloud delle librerie standard java.security che implementano l’algoritmo RSA a chiave asimmetrica a
2048 bit con random padding con gestione lato software degli Account che modificano il consenso successivamente all’ initial load.

Pro
• Non richiesto utilizzo chiave privata
• Utilizzo di librerie java.security certificate e standard che non richiedono installazione

Contro

• Effort di implementazione alto

• Impossibilità di ricondurre un Id Account cifrato al suo corrispettivo Id Account non cifrato
• Gli Account che modificano lo stato del consenso dovranno necessariamente essere cancellati e ricaricati ad ogni run
SECURITY ENCRYPT/DECRYPT

BCK
 SECURITY ENCRYPT/DECRYPT

1. Memorizzazione degli Account che hanno negato il consenso su tabelle separate e specializzate (STG-ODS-DMT)
2. Creazione di una tabella centralizzata che va popolata in Truncate/Insert ad ogni Run e che memorizza oltre alle informazioni di tutti gli Account che al momento del Run hanno consenso al trattamento dei dati =N e delle chiavi delle
relative entità relazionate (ad esempio la chiave delle Activity ecc.)
3. Ad ogni Run eseguire la Truncate delle tabelle ODS e DTM specializzate relative agli Account che hanno consenso al trattamento dei dati =N
4. Partire dalla tabella centralizzata creata al punto 2 e popolare ODS e DTM delle tabelle specializzate
5. Aggiornare le tabelle relazionate  (ad esempio Activity) propagando il nuovo id cifrato dell' Account sia strato ODS , DMT e HDFS, avendo le chiavi disponibili sulla tabella centralizzata creata al punto 2

  
Gestione di alcune casistiche:

Casistica N°1 => Account che varia il consenso al trattamento dati da Y a N :

Andrà cancellato fisicamente o logicamente tutto il set di dati dell' Account  (Parent/Child)  sulle tabelle ODS e DMT standard utilizzate ad oggi.
I record cancellati in questo caso verranno successivamente intercettati dal nuovo processo e caricati nelle tabelle specializzate (punto 1,2,3 ,4 e 5)

Casistica N°2 => Account che varia  il consenso al trattamento dati da N a Y:
Andranno cancellati i record orfani (record che non hanno più un Account associato) dopo aver eseguito i punti 1,2,3, 4  e 5
Andrà ricaricato l' Account e tutte le entità relazionate (ad esempio le Activity) sulle tabelle ODS e DMT standard.

Casistica N°3 => Aggiunta di un nuovo record (ad esempio Activity) relazionato ad un Account con consenso = N
Il record viene intercettato come da criptare e vengono applicate le stesse logiche elencate dal punto 2 al punto 5

Casistica N°4 => Aggiunta di un nuovo record (ad esempio Activity) relazionato ad un Account con consenso =Y
Il record viene intercettato e gestito dall'attuale processo