Segurança
Pensar em segurança durante o desenvolvimento de software é uma prática que é tão essencial de ser pensada quanto qualidade, arquitetura e acessibilidade.
Esse guia tende a mostrar alguns itens de segurança que são importantes, com o intuito de tornar o software mais seguro conforme o desenvolvimento do mesmo, e prevenindo-se de sofrer alguns ataques por falta de conhecimento de algumas ferramentas e práticas. Mas não se limite somente a esse guia.
Boas práticas de segurança
Existe uma lista de boas práticas de segurança que pode ser um guia bem completo para quem possui interesse nessa área.
Recursos
Chaves PGP
Tendo um par de chaves GPG é possível encriptar, decriptar e assinar os dados, podendo assim manter a segurança e autenticidade dos mesmos.
Recursos
- PGP
(Pretty Good Privacy) é uma implementação que provê criptografia e autenticação
de dados. - GPG (Gnu Privacy Guard) é a implementação livre do PGP.
Chaves SSH
SSH (Secure Shell) é um protocolo para acesso remoto ao shell de forma criptografada.
Recomenda-se utilizar chaves SSH ao invés de senhas para acesso a servidores, repositórios git entre outros.
Commit git assinado
Ao fazer commits com a ferramenta git, não há garantias de saber quem é o autor dos commits, já que git config não faz nenhum tipo de autenticação durante as configurações.
Um possível meio para ter garantia na autenticidade dos commits é assinando-os com chave PGP, assim todas as pessoas da sua equipe e as ferramentas usadas (como o Github, por exemplo) poderá verificar a assinatura do commit.
Efetuar commit assinado git commit -S
Verificar commits
git verify-commit
Gerenciador de senhas
Recomenda-se utilizar gerenciadores de senhas, criar senhas fortes e não utilizar as mesmas senhas para serviços.
Exemplo, ter uma senha com caracteres especiais, letras maiusculas e minusculas e números sendo elas diferentes para as contas que utilizas (ex. Heroku, Github, SnapCI, etc)
Ferramentas para gerenciador de senhas:
- 1Password
- Pago
- Mac OS, Windows, Android e iOS
- KeepassX
- Grátis
- Open source
- Interface gráfica
- Linux, Mac OS, Android, iOS
- Pass
- Grátis
- Open source
- Linha de comando
- Utiliza o GPG para criptografar
- Linux, Mac OS, Android.
Gerenciar segredos com o time
Um meio seguro de compartilhar segredos com o time é utilizar gerenciador de senhas compartilhado.
Um exemplo é usar o Pass que utiliza GPG para encriptar, o que permite que segredos sejam compartilhados para mais de uma pessoa resultando em um único arquivo e o segredos são sincronizados através do git para ser compartilhado por todos os membros do time.
Outra ferramenta é o 1Password for teams, porém essa ferramenta é paga.
Dois fatores de autenticação
Possuir dois fatores de autenticação (Two factor authentication) é uma boa prática para manter maior segurança no acesso as contas, principalmente quanto a serviços que podem dar acesso ao codebase ou a algum ambiente, exemplo: Github, Heroku, SnapCI e etc.
Recursos
Algumas ferramentas para fazer os dois fatores de autenticação são:
OAuth2 para autenticação em APIs
Recomenda-se o uso de OAuth2 para autenticação em APIs, esse mecanismo permite com que apps externos possam se conectar em APIs sem com que o mesmo saiba a senha do usuário.
Um exemplo para isso é uma app que utiliza a API do Github, essa app basta apenas pedir autorização pelo usuário para acessar determinadas informações, no qual o usuário fará utilizando o próprio Github.
Para mais detalhes sobre o OAuth2 no site
http://oauth.net/2/
Segurança em aplicações web
Durante o desenvolvimento de aplicações web geralmente são pensados pontos de
usabilidade e performance. Assim como esses itens, segurança é algo que deve
ser levado em consideração durante todo o desenvolvimento da aplicação. Um guia
para os itens relacionados a segurança é o
OWASP top 10
.
Recursos
- Há um PDF em português através do link OWASP top 10.
HTTPS não significa estar seguro
Um item importante ao construir aplicações é sempre pensar em encriptar os meios de comunicação entre APIs, microsserviços e usuário-aplicação. HTTPS é um recurso que pode-se dizer obrigatório e de baixo custo, que evita ataques man-in-the-middle e garante que os dados trafegados na rede não foram lidos por mais ninguém além das duas partes que estão trocando informações.
Existe um projeto chamado Let's Encrypt que fornece certificados HTTPS de forma gratuita e clientes que automatizam a atualização desses certificados em suas aplicações.
Para mais detalhes sobre o HTTPS acesse o link no Wikipedia.
Porém, lembre-se que HTTPS é o mínimo para sua aplicação. Ter HTTPS ainda assim não significa que sua aplicação está segura.
Verificação de vulnerabilidades em bibliotecas e pacotes
Um modo de encontrar falhas de segurança é fazer uma verificação nas bibliotecas e dependências que utilizas.
Exemplos de ferramentas:
- NodeJS
- Java
- Python
- Ruby
Recomenda-se executar essa verificação de forma periódica. Para isso, pode-se utilizar um script e integrar junto com uma ferramenta de integração contínua.
Gerenciando senhas em aplicações
Há casos de aplicações que costumam salvar o hash de senhas no banco de dados, muitas vezes usando apenas um algoritmo simples para isso, como o MD5 ou SHA1. Porém recomenda-se que haja uma camada extra de lógica antes de gerar esse hash.
Existe um método de criptografia para hash chamado bcrypt que possui uma segurança maior ao gerar o hash das senhas dos usuários.
Dinâmica: Modelagem de Ameaças
Também conhecida como Threat Modeling, a modelagem de ameaças é um processo pelo qual é possível identificar, entender, comunicar e priorizar as ameaças de segurança dentro do contexto do projeto.
Quem participa
É importante que todos os envolvidos no projeto participem:
Pessoas desenvolvedoras:
- elas serão capazes de trazer a visão técnica da aplicação. Além disso, sua participação incentiva desenvolvimento seguro e fortalece conhecimento de vulnerabilidades.
Pessoas da área de negócio:
- são as melhores pessoas para compartilharem o contexto do negócio, ajudar na priorização do backlog, identificação dos riscos e garantir a melhora contínua do projeto.
Times de segurança, qualidade, infra e outros:
- se há equipes separadas dentro do projeto, todas as equipes devem participar da dinâmica. A responsabilidade de manter a solução segura é de todos. A participação também ajuda a quebrar os silos entre as equipes e promover uma visão unificada das ameaças e possíveis mitigações.
Clientes:
- é quase institinvo querer esconder qualquer vulnerabilidade de segurança dos clientes, entretanto, esse é o pior caminho. A participação do cliente promove a transparência quanto riscos do projeto, fortalece a confiança e compartilha também a visão dos riscos de segurança que devem ser priorizados. Essa é uma grande vantagem da dinâmica, facilitar a conversa e priorização inclusive com quem é o dono do produto.
Qual processo
A dinâmica envolve 4 etapas:
Contexto: O que estamos construindo?
- Esta etapa é destinada ao entendimento da aplicação ou solução, qual o ser valor para o negócio do cliente e qual o aspecto de segurança mais importante. Use diagramas (arquitetura, sequência, componentes e/ou desenhos) e lembre-se de marcar um time-box como 15 minutos.
Identificação: O que podemos melhorar?
- Esta etapa é destinada a entender aquilo que pode acontecer de ruim com a app, quem pode causar isso e como pode causar isso;
- Discuta com o time e liste os principais atores que podem nos atacar:
- Vizinho
- Atacante desconhecida (hacker);
- Cliente descontente;
- Ex-funcionário recém demitido;
- Atacante interno (insider).
- Identifique de que forma os atores podem atacar a aplicação. Essa é a parte central da dinâmica. Existem várias formas de executar essa etapa. Recomendamos que todos escrevem em post its de forma individual o que acham que cada ator pode fazer na aplicação, assim estamos tentando identificar quais ameaças pode acontecer no nosso sistema.
Mitigação: O que faremos sobre isso?
- Etapa destinada a identificarmos quais são os controles que já possuímos e quais são os controles que precisamos implementar;
- Para cada vulnerabilidade realize a pergunta: "Temos algum controle que impeça isso de acontecer?". Se sim, retirar item com referência. Se não, manter o item no nosso mapeamento para próxima etapa.
Priorização: Quando faremos?
- Esta etapa é destinada a identificar probabilidade e impacto de cada associados às ameaças encontradas. Com isso, priorizá-las;
- Desenhe um matriz de Impacto versus Probabilidade. Defina para cada item qual é quadrante que ele está. Por exemplo: alto impacto, baixa probabilidade. Priorize as de Alto Impacto e Alta Probabilidade;
- Derive e priorize tarefas no backlog de acordo com o risco de cada uma.