Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Ao estabelecer a disciplina de Arquitetura de Segurança, este artigo fornece orientações sobre como aplicar 10 leis imutáveis do risco de segurança como dicas práticas enquanto estabelece e moderniza a disciplina de Arquitetura de Segurança.
Revê as leis imutáveis da segurança
A arquitetura existe para identificar requisitos desafiantes e transformá-los em orientações acionáveis para reduzir riscos de segurança, limitar danos e manter os sistemas disponíveis ao longo do tempo. Na base deste trabalho estão as leis imutáveis da segurança.
Estas leis descrevem verdades desconfortáveis sobre a segurança que o ajudam a planear um controlo eficaz, evitar equívocos comuns que minam a arquitetura de segurança e criam riscos organizacionais.
| Lei imutável | Impacto na arquitetura |
|---|---|
| 1. Se um ator mal-intencionado te conseguir convencer a executar o programa deles, não é o teu computador | A execução não autorizada de código causa perda de controlo. Só a prevenção é insuficiente. |
| 2. Se um agente malicioso pode alterar o sistema operativo, não é o teu computador | O comprometimento do plano de controlo é um risco sistémico. Isto aplica-se quer o plano de controlo seja um sistema operativo local, um sistema de gestão de identidade, uma ferramenta de segurança ou qualquer outra coisa com acesso ao nível do sistema/raiz. |
| 3. Se um agente mal-intencionado tem acesso físico irrestrito, não é o seu computador | A exposição física deve ser assumida, não tratada como exceção. |
| 4. Se um ator mal-intencionado consegue publicar conteúdo ativo no seu site, então não é o seu site | Os limites de execução definem os limites de confiança. |
| 5. Palavras-passe fracas sobrepõem-se à segurança forte | Falhas de identidade derrotam controlos em camadas. |
| 6. Um computador só é tão seguro quanto o seu administrador | O acesso privilegiado é uma prioridade de segurança de importância crítica. |
| 7. Os dados encriptados são tão seguros quanto a sua chave de desencriptação | A criptografia sem governação é frágil. |
| 8. Um scanner antimalware desatualizado é ligeiramente melhor do que nenhum | As defesas estáticas deterioram-se. |
| 9. Anonimato absoluto não é alcançável | A visibilidade é inevitável. |
| 10. A tecnologia não é uma panaceia | As falhas de pessoas e processos devem ser assumidas. |
Aplicar as dez leis do risco de cibersegurança
Mesmo depois de compreender como o controlo de segurança pode ser perdido e o impacto na arquitetura de segurança, esta informação não é suficiente para desenhar um sistema. Os arquitetos de segurança também devem compreender:
- Para que estamos a otimizar? - Onde concentramos o esforço? - Que trocas são aceitáveis?
Para esclarecer estas questões, podemos aplicar 10 leis comuns do risco de cibersegurança. Cada conjunto de leis trata de diferentes aspetos da cibersegurança.
| Direito | Implicação arquitetónica | Orientação de modernização |
|---|---|---|
| 1. O sucesso em segurança está a arruinar o retorno do investimento do atacante | Projetar arquiteturas que aumentem o custo do atacante e reduzam o retorno, especialmente para ativos de alto valor. | - Concentrar os controlos em torno da identidade, acesso privilegiado e dados sensíveis. - Reduzir as zonas de confiança indiferenciadas; segmentar os sistemas para que um comprometimento não se propague. - Priorizar proteções que quebram cadeias comuns de atacantes, não casos especiais. |
| 2. Não acompanhar é ficar para trás | As arquiteturas estáticas falham. A arquitetura deve assumir uma evolução contínua. | - A arquitetura de segurança nunca está concluída. Deve ser operacionalmente sustentável e continuamente melhorado. - Projeto para atualização contínua (patches, configuração, política). - Preferir serviços cloud-nativos e geridos que evoluem mais rapidamente do que sistemas on-premises ou personalizados. - Garantir que a visibilidade e a inventariação são requisitos arquitetónicos, e não algo em que se pense mais tarde. |
| 3. A segurança é um facilitador empresarial (a produtividade vence sempre) | Se a arquitetura cria atrito, é contornada. | - Uma boa arquitetura de segurança permite a produtividade por predefinição. - Favorecer o acesso baseado em identidade em detrimento da complexidade da rede. - Integrar os controlos de segurança nos fluxos de trabalho padrão de utilizadores e programadores. - Tornar os caminhos seguros os mais simples. |
| 4. Os atacantes não se importam | Os atacantes utilizam qualquer caminho de acesso disponível no ambiente. A arquitetura deve eliminar os caminhos mais baratos, não defender apenas os óbvios. | - A arquitetura deve refletir o comportamento real do atacante, não crenças idealizadas em controlos individuais. - Assuma que houve comprometimento através de phishing, má configuração ou protocolos legados. - Remover pontos únicos arquitetónicos de falha catastrófica. - Proteger contra todo o ciclo de vida do ataque (movimento lateral, execução de objetivos), não apenas acesso inicial. |
| 5. A priorização implacável é uma habilidade de sobrevivência | Não podes garantir tudo. | - A arquitetura é sobre escolher o que não fazer. - Identificar ativos críticos e conceber “defesa em profundidade” para esses ativos. - Aceitar garantias mais baixas quando o impacto no negócio é menor. - Utilizar cenários empresariais para orientar o investimento arquitetónico. |
| 6. A cibersegurança é um desporto de equipa | A arquitetura deve integrar o trabalho entre disciplinas e equipas. | - Os arquitetos projetam a coordenação, não apenas os controlos. - Alinhar a arquitetura com as equipas da plataforma, programadores e operações. - Delegar controlos a plataformas que os possam fazer melhor (fornecedores de cloud, sistemas de identidade). - Evitar soluções personalizadas onde os serviços partilhados sejam suficientes. |
| 7. A sua rede não é tão confiável como pensa | A confiança na rede nunca deve ser o plano de controlo primário ou único. | - Esta lei sustenta o afastamento do design centrado no perímetro. - Deslocar as decisões de confiança para identidade, dispositivo e contexto de aplicação. - Arquiteturas de design que assumem que a rede é observável e hostil. - Manter controlos eficazes como firewalls/firewalls de aplicações web (WAFs), mas não depender deles para detetar/bloquear tudo. - Utilizar modelos de acesso Confiança Zero de forma consistente entre ambientes. |
| 8. Redes isoladas não são automaticamente seguras | O isolamento só é eficaz quando rigorosamente desenhado e mantido. | - Mantenha o isolamento de rede que funciona bem. Certifica-te de que a manténs e de que os atacantes não a consigam contornar facilmente. - A arquitetura deve ter em conta as pessoas e o processo, não apenas a topologia. - Tratar o isolamento como um sistema, não como uma regra de filtragem de rede. - Proteger todos os pontos de ponte (media, acesso de fornecedores, administradores). - Presuma o comprometimento e aplique controlos de identidade e operacionais robustos, mesmo em arquiteturas isoladas (“air-gapped”). |
| 9. A encriptação sozinha não é uma solução de proteção de dados | A criptologia só é tão segura quanto as chaves que a desbloqueiam. | - A encriptação é importante, mas é ineficaz sem implementação e operação seguras. - Conceba a gestão centralizada de chaves e a governação de acessos. - Proteger os caminhos de desencriptação de forma tão agressiva quanto o armazenamento encriptado. - Combinar encriptação com identidade, monitorização e aplicação de políticas. |
| 10. A tecnologia não resolve pessoas nem processa problemas | A arquitetura deve assumir humanos e processos imperfeitos. | - Modernizar a arquitetura de segurança para reduzir o impacto de erros humanos. Não deixe que clicar num único email de phishing faça a sua postura de segurança falhar. - Projetar sistemas resilientes a erros. - Automatizar guarda-corpos sempre que possível. - Evitar arquiteturas que dependem de uma operação manual impecável. |
Construir uma arquitetura
Como arquiteto de segurança, pode usar estas duas tabelas como lentes complementares. Um para validar a solidez técnica e o outro para impulsionar a priorização baseada no risco. Quando combinados, formam um quadro prático de decisão para o design arquitetónico e a modernização.
| Leis | Objetivo | Utilização arquitetónica | Perguntas respondidas |
|---|---|---|---|
| Leis de segurança imutáveis | Captar verdades técnicas que são sempre válidas. | Garantir que as arquiteturas não violam a realidade técnica. Suposições de teste Valide as fronteiras de confiança. Evita falsa confiança. |
A arquitetura é fundamentalmente sólida? A conceção baseia-se em algo que possa ser facilmente contornado? Estamos a assumir que a tecnologia pode compensar administradores não confiáveis, palavras-passe fracas ou métodos físicos de acesso? Estamos a confundir encriptação, isolamento ou ferramentas com controlo real? |
| Leis do risco de cibersegurança | Decide o que é que mais importa. | Identifique onde investir o esforço em arquitetura. Defina planos de modernização. Justifique os trade-offs aos líderes de negócio. |
Onde é que os atacantes obtêm o maior retorno pelo menor esforço? Quais controlos realmente alteram o comportamento do atacante? Que trabalho já não vale a pena fazer? |
Exemplo
Portanto, se tomarmos um exemplo que aplica ambas as tabelas em conjunto.
| Decisão de conceção | Lente das leis imutáveis | A perspetiva das dez leis |
|---|---|---|
| Reduzir a dependência das ACLs de rede para acesso baseado em identidade | As redes não são de confiança, a identidade importa. | Aumenta o custo dos atacantes e está alinhado com os princípios do Confiança Zero. |
| Dá prioridade ao MFA para os administradores antes de reforçar firewalls de borda. | Palavras-passe fracas sobrepõem-se à segurança forte. | A forma mais barata de quebrar cadeias de ataques comuns. |
| Cargas de trabalho por segmentos em vez de depender de "intervalos aéreos" | O isolamento não é automaticamente seguro. | Reduz o raio de explosão quando os atacantes entram. |
| Automatizar a aplicação de patches e a deteção de desvios de configuração | Defesas desatualizadas falham. | Não acompanhar é ficar para trás |
Usar ambas as tabelas em conjunto conduz a arquiteturas de segurança que:
- Assuma compromissos, foque-se na redução do risco e na limitação de danos, em vez de prometer prevenção absoluta.
- Foca-te na identidade, no privilégio e no movimento lateral, não apenas na defesa do perímetro.
- Assuma mudança e evolução contínuas, e não diagramas estáticos.
- Equilibre a produtividade empresarial com a redução do risco. Alinhe os controlos de segurança ao valor do negócio.
- Integre pessoas, processos e tecnologia.
- Reduzir o ROI dos atacantes em vez de perseguir uma segurança perfeita.
- Aplicar os princípios do Confiança Zero de ponta a ponta.
Passos seguintes
Certifica-te de rever as outras disciplinas de segurança.