This post is also available in: Português Español
É nítido o crescimento das soluções para o desenvolvimento de softwares de alta qualidade. Está mais fácil do que nunca criar um aplicativo ou sistema, mas essa mesma facilidade chega também para os cibercriminosos.
À medida que os softwares ficam mais conectados e recheados com valiosos dados pessoais e corporativos, os cibercriminosos se tornam mais sofisticados. Eles não são mais amadores trabalhando no seu próprio quarto; são profissionais que vivem disso e fazem parte de grandes redes clandestinas.
Além disso, sabe-se que é praticamente impossível desenvolver softwares completamente livres de falhas de segurança. A boa notícia é que se pode projetar aplicativos que preveem tais vulnerabilidades desde a fase mais inicial de concepção até o lançamento no mercado. É um conceito chamado de Security By Design. Para atuar com essa proposta, a ideia é seguir alguns princípios pré-definidos durante a fase de design do aplicativo. Dessa forma, mesmo quando os bugs aparecem, o dano que eles causam não leva os invasores a obter todos os dados valiosos, nem resulta em interrupções no uso diário.
Para seguir com a ideia de incorporar a segurança em todas as fases de criação de um sistema, existem princípios de segurança padrão que funcionam basicamente em qualquer tipo de solução. Seguir esses princípios é fundamental para garantir que o software esteja o mais seguro e protegido possível, tanto para quem cria quanto para quem utiliza.
- 1. Princípio do Privilégio Mínimo
- 2. Princípio da Separação de Funções
- 3. Princípio da Defesa em Profundidade
- 4. Princípio de Falhar com Segurança
- 5. Princípio do Design Aberto
- 6. Princípio de Evitar Segurança por Obscuridade
- 7. Princípio de Minimização da Área de Superfície de Ataque
A ideia é garantir que as pessoas tenham acesso apenas ao que for estritamente necessário para fazer seu trabalho. Por exemplo: quem projetar um sistema que contém informações financeiras confidenciais de clientes, é uma boa prática limitar quem pode acessar essas informações. O funcionário que atende o telefone e agenda reuniões provavelmente não precisa de acesso a todas as informações sigilosas.
Por outro lado, um gerente de contas provavelmente precisa ter acesso a essas informações. Mas a ideia é garantir que esse mesmo gerente de contas não tenha acesso a informações de contas que ele não gerencia.
Ao fazer com que as contas tenham apenas os privilégios necessários para realizar seu trabalho, garante-se que, se um invasor comprometer uma conta, serão minimizadas as informações que ele pode acessar. Isso limita o dano do ataque.
A ideia por trás desse quesito é que nenhum cargo deve ter muita autoridade. Isso é diferente do conceito de privilégio mínimo. Embora isso se concentre em fazer com que as pessoas tenham apenas os privilégios de que precisam para realizar seu trabalho, trata-se de garantir que suas demandas não sejam muito grandes.
Quando alguém faz um trabalho muito grande, volta-se ao ponto em que eles precisarão de muitas permissões para fazer esse trabalho. Além disso, quando alguém tem muitos deveres em seu cotidiano, isso significa que é suscetível a tomar decisões erradas, por possivelmente estar sobrecarregado.
Em suma, ninguém gostaria que a pessoa responsável por fazer as vendas também pudesse aprovar descontos. Esse colaborador teria um incentivo para descontar o valor de venda do software e poderia tomar decisões ruins sobre descontos para aumentar seus números de vendas. Em vez disso, outra pessoa, como um gerente, precisa aprovar um desconto antes que a venda seja concluída.
Este é um pouco diferente dos princípios anteriores. Enquanto o Mínimo Privilégio e a Separação de Deveres pensam em como as pessoas obtêm acesso ao sistema, Defesa em Profundidade trata de impedir o acesso ao sistema. A expectativa é que qualquer sistema de segurança que se colocar em prática irá falhar. Pode ser muito difícil contornar as defesas, mas impossível não é.
Projetar com Defesa em Profundidade significa configurar sistemas que informarão quando a segurança designada falhar. Por exemplo, muitos servidores de aplicações usam software de segurança, mas estão localizados em um único prédio. Alguém que invadisse o local teria acesso físico a cada um dos servidores. Aí talvez esse firewall sofisticado ou software de detecção de intrusão seria pouco efetivo.
É por isso que os data centers são projetados com uma série de camadas de segurança lógica e física, para detectar e proteger as informações.
Assim como a Defesa em Profundidade, o Princípio de Falhar Com Segurança reconhece que a falha vai aparecer cedo ou tarde. Para imaginar como um sistema pode falhar com segurança, imagine um mecanismo de controle de acesso digital. Talvez seja necessário um crachá de segurança para acessar as áreas sensíveis de um prédio. Seguindo o princípio do Mínimo Privilégio, o crachá só dá acesso às áreas que você precisa para fazer seu trabalho. Mas deve-se pensar no que aconteceria em casos de falta de energia elétrica, por exemplo.
Em um sistema que falha ao abrir, todas as fechaduras param de funcionar. Em um sistema que falha com segurança, todas as portas travam. O mesmo conceito se aplica ao projeto de software. Um sistema projetado para falhar com segurança só concede acesso a partes do sistema quando todas as etapas do processo são concluídas com êxito.
O Princípio do Design Aberto diz que a segurança do seu sistema não deve depender do sigilo de sua implementação. Este é um princípio particularmente importante para conceitos de segurança como implementações criptográficas.
Em linhas gerais, o princípio de design seguro garante que o sistema esteja protegido, independentemente de alguém mal-intencionado obter acesso ao seu código.
É algo semelhante ao Design Aberto. Pode-se pegar o exemplo de um software que tenha uma combinação secreta de nome de usuário e senha codificada. Quando autenticada, esta conta tem acesso total a todas as contas do sistema. A segurança deste sistema depende de as credenciais desta conta permanecerem em segredo.
Entretanto, com o tempo, um número crescente de usuários terá acesso a ela. Alguns sairão da empresa, e se as credenciais não forem devidamente gerenciadas pelo time de tecnologia, abre-se uma brecha para incidentes de segurança.
A verdade é que a segurança de cada aplicativo depende, de uma certa forma, de sigilo. Afinal, as senhas continuam sendo uma parte crítica da maioria dos esquemas de autenticação. No entanto, um design melhor para esse sistema é aquele em que a conta com acesso total não existe. E se for necessário criá-la, é importante fazer a devida gestão da mesma, para evitar incidentes de segurança.
Aqui a ideia é remover partes de um aplicativo para torná-lo mais seguro. É algo semelhante ao que acontece com a estrutura física de data centers, que ficam em salas sem janelas. Como janelas são relativamente fáceis de quebrar, melhor removê-las – já que em um data center elas não têm grande utilidade.
Muitas das partes de um software são como janelas. A princípio, podem parecer interessantes, mas trazem consigo a possibilidade de expor funcionalidades que levam a bugs. Assim, para minimizar a área de superfície de ataque é importante questionar se determinado recurso é mesmo necessário. Às vezes, ao redesenhar um recurso para torná-lo mais simples, a segurança geral do aplicativo melhora.
This post is also available in: Português Español
