Design Confiança

Tags:
Categories:

Arquitetura de Segurança e Princípios de Design

Três Elementos de Segurança e Princípios de Design de Segurança

  • Integridade
  • Disponibilidade
  • Confidencialidade

Princípio de Design Aberto

Open Design

  • O design não deveria ser segredo, design aberto é mais seguro.
  • Segurança não depende de segredo.

Princípio de Falha-Segurança Padrão

Fail-safe defaults

  • Decisão de acesso baseia-se em “permitir”, não em “negar”.
  • Por padrão, acesso não é permitido, mecanismos de proteção apenas identificam situações de acesso permitido.
  • Segurança em falha: Qualquer sistema complexo deve ter um mecanismo de segurança de emergência quando falhar, além disso, mensagens de erro e logs precisam ser cuidadosos, evitando vazamento de informações.
  • Segurança padrão: O sistema, no estado inicial, a configuração padrão é segura, fornecendo segurança máxima usando o mínimo de serviços e sistemas.

Princípio de Separação de Privilégios

Separation of Privilege

  • Um mecanismo de proteção requer duas chaves para desbloquear, mais robusto e flexível do que uma única chave.
  • Objetivo da separação de privilégios
  • Evitar conflitos de interesse, abuso de poder individual
  • Dividir um privilégio importante em múltiplos privilégios, tornando mais difícil a obtenção ilegal de objetos a serem protegidos, aumentando assim a segurança.
  • Separar responsabilidades e autoridades de diferentes processos

O sistema pode definir três papéis por padrão, contas de sistema com autoridades mutuamente independentes, separando responsabilidades:

  • Administrador do Sistema: Responsável pela gestão diária de usuários e configuração do sistema.
  • Administrador de Segurança: Responsável pela ativação e desativação de estado de usuários e configurações de segurança.
  • Auditor de Segurança: Responsável por auditar as operações dos dois anteriores, possuindo permissão de exportação de logs, garantindo rastreabilidade de todas as operações dos usuários do sistema.

Princípio do Menor Privilégio

Least Privilege

  • Cada usuário e programa do sistema deve usar o menor conjunto de privilégios necessário para completar o trabalho.
  • Garantir que aplicativos sejam executados com os privilégios mínimos.
  • Para diferentes programas executados por usuários no sistema, como banco de dados, servidores WEB, prestar atenção para usar contas com privilégios mínimos, não contas com privilégios máximos do sistema.
  • Ao criar novas contas, atribuir por padrão o menor papel de privilégios.

Princípio de Mecanismo Econômico

Economy of Mechanism

  • Manter o design do sistema e código o mais simples e compacto possível.
  • Quanto mais complexo o software, maior a probabilidade de bugs no código; se o design for o mais elegante possível, menor a probabilidade de problemas de segurança.
  • Remover código redundante e módulos de funcionalidades desnecessárias, reter apenas o código que aumenta a superfície de ataque do sistema.
  • Projetar componentes reutilizáveis para reduzir código redundante.
  • Econômico e adequado: simples, elegante, componentizado.
  • Não sobredesenhado

Princípio de Comunicação Mínima

Least Common Mechanism

  • Evitar o máximo possível cenários onde múltiplos objetos compartilham o mesmo recurso, minimizando a quantidade e uso de recursos compartilhados.
  • Objetos compartilhados criam canais potenciais de fluxo de informações e interações involuntárias perigosas, evitar o máximo possível cenários onde múltiplos objetos compartilham o mesmo recurso.
  • Se um ou mais objetos não ficam satisfeitos com o serviço fornecido pelo mecanismo compartilhado, eles podem optar por não usar o mecanismo compartilhado, evitando ataques indiretos de bugs de outros objetos.
  • Minimizar memória compartilhada
  • Minimizar vinculação de portas
  • Reduzir conexões, defender contra ataques DoS

Princípio de Mediação Completa

Complete Mediation

  • O princípio de mediação completa exige que todo acesso a cada objeto seja verificado por auditoria de segurança.
  • Quando um sujeito tenta acessar um objeto, o sistema verifica a cada vez se o sujeito possui essa permissão.
  • Sempre que possível, permitir que o proprietário do recurso tome decisões de controle de acesso, por exemplo, se for uma URL, deixar que o servidor backend faça a verificação, não julgar no frontend.
  • Prestar atenção especial ao uso e verificação de cache, não é possível garantir que informações em cache não foram adulteradas por hackers. Ex.: engano de cache DNS.

Princípio de Aceitabilidade Psicológica

Psychological Acceptability

  • Mecanismos de segurança podem acrescentar carga extra aos usuários, mas essa carga deve ser mínima e razoável.
  • Mecanismos de segurança devem ser amigáveis ao máximo para usuários do sistema, facilitando o uso e entendimento do sistema.
  • Se o método de configuração for muito complexo e trabalhoso, administradores de sistemas podem inadvertidamente configurar uma opção incorreta, tornando o sistema inseguro.
  • Esse princípio geralmente está relacionado a interação homem-máquina e design centrado no usuário (UCD).

Princípio de Defesa em Profundidade

Defense in Depth Defesa em Profundidade é um princípio de defesa com requisitos abrangentes e altos, geralmente exigindo que arquitetos de sistemas integrem outros princípios de design de segurança, adotando mecanismos de verificação de segurança multipontos e múltiplos, observando o mecanismo de defesa de segurança em nível de arquitetura do sistema de forma abrangente, ao invés de depender apenas de um único mecanismo de segurança.