Nossa plataforma IaaS Cloud-152 é certificada simultaneamente de acordo com o PCI DSS e possui um certificado de conformidade 152- para UZ-2 (sem ameaças reais do 1º e 2º tipo). A mesma plataforma também está incluída no escopo do nosso sistema de gerenciamento de segurança da informação (ISMS), que certificamos de acordo com a ISO / IEC 27001: 2013. Definitivamente, vou falar sobre isso e a
STAR Cloud Security Alliance (CSA) também, mas hoje vou me concentrar nas vantagens das sinergias PCI DSS e 152-for para nossos clientes.
Vivemos na Rússia, nossos clientes fazem negócios principalmente na Federação Russa e todos devem cumprir os requisitos da legislação russa no campo da proteção de dados pessoais. A mesma Lei Federal “Sobre Dados Pessoais”, datada de 27 de julho de 2006, nº 152- e correções da Lei 242-Federal de 21 de julho de 2014, relativa ao processamento de dados pessoais de cidadãos da Federação Russa em bancos de dados localizados no território da Federação Russa. Nem todo mundo precisa do RGPD, e eu também levarei esse tópico além do escopo deste artigo.
152- foi concebido para proteger os direitos dos indivíduos com DP. A lei não fornece receitas prontas para a proteção de dados pessoais através da introdução e configuração de equipamentos de proteção (SZI). Se você descer para um nível mais "concreto" do Decreto Governamental nº 1119, da Ordem FSTEC da Rússia nº 21 e da Ordem FSB da Rússia nº 378, será mais sobre o fato da disponibilidade de fundos (em alguns casos certificados), e não como isso deve ser estabelecido. estar seguro.
O PCI DSS define os requisitos de segurança de dados no setor de cartões de pagamento. O escopo de sua ação está associado ao dinheiro, que todos tradicionalmente protegem com cuidado especial. Possui mais detalhes, requisitos e folhas de leitura :).
Pode parecer estranho para alguém que a conexão em si na mesma plataforma PCI DSS e 152-, mas para nós isso faz sentido. Não se trata apenas de duas em uma garrafa, mas, mais importante, a combinação de papel e segurança prática.
Vou dar alguns exemplos sobre esse sistema de "freios e contrapesos".
Exemplo 1. Um certificado para infraestrutura que atende aos requisitos do 152-FZ é emitido por 3 anos. Durante esse período, nada na infraestrutura deve mudar ou deve necessariamente ser acordado com a organização que emitiu o certificado. Certificação é igual a consertar o sistema por três anos inteiros. O modo como a infraestrutura atende aos requisitos da verificação à verificação está na consciência do certificado.
O PCI DSS possui um ciclo de auditoria mais curto: uma auditoria a cada ano. Além disso, um teste (intruso externo e interno) é realizado 2 vezes por ano e um ASV (Fornecedor de Digitalização Aprovado) digitaliza 4 vezes por ano. Isso é suficiente para manter a infraestrutura em boa forma.
Exemplo 2. A certificação de acordo com 152- tem seu próprio preço e essas são limitações na escolha do software e dos meios de proteção. Se você for submetido à certificação, todos eles deverão ser
certificados . Certificado - significa não as versões mais recentes de software e SZI. Por exemplo, o PAC CheckPoint é certificado, a gama de modelos de 2012, firmware R77.10. A certificação agora é R77.30, mas o suporte ao fornecedor já termina em setembro de 2019. O PCI DSS não possui esses requisitos (exceto o scanner - ele deve constar da lista de aprovados). Isso permite que você use ferramentas de proteção paralela que não têm problemas com a relevância das versões.
Exemplo 3. O 152- e o PCI DSS requerem um firewall (ME). Somente o FSTEC da Rússia simplesmente exige sua presença e, no caso de certificação, também requer um certificado de conformidade com os requisitos do FSTEC da Rússia. Ao mesmo tempo, o FSTEC não possui requisitos para sua configuração e manutenção. De fato, o firewall pode simplesmente ser, mas funciona corretamente e, se funciona em princípio, não é mencionado no documento. A mesma situação ocorre com proteção antivírus (SAVZ), detecção de intrusão (SOV) e proteção de informações contra acesso não autorizado (SZI da NSD).
As inspeções das organizações de certificação também não podem garantir que tudo funcione como deveria. Geralmente, tudo se limita ao upload de todas as regras de firewall. Também acontece que eles simplesmente removem as somas de verificação dos arquivos do sistema operacional Gaia (sistema operacional CheckPoint). Esses arquivos mudam dinamicamente e sua soma de verificação também. Há pouco sentido em tais verificações.
Também existem requisitos de fabricantes de SZI certificados para instalação e operação. Mas, na minha prática, vi muito poucas certificações (não segredos de estado), durante as quais o desempenho das especificações técnicas no SZI seria verificado.
O padrão PCI DSS requer uma análise das regras de firewall pelo detentor do certificado uma vez a cada seis meses. Uma vez por mês, os especialistas do centro de segurança cibernética do DataLine verificam as regras do ME no Cloud-152 para descobrir desnecessários, temporários e irrelevantes. Cada nova regra passa pelo nosso Service Desk, uma descrição dessa regra é registrada no ticket. Quando uma nova regra é criada no ME, o número do ticket é escrito no comentário.
Exemplo 4. O pedido do FSTEC da Rússia nº 21 implica a necessidade de um scanner de vulnerabilidades, novamente certificado para certificação. Como medida adicional, é fornecido um teste de caneta, teste de IP para penetração na cláusula 11.
Os relatórios desses scanners também são divertidos. Quando nossos clientes passam na certificação de seus IPs hospedados no Cloud-152, geralmente a organização certificadora deseja receber um relatório vazio que não contém vulnerabilidades no IP certificado. Além disso, os certificadores geralmente são limitados a verificações internas. A verificação externa em meu consultório foi realizada por certificadores apenas algumas vezes, e esses eram escritórios com um nome.
O PCI DSS prescreve claramente não apenas a presença de um scanner, mas também uma verificação ASV regular (fornecedor de digitalização aprovado) 4 vezes por ano. De acordo com seus resultados, os engenheiros do fornecedor verificam o relatório e dão uma opinião. E o teste de penetração para o Cloud-152 é realizado 2 vezes por ano, de acordo com os requisitos do PCI DSS.
Exemplo 5. Autenticação Multifator. O pedido nº 21 do FSTEC da Rússia não declara explicitamente esse requisito. O PCI DSS, no entanto, requer autenticação multifator.
Agora vamos ver como o padrão e a lei coexistem na mesma infraestrutura.
Sobre o Cloud-152
O segmento de controle Cloud-152 e a área do cliente estão localizados em diferentes equipamentos físicos em racks dedicados com sistemas de controle de acesso e videovigilância.
O Cloud-152 foi desenvolvido no VMware vSphere 6.0 (certificado nº 3659). Num futuro próximo, mudaremos para 6.5 e 6.7 já estarão sob controle de inspeção.
Não usamos SPI adicionais no nível de virtualização, pois assinamos um SLA restrito com os clientes para a disponibilidade da plataforma IaaS; portanto, tentamos minimizar pontos adicionais de falha.
O segmento de controle Cloud-152 é separado do DataLine, redes clientes e Internet usando um sistema de hardware e software certificado pela Check Point que combina as funções de um firewall e uma ferramenta de detecção de intrusões (certificado nº 3634).
Os administradores do cliente passam na autenticação de dois fatores do SafeNet Trusted Access (STA) antes de acessar os recursos virtuais.
Os administradores do Cloud-152 são conectados à nuvem por meio de um monitoramento e rastreamento das ações dos usuários privilegiados do SKDPU (certificado nº 3352). Em seguida, a autenticação de dois fatores também passa e somente então eles obtêm acesso ao gerenciamento do Cloud-152. Isso é exigido pelo padrão PCI DSS.
Como meio de proteção contra acesso não autorizado, usamos o SecretNet Studio (certificado nº 3675). A proteção antivírus é fornecida pelo Kaspersky Security para virtualização (certificado nº 3883).
Três scanners estão envolvidos no Cloud-152 de uma vez:
- XSpider certificado (certificado nº 3247) em conformidade com os requisitos 152-FZ. Usamos uma vez por trimestre.
- Nessus pelo trabalho real de pesquisa e análise de vulnerabilidades na plataforma Cloud-152.
- Qualys é o scanner que precisamos para a digitalização externa, de acordo com os requisitos do PCI DSS. Usamos mensalmente e, às vezes, com mais frequência.
Além disso, 4 vezes por ano, realizamos uma varredura ASV obrigatória para o PCI DSS.
Como SIEM, é usado o Splunk, que não é mais vendido na Federação Russa. Agora, estamos no processo de busca de uma nova solução, estamos realizando testes. O SIEM é necessário para conformidade com o PCI DSS.
Esquema Cloud-152Agora que descrevi em detalhes como a conformidade com o PCI DSS na plataforma IaaS sob 152- ajuda a obter segurança real, você provavelmente pergunta: por que complicar coisas como essa quando você pode fazê-lo funcionar sem nenhum PCI DSS. Sim, é possível, mas, juntamente com o PCI DSS, temos uma prova disso na forma de um certificado, que confirmamos anualmente.