Secondo le leggi russe, qualsiasi azienda che gestisce i dati personali dei propri utenti in Russia diventa un operatore dei dati personali, che lo voglia o no. Questo comporta una serie di obblighi formali e procedurali che non ogni attività è in grado o desidera sostenere autonomamente.
Come dimostra la pratica, è del tutto comprensibile che non lo desiderino, perché quest'area di conoscenze è ancora così nuova e poco testata che anche i professionisti incontrano difficoltà e domande. Oggi parleremo di come abbiamo realizzato un progetto per la conservazione dei dati personali per il nostro cliente e quali complessità non evidenti abbiamo affrontato.
Come abbiamo aiutato a proteggere i dati secondo il 152-FZ
All'inizio del 2019, siamo stati contattati dall'azienda LLC "Smart-Service", sviluppatore della piattaforma per la gestione dell'assistenza tecnica. e dell'applicazione per lo scambio di contatti. .
La prima soluzione consente di automatizzare il processo di assistenza delle attrezzature in diversi settori, dalla configurazione delle macchine da caffè e dei condizionatori d'aria 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 trattano i dati degli utenti, classificabili come 'personali' in conformità con il 152-FZ. In questo caso, la legge stabilisce una serie di restrizioni sui sistemi di archiviazione di tali dati personali per garantire il livello di protezione richiesto ed escludere il rischio di accesso non autorizzato per furto o uso improprio.
È necessario rispettare la legge, ma "Smart-Service" non intendeva sviluppare internamente 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 trasferito le capacità server dell'ambiente di lavoro in una zona di rete protetta del nostro data center, certificata in conformità con i requisiti stabiliti nel 152-FZ - il cosiddetto 'Cloud Protetto'.
COME FUNZIONA IL CLOUD PROTETTO
Qualsiasi sistema informativo che tratta dati personali deve soddisfare tre requisiti principali:
- L'accesso ai server di archiviazione e elaborazione dei dati deve avvenire attraverso un canale VPN con crittografia secondo il GOST;
- I server di archiviazione e elaborazione dei dati devono essere costantemente monitorati dalla protezione antivirus per verificare l'assenza di vulnerabilità;
- L'SAN deve essere situato in reti isolate.
Posizioniamo le risorse server del cliente in zone separate che soddisfano i requisiti della legge 152-FZ e aiutiamo a ottenere una certificazione di conformità.
Architettura di un'infrastruttura virtuale protetta per LLC «Smart Service».
Progresso dei lavori
Il primo accordo sui lavori è stato raggiunto a giugno 2019, che può essere considerata 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 svolgere il progetto senza interrompere il normale funzionamento di entrambi i sistemi.
Pertanto è stato redatto e concordato un piano d'azione chiaro suddiviso in 4 fasi:
- preparazione,
- migrazione,
- test e verifica in condizioni reali,
- inclusione dei sistemi di monitoraggio e limitazione degli accessi.
Per precauzione, abbiamo previsto una procedura di recupero in caso di imprevisti (DRP). Inizialmente, 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 della funzionalità dei sistemi.
La fase più complicata, in cui poteva "andare storto" qualcosa, è stata la migrazione. Inizialmente avevamo pianificato di eseguire la migrazione trasferendo completamente le macchine virtuali. Questa era l'opzione più logica, poiché non richiedeva l'impiego di ulteriori risorse per la riconfigurazione. Sembrava infatti che non ci potesse essere niente di più semplice di un vMotion.
Inaspettatamente
Tuttavia, come spesso accade nei progetti in un campo relativamente nuovo, è successo qualcosa che non ci si aspettava.
Poiché ogni macchina virtuale occupa 500 — 1.000 GB, copiare tali volumi anche all'interno di un singolo data center ha richiesto circa 3-4 ore per ogni macchina. Di conseguenza, non ci siamo riusciti a rimanere nel tempo previsto. Questo è avvenuto a causa delle limitazioni fisiche del sistema di archiviazione durante il trasferimento dei dati in vCloud.
Il bug della versione utilizzata di vCloud ha impedito di organizzare lo Storage vMotion per una macchina virtuale con tipi di dischi diversi, quindi è stato necessario cambiare i dischi. Di conseguenza, siamo riusciti a trasferire le macchine virtuali, ma ci è voluto più tempo di quanto previsto.
Un secondo aspetto che non avevamo previsto sono le limitazioni nel trasferimento del cluster DB (Failover Cluster MS SQLServer). Pertanto, abbiamo dovuto trasferire il cluster a funzionare con un solo nodo e lasciarlo al di fuori della zona protetta.
È interessante notare che, per ragioni ancora sconosciute, a seguito del trasferimento delle macchine virtuali, il cluster delle applicazioni si è distrutto e ha dovuto essere ricostruito.
A seguito del primo tentativo, abbiamo ottenuto uno stato insoddisfacente dei sistemi e abbiamo dovuto riprendere la pianificazione e l'elaborazione delle opzioni.
Tentativo n. 2
Rivedendo l'errore, il team ha capito che era meglio duplicare l'infrastruttura nella zona protetta e copiare solo i file con i dati. È stata presa la decisione di non richiedere al cliente un supplemento per le risorse server aggiuntive necessarie per completare la migrazione.
Di conseguenza, quando i cluster nella zona protetta sono stati totalmente duplicati, la migrazione è avvenuta senza problemi.
Successivamente è stato necessario separare le reti della zona protetta e quella non protetta. Qui ci sono stati solo alcuni piccoli scompensi nel funzionamento. La fase di test dell'intero sistema nella zona protetta senza alcuna protezione è riuscita a partire normalmente. Dopo aver raccolto statistiche positive sul funzionamento del sistema in tale modalità, siamo passati all'ultima fase: l'avvio dei sistemi di protezione e la limitazione dell'accesso.
Esito positivo e lezione utile
In definitiva, grazie agli sforzi congiunti insieme al cliente, siamo riusciti a apportare cambiamenti significativi all'infrastruttura server esistente, il che ha permesso di aumentare l'affidabilità e la sicurezza della conservazione dei dati sensibili, riducendo notevolmente i rischi di accesso non autorizzato e ottenendo un certificato di conformità per la conservazione, un traguardo che non è stato ancora raggiunto da tutti gli sviluppatori di software simile.
In sintesi, il complesso di lavori del progetto si è presentato così:
- È stata organizzata una rete dedicata;
- In totale sono stati migrati due cluster, composti da cinque macchine virtuali: il cluster di failover per database (due macchine virtuali), il cluster di applicazioni Service Fabric (tre macchine virtuali);
- Sono state effettuate le impostazioni dei sistemi di protezione e crittografia dei dati.
Sembra tutto chiaro e logico. Tuttavia, nella pratica, si rivela un po' più complicato. Abbiamo nuovamente constatato che, nel lavorare su ogni singolo compito di questo tipo, è necessario un livello di attenzione massima per i "dettagli", che si rivelano non essere affatto dettagli, ma fattori determinanti per il successo dell’intero progetto.
Fonte: habr.com
