De alguma forma, um aplicativo para serviços em nuvem chegou até nós. Descobrimos em termos gerais o que seria necessário de nós e enviamos uma lista de perguntas para esclarecer os detalhes. Em seguida, analisamos as respostas e percebemos: o cliente deseja colocar dados pessoais do segundo nível de segurança na nuvem. Nós respondemos a ele: "Você tem o segundo nível de persas, desculpe, só podemos criar uma nuvem privada". E ele: “Você sabe, mas na empresa X eles podem colocar tudo em um local público para mim.”
Foto de Steve Crisp, ReutersCoisas estranhas! Fomos ao site da empresa X, estudamos seus documentos de certificação, sacudimos a cabeça e percebemos: há muitas questões em aberto na colocação de persdans e elas devem ser ventiladas adequadamente. O que faremos neste post.
Como deve funcionar
Para começar, entenderemos por quais critérios os dados pessoais geralmente são atribuídos a um nível específico de segurança. Depende da categoria de dados, do número de sujeitos desses dados que o operador armazena e processa, bem como do tipo de ameaças reais.
Os tipos de ameaças reais são definidos no
Decreto do Governo da Federação Russa nº 1119, de 1º de novembro de 2012, “Sobre a aprovação dos requisitos para a proteção de dados pessoais durante o processamento em sistemas de informação de dados pessoais”:
“Ameaças do 1º tipo são relevantes para um sistema de informação se, para ele, ameaças relacionadas à presença de recursos não documentados (não declarados) no software do sistema usado no sistema de informação também forem relevantes para ele.
Ameaças do 2º tipo são relevantes para o sistema de informação se, para ele, ameaças relacionadas à presença de recursos não documentados (não declarados) no software aplicativo usado no sistema de informação também forem relevantes para ele.
Ameaças do 3º tipo são relevantes para um sistema de informação se as ameaças relevantes a ele não estiverem relacionadas à presença de recursos não documentados (não declarados) no sistema e no software aplicativo usado no sistema de informação. ”
O principal nessas definições é a presença de oportunidades não documentadas (não declaradas). Para confirmar a ausência de recursos de software não documentados (no caso da nuvem, é um hipervisor), o FSTEC da Rússia é certificado. Se o operador do PD aceitar que não haja tais recursos no software, as ameaças correspondentes serão irrelevantes. Ameaças dos 1º e 2º tipos raramente são aceitas pelos operadores de PD como relevantes.
Além de determinar o nível de segurança dos dados pessoais, o operador também deve determinar as ameaças reais específicas à nuvem pública e, com base no nível de segurança identificado dos dados pessoais e ameaças reais, determinar as medidas e os meios necessários de proteção contra eles.
No FSTEC, todas as principais ameaças estão listadas claramente no
BDU (banco de dados dessas ameaças). Fornecedores e certificadores de infraestruturas em nuvem usam esse banco de dados em seus trabalhos. Aqui estão alguns exemplos de ameaças:
UBI.44 : "A ameaça está na possibilidade de violar a segurança dos dados do usuário de programas que operam dentro da máquina virtual por software malicioso que opera fora da máquina virtual". Essa ameaça é causada pela presença de vulnerabilidades no software do hipervisor que isola o espaço de endereço usado para armazenar dados do usuário de programas que operam dentro da máquina virtual do acesso não autorizado por software malicioso que opera fora da máquina virtual.
A implementação desta ameaça é possível, desde que o software mal-intencionado supere com êxito os limites da máquina virtual, não apenas explorando as vulnerabilidades do hipervisor, mas também implementando esse impacto a partir dos níveis mais baixos (com relação ao hipervisor) do funcionamento do sistema. "
UBI.101 : “A ameaça está na possibilidade de acesso não autorizado às informações protegidas de um consumidor de serviços em nuvem de outro. Essa ameaça se deve ao fato de que, devido à natureza das tecnologias em nuvem, os consumidores de serviços em nuvem precisam compartilhar a mesma infraestrutura em nuvem. A implementação dessa ameaça é possível se forem cometidos erros ao compartilhar os elementos da infraestrutura de nuvem entre os consumidores de serviços em nuvem, bem como ao isolar seus recursos e isolar dados uns dos outros.
Você pode se proteger dessas ameaças apenas com a ajuda de um hipervisor, pois é ele quem gerencia os recursos virtuais. Assim, o hipervisor deve ser considerado como um meio de proteção.
E de acordo com a
ordem do FSTEC nº 21 de 18 de fevereiro de 2013, o hipervisor deve ser certificado pela ausência de NDV no nível 4; caso contrário, o uso de dados pessoais dos níveis 1 e 2 com ele será ilegal (
"Cláusula 12. ... Fornecer 1 e 2 níveis de segurança de dados pessoais, bem como garantir 3 níveis de segurança de dados pessoais em sistemas de informação para os quais as ameaças do segundo tipo são relevantes, são utilizadas ferramentas de proteção de informações, cujo software foi testado não menos do que no nível 4 de controle Eu não declarado capacidades ").O nível de certificação exigido, NDV-4, é possuído por apenas um hypervisor, do desenvolvimento russo -
Horizon VS. Para dizer o mínimo, não é a solução mais popular. As nuvens comerciais geralmente são criadas com base no VMware vSphere, KVM, Microsoft Hyper-V. Nenhum desses produtos é certificado para NDV-4. Porque Obviamente, a obtenção dessa certificação para os fabricantes ainda não é economicamente justificada.
E apenas o Horizonte do Sol permanece para nós para as pessoas de nível 1 e 2 em uma nuvem pública. Triste, mas é verdade.
Como tudo (em nossa opinião) realmente funciona
À primeira vista, tudo é bastante rigoroso: essas ameaças devem ser eliminadas através da configuração adequada de mecanismos de proteção padrão para o hipervisor certificado NDV-4. Mas há uma brecha. De acordo com a Ordem do FSTEC No. 21 (
"Cláusula 2, a segurança dos dados pessoais durante o processamento no sistema de informações de dados pessoais (a seguir denominado sistema de informações) é fornecida pelo operador ou pela pessoa que processa dados pessoais em nome do operador de acordo com a legislação da Federação Russa" ), os provedores avaliam independentemente a relevância de possíveis ameaças e, de acordo com isso, escolhem medidas de proteção. Portanto, se as ameaças do UBI.44 e UBI.101 não forem aceitas como relevantes, também não haverá necessidade de usar um hipervisor certificado NDV-4, que deve fornecer proteção contra eles. E isso será suficiente para obter um certificado de conformidade da nuvem pública com os níveis 1 e 2 de segurança do PD, com o qual Roskomnadzor ficará completamente satisfeito.
É claro que, além de Roskomnadzor, o FSTEC pode vir com um cheque - e essa organização é muito mais meticulosa em questões técnicas. Ela provavelmente estará interessada em por que precisamente as ameaças de UBI.44 e UBI.101 foram reconhecidas como irrelevantes? Mas geralmente o FSTEC só verifica quando recebe informações sobre algum incidente marcante. Nesse caso, o serviço federal chega primeiro ao operador Persdan - ou seja, o cliente dos serviços em nuvem. Na pior das hipóteses, o operador recebe uma pequena multa - por exemplo, para o Twitter no início do ano, a
multa em um caso semelhante era de 5.000 rublos. Em seguida, o FSTEC passa para o provedor de serviços em nuvem. O que pode muito bem ser privado de uma licença devido à não conformidade com requisitos regulamentares - e esses são riscos completamente diferentes para o provedor de nuvem e seus clientes. Mas, repito,
geralmente é necessário um motivo claro para verificar o FSTEC. Portanto, os provedores de nuvem estão dispostos a correr riscos. Até o primeiro incidente grave.
Há também um grupo de fornecedores "mais responsáveis" que acreditam que é possível fechar todas as ameaças adicionando um hipervisor com um suplemento como o vGate. Porém, em um ambiente virtual distribuído entre os clientes para algumas ameaças (por exemplo, o UBI.101 acima), um mecanismo de proteção eficaz pode ser implementado apenas no nível de um hipervisor certificado NDV-4, já que qualquer sistema complementar para funções padrão do trabalho do hipervisor de gerenciamento de recursos (em particular RAM) não são afetados.
Como trabalhamos
Temos um
segmento de nuvem implementado em um hipervisor certificado pelo FSTEC (mas sem certificação para NDV-4). Esse segmento é certificado, de modo que é possível colocar dados pessoais
dos níveis de segurança 3 e 4 na nuvem com base nele - os requisitos de proteção contra recursos não declarados não precisam ser observados aqui. A propósito, aqui está a arquitetura do nosso segmento de nuvem segura:
Sistemas para dados pessoais de
1 e 2 níveis de segurança que implementamos apenas em equipamentos dedicados. Somente nesse caso, por exemplo, a ameaça do UBI.101 não é realmente relevante, pois os racks de servidor que não estão unidos por um ambiente virtual não podem se influenciar, mesmo quando colocados no mesmo data center. Para esses casos, oferecemos um serviço de aluguel de equipamentos dedicado (também é chamado de hardware como serviço, equipamento como serviço).
Se você não tiver certeza do nível de segurança necessário para o seu sistema de dados pessoais, também ajudamos na classificação.
Conclusão
Nossa pequena pesquisa de mercado mostrou que alguns operadores de nuvem estão prontos para arriscar a segurança dos dados do cliente e seu próprio futuro para receber um pedido. Mas seguimos uma política diferente nesses assuntos, que descrevemos brevemente um pouco mais. Teremos o maior prazer em responder nos comentários suas perguntas.