Bem-vindo à aula sobre os Princípios de Engenharia de Confiança. Em segurança da informação, confiança não é um sentimento, mas uma propriedade projetada. Sistemas confiáveis são aqueles em que podemos depositar nossa segurança porque foram construídos seguindo princípios sólidos que minimizam riscos e limitam danos. Nesta aula, exploraremos quatro pilares essenciais: menor privilégio, defesa em profundidade, falha segura e padrão seguro. Esses conceitos são a base para arquiteturas robustas e resiliência contra ataques.

Menor Privilégio

O princípio do menor privilégio determina que cada usuário, processo ou sistema deve ter apenas as permissões estritamente necessárias para realizar suas funções legítimas. Isso reduz a superfície de ataque e limita o impacto de possíveis violações. Por exemplo, um funcionário do RH não precisa de acesso a dados financeiros; um serviço web não precisa de permissões de escrita em diretórios do sistema.

Na prática, aplicar o menor privilégio exige uma análise cuidadosa das necessidades de cada entidade. Em sistemas Unix, isso significa criar contas de serviço com permissões mínimas, usar grupos e ACLs (listas de controle de acesso) para granularidade. Em aplicações web, acessos a bancos de dados devem ser feitos com usuários que só têm permissões SELECT em tabelas específicas, nunca com privilégios de administrador.

Exemplo: Um serviço de backup precisa ler arquivos de log, mas não deve poder modificá-los.
  - Crie um usuário 'backup' no sistema.
  - Atribua ao usuário permissão de leitura (r--) para os arquivos de log.
  - Não conceda permissão de escrita ou execução desnecessária.
  - Em bancos de dados, conceda apenas SELECT nas tabelas de log.

Defesa em Profundidade

Defesa em profundidade (ou "camadas de segurança") é a estratégia de usar múltiplas camadas de controle de segurança para proteger um sistema. Se uma camada falhar, outra ainda estará presente para impedir ou mitigar o ataque. É como as camadas de uma cebola: cada uma adiciona uma barreira adicional.

Exemplos típicos incluem firewalls, sistemas de detecção de intrusão (IDS), criptografia, autenticação multifator, segmentação de rede e monitoramento contínuo. Um atacante que ultrapassa o firewall ainda encontra um IDS; se vencer a autenticação, a criptografia dos dados pode impedir o uso indevido. A ideia é não confiar em nenhuma única medida de segurança.

Exemplo: Proteção de um servidor web:
  1. Firewall de borda bloqueia portas não essenciais.
  2. WAF (Web Application Firewall) filtra requisições maliciosas.
  3. Autenticação forte (MFA) para acesso administrativo.
  4. Criptografia TLS para dados em trânsito.
  5. Monitoramento de logs e alertas de anomalias.
  6. Backup regular e plano de resposta a incidentes.

Falha Segura

O princípio de falha segura estabelece que, quando um sistema falha, ele deve falhar de maneira segura, ou seja, negando acesso ou mantendo o estado mais restritivo possível. Por exemplo, se um sistema de controle de acesso trava, ele deve negar permissão em vez de concedê-la. Isso evita que uma falha se transforme em uma brecha de segurança.

Em programação, isso significa tratar exceções de forma a não expor informações sensíveis ou deixar o sistema em estado vulnerável. Por exemplo, ao processar uma autenticação, se o banco de dados estiver indisponível, o sistema deve retornar um erro genérico e não permitir o login. Em sistemas físicos, como portas de segurança, uma falha de energia deve manter a porta trancada (fail-secure) em vez de destrancada (fail-open), a menos que a vida humana esteja em risco (saída de emergência).

Exemplo: Código de autenticação com falha segura:
  try {
    if (autenticar(usuario, senha)) {
      concederAcesso();
    } else {
      negarAcesso();
    }
  } catch (Exception e) {
    // Em caso de erro, negue acesso e registre o incidente
    logErro(e);
    negarAcesso(); // falha segura: nega acesso
  }

Padrão Seguro

O princípio do padrão seguro afirma que as configurações padrão de um sistema devem ser as mais seguras possíveis, deixando ao usuário a opção de reduzir a segurança se necessário (e com conhecimento). Isso evita que usuários desatentos ou inexperientes deixem sistemas vulneráveis por não alterarem configurações inseguras.

Exemplos incluem: senhas fortes obrigatórias na criação de contas, criptografia habilitada por padrão, firewalls ativos, portas não essenciais fechadas, e permissões mínimas. Na prática, muitos sistemas falham nesse princípio ao vir com senhas padrão (como "admin/admin") ou serviços expostos desnecessariamente. Sempre que possível, o padrão deve ser o mais restritivo, e qualquer alteração para menos segurança deve ser uma decisão explícita e documentada.

Exemplo: Configuração segura de um servidor web:
  - Desabilitar listagem de diretórios por padrão.
  - Exigir HTTPS (redirecionar HTTP para HTTPS).
  - Desabilitar métodos HTTP perigosos (PUT, DELETE) por padrão.
  - Definir cabeçalhos de segurança (HSTS, X-Frame-Options) ativos.
  - Usar senhas fortes para contas administrativas, sem senhas padrão.

Boas Práticas e Observações Finais

A engenharia de confiança não se limita a esses quatro princípios, mas eles formam uma base sólida. Sempre que projetar um sistema, questione: "Qual o menor privilégio necessário?", "Quantas camadas de defesa existem?", "O que acontece se algo falhar?", "As configurações padrão são seguras?". Documente suas decisões e realize revisões periódicas de segurança. Lembre-se: confiança é construída com design cuidadoso, não com suposições.

Referências

Exercícios

  1. Explique com suas palavras o princípio do menor privilégio e dê um exemplo de uma situação em que sua ausência poderia causar um incidente de segurança.

    2. ✓ Resposta: O princípio do menor privilégio estabelece que cada entidade (usuário, processo, sistema) deve ter apenas as permissões necessárias para executar suas funções. Exemplo: um estagiário com acesso de administrador a todo o sistema poderia, acidental ou maliciosamente, deletar arquivos críticos. Se tivesse apenas permissão de leitura em pastas específicas, o dano seria limitado.
  2. Descreva a estratégia de defesa em profundidade e liste pelo menos três camadas de segurança que podem ser implementadas em uma aplicação web.

    3. ✓ Resposta: Defesa em profundidade é usar múltiplas camadas de segurança para que, se uma falhar, outras protejam. Exemplos em uma aplicação web: (1) Firewall de aplicação web (WAF) filtrando requisições; (2) Autenticação multifator para acesso; (3) Criptografia TLS para dados em trânsito; (4) Validação rigorosa de entrada no servidor; (5) Monitoramento de logs e alertas.
  3. Dê um exemplo de falha segura em um sistema de controle de acesso físico (porta eletrônica). Explique por que essa abordagem é preferível em relação a uma falha que libera o acesso.

    4. ✓ Resposta: Em uma porta eletrônica, falha segura significa que, em caso de falta de energia ou mau funcionamento, a porta permanece trancada (fail-secure). Isso impede acesso não autorizado. Já uma falha que destranca (fail-open) poderia permitir invasões. A falha segura é preferível pois prioriza a segurança sobre a conveniência, exceto em saídas de emergência onde a vida está em risco.
  4. Por que é importante que sistemas venham com configurações seguras por padrão? Cite um exemplo de um produto ou software que historicamente falhou nesse aspecto.

    5. ✓ Resposta: Configurações seguras por padrão protegem usuários que não alteram as configurações, evitando vulnerabilidades comuns. Exemplo histórico: roteadores domésticos que vinham com senha padrão 'admin' e porta 80 aberta, permitindo que malwares como o 'Mirai' os recrutassem para botnets. Hoje, muitos fabricantes já exigem troca de senha no primeiro acesso.
  5. Pense em um sistema que você usa diariamente (ex.: e-mail, rede social, banco online). Identifique pelo menos dois princípios de engenharia de confiança presentes nesse sistema e explique como eles são aplicados.

    6. ✓ Resposta: Exemplo: sistema de banco online. (1) Menor privilégio: um usuário comum só pode ver suas próprias contas e realizar transferências limitadas; um gerente tem acesso a relatórios, mas não a senhas. (2) Defesa em profundidade: uso de senha + token (MFA), criptografia SSL, monitoramento de transações suspeitas, e bloqueio após múltiplas tentativas erradas.