Gerenciamento de Segredos: segurança, auditoria e automação com Vault

Fundamentos de gestão de segredos - Apresentação

Introdução ao Curso de Gestão de Segredos

Olá, e boas-vindas ao curso de Gestão de Segredos em Aplicações da Alura. Eu sou Gustavo Henrique Rorato, analista de segurança da informação, e estou aqui para acompanhá-los nessa jornada de aprendizado.

Audiodescrição: Gustavo é um homem branco, de cabelo castanho, e está vestindo uma blusa preta.

Objetivos do Curso

Neste curso, vamos aprofundar nossos conhecimentos sobre a gestão de segredos em aplicações. Aprenderemos sobre a gestão desses segredos, como rotacioná-los, o ciclo de vida deles, como identificá-los no código, verificar se são segredos ou informações sensíveis, entre outras questões relacionadas.

O Que São Segredos em Aplicações

Na primeira aula, vamos entender o que são segredos em aplicações. Se em algum momento foi necessário definir uma senha ou um token em um arquivo ou variável de ambiente na sua aplicação, já trabalhamos com segredos, mesmo que tenhamos dado outro nome a eles.

A definição de segredo refere-se a credenciais sensíveis usadas por aplicações, serviços ou usuários para autenticação e autorização. Ou seja, utilizamos essas credenciais para autenticar e, ao mesmo tempo, autorizar o acesso a algum serviço ou parte de um sistema.

Riscos da Exposição de Segredos

Se esses dados forem expostos, podem comprometer a integridade e confidencialidade da aplicação. A integridade pode ser comprometida se alguma informação for alterada, e a confidencialidade pode ser comprometida se alguma informação sensível da empresa ou aplicação for exposta.

Exemplos Comuns de Segredos

Os exemplos mais comuns de segredos são senhas de bancos, como DB Password, que nós utilizamos frequentemente, chaves de API, como Google Maps, OpenAI, AWS, tokens de acesso, como JWT, Bearer Token, certificados e chaves privadas, TLS ou SSH.

Arquivos de Configuração e Segredos

Aqui temos um arquivo .env, que provavelmente, se trabalhamos com aplicações, já devemos ter visto, contendo DB Host, DB Port, que inclui uma porta do Postgres, entre outros segredos que podem causar prejuízos se forem expostos.

Diferença entre Segredos e Informações Sensíveis

É importante destacar que nem toda informação sensível é um segredo. Por exemplo, dados pessoais de usuários não são segredos de aplicação, mas precisam ser protegidos de outra forma. Se nossa aplicação contém dados pessoais, como em um seeder que importa dados para a base de dados, eles não são segredos, mas devem ser protegidos por serem dados sensíveis e informações de usuários. Esses dados precisam ser tratados de forma segura, mas o tratamento é diferente de um segredo. A segurança pode ser garantida através de anonimização ou outras formas.

Exemplos de Segredo versus Informação Sensível

Aqui temos outro exemplo de segredo versus informação sensível. Qual é a diferença? Por exemplo, uma URL de uma API como https://meubeckend.com/.api não é um segredo; é apenas a URL, o host de uma API que aponta para algum recurso. No entanto, se a URL fosse https://user2.senha.meubeckend.com.br, por exemplo, seria um segredo, pois contém credenciais embutidas. Se essas credenciais vazarem, podem ocorrer problemas de integridade e confidencialidade mencionados anteriormente.

Importância da Proteção de Dados Sensíveis e Segredos

Portanto, dados sensíveis também precisam de proteção por serem confidenciais, e segredos precisam de proteção porque concedem acesso a algo. Em resumo, segredos são credenciais sensíveis usadas por aplicações. Por que as aplicações precisam desses segredos? Porque atualmente, praticamente todas as aplicações interagem com serviços externos, como SMS, e-mail, banco de dados, etc. É para isso que servem esses segredos.

Encerramento

Até a próxima aula!

Fundamentos de gestão de segredos - Tipos de segredos

Revisão da Aula Anterior

Na aula anterior, discutimos a diferença entre um segredo e uma informação sensível, bem como a forma de tratá-los em termos de segurança. Um segredo é tratado de uma maneira, enquanto uma informação sensível requer um tratamento diferente, como, por exemplo, a anonimização. Também abordamos alguns conceitos sobre segredos.

Tipos Comuns de Segredos em Aplicações

Nesta aula, vamos aprender sobre os principais tipos de segredos e onde eles aparecem. Os tipos mais comuns de segredos em aplicações incluem senhas de banco de dados e de serviços externos. Por exemplo, pode ser necessário acessar um banco de dados na AWS, como um RDS, ou acessar um Bucket S3 na AWS para fazer o upload de arquivos na aplicação. Isso pode incluir imagens e uma série de outros serviços disponíveis na AWS, na nuvem do Google ou na Azure.

Tokens JWT e Chaves de API

Além disso, tokens JWT e chaves de API são exemplos de segredos utilizados em integrações com serviços como Google Maps, AWS, Google Cloud e Azure. Existem diversas APIs que podemos consumir, e é importante entender como gerenciar esses segredos de forma segura.

Armazenamento e Proteção de Segredos

Nós temos APIs de validação de arquivos, de validação de uma série de informações na aplicação, além de certificados e chaves de criptografia SSH, e variáveis de configurações sensíveis, como, por exemplo, Secret Key, onde esses segredos normalmente aparecem na aplicação. Existem os arquivos .env, que são muito comuns. Aplicações Laravel, por exemplo, em PHP, utilizam bastante o arquivo .env, onde estão declaradas todas as variáveis que a aplicação utiliza, seja o acesso a um banco de dados, a configuração de cache, entre outros tipos de variáveis. Por isso, ele deve ser protegido.

Riscos de Exposição de Segredos

No código-fonte, que é a forma menos aconselhável de todas, ainda vemos desenvolvedores colocando esses segredos dentro do próprio código. Essa é uma forma insegura de se fazer, pois o segredo acaba indo para o Git e fica, de certa forma, exposto para que todos vejam. Mesmo que não ocorra um vazamento, todos da equipe, que talvez não deveriam ver, acabam tendo acesso a esse segredo.

Desafios em Containers, Logs e Ferramentas Externas

Em containers e imagens Docker, infraestrutura e nuvem, se utilizarmos IaC, podemos acabar tendo alguma questão de chave dentro desses arquivos. Logs de erros, quando são impressos sem querer ou compartilhados, podem conter todas as informações do código e credenciais. Alguém pode pedir esse log para ver um debug e ele acaba sendo compartilhado, até com outras empresas. Outro problema dos logs é que, às vezes, outras ferramentas os consomem, como um Power BI, e esses logs acabam indo para ferramentas externas.

Exemplo Prático de Uso de Segredos

Aqui está um exemplo bem simples: no arquivo .env, em Laravel, por exemplo, temos a aplicação do lado esquerdo, indicada com o símbolo do código, e à direita, por exemplo, um MySQL, um Redis e uma SMS API. À direita, está todo o código desse .env, descrevendo essa integração. Este é um exemplo simples do uso de segredos em uma aplicação.

Encerramento

Até a próxima aula.

Fundamentos de gestão de segredos - Riscos do gerenciamento inadequado

Introdução ao Gerenciamento de Segredos

Olá! Na aula anterior, discutimos os principais tipos de segredos e onde eles aparecem. Nesta aula, vamos aprender sobre os riscos e consequências do gerenciamento inadequado de segredos.

Riscos do Gerenciamento Inadequado de Segredos

Os riscos mais comuns que ocorrem quando há um gerenciamento inadequado desses segredos incluem, por exemplo, segredos inseridos diretamente no código (hard-coded), especialmente em repositórios públicos. Um exemplo disso é quando colocamos a conexão de um banco de dados MySQL diretamente no código e versionamos esse código em um GitHub público, expondo essa informação e possibilitando o comprometimento da base de dados.

Chaves de API esquecidas em arquivos .env ou Dockerfile podem ser um problema quando não incluímos o .env no .gitignore. Isso pode resultar em um commit que vai para um GitHub, às vezes público, ou em uma imagem publicada no Docker Hub, expondo o Dockerfile com alguma chave de API diretamente nele. Tokens em logs ou prints de erro também são preocupantes. Quando expomos um segredo em um arquivo de log, perdemos a rastreabilidade, pois o desenvolvedor pode compartilhar esse log para depuração, ou ele pode ser consumido por outras ferramentas, até mesmo de terceiros, para monitoramento. Devemos ter cuidado com essas questões.

Impactos do Gerenciamento Inadequado

Senhas fracas e sem rotações são outro problema. Senhas fáceis e provisórias acabam ficando para sempre, tornando-se uma porta de entrada para ataques e comprometimentos dos sistemas. Os impactos diretos de um gerenciamento inadequado de segredos incluem acesso não autorizado a sistemas e dados sensíveis, roubo de informações corporativas e dados de clientes, e interrupção de serviços e operações críticas. Isso pode resultar em roubo de informações, acesso não autorizado para modificações ou benefícios, e interrupção de serviços por invasores que desejam derrubar o sistema.

Extorsão e chantagem por parte dos atacantes são comuns, com bases de dados sendo vendidas na dark web. O comprometimento da cadeia de suprimentos de software é uma questão importante, pois invasores podem comprometer uma biblioteca utilizada em vários sistemas, afetando diversas empresas.

Exemplos Reais de Comprometimento

Alguns casos reais ilustram o gerenciamento inadequado de segredos. Em 2016, um desenvolvedor da Uber deixou credenciais de acesso à AWS em um repositório privado do GitHub. Hackers invadiram o repositório e usaram as credenciais para acessar cerca de 57 milhões de dados de usuários e motoristas. A Uber foi multada em 148 milhões de dólares e tentou negociar com os hackers, mas sem sucesso.

Outro exemplo é a Toyota em 2022, onde desenvolvedores deixaram chaves de acesso em um código-fonte no GitHub por cinco anos sem rotação. Isso resultou em uma grande perda de confiança no processo de segurança da Toyota e prejuízo de marketing.

Em 2023, pesquisadores da Wiz descobriram que a Microsoft acidentalmente expôs uma chave de acesso privilegiada do Azure em um repositório público do GitHub. Essa chave permitia acesso às caixas de e-mail do Outlook de diversas organizações, gerando um prejuízo reputacional significativo.

Consequências Legais e Financeiras

As consequências incluem multas por violação de LGPD ou GDPR, danos à reputação da marca, custos operacionais para resposta e mitigação, e a possibilidade de ações judiciais de clientes prejudicados. Empresas podem ser forçadas a investir em segurança devido a leis que exigem controles específicos.

Conclusão e Próximos Passos

Essas são as consequências que queremos evitar, e abordaremos alguns controles neste curso. Até a próxima aula!

Sobre o curso Gerenciamento de Segredos: segurança, auditoria e automação com Vault

O curso Gerenciamento de Segredos: segurança, auditoria e automação com Vault possui 167 minutos de vídeos, em um total de 52 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de gestão de segredos