É hora de continuar com nossas importantes boas práticas da Amazon Web Services, baseadas no estudo da Gartner sobre Segurança de Workload em Nuvem. Na verdade, o tempo é o fundamental nessa ótima dica.
Imagine-se no dia 1º de abril de 2014. A vulnerabilidade Heartbleed é divulgada. Ela permite que os agressores possam extrair informações sensíveis da memória usando um falha no handshake SSL de qualquer aplicação que use o OpenSSL. A biblioteca OpenSSL vem junto com muitas aplicações em todo o mundo!
O que você faz?
Primeiro, você precisa saber se foi afetado. A verificação de vulnerabilidades, ou baseada na rede ou privilegiada, pode ajudar a identificar as workloads impactadas. Mas, e depois? Agora, aqui é onde eu concordo plenamente com os especialistas da Gartner e recomendo uma coisa que, tenho certeza, vai contra a metodologia operacional da maioria das empresas: Não Atualize. Isso mesmo… não atualize o sistema em atividade!
Não queremos dizer para não corrigir a vulnerabilidade e deixar seu servidor exposto. O que queremos dizer é: não aplique patches potencialmente disruptivos nos sistemas ativos.
Ao invés disso, aplique apenas o patch no seu template e faça um teste antes de implementar. Em nossa última dica, falamos sobre incorporar a segurança desde o começo e de como você pode criar seus novos servidores de forma dinâmica ou estática. Com essa linha de conduta e capacidade de teste, você reduz suas chances dos patches interromperem os sistemas operacionais. De novo, o principal da automação é garantir que você tenha uma linha de conduta para rapidamente criar e testar novos ambientes para suas aplicações.
Mas, e a vulnerabilidade? O tempo está correndo…
Aqui é onde o virtual patching, através de um software IPS como o Deep Security, pode ajudar a encontrar as instâncias vulneráveis e fechar essa janela de vulnerabilidade. Aplicar um virtual patch permite que você impeça explorações da vulnerabilidade de maneira rápida e segura. Isso impede a possível extração de dados ou intrusões no sistema no início.
E muda fundamentalmente o modelo operacional. Os servidores em nuvem são descartáveis, são os dados que importam. Pare de abraçar seus servidores e abra as opções de migrações sem interrupções com técnicas como implementações verde/azul.
Nem todas as workloads aceitam bem esse modelo, por exemplo, aplicações legadas que utilizaram o modelo lift and shift para a nuvem. Nesse caso, você ainda aplica os virtual patches em suas workloads de produção enquanto testa os patches em um conjunto de testes de instâncias. Porém, o modelo de servidor stateless é, no final, o seu objetivo e o que está avaliando e comparando para as suas compras.
Para saber mais sobre como responder a vulnerabilidades e ter uma resposta inicial e uma reparação a longo prazo, veja a palestra de Mark Nunnikhoven na AWS re:invent deste ano.
Interessado em saber mais sobre as boas práticas para proteger suas workloads na AWS? Leia o estudo da Gartner sobre boas práticas para proteger workloads na AWS.
