Un giorno abbiamo ricevuto una richiesta per servizi cloud. Abbiamo valutato in linea di massima cosa ci sarebbe stato richiesto e abbiamo inviato una lista di domande per chiarire i dettagli. Dopodiché abbiamo analizzato le risposte e abbiamo capito: il cliente vuole memorizzare nel cloud dati personali di secondo livello di protezione. Rispondiamo: «Hai dati personali di secondo livello, ci dispiace, possiamo fare solo un cloud privato». E lui: «Sapete, in realtà in azienda X possono fare tutto anche nel pubblico».
Foto di Steve Crisp, Reuters
Cose strane! Siamo andati sul sito dell’azienda X, abbiamo esaminato i loro documenti di certificazione, abbiamo scosso la testa e abbiamo capito: ci sono molte domande aperte sulla memorizzazione dei dati personali che meritano di essere approfondite. E ci occuperemo di questo in questo post.
Come tutto dovrebbe funzionare
Iniziamo quindi a capire quali criteri determinano il livello di protezione dei dati personali. Questo dipende dalla categoria dei dati, dal numero di soggetti di questi dati che l’operatore memorizza e tratta, nonché dal tipo di minacce attuali.
La definizione dei tipi di minacce attuali è fornita in del 1 novembre 2012 «Sulla conferma dei requisiti per la protezione dei dati personali durante il loro trattamento nei sistemi informatici dei dati personali»:
«Le minacce di primo tipo sono rilevanti per il sistema informatico se per esso, tra l'altro, sono rilevanti le minacce associate alla presenza di possibilità non documentate (non dichiarate) nel software di sistema, utilizzato nel sistema informatico.
Le minacce di secondo tipo sono rilevanti per il sistema informatico se per esso, tra l'altro, sono rilevanti le minacce associate alla presenza di possibilità non documentate (non dichiarate) nel software applicativo, utilizzato nel sistema informatico.
Le minacce di terzo tipo sono rilevanti per il sistema informatico se per esso sono rilevanti le minacce che non sono associate alla presenza di possibilità non documentate (non dichiarate) nel software di sistema e applicativo, utilizzato nel sistema informatico.»
L'aspetto principale di queste definizioni è la presenza di possibilità non documentate (non dichiarate). Per confermare l'assenza di possibilità non documentate nel software (nel caso del cloud, si tratta del hypervisor) viene effettuata la certificazione da parte del FSTEC della Russia. Se l'operatore dei dati personali ritiene che tali possibilità non siano presenti nel software, le minacce corrispondenti non sono rilevanti. Gli operatori di dati personali raramente considerano rilevanti le minacce di primo e secondo tipo.
Oltre a definire il livello di protezione dei Dati Personali, l'operatore deve anche identificare le minacce attuali specifiche per il cloud pubblico e, sulla base del livello di protezione dei Dati Personali identificato e delle minacce attuali, determinare le misure e i mezzi di protezione necessari contro di esse.
L'FSTEK ha elencato chiaramente tutte le principali minacce in (database delle minacce). I fornitori e gli auditor delle infrastrutture cloud utilizzano questa base nel loro lavoro. Ecco alcuni esempi di minacce:
: «La minaccia consiste nella possibilità di violazione della sicurezza dei dati degli utenti da parte di programmi che operano all'interno di una macchina virtuale, da software malevolo che opera al di fuori della macchina virtuale». Questa minaccia è determinata dalla presenza di vulnerabilità nel software del hypervisor, che deve garantire l'isolamento dello spazio di indirizzamento utilizzato per memorizzare i dati degli utenti dei programmi all'interno della macchina virtuale, da accessi non autorizzati da parte di software malevolo che opera al di fuori della macchina virtuale.
L'attuazione di questa minaccia è possibile se il codice malevolo riesce a superare i confini della macchina virtuale non solo sfruttando le vulnerabilità del hypervisor, ma anche esercitando un tale impatto da livelli operativi inferiori (rispetto al hypervisor) nel funzionamento del sistema».
: «La minaccia consiste nella possibilità di accesso non autorizzato alle informazioni protette di un utente di servizi cloud da parte di un altro. Questa minaccia è dovuta al fatto che, a causa delle peculiarità delle tecnologie cloud, gli utenti dei servizi cloud devono condividere la stessa infrastruttura cloud. L'attuazione di questa minaccia è possibile nel caso di errori commessi nella separazione degli elementi dell'infrastruttura cloud tra gli utenti dei servizi cloud, così come nell'isolamento delle loro risorse e nella separazione dei dati tra loro».
Per proteggersi da queste minacce è possibile solo tramite l'hypervisor, poiché è lui a gestire le risorse virtuali. Pertanto, l'hypervisor deve essere considerato come uno strumento di protezione.
E in conformità con Dal 18 febbraio 2013, l'ipervisor deve essere certificato per l'assenza di NDI di livello 4, altrimenti l'uso di dati personali di livello 1 e 2 con esso sarà illegale («p.12. … Per garantire i livelli 1 e 2 di protezione dei dati personali, nonché per garantire il livello 3 di protezione dei dati personali nei sistemi informativi, per i quali i rischi attuali sono di tipo 2, vengono utilizzati mezzi di protezione delle informazioni, il software dei quali ha superato il controllo a non meno di livello 4 per l'assenza di opportunità non dichiarate»).
Solo un ipervisor, sviluppato in Russia, possiede il livello di certificazione richiesto, NDI-4 — . Ad essere gentili, non è la soluzione più popolare. Le nuvole commerciali sono solitamente costruite utilizzando VMware vSphere, KVM, Microsoft Hyper-V. Nessuno di questi prodotti ha ottenuto la certificazione NDI-4. Perché? Probabilmente, ottenere tale certificazione non è economicamente giustificato per i produttori.
E ci rimane solo Gorizont VS per i dati personali di livello 1 e 2 nel cloud pubblico. Triste ma vero.
Come funziona realmente, a nostro avviso
A prima vista, tutto sembra piuttosto rigoroso: i rischi indicati devono essere mitigati attraverso la corretta configurazione dei meccanismi di protezione standard dell'ipervisor, certificato NDI-4. Ma c'è una scappatoia. Secondo l'Ordine del FSTEK n. 21 («p.2 La sicurezza dei dati personali durante il loro trattamento in un sistema informativo sui dati personali (di seguito denominato — sistema informativo) è garantita dall'operatore o dalla persona che tratta i dati personali per conto dell'operatore in conformità con il della Federazione Russa»), i fornitori valutano autonomamente la pertinenza dei potenziali rischi e scelgono le misure di protezione di conseguenza. Pertanto, se non si considerano pertinenti i rischi UBI.44 e UBI.101, non si avrà nemmeno la necessità di utilizzare un ipervisor certificato NDI-4, il quale deve garantire protezione contro di essi. E questo sarà sufficiente per ottenere il certificato di conformità del cloud pubblico ai livelli 1 e 2 di protezione dei dati personali, di cui sarà pienamente soddisfatto il Roskomnadzor.
Certo, oltre al Roskomnadzor, anche il FSTEK può effettuare controlli — e questa organizzazione è molto più pignola in materia tecnica. Sono sicuramente interessati a sapere perché minacce come UBI.44 e UBI.101 siano state riconosciute come irrilevanti. Ma di solito il FSTEK effettua controlli solo quando riceve informazioni su qualche incidente eclatante. In questo caso, l'agenzia federale si rivolge prima all'operatore di dati personali — cioè al committente dei servizi cloud. Nel peggiore dei casi, l'operatore riceve una piccola multa — ad esempio, per Twitter all'inizio dell'anno in un caso simile è stata di 5000 rubli. Successivamente, il FSTEK si rivolge al fornitore di servizi cloud. Che potrebbe essere privato della licenza a causa del mancato rispetto dei requisiti normativi — e questi sono rischi completamente diversi, sia per il fornitore cloud che per i suoi clienti. Ma, ripeto, per un controllo il FSTEK di solito ha bisogno di un chiaro motivo. Quindi i fornitori di cloud sono pronti a correre dei rischi. Fino al primo incidente serio.
C'è anche un gruppo di fornitori 'più responsabili' che ritiene che sia possibile risolvere tutte le minacce, aggiungendo un componente ipervisore come vGate. Ma in un ambiente virtuale distribuito tra i clienti, per alcune minacce (come quella menzionata sopra, UBI.101) un meccanismo di protezione efficace può essere realizzato solo a livello di ipervisore certificato secondo NDV-4, poiché qualsiasi sistema di estensione non influisce sulle funzioni standard dell'ipervisore nella gestione delle risorse (in particolare, della memoria RAM).
Come lavoriamo noi
Abbiamo un segmento cloud realizzato su un ipervisore certificato dal FSTEK (ma senza certificazione per NDV-4). Questo segmento è attestato, quindi nel cloud basato su di esso è possibile ospitare dati personali di livelli 3 e 4 di protezione — i requisiti per la protezione da possibilità non dichiarate non devono essere rispettati qui. Ecco, tra l'altro, l'architettura del nostro segmento cloud protetto:
Sistemi per dati personali di livelli 1 e 2 di protezione Realizziamo solo su apparecchiature dedicate. Solo in questo caso, ad esempio, la minaccia UBI.101 non è realmente rilevante, poiché i rack dei server, non uniti da un ambiente virtuale, non possono influenzarsi a vicenda anche se collocati nello stesso data center. Per tali casi, offriamo il servizio di noleggio di apparecchiature dedicate (noto anche come Hardware as a Service).
Se non siete sicuri del livello di protezione necessario per il vostro sistema di dati personali, vi aiuteremo anche nella loro classificazione.
Conclusione
La nostra piccola ricerca di mercato ha rivelato: alcuni operatori cloud sono disposti a mettere a rischio la sicurezza dei dati dei clienti e il proprio futuro per ottenere un contratto. Ma noi adottiamo una politica diversa in queste questioni, che abbiamo brevemente descritto poco sopra. Saremo felici di rispondere alle vostre domande nei commenti.
Fonte: habr.com
