Fenômenos com impacto mundial, como a pandemia de COVID-19, aceleraram a adoção de recursos e ferramentas digitais, bem como a frequência e a gravidade de incidentes. Legislações ainda imaturas estão entrando em vigor e a incerteza sobre o que é obrigatório ou simplesmente responsável é parte do cotidiano.
No passado, era comum que apenas empresas que trabalhassem com dados obviamente sensíveis se preocupassem com segurança. Hoje, essa distinção não é mais aplicável.
Há uma certa tendência de dar ênfase, na prática arquitetural, a padrões e estilos. Entretanto, essa abordagem nem sempre é a melhor. A definição de restrições e atributos de qualidade, observando os objetivos de negócio, é premissa para um trabalho bem-feito. Segurança é importante demais para ser um tema secundário.
Motivações para “pensar segurança”
Competência tecnológica é fundamento para o sucesso nos negócios. Cadeias produtivas estão cada vez mais integradas. No “chão de fábrica”, as máquinas físicas já têm “gêmeas digitais”. No varejo, as vendas são apoiadas por tecnologia e ocorrem em multicanalidade, com curadoria individual.
Fora das empresas, a tecnologia vem impactando, de maneira evidente, cada vez mais, o dia-a-dia das pessoas. Bens de consumo têm cada vez mais sensores, processadores e conexões com a internet. Produtos tecnológicos são canais por onde consumimos serviços, muitos deles essenciais.
Infelizmente, sistemas dificilmente serão seguros acidentalmente, ou seja, sem projeto apropriado. O acaso, quando se trata de segurança em sistemas, é desfavorável e não dá proteção aos distraídos.
Segurança é um processo!
Problemas de segurança têm origem na maldade, inocência, estupidez ou infortúnio humano. As medidas para tornar sistemas mais seguros incluem mecanismos para coibição de ações maliciosas, prevenção de uso inadequado ou descuidado e, finalmente, planos de contingência.
Segurança é um processo. (Bruce Schneier)
World Trade Center
Há dezenas de relatos de empresas que mantinham sistemas principais e suas redundâncias distribuídas nas duas torres do World Trade Center, tragicamente atacadas em 11 de setembro de 2001. Essa estratégia, aparentemente lógica em primeira análise, se mostrou catastroficamente equivocada.
Imprudência ou infortúnio?
Sistemas desenvolvidos e mantidos com processos que não dão ênfase para a segurança têm alta probabilidade de serem “vitimados” direta ou indiretamente.
Segurança bem implementada desencoraja e coíbe condutas maliciosas, previne enganos e protege contra infortúnios (afinal, acidentes acontecem). Por isso, diminui desperdícios de tempo e dinheiro, protegendo a privacidade das pessoas e a reputação das marcas.
Segurança é CIA
São atributos de qualidade associados com segurança a confidencialidade, integridade e disponibilidade (availability).
A confidencialidade tem relação com a garantia de que o acesso a leitura e modificação de informações será restrito a aqueles que possuem autorização.
A integridade, por sua vez, indica que apenas dados válidos são aceitos.
Finalmente, disponibilidade garante que dados permanecerão disponíveis quando necessários, frente a conduta maliciosa, inocência ou estúpida dos usuários.
Segurança é um “concern” arquitetural
Boas práticas de arquitetura de software visam contribuir para o atendimento dos objetivos de negócio, respeitando restrições, atingindo atributos de qualidade.
A segurança é, sob o ponto de vista da arquitetura de software, um atributo de qualidade. Como tal, precisa ser adequadamente descrito e priorizado de acordo com os possíveis impactos para o atendimento dos objetivos de negócio.
Segurança é como uma corrente, onde a força é determinada pelo elo mais fraco (Bruce Schneier)
Restrições como ativo arquitetural
Roy Fielding, em sua tese de douturado que formalizou REST, sinaliza a importância da definição de restrições como prática arquitetural. Afinal, REST é WWW com restrições.
O exercício maduro da arquitetura de software é caracterizado pela definição assertiva de restrições, antes de qualquer projeto propositivo, como forma prática de validar as soluções propostas.
Segurança é um atributo de qualidade “invisível”
Importante destacar que o Brasil, hoje, é segundo colocado mundial na relação de países com maior volume de ataques cibernéticos identificados. Logo, os riscos associados a operações tecnológicas em nosso país são inerentemente mais altos.
Segurança pode “conflitar” com a confiabilidade
As decisões arquiteturais relacionadas a segurança tratam de riscos diferentes daqueles relacionados a confiabilidade. Embora os temas aparentem similaridade, na prática, são bem distantes.
Riscos relacionados a confiabilidade são, por natureza, relativos a infortúnios, a ingenuidade ou incompetência humana, mas não à maldade. São riscos para a confiabilidade, por exemplo, falhas na atualização de componentes ou no hardware. Riscos de segurança, por outro lado, geralmente decorrem da existência de “adversários” atuando, de forma ativa ou passiva, para explorar vulnerabilidades.
Decisões de design relacionadas a confiabilidade devem assumir que alguma coisa pode “dar errado” em algum momento. Já as decisões relacionadas à segurança devem assumir que há, sempre, algo ou alguém tentando “fazer as coisas darem errado”.
A recuperação de incidentes relacionados a confiabilidade geralmente envolvem várias mais pessoas, com mais “pontos de vista”, atuando para identificar e mitigar causas raiz. Em contraste, incidentes relacionados com segurança geralmente têm poucos envolvidos e somente compartilham informações que realmente precisem ser compartilhadas.
Não raro, informações em logs que cooperam para resolução mais rápida de sistemas em produção também são valiosas para agentes mal-intencionados que, aliás, precisam de apenas “um caminho aberto”.
Segurança pode “convergir” com confiabilidade
Tanto segurança quanto confiabilidade são atributos de qualidade emergentes, ou seja, resultantes de decisões de design.
Em sistemas mais complexos, os maiores desafios, tanto para a confiabilidade como para segurança, decorrem da interação entre os componentes. Manter sistemas simples colabora para ambos atributos, indiretamente, colaborando para o MTTR.
MTTR ou MTBF?
Muitos times de engenharia priorizam aumentar o MTBF (tempo médio entre falhas) no lugar de reduzir o MTTR (tempo médio para se recuperar de falhas).
A escolha pelo MTBF acaba justificando deploys menos frequentes (ninguém quer mexer em um sistema que está funcionando), logo, pacotes de atualização maiores, o que causa mais dificuldade para detectar problemas, gerando mais rollbacks e aumentando o leadtime.
MTTR, por outro lado, é incentivo para pacotes de atualização menores, gerados por deploys mais frequentes, teoricamente com impactos menores, menos rollbacks, minimizando o leadtime.
MTTR ou MTBF? Depende muito das implicações para segurança.
Segurança implica combinação de software, infraestrutura e operações
Recomendações básicas para mitigação de riscos de segurança
Projetar sistemas seguros é tarefa difícil. Quanto maiores os riscos associados, também maiores são as demandas de envolver especialistas de maneira ativa em todo o ciclo de vida da solução. Entretanto, há algumas estratégias básicas que podem e devem ser observadas sempre nas atividades relacionadas à arquitetura, pelos arquitetos.
Reduzir “privilégios” ao mínimo possível
Seguindo a mesma linha de raciocínio, processos “rodando” sistemas devem “usuários próprios” com privilégios junto ao ambiente operacional reduzidos para o essencial. No caso de intermediação com sistemas externos, deve-se considerar a adoção de redes DMZ
DMZ
DMZ ou zona desmilitarizada, é uma sub-rede que contém e expõe serviços de uma organização para uma rede maior e não confiável, geralmente a Internet.
As regras de segurança relacionadas a redes DMZ são:
- A rede interna pode iniciar conexões a qualquer uma das outras redes, mas nenhuma das outras redes pode iniciar conexões nesta.
- A rede pública (internet) não pode iniciar conexões na rede interna, mas pode na DMZ.
- A DMZ não pode fazer conexões à rede interna, mas pode na rede pública.
Decompor sistemas em “contextos delimitados” (de segurança)
Componentes independentes devem ter acesso apenas a recursos sensíveis relacionados às responsabilidades que cumprem. Módulos fiscais (e seus usuários), por exemplo, não devem ter acesso aos recursos utilizados por módulos de venda e vice-versa.
Estabelecer relações de confiança (entre componentes)
Idealmente, a interação entre componentes deve ser planejada. Quanto maior o acoplamento aferente de um componente, maiores são riscos potenciais que deste componente para a segurança.
Sempre que possível, a restrição de acessos de fontes não planejadas deve ser garantida em infraestrutura, adotando certificados ou outros mecanismos de identificação.
Monitorar sistemas consistentemente
Todos os eventos sensíveis relacionados a segurança devem ser monitorados e logados em bases não violáveis.
Em cenários onde segurança for realmente prioridade, todas as alterações em “entidades” críticas devem ser armazenadas e gerenciadas em bases de dados append-only .
Adotar práticas defensivas em diversos níveis de “profundidade”
Componentes com criticidade para a segurança não devem “confiar” em verificações prévias, Por isso, implementam e avaliam solicitações de outros componentes seguindo alguma forma de controle de acesso.
Projetar segurança como se “ofensores” pudessem “ler o manual”
Não projete sistemas de segurança assumindo que seus “segredos” estão seguros. Eventualmente, dados e estratégias preservados de maneira ingênua se tornam públicos.
Não “reinventar a roda”
Quase nunca é boa idéia criar tecnologia de segurança dentro de casa. Não implemente seu mecanismo de criptografia, mecanismos de identidade, tecnologia de persistência inviolável, etc. Tenha humildade!
Tecnologias e protocolos consagrados eventualmente são difíceis de aprender e adotar, mas esta característica não é indevida. Não cometa o erro de querer simplificar as coisas “reinventando a roda”.
Riscos mais frequentes para segurança (segundo OWASP)
Open Web Application Security Project (OWASP) é uma fundação sem fins lucrativos, iniciada em 2001, que objetiva melhorar a qualidade da segurança em sistemas de software. Trata-se de uma comunidade aberta dedicada a capacitar organizações na concepção, desenvolvimento, aquisição, operação e manutenção de aplicações confiáveis. Sem dúvidas, é ativo de conhecimento para qualquer arquiteto.
Há anos, a organização mantém um guia com as 10 falhas de segurança mais comuns. Atualmente, são elas:
- (SQL|NoSQL|OS|LDAP|*)-Injection
- Autenticação mal-implementada
- Exposição não-planejada de dados sensíveis
- XXE (XML External Entities)
- Controle de acesso mal-implementado
- Configuração ineficaz de segurança
- Cross-site scripting (XSS)
- Desserialização insegura
- Uso de componentes com vulnerabilidades conhecidas
- Logging e Monitoramento insuficientes
Um padrão para verificação de sistemas seguros
O objetivo principal do ASVS é normalizar a abrangência e o nível de rigor disponível no mercado quando se trata de realizar a verificação de segurança de aplicativos da Web usando um padrão aberto comercialmente funcional. O padrão fornece uma base para testar os controles técnicos de segurança do aplicativo, bem como quaisquer controles técnicos de segurança no ambiente, que são usados para proteger contra vulnerabilidades, como Cross-Site Scripting (XSS) e injeção de SQL. (OWASP)
SAMM – Um modelo de maturidade para garantia de segurança em software
Eventualmente, mais do que desenvolver aplicações seguras, é desejável desenvolver empresas que desenvolvem aplicações seguras. Para este fim, existe o SAMM.
OWASP SAMM (Software Assurance Maturity Model) é a estrutura OWASP para ajudar as organizações a avaliar, formular e implementar uma estratégia para segurança de software, que pode ser integrada ao seu ciclo de vida de desenvolvimento de software (SDLC) existente. O OWASP SAMM é adequado para a maioria dos contextos, se sua organização está principalmente desenvolvendo, terceirizando ou adquirindo software, ou se você está usando um método em cascata, um método ágil ou DevOps, o mesmo modelo pode ser aplicado. (OWASP)
// TODO
Antes de avançar para o próximo capítulo, recomendo as seguintes reflexões:
- Segurança está relacionada entre os atributos de qualidade do sistema que está desenvolvendo? Com que prioridade?
- Que restrições foram desenvolvidas a partir de segurança?
- Você conhecia OWASP?
Parabéns pelo capitulo Elemar, bem esclarecedor.
Mas gostaria de ver sua visão com relação ao modelos “STRIDE” de identificação de vulnerabilidade e (caso se enquadre) como podemos usa-lo para ajudar a pensar uma nova arquitetura, sem ultrapassar as competências de um arquiteto.
Li um material nos docs da MS
https://www.microsoft.com/security/blog/2007/09/11/stride-chart/
https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats