Arquitetura de segurança: princípios básicos

Os princípios da arquitetura de segurança podem ser entendidos como as diretrizes ou os fundamentos gerais a serem seguidos para garantir a segurança de sistemas e redes, e podem ser considerados práticas recomendadas e diretrizes amplamente aceitas atualmente.

Estabelecer e seguir esses princípios nos ajuda a proteger os ativos digitais, evitar ataques cibernéticos e manter a integridade, a confidencialidade e a disponibilidade das informações. Eles formam uma base sobre a qual construir estratégias de segurança adequadas e, ao aderir a eles, as organizações fortalecem sua postura de segurança e reduzem os riscos.

Nada disso poderia acontecer sem a figura principal encarregada de planejar e projetar a segurança em tais contextos: o arquiteto de segurança.

Princípios de arquitetura segura

Defesa em profundidade

O primeiro dos princípios que mencionaremos nesta postagem. Ele consiste em criar uma espécie de "pista de obstáculos", para dificultar o trabalho do adversário. Se imaginarmos um modelo de segurança antigo, como o castelo (um exemplo clássico), veremos que ele foi projetado com paredes grossas e altas para manter os "mocinhos" dentro e os "bandidos" fora.

Funcionou muito bem até percebermos que os "mocinhos" às vezes precisavam sair, então tivemos que adicionar um portão a essa estrutura, o que paradoxalmente se tornou uma vulnerabilidade. Para reforçá-la, acrescentamos medidas adicionais, como a escavação de um fosso ao redor da estrutura para dificultar ainda mais a invasão e a instalação de uma ponte levadiça sobre o fosso, aumentando ainda mais a dificuldade. E, como se isso não bastasse, tínhamos até cães para proporcionar segurança adicional. Nesse modelo, não há dependência de um único mecanismo de segurança para manter o sistema seguro. Para aplicar esse princípio a um exemplo moderno de segurança, temos um usuário em uma estação de trabalho cujo fluxo de dados atravessará uma rede para um servidor da Web, depois para um servidor de aplicativos e, finalmente, para um banco de dados.

Para implementar a defesa em profundidade nesse cenário, poderíamos incorporar a autenticação multifator (MFA) e adicionar ao próprio dispositivo (vamos supor que seja um laptop ou smartphone) um software de gerenciamento de dispositivos móveis (MDM) que garanta a aplicação da política de segurança no dispositivo, incluindo patches, senhas e outras medidas. Também poderíamos acrescentar o EDR (Endpoint Detection and Response), um tipo de solução de última geração que oferece recursos de detecção e resposta para proteger a plataforma contra vários tipos de ameaças, inclusive malwares. Do ponto de vista da rede, podemos incluir um firewall para proteger o servidor Web contra ameaças externas e permitir seletivamente o retorno do tráfego para essas áreas mais sensíveis. Além disso, podemos realizar varreduras de vulnerabilidade em servidores da Web e de aplicativos para garantir que eles não sejam suscetíveis a ataques. Por fim, quando os dados são necessários, aplicamos criptografia a eles, implementando controles de acesso para protegê-los.

Dessa forma, criamos um sistema que depende de vários mecanismos de segurança, de modo que, se um deles falhar, o restante do sistema continuará funcionando e não teremos um único ponto de falha.

Princípio do menor privilégio

O segundo princípio que exploraremos é o princípio do menor privilégio. Essencialmente, ele afirma que os direitos de acesso devem ser concedidos somente às pessoas que precisam deles, estão autorizadas, podem justificar seu acesso, e, somente pelo tempo necessário. Por exemplo, se considerarmos três usuários, em que o primeiro não tem nenhuma necessidade funcional e, portanto, não concedemos acesso, e os outros dois usuários demonstram uma necessidade legítima e fornecemos a eles o acesso adequado: mesmo para esses, não concedemos acesso indefinidamente, mas reavaliamos periodicamente se o acesso ainda é justificado e, se não for, o revogamos.

Outro aspecto desse princípio é o endurecimento do sistema, mais conhecido como hardening. Se tivermos um servidor da Web que executa HTTP por padrão, o que é necessário para o tráfego da Web, e tem serviços de FTP e SSH ativados para conectividade remota, devemos nos perguntar se realmente precisamos desses serviços adicionais. Caso contrário, devemos removê-los. Cada serviço que removemos reduz nossa superfície de ataque.

Além disso, devemos remover IDs padrão desnecessários e alterar as credenciais padrão dos IDs que mantemos. Por exemplo, se a ID de administrador foi inicialmente definida como "admin", devemos substituí-la por uma desconhecida.

Também é fundamental alterar as senhas padrão, pois não queremos que nosso sistema tenha uma configuração básica (vanilla) porque os agentes mal-intencionados podem identificá-la e explorá-la com mais facilidade. Além disso, um processo de recertificação anual (ou até mais frequente) ajuda a lidar com a acumulação de privilégios. Durante a recertificação, analisamos todos os direitos de acesso do usuário para garantir que eles ainda sejam justificados.

Ao aderir ao princípio do menor privilégio, concedemos acesso acesso apenas ao que é necessário e somente pelo tempo exigido, fortalecemos os sistemas, eliminamos o acúmulo e abandonamos a lógica do "just in case".

Separação de funções

O terceiro princípio de segurança a ser considerado é o conceito de separação de tarefas, que garante que não haja um ponto de controle centralizado. Em vez disso, é criado um cenário no qual vários agentes mal-intencionados teriam que concordar em comprometer o sistema. Um exemplo do mundo físico poderia ser o caso de duas pessoas e uma porta com duas fechaduras; uma tem a chave da primeira fechadura, enquanto a outra tem a chave da segunda fechadura. Separadamente, elas não conseguem abrir a porta, mas se trabalharem juntas, conseguem. Nesse cenário, não há um único ponto de controle, o que proporciona a separação de funções.

Na tecnologia, podemos aplicar isso aos processos de aprovação de acesso. Por exemplo, um usuário envia uma solicitação de acesso a um banco de dados, e um aprovador a analisa e decide se a concede ou nega com base em uma necessidade comercial justificada. Ao garantir que o solicitante e o aprovador sejam pessoas diferentes, evitamos um único ponto de controle.
A separação de tarefas exige colaboração para comprometer o sistema, o que se torna um desafio quando muitas pessoas precisam trabalhar juntas e manter sigilo.

Segurança por design

O quarto princípio de segurança que discutiremos é a segurança por projeto, o que significa que a segurança não deve ser uma reflexão tardia. Da mesma forma que, ao projetar um edifício em uma zona sísmica que deve resistir a movimentos, você não o constrói primeiro e depois decide torná-lo à prova de terremotos, mas inclui esse requisito desde o início. Em projetos de tecnologia, geralmente começamos com a fase de requisitos, passamos para o design, depois para o código, instalamos o código escrito, testamos e, por fim, implantamos em produção

Idealmente, gostaríamos de alimentar esse ciclo continuamente, mantendo um processo de desenvolvimento contínuo, mas não queremos esperar pelas últimas fases para abordar a segurança depois que a solução estiver pronta. A segurança não pode ser um complemento no final, mas deve estar presente durante todo o processo. Portanto, devemos analisar os aspectos de segurança durante a fase de requisitos e integrar a segurança ao projeto, levando em conta os princípios do desenvolvimento seguro em cada etapa, garantindo uma instalação segura, protegendo os dados de teste e continuando com os testes em produção. Dessa forma, a segurança não é algo que fazemos no último minuto, mas algo que incorporamos de forma generalizada.

Keep it Simple, Stupid

O quinto princípio que exploraremos é conhecido como K.I.S.S. sigla em inglês para "Keep it Simple, Stupid" (Mantenha simples, estúpido). Em outras palavras, não devemos complicar as coisas mais do que o necessário, pois isso tornaria as coisas mais fáceis para os invasores e mais difíceis para os usuários legítimos. Quando projetamos medidas de segurança, geralmente adicionamos complexidade para impedir o acesso não autorizado, mas às vezes isso resulta em um labirinto complexo para os usuários navegarem, o que pode desestimular o uso pretendido ou incentivar a evasão das medidas, o que é um resultado que queremos evitar. Se tornarmos mais difícil fazer a coisa certa do que a coisa errada, as pessoas escolherão o caminho errado, portanto, precisamos tornar o sistema seguro, mas também o mais simples possível para os usuários legítimos.

Por exemplo, se estabelecermos regras de senha (como uma combinação de letras maiúsculas e minúsculas, números, caracteres especiais e um comprimento mínimo), também exigiremos que os usuários mantenham senhas diferentes para cada sistema e as alterem periodicamente. Mas o conjunto de regras cria o problema de que, quando os usuários encontram uma senha que atende aos critérios, eles a usam em vários sistemas e a anotam em algum lugar, reduzindo a segurança, que é exatamente o que queremos evitar. É por isso que dizemos que a complexidade é inimiga da segurança, e queremos que o sistema seja complexo o suficiente para deter os invasores, mas simples o suficiente para os usuários legítimos.

Deve-se observar também que, além dos princípios a serem considerados, há alguns que devem ser totalmente evitados. O mais importante é o da segurança por obscuridade, que se refere à dependência de conhecimento secreto para a segurança de um sistema. Em vez disso, o que queremos é um sistema aberto e observável. Essa ideia é conhecida como um dos princípios de Kerckhoff, que afirma que um sistema criptográfico deve permanecer seguro mesmo que todos os seus detalhes, exceto a chave, sejam conhecidos. Se a segurança for fornecida por uma caixa preta, não poderemos ver como ela funciona e, mesmo que o criador afirme que ela é inquebrável e a tenha testado, isso significa que ele não encontrou uma maneira de quebrá-la, mas isso não significa que ela não possa ser quebrada. Aplicamos a mesma abordagem para proteger redes, aplicativos e sistemas.

O papel do arquiteto

Para poder implementar o que foi mencionado acima, é necessário ter uma função com a responsabilidade e o conhecimento adequados para garantir sua realização. Essa é a tarefa do arquiteto de segurança cibernética e abrange não apenas os aspectos técnicos, mas também a consideração das necessidades e preocupações das partes interessadas. Tanto nos sistemas físicos quanto nos de TI, o arquiteto de segurança cibernética deve priorizar a segurança e a proteção ao projetar a arquitetura. Assim como um arquiteto que projeta um edifício incorpora medidas de segurança, como fechaduras fortes, câmeras de vigilância, detectores de fumaça e firewalls, o arquiteto de segurança cibernética deve implementar medidas para reduzir os riscos e melhorar a segurança geral.

Ao lidar com sistemas de TI, o arquiteto de segurança cibernética usa uma variedade de ferramentas, desde diagramas que fornecem contexto comercial e de sistemas até diagramas de arquitetura de alto nível para entender a relação entre os componentes e os possíveis pontos de falha. Esse entendimento holístico permite que as vulnerabilidades sejam identificadas e que medidas de segurança eficazes sejam projetadas. Para garantir a segurança em todas as fases de um projeto, os arquitetos de segurança cibernética se baseiam em uma série de conhecimentos, estruturas e modelos, e se baseiam nos princípios acima para estabelecer uma base sólida.

É fundamental envolver o arquiteto de segurança cibernética desde os primeiros estágios do projeto, em vez de tentar adicionar segurança após o fato, o que geralmente acaba se tornando algo forçado. Ao envolvê-los desde o início, as organizações podem abordar de forma proativa os possíveis desafios de segurança e integrar a segurança à arquitetura de forma mais perfeita. As áreas em que os arquitetos de segurança cibernética atuam são diversas e estão em constante evolução. Elas abrangem gerenciamento de identidade e acesso, segurança de endpoint, segurança de rede, segurança de aplicativos, proteção de dados, gerenciamento de eventos e informações de segurança e resposta a incidentes. Aproveitando sua experiência nessas áreas, eles podem criar arquiteturas de segurança que protegem as organizações contra ameaças conhecidas e emergentes..

Conclusões

Ao adotar esses princípios, evitando a segurança por obscuridade, podemos estabelecer uma arquitetura de segurança cibernética robusta. O papel de um arquiteto é fundamental para essa tarefa, pois facilita a criação de soluções adequadas. Ao levar em conta as necessidades de cada parte interessada, integrando medidas de segurança à arquitetura e baseando-se em princípios e estruturas estabelecidos, as organizações podem, de fato, operar com mais confiança. Fica claro, portanto, que o engajamento antecipado e o acompanhamento da evolução das questões de segurança cibernética é um componente essencial que ajuda as organizações a permanecerem realmente resistentes às ameaças.