Aspectos de segurança ao usar infraestrutura imutável

Apresentação sobre Infraestrutura Imutável e segurança no Code4Sec.

Transcript

1. Aspectos de segurança ao usar infraestrutura imutável @fernandoike
2. Fernando Ike IT Director @ Nuveo // fernando.ike@gmail.com // linkedin.com/in/fernandoike // twitter.com/fernandoike // www.10deploys.com // https://www.maburix.com
5. Problemas mais comuns - Segurança => TI - Servidores de produção mal configurados - Servidores de produção estão levemente diferentes comparando um do outro - Servidores de produção são mais "complicados" para aplicar correções de segurança (Patches)
7. Problemas mais comuns - Segurança => TI - Gerenciamento de usuários privilegiados são difíceis de escalar - Mudanças não autorizados pode ocorrer via acesso remoto (SSH) - Auditar é difícil e complexo
9. Por que segurança é tão complicado? - Antes - Instalar/atualizar servidores era um processo com muito trabalho manual - Servidores custam caro (Dinheiro, capacidade e armazenamento) - TI é péssima em liberar servidores porque geralmente alguma coisa (esquecida) quebra - Segredos, chaves ssh, certificados, string de conexões armazenados no servidor
10. - Sistema Operacionais são automaticamente provisionados a partir de um template - Imagens de containers são automaticamente provisionados a partir de um template Por que segurança é tão complicado? - Agora
11. - (Micro) serviços surgem e desaparecem rapidamente antes mesmo de conseguir catalogá-los (identificá-los) - A rastreabilidade tornou-se mais complexo - A segurança não é mais o gatekeeper das organizações Por que segurança é tão complicado? - Agora
13. “Sinônimos” • Immutable Infrastructure • Immutable Server • Immutable Delivery • Golden Images • Phoenix Servers vs Snowflake Servers • Pets vs Cattle • Infrastructure as Code
18. Cenário mais comum - Snowflakes • A construção do artefato é realizado numa ferramenta de Entrega Contínua • As dependências são (re)instaladas a cada lançamento de versão do artefato • O artefato é implementado nos servidores de homologação • O artefato é implementado nos servidores de produção
19. Snowflake Servers
21. Uma (falsa) premissa “A maneira mais econômica de garantir que o comportamento de dois servidores permanecerá completamente idêntico é sempre a implementar as mesmas alterações na mesma ordem em ambos anfitriões.” John Willis - @botchagalupe
22. Por que (Quando) a ordem dos comandos é importante? • Dependência Circular • Comandos certos na ordem errada • Pacotes certos na ordem errada
24. Efeitos colaterais • O repositório do sistema de empacotamento (Composer, PIP, GEM, apt, etc.) está indisponível • As dependências quebram porque a biblioteca foo-1.15-1 não está mais disponível • A biblioteca de dependência foobar-1.15-2 quebrou a construção do artefato
26. Problemas comuns em servidores mutáveis • Aumento da complexidade operacional ◦ Mais etapas no Pipeline ◦ Maior tempo de Lead Time ◦ Mais suscetível a falhas de terceiros, ex: repositórios externos
29. Phoenix Servers
30. https://www.thoughtworks.com/insights/blog/moving-to-phoenix-server-pattern-introduction
32. Container Infrastructure Hypervisor Docker App A Artifact Bin/Libs App B Bin/Libs App C Bin/Libs
33. VM Infrastructure Hypervisor App A Artifact Bin/Libs App B Bin/Libs App C Bin/Libs Guest OS Guest OS Guest OS VM Infrastructure Hypervisor App A Artifact Bin/Libs App B Bin/Libs App C Bin/Libs Guest OS Guest OS Guest OS
35. Implementação - Não faça em produção • Atualização de pacotes (bibliotecas e dependências) • Alteração de configurações • Modificações na aplicação • “Não usar SSH”
37. Implementação - Boas práticas • Servidores na Nuvem • Automação completa de todo pipeline de serviços • Logs centralizados • Armazenamento de dados em “ambiente” externo • Equipes de desenvolvimento e operações “engajadas”
38. Implementação - Boas práticas • Estado de serviços, dados da aplicação ou qualquer outra informação que deve ser preservada até que outro “servidor” estava “no ar” devem estar em outro local da infraestrutura. (Stateless)
40. Visibilidade • Onde e quando foi construído e por que? • Qual foi a imagem anterior? • Como iniciar, validar, monitorar e atualizá-la? John Willis - @botchagalupe
41. Visibilidade • Qual repositório está sendo usado e qual hash do git foi usado para construir a imagem? • Quais são as tags específicas do container/vm usada como registro do build? • Qual o nome do projeto no qual pertence o artefato John Willis - @botchagalupe
43. Como tornar Imutável • Provisione um novo servidor • Teste o novo servidor • Altera a referência para o novo servidor • Mantenha a versão antiga (temporariamente) para fazer o rollback
45. Pontos de atenção • Centralização de Logs • Feature toggle • Observability • Múltipla Versões (“temporariamente”) em produção
46. Pontos de atenção • Balanceadores de carga com suporte: ◦ Canary ◦ Blue/Green ◦ Rolling Deploys • Service Mesh • Boa prática ao usar os códigos de status HTTP
47. Quando não usar • Serviços que mantenham o estado localmente • Serviços Stateful • Serviços de infraestrutura base
48. Testes de “aceitação” • Testes de segurança • Testes dos serviços • Testes de conformidade • Testes de integração
50. Testes de segurança no pipeline • Análise estática de código • Validações de de conformidade de acesso autoriza • Pen-tests • Varredura por dependências com vulnerabilidades
51. Conclusão Infraestrutura Imutável é tornar como parte do artefato que será lançado (instalado) em produção a pilha (stack) completa da aplicação. Maximizando os diversos tipos de testes antes do artefato entrar em “produção”
53. Demo
54. https://github.com/maburix/immutable_infrastructure
55. Referências • https://medium.com/netflix-techblog/building-with-legos-d68368fe4ce • https://martinfowler.com/bliki/PhoenixServer.html • https://martinfowler.com/bliki/SnowflakeServer.html • https://www.oreilly.com/ideas/an-introduction-to-immutable-infrastructure • https://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/ • https://boxfuse.com/blog/no-ssh • https://www.digitalocean.com/community/tutorials/what-is-immutable-infrastructure • https://www.devopsdays.org/events/2018-sao-paulo/welcome/ • https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ • https://www.thoughtworks.com/insights/blog/moving-to-phoenix-server-pattern-introduction
56. Fernando Ike IT Director @ Nuveo // fernando.ike@gmail.com // linkedin.com/in/fernandoike // twitter.com/fernandoike // www.10deploys.com // https://www.maburix.com