Un día recibimos unha solicitude de servizos na nube. Esbozamos en termos xerais o que se nos esixiría e enviamos unha lista de preguntas para aclarar os detalles. Despois analizamos as respostas e decatámonos: o cliente quere colocar na nube datos persoais do segundo nivel de seguridade. Contestámoslle: "Tes un segundo nivel de datos persoais, desculpa, só podemos crear unha nube privada". E el: "Xa sabes, pero na empresa X pódenme publicar todo publicamente".
Foto de Steve Crisp, Reuters
Cousas estrañas! Fomos ao sitio web da empresa X, estudamos os seus documentos de certificación, sacudimos a cabeza e decatámonos: hai moitas preguntas abertas na colocación de datos persoais e deberían ser abordadas a fondo. Iso é o que faremos nesta publicación.
Como debe funcionar todo
En primeiro lugar, imos descubrir que criterios se utilizan para clasificar os datos persoais como un ou outro nivel de seguridade. Isto depende da categoría de datos, do número de suxeitos destes datos que o operador almacena e procesa, así como do tipo de ameazas actuais.
Os tipos de ameazas actuais defínense en do 1 de novembro de 2012 “Sobre aprobación dos requisitos para a protección de datos persoais durante o seu tratamento nos sistemas de información de datos persoais”:
“As ameazas de tipo 1 son relevantes para un sistema de información se inclúe ameazas actuais relacionadas con coa presenza de capacidades non documentadas (non declaradas). no software do sistemautilizados no sistema de información.
As ameazas do 2o tipo son relevantes para un sistema de información se é para el, incluído ameazas actuais relacionadas con coa presenza de capacidades non documentadas (non declaradas). en software de aplicaciónutilizados no sistema de información.
As ameazas do 3o tipo son relevantes para un sistema de información se é para el ameazas que non están relacionadas coa presenza de capacidades non documentadas (non declaradas). en sistemas e software de aplicaciónutilizados no sistema de información".
O principal nestas definicións é a presenza de capacidades non documentadas (non declaradas). Para confirmar a ausencia de capacidades de software non documentadas (no caso da nube, este é un hipervisor), a certificación é realizada por FSTEC de Rusia. Se o operador de PD acepta que non hai tales capacidades no software, entón as ameazas correspondentes son irrelevantes. Os operadores de PD raramente consideran relevantes as ameazas dos tipos 1 e 2.
Ademais de determinar o nivel de seguridade do PD, o operador tamén debe determinar as ameazas específicas actuais para a nube pública e, en función do nivel identificado de seguridade do PD e das ameazas actuais, determinar as medidas e os medios de protección necesarios contra elas.
FSTEC enumera claramente todas as principais ameazas en (base de datos de ameazas). Os provedores e avaliadores de infraestruturas na nube usan esta base de datos no seu traballo. Aquí tes exemplos de ameazas:
: "A ameaza é a posibilidade de violar a seguridade dos datos dos usuarios dos programas que operan dentro dunha máquina virtual por software malicioso que opera fóra da máquina virtual". Esta ameaza débese á presenza de vulnerabilidades no software do hipervisor, o que garante que o espazo de enderezos utilizado para almacenar os datos dos usuarios dos programas que operan dentro da máquina virtual estea illado do acceso non autorizado por parte de software malicioso que opera fóra da máquina virtual.
A implementación desta ameaza é posible sempre que o código do programa malicioso supere con éxito os límites da máquina virtual, non só explotando as vulnerabilidades do hipervisor, senón tamén realizando tal impacto desde niveis máis baixos (en relación ao hipervisor). funcionamento do sistema".
: "A ameaza reside na posibilidade de acceso non autorizado á información protexida dun consumidor do servizo na nube doutro. Esta ameaza débese ao feito de que, debido á natureza das tecnoloxías na nube, os consumidores de servizos na nube teñen que compartir a mesma infraestrutura de nube. Esta ameaza pódese realizar se se cometen erros ao separar os elementos da infraestrutura na nube entre os consumidores de servizos na nube, así como ao illar os seus recursos e separar os datos entre si.
Só se pode protexer contra estas ameazas coa axuda dun hipervisor, xa que é o que xestiona os recursos virtuais. Así, o hipervisor debe ser considerado como un medio de protección.
E de acordo co con data do 18 de febreiro de 2013, o hipervisor debe estar certificado como non NDV no nivel 4, se non, o uso de datos persoais dos niveis 1 e 2 con el será ilegal (“Cláusula 12. ... Para garantir os niveis 1 e 2 de seguridade dos datos persoais, así como para garantir o nivel 3 de seguridade de datos persoais nos sistemas de información para os que as ameazas de tipo 2 se clasifican como actuais, utilízanse ferramentas de seguridade da información cuxo software foi probado polo menos segundo o nivel 4 de control sobre a ausencia de capacidades non declaradas").
Só un hipervisor, desenvolvido en Rusia, ten o nivel de certificación necesario, NDV-4. . Por dicilo suavemente, non é a solución máis popular. As nubes comerciais adoitan construírse sobre a base de VMware vSphere, KVM, Microsoft Hyper-V. Ningún destes produtos está certificado por NDV-4. Por que? É probable que a obtención desta certificación para os fabricantes aínda non estea xustificada economicamente.
E todo o que nos queda para os datos persoais dos niveis 1 e 2 na nube pública é Horizon BC. Triste pero certo.
Como funciona todo (na nosa opinión) realmente
A primeira vista, todo é bastante estrito: estas ameazas deben eliminarse configurando correctamente os mecanismos de protección estándar dun hipervisor certificado segundo NDV-4. Pero hai unha fenda. De acordo coa orde FSTEC n.º 21 («cláusula 2 A seguridade dos datos persoais cando se tratan no sistema de información de datos persoais (en diante, o sistema de información) está garantida polo operador ou a persoa que trata os datos persoais en nome do operador de acordo co Federación Rusa"), os provedores avalían de forma independente a relevancia das posibles ameazas e escollen as medidas de protección en consecuencia. Polo tanto, se non acepta as ameazas UBI.44 e UBI.101 como actuais, non será necesario utilizar un hipervisor certificado segundo NDV-4, que é precisamente o que debería proporcionar protección contra elas. E isto será suficiente para obter un certificado de conformidade da nube pública cos niveis 1 e 2 de seguridade de datos persoais, co que Roskomnadzor estará completamente satisfeito.
Por suposto, ademais de Roskomnadzor, FSTEC pode vir cunha inspección, e esta organización é moito máis meticulosa en cuestións técnicas. Probablemente lle interese por que exactamente as ameazas UBI.44 e UBI.101 foron consideradas irrelevantes? Pero normalmente FSTEC realiza unha inspección só cando recibe información sobre algún incidente significativo. Neste caso, o servizo federal chega primeiro ao operador de datos persoais, é dicir, ao cliente dos servizos na nube. No peor dos casos, a operadora recibe unha pequena multa -por exemplo, por Twitter a principios de ano nun caso semellante ascendeu a 5000 rublos. Entón FSTEC vai máis aló ao provedor de servizos na nube. Que ben pode verse privado dunha licenza por incumprir os requisitos regulamentarios, e estes son riscos completamente diferentes, tanto para o provedor de nube como para os seus clientes. Pero, repito, Para comprobar FSTEC, normalmente necesitas un motivo claro. Polo tanto, os provedores de nube están dispostos a asumir riscos. Ata o primeiro incidente grave.
Tamén hai un grupo de provedores "máis responsables" que cren que é posible pechar todas as ameazas engadindo un complemento como vGate ao hipervisor. Pero nun entorno virtual distribuído entre os clientes para algunhas ameazas (por exemplo, o anterior UBI.101), un mecanismo de protección eficaz só se pode implementar a nivel dun hipervisor certificado segundo NDV-4, xa que calquera sistema adicional para as funcións estándar do hipervisor para xestionar recursos (en particular, RAM) non afectan.
Como traballamos
Temos un segmento de nube implementado nun hipervisor certificado por FSTEC (pero sen certificación para NDV-4). Este segmento está certificado, polo que os datos persoais pódense almacenar na nube en función del 3 e 4 niveis de seguridade — Os requisitos para a protección contra as capacidades non declaradas non son necesarios aquí. Aquí está, por certo, a arquitectura do noso segmento de nube segura:
Sistemas de datos persoais 1 e 2 niveis de seguridade Implementamos só en equipos dedicados. Só neste caso, por exemplo, a ameaza de UBI.101 non é realmente relevante, xa que os racks de servidores que non están unidos por un entorno virtual non poden influír entre si mesmo cando se atopan no mesmo centro de datos. Para tales casos, ofrecemos un servizo de aluguer de equipos dedicado (tamén se chama Hardware como servizo).
Se non está seguro de que nivel de seguridade é necesario para o seu sistema de datos persoais, tamén axudamos a clasificalo.
Saída
A nosa pequena investigación de mercado mostrou que algúns operadores na nube están bastante dispostos a arriscar tanto a seguridade dos datos dos clientes como o seu propio futuro para recibir un pedido. Pero nestes asuntos adherimos a unha política diferente, que describimos brevemente xusto arriba. Estaremos encantados de responder ás súas preguntas nos comentarios.
Fonte: www.habr.com