Segurança de Aplicação

Afinal, o que é Arquitetura de Segurança?

De forma geral o termo Arquitetura de Segurança possui significados diferentes e tudo vai depender do contexto em que o termo está colocado.

A questão com a definição do termo é tão relevante para o entendimento que o Gartner reservou um artigo inteiro para descrever a sua visão de Arquitetura Segura. E para o Gartner, o termo significa:

“In Gartner’s experience, practitioners use the term “security architecture” to refer to the security elements in a range of different (often unspoken) domains. These may be enterprise architecture, technical design, organizational structure, policy framework, process catalog, or some other intended focus area.”

Que em tradução livre, seria:

“Na visão do Gartner, quem usa o termo arquitetura de segurança se refere a elementos de segurança de diversos domínios. Estes podem ser arquitetura empresarial, desenho técnico, estrutura organizacional, modelos de políticas, catálogo de processos ou outras áreas de foco.”

A partir desse entendimento, o Gartner menciona também que um dos mais conhecidos conceitos para o termo é quando o usamos para descrever a Arquitetura Empresarial.

Além da definição do Gartner, podemos achar definições nos mais diversos modelos e metodologias como o NIST 800-39 ou mesmo no NIST 800-53 Rev4 — todos mostrando o conceito dentro de seus contextos. 

Nem só de código vive AppSec

Quando imaginamos AppSec ou Application Security, uma das primeiras ideias que vem à mente é a preocupação exclusiva em manter e melhorar a segurança do código.

Isso não deixa de ser importante, mas por trás de uma aplicação segura existe uma infinidade de controles, processos, camadas e estruturas que devem trabalhar juntas para que o resultado final seja a aplicação segura.

Sendo assim, é importante que a equipe que desenha a estrutura do aplicativo busque formas de garantir a segurança desse software.

Para isso, uma boa estratégia pode ser a realização de uma modelagem de ameaças: inclusive esse assunto já foi tema de outros artigos em que abordamos os 3 benefícios da modelagem de ameaças. Abordamos a modelagem de ameaças de um ponto de vista mais amplo neste artigo também. Se você está pensando sobre o assunto, vale a pena conferir.

A seguir, vamos apontar aspectos a serem observados quando se está começando a planejar ou melhorar sua aplicação e sua estrutura.

Arquitetura de segurança básica de uma aplicação web

De uma forma bem rudimentar, podemos começar a falar sobre arquiteturas de segurança entendendo os modelos mais básicos, que mesmo sendo pouco usados nos dias de hoje ainda possuem um valor educacional.

Assim, quando falamos de uma estrutura de segurança básica, como temos demonstrado na figura abaixo (Figura 1), podemos ver que tanto a estrutura da aplicação quanto o seu banco de dados estão compartilhando uma mesma máquina.

Isso, além de ser um problema de continuidade do serviço — pois temos um ponto único de falha —, é também uma fragilidade na arquitetura, já que se houver o comprometimento da aplicação, o banco de dados acabará sendo prejudicado por conseguinte.

Não é incomum que neste tipo de estrutura o usuário responsável por executar as aplicações seja o mesmo, e muitas vezes o usuário com mais privilégio, que pode ser o root para sistemas *NIX ou mesmo o Administrador para sistemas Windows.

Isso introduz uma falha de segurança séria, pois ao acontecer o comprometimento do usuário, todos os sistemas por ele executados estarão comprometidos.

Como falamos, essa é uma estrutura muito mais rara de se ver em empresas que levam realmente a sério o conceito de segurança de suas aplicações, mas ainda pode ser encontrada em empresas menores e com menos recursos. O comprometimento de uma máquina pode comprometer todo um  serviço.

Múltiplos pontos únicos de falha

Bem, vamos agora para um cenário em que essa estrutura evoluiu e mudamos para uma estrutura semelhante a que temos nesta imagem abaixo (Figura2).

Mesmo que agora tenhamos uma melhor distribuição dos serviços que entregam a aplicação, ainda podemos notar que existem múltiplos pontos únicos de falha: em cada uma das máquinas há um serviço, mas apenas uma máquina para garantir este serviço.

De modo geral podemos relacionar como desvantagens destes modelos — tanto do Single-Tier (Figura1) quanto do Two-Tier (Figura2) — que em ambos existem pontos únicos de falha.

Além desta característica, podemos dizer que estes modelos também possuem falham relacionadas a atualização de qualquer componente da estrutura. Isso porque para realizar uma atualização, o sistema deverá ser paralisado durante o processo. Isso é uma coisa impensável nos dias de hoje para a grande maioria dos sistemas.

Existe ainda, como falamos, a possibilidade de um comprometimento de um componente do sistema, e isso acabaria afetando toda a estrutura e o sistema.

Como podemos ver, estas duas formas de montarmos nossa estrutura não são nada seguras e raramente são vistas ainda hoje, mas nos serviram para introduzir o conceito de ponto único de falhas, ou como vocẽ pode encontrar single point of failure.

Soluções baseadas em conceitos de Multi-Tier

Como você sabe, arquiteturas multi-tier são arquiteturas construídas com separação de componentes, e essa separação é muito utilizada como controle compensatório de segurança pois ajuda isolar sistemas e componentes de sistemas críticos.

Em arquiteturas multi-tier, como mostrado na imagem abaixo (figura3), os componentes e sistemas ficam distribuídos em máquinas ou conjuntos de máquinas separadas.

Esse modelo se torna ainda mais real se falarmos de virtualização ou mesmo do uso de container e microsserviços dentro da construção de sistemas.

Como você pode imaginar, o uso de estruturas deste tipo contribui muito para a construção de sistemas seguros, pois garante o isolamento e a rápida substituição de componentes afetados ou mesmo comprometidos.

O modelo Single-Tier

Uma das fragilidades existentes em modelos Single-Tier, a atualização, deixa de ser um problema pois podemos atualizar e modificar sistemas muito mais facilmente. 

Portanto, modelos de Multi-tier são mais eficientes para os modelos de segurança e sistemas de hoje, e por isso são os mais recomendados para a construção de aplicações que tenham o foco em segurança.

Pensar em segurança de software não é só pensar em melhorar seu código ou mesmo escrever um código mais seguro — tem muito mais coisa envolvida nisso.

Uma introdução à Arquitetura de Segurança

O termo arquitetura já está incorporado em muitos dos frameworks que conhecemos. Alguns exemplos podem ser encontrados nas normas da série ISO 27000, ou mesmo em outros como o NIST CSF ou mesmo o PCI-DSS.

No entanto, o que percebemos é que este termo ficou perdido dentro das empresas.

O entendimento que temos nos dias de hoje está atrelado aos planos de segurança de arquitetura organizacional, e tem suas origens em um modelo de pensamento criado na década de 80 por John Zachman. Este modelo ficou conhecido como Zachman Framework.

O modelo Zachman tem como foco apresentar uma forma de como podemos ver e estruturar a arquitetura organizacional em termos de tecnologia da informação.

Arquitetura de Segurança: construindo um framework

No entanto, caso queira uma visão mais estruturada e moldada para os tempos mais atuais, um bom artigo para leitura é o produzido pelo Gartner apresentando o Guia para ajudar na construção de um framework de Arquitetura de Segurança.

Considerando os pontos abordados acima, mesmo possuindo uma área de Arquitetura Empresarial ou Organizacional,  muitas empresas ainda deixam de lado a aplicação dos conceitos de Arquitetura de Segurança.

Isso acontece muitas vezes pela forma como estas duas áreas podem estar dispostas dentro da estrutura organizacional da empresa. Aqui, o termo arquitetura diz respeito ao modo como estão distribuídas dentro das funções empresariais.

Em algumas empresas a área de Arquitetura de Segurança está diretamente ligada à área de Estrutura Empresarial, mas nem sempre este é o caso.

Em outras ela está ligada à área de Segurança da Informação, e isso certamente afeta a forma como a expressão “arquitetura de segurança” será interpretada.

Caso queira saber mais sobre esse ponto, neste artigo do Gartner é possível encontrar conceitos mais apronfundados sobre essa estruturação.

Esse mesmo conflito muitas vezes é o mesmo que vemos entre a área de segurança e a área de desenvolvimento, o que tratamos em nosso artigo sobre o Security Champion.

Este é um conflito que deve ser resolvido com comunicação assertiva: é necessário uma mudança de postura para solucionar o problema com clareza.

Já vimos também que erros de comunicação podem trazer grandes problemas para a segurança da empresa neste artigo sobre comunicação em DevSecOps.

Portanto, uma solução que deve ser perseguida é sempre buscar transmitir uma a informação correta sobre o que vem a ser Arquitetura de Segurança, pois em muitos casos as pessoas entendem que não é nada mais do que a criação de mapas e diagramas de redes ou serviços.

Precisamos entender que Estrutura de Segurança é um processo, e como tal deve ser realizado por pessoas e sistemas que entendam sua importância.

Como podemos ver na imagem abaixo, o Gartner tem uma visão bem mais clara do que vem a ser Estrutura de Segurança, uma grande auxiliar para outras áreas e que pode facilitar a visão de pontos que contribuem para a construção de uma melhor solução.

Por tudo isso, é evidente a importância de um melhor entendimento. Fica aqui o convite ao aprofundamento deste tema dentro da sua realidade.

Qual a relação entre Estrutura Organizacional e Estrutura de Segurança?

Bom, é evidente que a dúvida surgiria. Afinal de contas de quem é o papel de pensar na estrutura de segurança? Um arquiteto corporativo, que pensa na estrutura baseada no negócio, ou em especialista em segurança?

Talvez a resposta possa vir de uma visão que achamos no artigo “Improve Your Security With Security Architecture” do Gartner.

“The main challenge of security architecture is about proposing architectures that can withstand the real threats and comply with policies while also serving the business and the rest of IT.”

Visão, esta, que podemos traduzir da seguinte forma:

“O principal desafio da arquitetura de segurança consiste em propor arquiteturas que possam suportar ameaças reais e cumprir políticas, além de servir os negócios e o restante da TI.”

Sendo assim, talvez trabalhar próximo à Arquitetura Corporativa seja uma boa ideia para dar início ao envolvimento da arquitetura de segurança nos projetos, e estes podem ou não ser desenvolvidos usando métodos ágeis.

De fato, podemos dizer que as práticas desenvolvidas pela área de Arquitetura de Segurança são alinhadas de forma mais fácil quando trabalham próximo à área de Arquitetura Corporativa, e isso pode ser visto principalmente se sua empresa usa um modelo como o SABSA.

Arquitetura de Segurança e o trabalho em conjunto

Para reforçar este conceito, podemos apontar uma pesquisa do Gartner onde se constatou ser mais efetiva a participação da área de Arquitetura Corporativa juntamente com a área de Segurança de TI, tudo sobre a mesma liderança.

Então, antes de tomar a decisão sobre como estruturar essa área ou como reposicioná-la dentro de sua organização, sempre será recomendada a análise e o entendimento de como melhor se relacionam as estruturas da sua empresa.

Quando essas duas área trabalham juntas, podemos dizer que a Arquitetura de Segurança será uma grande fornecedora de padrões e informações para muitas outras áreas da empresa — principalmente para a gestão de risco ou mesmo para as lideranças, que passam a receber informações mais claras e detalhadas.

Como podemos ver na imagem abaixo, a sinergia entre as áreas pode ser bem maior que imaginávamos anteriormente.

Por que pensar Arquitetura de Segurança?

Quando uma empresa busca elaborar uma estratégia visando construir um plano de Arquitetura de segurança, o resultado final pode ser um conjunto de benefícios que nem sempre são observados em primeiro momento.

A criação de uma Estrutura de Segurança permite a empresa encontrar melhores controles de segurança e visualizar onde melhor se encaixam dentro do seu plano de segurança. Ajuda também na criação de um modelo de referência que pode contribuir com diferentes áreas.

Os profissionais de segurança e gerenciamento de riscos, responsáveis ​​pela implantação da segurança nas soluções corporativas, devem demonstrar que sua abordagem atende às necessidades coletivas da organização.

As metodologias de arquitetura de segurança são complexas para se executar, e mais complexas ainda para demonstrar seu valor.

Portanto, a implementação de modelos previamente criados para serem mais genéricos precisam de adaptação e adequação para que sejam consideradas relevantes para os negócios.

Para ajudar com este problema, o Gartner mais uma vez vem nos ajudar com seu artigo apresentando este rico material com um Guia de como aplicar modelos de arquitetura de segurança: recomendamos fortemente esta leitura.

Principais benefícios da Arquitetura de Segurança

De forma geral podemos enumerar os seguintes benefícios:

  • Melhora da postura de segurança da empresa, mostrando que os problemas de segurança foram tratados de forma adequada
  • Auditabilidade dos processos e controles
  • Ponte entre os requisitos de compliance e de risco, sendo estes ajustados às necessidades do negócio
  • Havendo necessidade de demonstrar compliance com normas e políticas internas, estas estão melhor organizadas e planejadas
  • Facilita a visualização do estado atual de risco e compliance do negócio e a criação de um roadmap para etapas futuras

Então, construir a sua arquitetura de segurança garante que você busque sistematicamente atuar nas questões de segurança para o — dentre eles os riscos voltados para a construção da arquitetura que dará suporte à aplicação ou mesmo da construção do código.

Além destas preocupações, todos os requisitos relacionados com políticas, normas e regulamentações foram estudadas e resolvidas dentro do seu planejamento.

Isso proporciona ainda que as medidas e controles de segurança sejam comunicados da melhor forma possível a todos os envolvidos.

Afinal, as medidas e controles foram criadas tendo como base as necessidades do negócio, e não simplesmente a atuação para conformidade com alguma regulamentação.

Por fim, a metodologia de arquitetura de segurança e as orientações colocadas aqui podem ajudar na estruturação de arquitetura de segurança em si.

Ao fornecer mecanismos para passar de atividades descoordenadas para uma abordagem estruturada e altamente lógica, a implementação deste modelo permite a empresa suportar toda a segurança, já que proporciona o alinhamento entre a política de segurança interna aos padrões externos sempre que necessário.

New call-to-action
About author

Articles

Mais de 15 anos de experiência em segurança da informação e aplicações, graduado em processamento de dados, trabalhei como professor universitário e participei ativamente como instrutor de treinamento para mais de 6000 desenvolvedores em equipes de TI. Sou pai de duas meninas e trader nas horas vagas.
Related posts
Segurança de AplicaçãoTech

Conheça as diferenças entre segurança de aplicativos web e mobile

Com o mercado de desenvolvimento de aplicativos para aparelhos móveis (os famosos “mobile…
Read more
Segurança de Aplicação

O seu container é realmente seguro?

Nestes últimos anos, o uso de containers para empacotar e entregar aplicações tem se tornado cada…
Read more
OWASP SAMMSegurança de AplicaçãoTech

Como se comparam os modelos SAMM e BSIMM

A OWASP é uma das melhores fontes de conhecimento para todos os profissionais que desejam trabalhar…
Read more

Deixe um comentário