Arquitetura Segura de Software

Prévia do material em texto

Arquitetura Segura de Software 
Introdução 
Quando tentamos solucionar um problema, é possível identificar diversas 
soluções que poderiam ser utilizadas visando resolvê-lo. Contudo, outros 
fatores como custo e eficiência influenciam na escolha da solução a ser 
adotada. No contexto do desenvolvimento de software, o mesmo pode ser 
observado ao se analisar os requisitos visando à construção de um software: 
várias soluções computacionais podem ser definidas para atender a esses 
requisitos, mas uma análise deve ser feita para definir a mais adequada ao 
contexto de desenvolvimento da aplicação. 
Para se representar essas soluções, a arquitetura de software é uma das 
abordagens que podem ser usadas. Com isso, para se obter a arquitetura 
(solução) mais adequada para atender aos requisitos do software (problema), 
uma avaliação dessa estrutura deve ser realizada. A arquitetura, portanto, 
consiste em um modelo de alto nível que possibilita um entendimento e uma 
análise mais fácil do software a ser desenvolvido. 
O uso de arquitetura para representar soluções de software foi incentivado 
principalmente por duas tendências: 
 o reconhecimento por parte dos projetistas de que o uso de abstrações 
facilita a visualização e o entendimento de certas propriedades do 
software; 
 a exploração cada vez maior de frameworks visando diminuir o esforço 
de construção de produtos através da integração de partes previamente 
desenvolvidas. 
Uma outra propriedade da arquitetura é a possibilidade de usá-la como 
ferramenta para comunicar a solução projetada às diversas partes interessadas 
que participam do processo de desenvolvimento do software. Contudo, para 
que essa comunicação seja possível, a arquitetura deve ser representada 
através de um documento conhecido como documento arquitetural. 
Para se construir a arquitetura de um software, e por consequência o 
documento arquitetural que a representa, os requisitos são as principais 
informações usadas. Durante o processo de especificação arquitetural, além 
dos requisitos, outras fontes de conhecimento podem ser utilizadas para definir 
os elementos arquiteturais e a forma como eles devem estar organizados. 
Entre essas fontes de conhecimento se destacam principalmente a experiência 
do arquiteto, o raciocínio sobre os requisitos e os estilos e princípios 
arquiteturais. 
Dentre os objetivos e desafios da fase de elaboração da arquitetura de 
software estão: 
 Garantir o alinhamento técnico do projeto às diretrizes e estratégias 
tecnológicas da organização, bem como à sua cultura; 
 Atender as restrições gerenciais de um projeto tais como custo, prazo e 
competências técnicas da equipe; 
 Identificar e detalhar requisitos significativos para a arquitetura de 
software; 
 Antecipar e mitigar os riscos técnicos de um projeto; 
 Construir provas de conceito e gerar código executável para os 
principais pontos de risco do projeto; 
 Orientar e acompanhar o time técnico para garantir a aderência do 
código construído às diretrizes arquiteturais do projeto; 
 Validar a estabilidade e objetivos da arquitetura do produto; 
 Coletar lições aprendidas e promover um novo ciclo de melhorias; 
 Manter a rastreabilidade entre os resquisitos, as definições 
arquiteturais e o código construído. 
Vale a pena destacar o último objetivo pois consiste em garantir a 
rastreabilidade entre o que foi especificado pelo Analista de Requisitos, o que 
está sendo projetado pelo Arquiteto e ainda pelo que será codificado pelo 
desenvolvedor. 
 
Esta rastreabilidade facilita uma análise dos controles de segurança que serão 
adotados no software. Por meio dela é possível saber que determinada função 
implementada no software está aderente ao padrão arquitetural adotado e que 
este padrão atende aos requisitos de segurança. 
O objetivo do ciclo de desenvolvimento seguro de software é garantir que o 
produto final de software tenha o nível de segurança adequado, levando em 
consideração o ambiente em que será executado. Para isso, é muito 
importante executar atividades de segurança durante a definição da 
arquitetura. 
As atividades de segurança conduzidas na fase de Requisitos produziram a 
categorização de segurança do sistema, os requisitos especificados (inclusive 
os de segurança) e os diagramas de caso de abuso. Na fase de Análise e 
Projeto, temos que definir orientações técnicas para auxiliar o Arquiteto de 
Segurança. Dois guias são fundamentais: 
 Definição dos frameworks de segurança recomendados; e 
 Uma lista de princípios de arquitetura segura. 
A definição de uma arquitetura segura inicia-se pela Análise da Superfície de 
Ataque, onde o Arquiteto de segurança verifica os pontos de entrada que 
podem ser utilizados para fins maliciosos no software. Depois disso, deve ser 
feita uma Modelagem de Ameaças para entender a que ameaças o sistema 
está exposto e quais são os riscos dessas ameaças. Por fim a Arquitetura 
Segura do software é definida com todos os controles de segurança que 
deverão ser implementados. 
1 Frameworks de segurança 
" Framework é um conjunto de classes que colaboram para realizar uma 
responsabilidade para um domínio de um subsistema da aplicação" 1 . 
Um framework define parâmetros de projeto, a forma como é realizada a 
divisão em classes e objetos e suas responsabilidades, a maneira como 
colaboram entre si e o fluxo de controle, ditando, assim, a arquitetura de 
software das aplicações que os utilizam. Além disso, fornece padrões de 
projetos - estruturas essenciais para o desenvolvimento de projetos de 
aplicações de software - uma espinha dorsal e o continente para os 
componentes criados nas aplicações e que irão funcionar dentro delas. 
Os principais objetivos dos frameworks e das metodologias de 
desenvolvimento baseadas em componentes são a reutilização de softwares, a 
padronização de desenvolvimento, a difusão do entendimento comum entre 
equipes de desenvolvimento, entre outros. 
Os frameworks permitem que as aplicações sejam desenvolvidas mais 
rapidamente e mais facilmente, além de contribuir para a qualidade do produto 
final. Por meio dos frameworks os desenvolvedores contam com estruturas 
bem definidas, revisadas por outras pessoas e melhoradas constantemente. 
Portanto, os desenvolvedores podem se beneficiar com o uso dos frameworks 
quando escolhem utilizá-los para resolver alguma função de codificação em 
vez de criar do zero. 
Do ponto de vista da segurança do software, os frameworks podem ajudar o 
desenvolvedor no sentido de fornecer funções de segurança, como: 
 autenticação/autorização; 
 validação/codificação de dados; 
 tratamento de erros; 
 logs; 
 detecção de intrusão; 
 criptografia. 
Existem algumas bibliotecas livres que exercem este papel muito bem. Para o 
desenvolvimento em plataforma .NET, a biblioteca de proteção web da 
Microsoft (Web Protection Library) fornece funções para proteger a aplicação 
de ataques Cross Site Scripting (XSS) e SQL Injection. Os ataques serão 
explicados nos módulos mais adiante. 
A biblioteca de segurança mais atual e completa hoje é a ESAPI (Enterprise 
Security API), mantida pela comunidade OWASP (explicada no Módulo 1). A 
ESAPI é complexa e exige um bom esforço para dominá-la, mas existem 
muitas pessoas contribuindo para a melhoria da documentação da ESAPI de 
forma a facilitar sua adoção.No SERPRO recomendamos o uso desta 
biblioteca e dedicaremos uma parte do nosso curso para explicá-la com mais 
detalhes. Uma boa referência para implementação da ESAPI está disponível no 
portal da COGSI . 
Outro framework de segurança é o Apache Shiro, voltado para aplicações 
JAVA. Apesar de ser mais simplesde usar e entender do que a ESAPI, ele 
cobre parte das funções de segurança (autenticação, autorização, 
gerenciamento de sessões e criptografia) e deixa de fora funções muito 
importantes, como a validação e codificação de entradas/saídas. 
Além da ESAPI, que é a biblioteca recomendada e mais abrangente, existem 
outros frameworks para atender controles de segurança específicos, conforme 
mostra a tabela 3.1. 
Tabela 3.1 
Nome Descrição Desenvolvedor 
Spring Security Segurança para Spring Acegi Security 
System 
AntiSamy Sanitização de rich HTML OWASP 
CSRFGuard Proteção de Cross Site Request Forgery 
(CSRF) 
OWASP 
Java Simplified Encryption 
Libray 
Para criptografia Jasypt 
Bibliotecas da Bouncy Castle Para criptografia Java e C# Bouncy Castle 
JSReg Expressões regulares Google 
Java HTML Sanitizer JAVA Google 
Javascript Sandboxing Para Javacript Google 
XHP Para PHP Facebook 
Django Security Para Python com Django SD Elements 
Podemos ver que a lista de frameworks é bem extensa. É importante que os 
Arquitetos de Segurança contribuam na especificação dos componentes 
recomendados para a empresa, inclusive sugerindo melhorias corporativas 
desses frameworks. Outra tarefa essencial é disponibilizar ao desenvolvedor 
toda documentação e orientação de uso dos frameworks de segurança. 
 2 Princípios de arquitetura segura 
Durante a elaboração da arquitetura do software temos que balancear os 
objetivos como o custo, a performance, a manutenibilidade , a segurança, etc. 
É provável que um sistema completamente seguro apresente baixa 
performance. O objetivo é projetar um sistema que seja seguro enquanto tenha 
uma boa performance e confiança. Os hackers tecnicamente competentes 
geralmente encontram um modo de burlar o sistema, tendo em vista o tempo e 
os recursos empregados que costumam ser suficientes para atingir seus 
propósitos. 
A proteção da informação armazenada em um sistema deve ser projetada 
durante a fase de arquitetura do sistema. É importante que os princípios de 
segurança sejam observados. 
 Privilégios mínimos: qualquer entidade (usuário, processo, etc.) deve 
receber os privilégios mínimos e os recursos durante o menor tempo 
possível para cumprir uma tarefa. Esta abordagem evita que uma 
entidade receba permissões que elas não precisam ter, reduzindo a 
oportunidade de acesso não autorizado às informações sigilosas. 
 Defesa em profundidade: consiste na aplicação de múltiplas camadas 
de proteção para que uma camada bloqueie um ataque se a camada 
anterior foi transposta. 
 Separação de responsabilidades: este princípio orienta que devem ser 
atendidas múltiplas condições para completar uma determinada tarefa 
sensível ou acessar uma informação sigilosa. Por exemplo, determinada 
transação será aceita somente com a assinatura de mais de um 
indivíduo. 
 Arquitetura aberta: há uma discussão no mérito e nível de segurança 
de projetos que são mantidos em segredo contra os que são abertos 
para a comunidade avaliar e contribuir. Um bom exemplo é a 
criptografia. Alguns defendem que os algoritmos mantidos em segredo 
são mais difíceis de quebrar que um algoritmo público. Outros 
defendem que a força de um algoritmo de criptografia reside somente 
na chave. Para a maioria dos casos, um projeto aberto que foi avaliado 
e testado por muitos experts, provavelmente deve possuir uma 
segurança maior do que aqueles que não foram largamente acessados e 
testados. A segurança desses sistemas não deve se concentrar apenas 
na forma como trabalham (algoritmo), mas deve-se garantir o sigilo e 
manutenção 1 das chaves. 
 Falha segura: este princípio significa que caso ocorra uma falha no 
sistema ele deve retornar a um estado onde a segurança não seja 
comprometida. Uma implementação desta ideia seria fazer com que o 
sistema passe para um estado padrão onde os usuários e processos não 
podem acessar o sistema. Uma regra complementar é assegurar que o 
sistema seja recuperado para um estado seguro. Nos casos onde a 
recuperação é feita manualmente, o sistema em falha deve restringir o 
acesso somente ao administrador e deixar que os usuários acessem 
somente depois de restabelecer os controles de segurança. 
 Economia de mecanismos: defende que o projeto ou a implementação 
dos controles de segurança seja simples e compreensível. Isto evita que 
o sistema apresente corvert channels 2 . 
 Carga de trabalho : o custo de um controle de segurança necessário 
para diminuir um risco deve ser comparado com o custo da perda da 
informação resultante de um ataque que explora 
a vulnerabilidade associada à este risco. 
 Elo mais fraco: como no ditado que diz "uma corrente é tão forte 
quanto o seu elo mais fraco", a segurança da informação é tão boa 
quanto o seu componente mais frágil. Portanto, é importante 
identificar o mecanismo mais fraco em uma arquitetura e fortalecê-lo 
para que os riscos ao sistema sejam mitigados até o nível aceitável. 
 Evitar segurança por obscuridade : este princípio é a generalização do 
princípio de arquitetura aberta. Ele defende que a segurança não deve 
ser obtida pelo desconhecimento de como o sistema funciona, mas sim 
por um controle de segurança bem implementado (um 
desafio/resposta, certificado digital, etc.) 
 Isolamento de entidades não confiáveis: consiste em isolar as 
entidades ou os processos não confiáveis para que o comportamento 
deles não afete o funcionamento esperado do sistema ou consiga acesso 
a áreas restritas. Este princípio pode ser obtido por meio de 
sandboxing, máquinas virtuais, módulos de processamento confiáveis e 
configurações do controle de acesso. 
A tabela 3.2 agrupa os princípios de segurança em 3 objetivos gerais: 
Tabela 3.2 
1. Minimizar o número de 
alvos de alta consequência 
2. Não expor componentes 
vulneráveis 
3. Negar ataques que venham a 
comprometer o sistema 
privilégios mínimos manter arquivos de configuração 
do sistemaseparados da aplicação 
simplificar o design 
separação de trabalhos isolamento de entidades não 
confiáveis 
manter todos os autores 
responsabilizados 
 minimizar o número de pontos de 
entradas/saída 
evitar problemas de temporização, 
sincronização e sequenciamento 
 assumir que os dados do ambiente 
não são confiáveis 
falha segura 
 usar somente interfaces seguras 
para os recursos do ambiente 
funções do servidor nunca devem 
confiar em dados originados pelo 
cliente 
3 Análise da superfície de ataque 
Os pontos de entrada e saída de uma aplicação que são acessíveis aos 
usuários e atacantes são referenciados como a superfície de ataque da 
aplicação. O objetivo é analisar e reduzir a superfície de ataques de uma 
aplicação. Os pontos de entrada são as interfaces, serviços, protocolos, 
códigos, etc. Os pontos de saída consistem nas mensagens produzidas pela 
aplicação, relatório, respostas a uma interação, etc. Esses pontos de 
entrada/saída devem estar acessíveis somente aos usuários que possuam o 
nível adequado de confiança. 
Michael Howard mostra em seu artigo "Fending Off Future Attacks by Reducing 
Attack Surface" que é possível calcular a "atacabilidade", a probabilidade de 
um sistema ser atacado ou a exposição da aplicação a ataques, mas não 
necessariamente a vulnerabilidade. Esta é uma ideia muito importante a 
respeito da superfície de ataque. Uma aplicação com superfície de ataque 
muito grande implica em sua exposição ser alta e, consequentemente, um 
aumento em sua probabilidade de ser atacada. Porém, isso não quer dizer que 
a aplicação necessariamente esteja vulnerável a esses ataques. 
Para analisar a superfície de ataque de uma aplicação é necessário identificar 
as funcionalidades ou os pontos de entrada e saída que são passíveisde 
serem atacados. Esses pontos podem ser chamados de vetores de ataques. 
Em uma arquitetura é importante identificarmos todos esses vetores para que 
sejam aplicados controles de segurança quando necessário. 
Para cada projeto de software é necessário criar uma visão simplificada da 
arquitetura geral. Esta visão deve ter como base os artefatos do projeto já 
produzidos (especificação de requisitos, modelos de análise, etc). É importante 
cobrir todos os módulos do sistema, mas a granularidade da visão geral da 
arquitetura deve ser decidida de acordo com o tamanho e complexidade do 
sistema. O desafio é obter uma visão simples da arquitetura e ao mesmo 
tempo com todas as informações relevantes das interfaces do sistema. 
A partir da visão simplificada da arquitetura devemos analisar cada 
componente em termos de acessibilidade das interfaces. Esta análise envolve 
verificar se cada interface pode ser acessada por usuários autorizados, 
usuários anônimos ou por papéis específicos da aplicação. Os componentes 
que fornecem a interface também devem ser considerados no contexto da 
visão geral da arquitetura para que seja possível identificar delegações de 
função ou dados que passam de um componente a outro. Neste momento 
podemos agrupar as interfaces e componentes com perfis de acesso 
semelhantes. O conjunto dessas interfaces e componentes formam a superfície 
de ataque da aplicação. 
Com base nos grupos de interfaces e componentes da superfície de ataque, é 
importante verificar a segurança das interfaces. Essa análise deve ser 
conduzida por alguém experiente na área de segurança, pode ser um Arquiteto 
de Segurança ou um consultor externo. 
Uma forma de verificar a segurança das interfaces e componentes é atribuir 
pesos de acordo com a probabilidade de ser atacada e impacto ao sistema 
caso o ataque ocorra nesses locais. Para identificar a probabilidade do ataque 
podemos verificar o nível de acesso necessário para se "chegar" a determinada 
função do sistema. O nível de acesso pode variar tanto pelas permissões 
necessárias quanto pela sua exposição. 
A figura 3.2 mostra que quanto maior a permissão de acesso e quanto mais 
exposto está o sistema, maior a superfície de ataque. 
 
O eixo X representa as permissões necessárias para acessar determinada 
interface, componente ou função do sistema. Um acesso administrativo diminui 
a probabilidade de que um ataque ocorra através do recurso que está sendo 
analisado. 
O eixo Y representa a exposição de determinada interface, componente ou 
função do sistema. Um componente que é acessado somente em seu escopo 
local, ou seja, somente por outros componentes da própria aplicação, tem 
menos probabilidade de ser explorado do que uma interface pública que pode 
ser acessada por requisições de fora da aplicação. 
Por fim, é importante destacar que a análise da superfície de ataque deve ser 
atualizada sempre que houver mudanças nas interfaces ou componentes do 
sistema durante a fase de Análise e Projeto. 
4 Modelagem de ameaças 
Uma ameaça pode ser definida como "um ator, agente, circunstância ou evento 
que tem potencial para causar prejuízos a um sistema ou a seus dados e 
recursos." Uma ameaça pode ser categorizada por sua intenção: não 
intencional; intencional, mas não maliciosa; e maliciosa (que necessariamente 
é intencional). Todas as ameaças, independentemente da categoria, são 
capazes de comprometer o software, porém somente as ameaças maliciosas 
são realizadas por meio de um ataque. A maioria dos ataques contra softwares 
se aproveitam de (ou exploram) alguma vulnerabilidade ou falha no sistema. 
Fazer a modelagem de um software é uma forma de visualizar as interações do 
sistema dentro do ambiente em que será executado. Quanto mais a 
modelagem refletir o ambiente operacional em que o software irá operar, mais 
útil será para a análise de segurança. Esta análise de segurança consiste em 
incorporar as ameaças nos documentos de modelagem. 
Daí a definição de modelagem de ameças: "uma metodologia para avaliar e 
documentar os pontos fracos ou riscos de segurança de uma aplicação". A 
modelagem de ameaças ajuda a equipe de projeto a identificar os 
componentes de maior risco, analisando o sistema sobre a perspectiva de um 
atacante que tem o objetivo de comprometer o sistema. 
Existem muitas sistemáticas e ferramentas para apoiar a modelagem de 
ameaças de um software. As vantagens de usar ferramentas em vez de fazer 
um processo manual são: 
 a modelagem e análise manual tendem a consumir muito mais tempo; 
 quando o software a ser analisado é muito grande, a probabilidade de 
erros na análise é maior; 
 por meio da ferramenta é possível gerar novas ameaças quando alguma 
alteração é feita no ambiente da aplicação; 
 a ferramenta auxilia o processo de gerar diferentes visualizações do 
sistema e suas ameaças; 
 todos os requisitos de segurança do software são centralizados na base 
de dados da ferramenta, auxiliando na rastreabilidade e entendimento 
dos controles de segurança. 
A tabela 3.3 mostra algumas sistemáticas que podem auxiliar uma equipe na 
tarefa de modelagem de ameaças. Essas sistemáticas podem servir também 
como um guia de referência para elaborar uma sistemática própria do 
SERPRO. 
Tabela 3.3 
Application Threat Modeling - Microsoft http://msdn.microsoft.com/en-
us/security/aa570413.aspx 
Calculative Threat Modeling Methodology http://www.ptatechnologies.com/ 
Trike http://www.octotrike.org/ 
Consultative Object Risk Analysis System 
(CORAS) 
http://coras.sourceforge.net 
Threat Modeling based on Attacking Path 
(T-MAP) 
http://sunset.usc.edu/csse/research/COTS_Security/ 
A sistemática descrita na dissertação de doutorado de Yue Chen (SOFTWARE 
SECURITY ECONOMICS AND THREAT MODELING BASED ON ATTACK 
PATH ANALYSIS) mostra como quantificar as ameaças de segurança pelo 
cálculo do peso dado à severidade de caminhos de ataques relevantes aos 
softwares de prateleira (commercial off the shelf). 
Esta metodologia leva em consideração as prioridades das partes interessadas 
e o ambiente operacional de TI. Outra característica da sistemática 
apresentada por Yue Chen é permitir a rastreabilidade entre os objetivos de 
negócio, as ameaças de segurança e seus respectivos controles. 
A Microsoft possui uma sistemática própria bastante popular, que tem evoluído 
ao longo do tempo. Em sua primeira versão, a modelagem de ameaças da 
Microsoft usava 6 categorias gerais de ameaças. 
 Enganação ou Imitação (Spoffing): tentativa de oter acesso a um 
sistema usando uma identidade falsa. Isto pode ser realizado usando 
uma credencial falsa ou roubada. Depois que o atacante ganhou acesso 
como um usuário ou máquina legítima, ele pode tentar a elevação de 
privilégios ou o abuso de funções. 
 Falsificação (Tampering): modificação não autorizada de dados, como, 
por exemplo, o tráfego que passa na rede entre dois computadores. 
 Repúdio (Repudiation): habilidade de um usuário (legítimo ou não) de 
negar que tenha realizado uma ação ou transação. Sem a adequada 
auditoria, o não repúdio é difícil de ser obtido. 
 Divulgação de Informação (Information Disclosure): divulgação não 
autorizada de informações privadas. Por exemplo, um usuário visualiza 
o conteúdo de uma tabela ou arquivo que ele não tem permissão de 
abrir ou monitora os dados que passam em claro pela rede. Algumas 
vulnerabilidades de vazamento de informações incluem: campos 
escondidos em código HTML; comentários embutidos no código que 
revelam informações sobre conexão com o banco ou até mesmo senhas; 
tratamento de exceções mal-implementado que revela informações do 
sistema para o cliente; etc. 
 Negaçãode Serviço (Denial of Service): processo de deixar a aplicação 
ou um sistema indisponível. Este ataque pode ser conseguido pelo 
"bombardeamento" de requisições para consumir todos os recursos do 
sistema ou submeter uma entrada maliciosa que causa a parada total 
do sistema (crash). 
 Elevação de Privilégios (Elevation of Privileges): ocorre quando um 
usuário com privilégios limitados assume a identidade de um usuário 
com mais privilégios. Por exemplo, um atacante com privilégio restrito 
poderia elevar seu privilégio para comprometer ou tomar controle de 
uma conta ou processo de privilégio mais alto. 
Essas categorias são chamadas de STRIDE, que vem do termo em inglês, 
conforme mostra a tabela 3.4. 
Tabela 3.4 
Ameaça Princípio de 
Segurança 
Definição 
Spoofing Autenticação Personalização de algo ou alguém 
Tampering Integridade Alteração de código ou de dados 
Repudiation Não repúdio Alegar não ter realizado determinada ação 
Information 
Disclosure 
Confidencialidade Expor informações a alguém que não tenha permissão 
Denial of Service Disponibilidade Negar ou degradar o serviço aos usuários 
Elevation of 
Privilege 
Autorização Ganhar permissões ou capacidades sem a devida 
autorização 
Para complementar o STRIDE, uma metodologia de cálculo dos riscos 
chamada DREAD foi criada: 
 Damage potential (potencial de dano): Quão alto é o dano se a 
vulnerabilidade for explorada? 
 Reproducibility (facilidade de reprodução): Quão fácil é reproduzir o 
ataque? 
 Exploitability (facilidade de exploração): Quão fácil é executar o 
ataque? 
 Affected users (usuários afetados): Qual é a estimativa de usuários 
afetados (em porcentagem)? 
 Discoverability (facilidade de descobrimeto): Quão fácil é descobrir a 
vulnerabilidade? 
Podemos notar alguns pontos fracos na primeira versão da metodologia de 
modelagem de ameaças da Microsoft: 
(i) o STRIDE e DREAD são subjetivos e precisam ser aplicados por pessoas 
com conhecimento em segurança para serem efetivos; 
(ii) são focados em ataques em vez de ter o foco em ameaças. 
Por conta disso, a Microsoft evoluiu a metodologia para um processo mais 
simples e compreensível. A nova versão da metodologia ficou mais amigável 
para os desenvolvedores, arquitetos e outras partes interessadas que não são 
especialistas em segurança. Os guias de uso da metodologia e as ferramentas 
de apoio podem ser acessados em: 
http://www.microsoft.com/security/sdl/adopt/threatmodeling.aspx 
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=2955 
5 Arquitetura segura 
A última atividade de segurança da fase de Análise e Projeto é documentar 
a Arquitetura Segura do software. Nesta atividade, o Arquiteto de Segurança 
identificará os controles para cada ameaça levantada na modelagem de 
ameaças. O arquiteto pode obter auxílio de listas de verificação 
contendo controles de segurança divididos em categorias específicas. Um bom 
documento da OWASP que foi traduzido para português é o ASVS. No Módulo 
01 apresentamos o ASVS como Application Security Verification Standard 
(ASVS). 
Este documento descreve quatro níveis de segurança que podem ser 
atribuídos a uma aplicação web e, para cada um dos níveis, os requisitos 
arquiteturais que devem ser atendidos. 
Nossa atenção será na parte dos requisitos arquiteturais do documento 
chamados de requisitos de verificação. As tabelas a seguir representam alguns 
requisitos de verificação do ASVS. 
Tabela 3.5 
Requisitos de Verificação da Arquitetura de Segurança (V1) 
Requisitos de Verificação 
Nível 
1A 
Nível 
1B 
Nível 
2A 
Nível 
2B 
Nível 
3 
Nível 
4 
V1.1: Identificar todos os componentes da aplicação 
(tanto individuais como grupos de códigos-fonte, 
bibliotecas e/ou executáveis). 
x x x x x x 
V1.2: Definir ou checar a existência de uma 
arquitetura de alto nível para a aplicação. 
x x x x 
V1.3: Identificar as interconexões lógicas entre 
componentes da aplicação, grupos de componentes 
e sistemas externos. 
 
x x 
V1.4: Verificar que na definição da arquitetura da 
aplicação os aspectos de segurança foram 
documentados. 
 
x x 
V1.5: Verificar a integridade de códigos 
interpretados, bibliotecas, executáveis e arquivos 
de configuração, utilizando checksums ou hashes. 
 
x 
Observe que para cada requisito de verificação o documento associa em qual 
nível de segurança cada requisito deve ser atendido. Por exemplo, para as 
aplicações menos críticas (de nível 1) basta atender o requisito de verificação 
V1.1. Por outro lado uma aplicação crítica (nível 4) deve atender todos os 
requisitos de verificação (V1.1 ao V.1.5) no caso acima. 
O ASVS define 4 níveis de verificação de segurança, onde o rigor e a cobertura 
das verificações aumentam a cada nível. O Nível 1 consiste na verificação 
automática, sendo dividido em análise de vulnerabilidades e análise de código. 
O Nível 2 consiste na verificação manual e é dividida em testes de invasão e 
revisão de código. O Nível 3 consiste na verificação da arquitetura e o Nível 4 
na verificação interna da aplicação (incluindo todas as bibliotecas utilizadas). 
O ASVS agrupa os requisitos de verificação em 14 categorias ao todo: 
 V1. Arquitetura de Segurança 
 V2. Autenticação 
 V3. Gerenciamento de Sessões 
 V4. Controle de Acesso 
 V5. Validação de Entradas 
 V6. Codificação/Escape de saídas 
 V7. Criptografia 
 V8. Tratamento de Erros e Logs 
 V9. Proteção de Dados 
 V10. Segurança da Comunicação 
 V11. Segurança do HTTP 
 V12. Configuração da Segurança 
 V13. Investigação de Códigos Maliciosos 
 V14. Segurança Interna 
Tabela 3.6 - Requisitos de Verificação do Controle de Acesso (V4) 
Requisitos de Verificação 
Nível 
1A 
Nível 
1B 
Nível 
2A 
Nível 
2B 
Nível 
3 
Nível 
4 
V4.1: Verificar que os usuários podem acessar 
somente URLs nas quais eles possuem autorização 
específica. 
x 
 
x x x x 
V4.2: Verificar que os usuários podem acessar 
somente arquivos para os quais eles possuem 
autorização específica. 
x 
 
x x x x 
V4.3: Verificar que a navegação pelos diretórios está 
desabilitada, a menos que explicitamente desejada. 
x 
 
x 
 
x x 
V4.4: Verificar que os usuários podem acessar 
somente funções protegidas para as quais eles 
possuem autorização específica. 
x x x x x x 
V4.5: Verificar que os usuários podem acessar 
somente serviços para os quais eles possuem 
autorização específica. 
 
x x x x 
V4.6: Verificar que os usuários podem acessar 
somente dados para os quais eles possuem 
autorização específica. 
 
x x x x 
V4.7: Verificar que os controles de acesso falham de 
forma segura (princípio do fail safe). 
x x x x 
V4.8: Verificar que as decisões de controle de acesso 
são registradas (logs), inclusive as decisões de falha 
de acesso. 
 
x x x 
V4.9: Verificar que as mesmas regras de controle de 
acesso aplicadas pela camada de apresentação são 
executadas no lado servidor. 
 
x x x x 
V4.10: Verificar que toda informação usada pelos 
controles de acesso não pode ser manipulada pelos 
usuários finais, a menos que especificamente 
autorizado. 
 
x x x x 
V4.11: Verificar que referências diretas a objetos são 
protegidas, tal que somente objetos autorizados são 
acessíveis para cada usuário. 
x 
 
x x x x 
V4.12: Verificar que para cada tipo de recurso 
 
x x x 
protegido, existe um controle de segurança único 
que é usado para proteger aquele tipo de recurso. 
V4.13: Verificar que todos os controles de acesso são 
executados do lado servidor. 
x x x x 
V4.14: Verificar que todos os códigos que 
implementam ouusam controles de acesso não são 
afetados por nenhum código malicioso. 
 
x 
V4.15: Verificar que as regras de negócio que 
limitam o controle de acesso (por exemplo, limite de 
transações diárias) não são burladas. 
 
x x x x 
A tabela 3.6 é outro exemplo de requisitos de verificação definidos no ASVS. 
Estes são específicos para o controle de acesso da aplicação. Esse tipo de 
checklist contendo controles de segurança divididos em categorias específicas 
podem auxiliar o Arquiteto de Software na atividade de Gerenciar os Riscos 
Arquiteturais . 
Um checklist deve ser customizado pela organização para atender os princípios 
de arquitetura segura respeitando os padrões arquiteturais da empresa. Como 
o SERPRO possui diversos clientes, cada um com requisitos muito específicos, 
é possível haver um checklist geral e outros específicos para determinados 
clientes. 
Outra tarefa importante é definir a prioridade de cada controle e selecionar os 
frameworks de segurança que serão adotados. A prioridade deve ter como 
base a probabilidade e impacto da ameaça a que a interface ou componente da 
aplicação estão expostos (atividade realizada na modelagem de ameaças). 
A tabela 3.7 representa a estrutura geral de um checklist, composto pelo grupo, 
descrição do item e prioridade de adoção do requisito, sendo esta última 
definida para cada aplicação. 
Tabela 3.7 
ID Grupo Descrição Prioridade 
1 Registro de 
Auditoria 
Aplicação apta a receber auditorias de segurança. 
2 Controle de 
Acesso 
A autorização controlada tanto nas telas quanto nas chamadas às 
regras de negócio. 
 
3 Banco de 
Dados 
A base de dados do sistema acessada para alteração de estruturas 
(DDL), o que será realizado apenas por um usuário administrador 
do banco de dados, e não por usuários da aplicação. 
 
4 Controle de 
Acesso 
Antirrobô na Autenticação 
5 Tráfego de 
dados 
Certificação de que as informações transmitidas não são 
alteradas acidental ou maliciosamente em nenhum ponto de seu 
trajeto entre um emissor e um receptor. 
 
6 Controle de 
Acesso 
Credenciais de acesso ao sistema individuais para cada usuário 
(CPF ou um Código Especial). 
 
7 Não repúdio Não Repúdio, garantia, através de criptografia, de que um 
emissor não pode negar que enviou uma mensagem que foi 
recebida por um receptor. 
 
8 Controle de 
Sessão 
O sistema expira a sessão do usuário por inatividade, configurável 
para a aplicação. 
 
9 Infraestrutura Balaceamento de Carga na Aplicação 
10 Modelo 
Arquitetural 
Acesso à camada de negócio protegida 
... ... ... 
Para cada aplicação que será construída, é necessário que um checklist deste 
seja respondido. A próxima fase do ciclo de desenvolvimento seguro, a fase de 
codificação, deve atender às especificações de arquitetura. 
A figura 3.3 resume as atividades da fase de Análise e Projeto ligadas à 
segurança da aplicação a ser construída.