Secondo le leggi russe, qualsiasi azienda che gestisce dati personali dei propri utenti in Russia diventa un operatore di Dati Personali, che lo desideri o meno. Questo comporta una serie di obblighi formali e procedurali che non tutte le aziende possono o vogliono affrontare autonomamente.
Come dimostra la pratica, è del tutto comprensibile non volerlo fare, poiché quest’area di conoscenza è così nuova e poco testata che anche i professionisti incontrano difficoltà e domande. Oggi parleremo di come abbiamo implementato un progetto per la conservazione dei dati personali per il nostro cliente e quali difficoltà non evidenti abbiamo affrontato.
Come abbiamo aiutato a proteggere i dati secondo la legge 152-FZ
All'inizio del 2019, ci ha contattato la società LLC «Smart-Service», sviluppatore di una piattaforma per la gestione del servizio clienti e di un'applicazione per lo scambio di contatti .
La prima soluzione consente di automatizzare il processo di assistenza alle attrezzature in vari settori, dalla configurazione delle macchine da caffè e dei climatizzatori negli uffici alla riparazione di turbine a gas. La seconda è un costruttore online per creare biglietti da visita elettronici basati su codici QR.
Biglietto da visita online myQRcards.
Entrambi i sistemi memorizzano e elaborano i dati degli utenti, classificabili come 'personali' ai sensi della legge 152-FZ. In questo caso, la legge impone una serie di restrizioni ai sistemi di archiviazione di tali dati personali per garantire il livello di protezione richiesto ed escludere il rischio di accessi non autorizzati con l'obiettivo di furto o utilizzo improprio.
La legge deve essere rispettata, ma «Smart Service» non aveva pianificato di sviluppare internamente le competenze per la protezione dei dati personali. Pertanto, i servizi e i dati condivisi dai loro utenti sono stati trasferiti a Linxdatacenter. «Smart Service» ha spostato le capacità server dell'ambiente di lavoro in una zona di rete protetta del nostro data center, certificata in conformità con i requisiti stabiliti nella legge 152-FZ, il cosiddetto «Cloud Protetto».
COME È STRUTTURATO IL CLOUD PROTETTO
Qualsiasi sistema informativo che elabora dati personali deve soddisfare tre requisiti fondamentali:
- l'accesso ai server di archiviazione e elaborazione dei dati deve avvenire tramite un canale VPN con crittografia secondo le norme GOST;
- i server di archiviazione e elaborazione dei dati devono essere costantemente monitorati da antivirus per l'assenza di vulnerabilità;
- Il sistema di archiviazione dei dati deve essere collocato in reti isolate.
Collocchiamo le capacità server dei clienti in aree separate che soddisfano i requisiti della legge 152-FZ e aiutiamo a ottenere la dichiarazione di conformità.
Architettura dell'infrastruttura virtuale protetta per LLC «Smart Service».
Progresso dei lavori
L'approvazione iniziale dei lavori è stata effettuata a giugno 2019, che può essere considerate la data di inizio del progetto. Tutti i lavori devono essere svolti in un ambiente "live" con migliaia di richieste al giorno. Naturalmente, era necessario completare il progetto senza interrompere il normale funzionamento di entrambi i sistemi.
Pertanto, è stato redatto e approvato un piano d'azione chiaro, suddiviso in 4 fasi:
- preparazione,
- migrazione,
- test e verifica in condizioni reali,
- attivazione dei sistemi di monitoraggio e limitazione degli accessi.
Per ogni evenienza, abbiamo previsto una procedura di recupero in caso di situazioni impreviste (DRP). Secondo il piano iniziale, i lavori non avrebbero dovuto richiedere molto tempo e risorse e dovevano concludersi a luglio 2019. Ogni fase prevedeva, alla fine, un completo collaudo della disponibilità di rete e delle funzionalità dei sistemi.
Il passaggio più complesso, in cui poteva "andare storto" qualcosa, è stata la migrazione. Inizialmente, avevamo pianificato di eseguire la migrazione trasferendo interamente le macchine virtuali. Questa era l'opzione più logica, poiché non richiedeva il coinvolgimento di risorse aggiuntive per la riconfigurazione. Cosa potrebbe essere più semplice di vMotion?
Inaspettatamente
Tuttavia, come spesso accade nei progetti in ambiti relativamente nuovi, è successo ciò che non ci aspettavamo.
Poiché ogni macchina virtuale occupa tra 500 e 1.000 GB, copiare tali volumi anche all'interno dello stesso data center ha richiesto circa 3-4 ore per ogni macchina. Di conseguenza, non siamo riusciti a rispettare il tempo assegnato. Ciò è stato causato da limitazioni fisiche del sottosistema di archiviazione durante il trasferimento dei dati in vCloud.
Un bug della versione utilizzata di vCloud non ha consentito di organizzare Storage vMotion per macchine virtuali con tipi di disco diversi, quindi è stato necessario cambiare i dischi. Alla fine, siamo riusciti a trasferire le macchine virtuali, ma ci è voluto più tempo del previsto.
Il secondo aspetto che non avevamo previsto erano le limitazioni nel movimento del cluster DB (Failover Cluster MS SQLServer). Di conseguenza, abbiamo dovuto ridurre il cluster a un'operazione con un solo nodo e lasciarlo al di fuori della zona protetta.
È notevole: per ragioni che non sono ancora chiare, durante il trasferimento delle macchine virtuali il cluster delle applicazioni si è disintegrato, e abbiamo dovuto ricostruirlo da zero.
Dalla prima tentativa, abbiamo ottenuto uno stato insoddisfacente dei sistemi e siamo stati costretti a riprendere la pianificazione e l'elaborazione delle opzioni.
Tentativo n. 2
Dopo aver lavorato sugli errori, il team ha capito che era più corretto duplicare l'infrastruttura nella zona protetta e copiare solo i file con i dati. È stata presa la decisione di non richiedere al cliente un pagamento supplementare per le risorse server aggiuntive necessarie per completare la migrazione.
Di conseguenza, quando i cluster nella zona protetta sono stati completamente duplicati, la migrazione è avvenuta senza problemi.
Successivamente è stato necessario separare le reti della zona protetta e non protetta. Qui ci sono stati solo alcuni brevi interruzioni nel funzionamento. La fase di test di tutto il sistema nella zona protetta senza alcuna protezione è riuscita a partire in modalità normale. Dopo aver raccolto statistiche positive sul funzionamento del sistema in questa modalità, siamo passati all'ultima fase: l'attivazione dei sistemi di protezione e la restrizione dell'accesso.
Esito positivo e lezione utile
Alla fine, grazie agli sforzi congiunti con il cliente, siamo riusciti a apportare cambiamenti significativi all'attuale infrastruttura server, il che ha permesso di migliorare l'affidabilità e la sicurezza della conservazione dei dati personali, riducendo notevolmente i rischi di accesso non autorizzato e ottenendo un certificato di conformità ai requisiti di stoccaggio — un traguardo non ancora raggiunto da molti sviluppatori di software simile.
In sintesi, l'insieme delle attività del progetto si è presentato così:
- È stata organizzata una rete dedicata;
- Complessivamente sono stati migrati due cluster, composti da cinque macchine virtuali: un cluster di failover per database (due macchine virtuali), un cluster Service Fabric per applicazioni (tre macchine virtuali);
- Sono state effettuate impostazioni per la protezione e la crittografia dei dati.
Sembra tutto chiaro e logico. Tuttavia, nella pratica, risulta un po' più complicato. Abbiamo nuovamente constatato che per affrontare ciascun compito di questo tipo è richiesto un elevato livello di attenzione ai "dettagli", che si rivelano, invece, fattori decisivi per il successo dell'intero progetto.
Fonte: habr.com
