Aspectos de segurança ao usar infraestrutura imutável

Slide 1

Slide 1 text

Aspectos de segurança ao usar infraestrutura imutável @fernandoike

Slide 2

Slide 2 text

Fernando Ike IT Director @ Nuveo // [email protected] // linkedin.com/in/fernandoike // twitter.com/fernandoike // www.10deploys.com // https://www.maburix.com

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

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)

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

- 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

Slide 11

Slide 11 text

- (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

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

“Sinônimos” ● Immutable Infrastructure ● Immutable Server ● Immutable Delivery ● Golden Images ● Phoenix Servers vs Snowflake Servers ● Pets vs Cattle ● Infrastructure as Code

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Snowflake Servers

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Por que (Quando) a ordem dos comandos é importante? ● Dependência Circular ● Comandos certos na ordem errada ● Pacotes certos na ordem errada

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Phoenix Servers

Slide 30

Slide 30 text

https://www.thoughtworks.com/insights/blog/moving-to-phoenix-server-pattern-introduction

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

Container Infrastructure Hypervisor Docker App A Artifact Bin/Libs App B Bin/Libs App C Bin/Libs

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

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”

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

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”

Slide 38

Slide 38 text

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)

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Pontos de atenção ● Centralização de Logs ● Feature toggle ● Observability ● Múltipla Versões (“temporariamente”) em produção

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Quando não usar ● Serviços que mantenham o estado localmente ● Serviços Stateful ● Serviços de infraestrutura base

Slide 48

Slide 48 text

Testes de “aceitação” ● Testes de segurança ● Testes dos serviços ● Testes de conformidade ● Testes de integração

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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”

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

Demo

Slide 54

Slide 54 text

https://github.com/maburix/immutable_infrastructure

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Fernando Ike IT Director @ Nuveo // [email protected] // linkedin.com/in/fernandoike // twitter.com/fernandoike // www.10deploys.com // https://www.maburix.com