Secondo le leggi russe, qualsiasi azienda che lavora con i dati personali dei propri utenti in Russia diventa un operatore dei dati personali, che lo voglia o no. Ciò le impone una serie di obblighi formali e procedurali che non tutte le imprese possono o vogliono sostenere da sole.
Come dimostra la pratica, è giusto che non lo voglia, perché quest'area della conoscenza è ancora così nuova e non testata nella pratica che sorgono difficoltà e domande anche per i professionisti. Oggi parleremo di come abbiamo implementato un progetto per archiviare i dati personali del nostro cliente e di quali difficoltà non evidenti abbiamo incontrato.
Come abbiamo contribuito a proteggere i dati secondo 152-FZ
All'inizio del 2019 siamo stati contattati da Smart-Service LLC, sviluppatore di una piattaforma per la gestione dei servizi e applicazioni di condivisione dei contatti .
La prima soluzione consente di automatizzare il processo di manutenzione delle apparecchiature in vari settori, dall'installazione di macchine da caffè e condizionatori d'aria negli uffici alla riparazione di turbine a gas. Il secondo è un designer online per creare biglietti da visita elettronici basati su codici QR.
Biglietto da visita online myQRcards.
Entrambi i sistemi memorizzano ed elaborano i dati degli utenti che rientrano nella classificazione di "personali" ai sensi della 152-FZ. In questo caso, la legge impone una serie di restrizioni sui sistemi di conservazione di tali dati personali al fine di garantire il livello di sicurezza richiesto ed eliminare il rischio di accesso non autorizzato a scopo di furto o uso improprio.
La legge va rispettata, ma Smart Service non ha previsto di sviluppare al proprio interno la competenza per la protezione dei dati personali. Pertanto, i servizi e i dati condivisi dai loro utenti “spostati” su Linxdatacenter. "Smart-Service" ha trasferito la capacità del server dell'ambiente di lavoro in una zona di rete protetta separata del nostro data center, certificata secondo i requisiti stabiliti in 152-FZ - il cosiddetto "Secure Cloud".
COME È PROGETTATO UN CLOUD SICURO?
Qualsiasi sistema informativo che tratti dati personali deve soddisfare tre requisiti fondamentali:
- l'accesso ai server di archiviazione ed elaborazione dei dati deve avvenire tramite un canale VPN con crittografia secondo GOST;
- i server di archiviazione ed elaborazione dei dati devono essere costantemente monitorati dalla protezione antivirus per eventuali vulnerabilità;
- Il sistema di storage deve essere collocato in reti isolate.
Collochiamo le capacità del server del cliente in aree separate che soddisfano i requisiti di 152-FZ e aiutano a ottenere una conclusione sulla conformità.
Architettura dell'infrastruttura virtuale sicura per Smart Service LLC.
Corso di lavoro
La prima approvazione dei lavori è stata effettuata nel mese di giugno 2019, che può essere considerata la data di inizio del progetto. Tutto il lavoro deve essere svolto in un ambiente “vivo” con migliaia di richieste al giorno. Naturalmente era necessario completare il progetto senza interrompere il normale funzionamento di entrambi gli impianti.
Pertanto è stato elaborato e concordato un piano d’azione chiaro, suddiviso in 4 fasi:
- preparazione,
- migrazione,
- test e test in condizioni reali,
- abilitazione di sistemi di monitoraggio e restrizioni di accesso.
Per essere sicuri, abbiamo incluso una procedura di Disaster Recovery (DRP). Secondo il piano originale, i lavori non avrebbero richiesto molto tempo e risorse e avrebbero dovuto essere completati nel luglio 2019. Ogni fase prevedeva alla fine un test completo della disponibilità della rete e della funzionalità dei sistemi.
La fase più difficile in cui “qualcosa potrebbe andare storto” è stata la migrazione. Inizialmente avevamo previsto di effettuare la migrazione trasferendo intere macchine virtuali. Questa era l'opzione più logica, poiché non richiedeva il coinvolgimento di risorse aggiuntive per la riconfigurazione. Sembrerebbe che vMotion potrebbe essere più semplice.
Inaspettatamente
Tuttavia, come di solito accade nei progetti in un campo relativamente nuovo, è successo qualcosa di inaspettato.
Poiché ciascuna macchina virtuale occupa 500 - 1 GB, la copia di tali volumi anche all'interno di un data center ha richiesto circa 000-3 ore per macchina. Di conseguenza, non abbiamo rispettato la finestra temporale assegnata. Ciò è accaduto a causa delle limitazioni fisiche del sottosistema del disco durante il trasferimento dei dati su vCloud.
Un bug nella versione vCloud utilizzata non permetteva di organizzare Storage vMotion per una macchina virtuale con diversi tipi di dischi, quindi i dischi dovevano essere cambiati. Di conseguenza è stato possibile trasferire le macchine virtuali, ma ciò ha richiesto più tempo del previsto.
Il secondo punto che non abbiamo previsto riguarda le restrizioni sullo spostamento del cluster di database (Failover Cluster MS SQLServer). Di conseguenza, è stato necessario cambiare il cluster in modo che funzioni con un nodo e lasciarlo fuori dalla zona protetta.
Da notare: per un motivo ancora non chiaro, a seguito del trasferimento delle macchine virtuali, il cluster applicativo si è disintegrato e ha dovuto essere rimontato.
Dopo il primo tentativo abbiamo riscontrato uno stato insoddisfacente dei sistemi e siamo stati costretti a ricominciare a pianificare e sviluppare opzioni.
Tentativo #2
Dopo aver lavorato sugli errori, il team ha capito che sarebbe stato più corretto duplicare l'infrastruttura in un'area protetta e copiare solo i file di dati. Si è deciso di non richiedere al cliente alcun pagamento aggiuntivo per la capacità aggiuntiva del server da utilizzare per completare la migrazione.
Di conseguenza, quando i cluster nell’area protetta sono stati completamente duplicati, la migrazione è avvenuta senza problemi.
Successivamente, era solo necessario separare le reti delle zone protette e non protette. Ci sono stati alcuni piccoli disagi qui. La fase di collaudo dell'intero sistema in un'area protetta senza alcuna protezione ha potuto iniziare in modalità normale. Dopo aver raccolto statistiche positive sul funzionamento del sistema in questa modalità, siamo passati all'ultima fase: avviare i sistemi di protezione e limitare l'accesso.
Risultato efficace e lezione utile
Di conseguenza, attraverso gli sforzi congiunti con il cliente, è stato possibile apportare modifiche significative all'infrastruttura del server esistente, che ha permesso di aumentare l'affidabilità e la sicurezza dell'archiviazione dei dati personali, ridurre significativamente i rischi di accesso non autorizzato agli stessi e ottenere un certificato di conformità ai requisiti di archiviazione - un risultato che non tutti hanno ancora raggiunto gli sviluppatori di software simili.
La conclusione è che il pacchetto di lavoro per il progetto era simile al seguente:
- È stata organizzata una sottorete dedicata;
- In totale sono stati migrati due cluster, costituiti da cinque macchine virtuali: cluster database di Failover (due macchine virtuali), cluster applicativo di Service Fabric (tre macchine virtuali);
- Sono stati configurati sistemi di protezione e crittografia dei dati.
Tutto sembra chiaro e logico. In pratica, tutto risulta essere un po’ più complicato. Eravamo ancora una volta convinti che quando si lavora con ogni singolo compito di un tale piano, è richiesto il massimo livello di attenzione alle “piccole cose”, che in realtà risultano non essere piccole cose, ma fattori determinanti per il successo di l'intero progetto.
Fonte: habr.com