A engenharia de confiança é uma abordagem de design de sistemas que busca garantir que o sistema se comporte de maneira previsível e segura mesmo sob condições adversas. Diferente de confiar em suposições sobre o comportamento de usuários ou componentes, a engenharia de confiança estabelece mecanismos explícitos para proteger dados e funcionalidades. Nesta aula, exploraremos quatro princípios fundamentais que formam a base de sistemas seguros: privilégio mínimo, defesa em profundidade, falha segura e seguro por padrão.

Esses princípios são aplicáveis a qualquer sistema computacional, desde aplicações web até infraestrutura de rede e sistemas operacionais. Compreendê-los é essencial para projetar, implementar e auditar sistemas resilientes a ataques e falhas.

Least privilege

O princípio do menor privilégio (least privilege) determina que cada entidade (usuário, processo, serviço) deve ter apenas as permissões estritamente necessárias para realizar sua função. Isso limita o dano potencial em caso de comprometimento ou erro, pois o atacante não consegue acessar recursos além do escopo da entidade comprometida.

Na prática, isso significa conceder permissões mínimas para cada tarefa. Por exemplo, um serviço de backup só precisa ler arquivos, não escrever neles; um usuário comum não precisa de acesso administrativo ao sistema. A implementação envolve controle de acesso baseado em funções (RBAC), listas de controle de acesso (ACLs) e a prática de executar processos com contas de serviço dedicadas e com privilégios reduzidos.

Exemplo: Em um sistema Linux, o serviço web (nginx) é executado como usuário 'www-data' com permissão apenas para ler arquivos estáticos e escrever logs. Não tem acesso a arquivos de configuração sensíveis ou ao shell.

Boas práticas incluem revisar periodicamente as permissões, usar o princípio de 'need-to-know' para dados, e evitar contas com privilégios elevados para tarefas rotineiras. Ferramentas como SELinux e AppArmor ajudam a impor o menor privilégio no nível de sistema.

Defense in depth

Defesa em profundidade (defense in depth) é a estratégia de implementar múltiplas camadas de segurança, de modo que, se uma camada falhar, outras ainda protejam o sistema. É o equivalente a ter várias fechaduras em uma porta: nenhuma é perfeita, mas juntas aumentam significativamente a segurança.

As camadas podem incluir: firewalls de rede, sistemas de detecção de intrusão, autenticação multifator, criptografia, controles de acesso, hardening de sistema, monitoramento e resposta a incidentes. Cada camada deve ser independente e complementar. Por exemplo, mesmo que um firewall seja burlado, a autenticação forte pode impedir o acesso não autorizado a dados.

Exemplo: Um banco de dados crítico é protegido por: (1) firewall de rede bloqueando portas não essenciais; (2) autenticação de aplicação com senha forte e MFA; (3) criptografia dos dados em repouso; (4) logs de acesso monitorados por SIEM; (5) backup offline para recuperação.

A defesa em profundidade não se limita a tecnologia: inclui também políticas, treinamento de usuários e procedimentos de resposta. O objetivo é criar redundância e diversidade de controles, dificultando ao máximo a exploração bem-sucedida.

Fail safe

O princípio de falha segura (fail safe) determina que, quando um sistema falha, ele deve falhar em um estado seguro, ou seja, negando acesso ou protegendo dados, em vez de expô-los. Isso contrasta com sistemas que falham abertos (fail open), que podem permitir acesso inadvertido.

Exemplos clássicos: um firewall que, ao travar, deve bloquear todo o tráfego (fail closed) em vez de permitir todo o tráfego (fail open). Um sistema de controle de acesso físico que, em caso de falha elétrica, deve manter portas trancadas (fail secure) ou destrancá-las para evacuação (fail safe) – a escolha depende do contexto. Em segurança da informação, geralmente prefere-se fail secure: negar acesso quando não é possível verificar.

Exemplo: Um sistema de autenticação que, ao não conseguir contatar o servidor LDAP, deve recusar o login (negar acesso) em vez de permitir o acesso irrestrito.

Ao projetar, considere cenários de falha (quebra de hardware, falta de rede, erro de software) e defina explicitamente o comportamento padrão. Documente essas decisões e teste-as regularmente.

Secure by default

Seguro por padrão (secure by default) significa que a configuração inicial de um sistema deve ser a mais segura possível, exigindo que o administrador reduza intencionalmente a segurança para habilitar funcionalidades. O oposto é inseguro por padrão, onde a segurança é uma opção que pode ser ativada.

Na prática, isso implica desabilitar serviços desnecessários, usar senhas fortes padrão (ou forçar troca no primeiro login), criptografar comunicações por padrão, e aplicar permissões restritivas. Por exemplo, um servidor web recém-instalado não deve expor diretórios sensíveis ou executar scripts desnecessários.

Exemplo: Ao instalar um banco de dados, a conta 'root' deve ter uma senha aleatória gerada, o acesso remoto deve ser desabilitado, e apenas portas locais devem estar ativas. O administrador configura explicitamente as permissões para cada aplicação.

Esse princípio reduz a superfície de ataque e minimiza erros de configuração. É especialmente importante em dispositivos IoT, software de consumo e sistemas que serão implantados por usuários não especialistas.

Boas práticas e observações finais

Integrar esses princípios desde o início do design de sistemas reduz custos e riscos. Realize análises de risco para determinar quais princípios são mais críticos em cada contexto. Documente as decisões de segurança e realize revisões periódicas. Lembre-se de que segurança é um processo contínuo: mesmo um sistema seguro por padrão precisa de atualizações e monitoramento.

Referências

Exercícios

  1. Explique com suas palavras o princípio do menor privilégio e dê um exemplo de sua aplicação em um sistema operacional.

    ✓ Resposta: O menor privilégio significa que cada entidade deve ter apenas as permissões estritamente necessárias para executar sua função. Exemplo: em um sistema Linux, o serviço web (nginx) roda como usuário 'www-data' com permissão apenas de leitura para arquivos estáticos e escrita em logs, sem acesso a arquivos de sistema ou shell.

  2. Cite três camadas de segurança que podem compor uma estratégia de defesa em profundidade para proteger um banco de dados.

    ✓ Resposta: Três camadas: (1) firewall de rede bloqueando portas não utilizadas; (2) autenticação forte (senha + MFA) para acesso à aplicação; (3) criptografia dos dados em repouso no disco.

  3. Qual a diferença entre fail safe e fail secure? Dê um exemplo de cada no contexto de segurança da informação.

    ✓ Resposta: Fail safe significa que, em caso de falha, o sistema assume um estado seguro (geralmente negando acesso). Fail secure é um subconjunto que foca em manter a segurança (ex.: portas trancadas). Exemplo: um firewall que, ao falhar, bloqueia todo o tráfego (fail secure); um sistema de controle de acesso a uma sala de servidores que, em caso de incêndio, destranca as portas para evacuação (fail safe).

  4. Por que é importante que um software seja seguro por padrão? Dê um exemplo de configuração que viola esse princípio.

    ✓ Resposta: Seguro por padrão reduz a superfície de ataque e evita que usuários menos experientes deixem o sistema vulnerável. Exemplo de violação: um servidor web que, na instalação padrão, expõe diretórios de administração sem autenticação ou permite listagem de diretórios.

  5. Descreva uma situação onde o princípio do menor privilégio entra em conflito com a usabilidade e como você poderia resolver esse conflito.

    ✓ Resposta: Conflito: um usuário que precisa instalar software frequentemente pode achar restritivo não ter privilégios administrativos. Solução: fornecer um mecanismo de elevação temporária de privilégios (ex.: sudo com senha) que registre em log cada uso, e criar um processo de aprovação para instalações, equilibrando segurança e produtividade.