Análise dos Resultados

Com base na Tabela 5.3, foram submetidos três estudos de caso aos testes destes expe- rimentos de campo, com os resultados obtidos pela pelas ferramentas de monitoramento. As pesquisas publicadas por Goettelmann et al. (2015) e Mohapatra, Gulati e Luthra (2012) guiaram na interpretação e qualificação das escalas.

Observou-se que em alguns casos a escala foi definido um nível de qualificação como "Satisfatório", outro se estendem até o "Excelente". Os casos como ausência definição do nível refere-se aos ambientes de teste que, devido à falta de cenários prontos e o tempo e esforço para desenvolvê-los, não contemplam todos os aspectos de ameaças descritos no estudo.

Em contrapartida, esses estudos de caso abrangem os comportamentos mais elementares levantados nesta pesquisa.

Além disso, todos os aspectos pertinentes às ameaças em CN estão de acordo com os estudos de casos proposto. Outro fato relevante é que os falso positivos não foram considerados nestes testes, uma vez que o estudo atribui o fator humano responsável pela correções dos erros da análise. Sendo assim os estudos de caso apresentados foram definidos como ameaças reais aos serviços providos. Nesta seção serão descritas as considerações do estudo realizando com base nos resultados extraídos para as questões citadas na Tabela 5.3.

Resultado da Questão 01

O gráfico da Figura 5.4 apresenta a execução dos mecanismos de segurança utilizados no Estudo de Caso 01 das especificações WSS e W SP. Sua validação serviu com base para identificação do problema de aumento do tempo de resposta durante a sobrecarga do sistema diante da injeção de ataques, como negação de serviço e XML Injection. Assim, a ferramente SoapUI facilitou todo o processo de criação e depuração dos testes por meio de sua interface gráfica.

Durante a execução dos testes é medido o tempo de resposta em milissegundos de requisições com tokens válidos e com tokens inválidos. Assim, o tempo médio de resposta, para uma requisição de geração e validação de token válido, é aproximado de 550 milissegundos. Em contrapartida, o tempo médio de resposta, para uma requisição de geração e validação de token inválido, é aproximadamente de 810 milissegundos.

Conforme observado no gráfico d a F igura 5 .4, a d iferença d o t empo d e r esposta é aproximadamente 45% mais rápido que o mesmo cenário sem a solução. Essa performance é

5.1. METODOLOGIA 79 devido ao uso de credenciais de segurança, mais conhecida como Security Tokens, que comprova a identidade do emissor e permite acesso aos serviços do provedor, sempre e quando o provedor realiza a validação do passwordDisgest. Por outro lado, a solução sem segurança não realiza a validação das credenciais de acesso e faz com que o servidor retorne o status de requisição "HTTP 400 – Bad Request"ou "HTTP 500 – Internal Server Error" descrevendo um erro de sintaxes na resposta.

Figura 5.4: Análise do aumento do tempo de resposta

Fonte: própio autor.

Além disso, a arquitetura proposta proveu segurança fim-a-fim para aplicações que necessitam realizar trocas de dados de forma segura, e em conjunto, a especialização WS- SecurityPolicypossibilitou a declaração o uso do protocolo HTTPS para conexões seguras. E por fim, a criação de uma cadeia aleatória (nonce), permitindo rejeitar as mensagens SOAP manipuladas com intuito de sobrecarregar o sistema. A aplicação manteve um tempo de resposta para os clientes abaixo de 400 milissegundos.

80 5. AVALIAÇÃO DA PROPOSTA Figura 5.5: Resultados da avaliação da Questão 01

Fonte: própio autor.

Resultado da Questão 02

Seguindo a análise das especializações XML Digital Signature, XML Encryption e WS-Policy, conforme implementado no estudo de caso 02, obteve-se os resultados ilustrado na Figura 5.6.

A especialização XML Digital Signature garantiu os atributos de autenticidade, integri- dade e permitiu suporte para não repúdio aos dados assinados. Uma característica fundamental da XML Digital Signature, permitida no experimento, é a capacidade de assinar apenas partes específicas da mensagem SOAP, essa flexibilidade é importante para garantir o atributo de integridade dessas partes. Outra característica para garantir integridade, desta especialização, é a troca de mensagens assinadas, permitindo a validação do documento a partir da assinatura incluída na mensagem conforme demonstrado neste estudo de caso.

Desta forma, os atributos de autenticidade, integridade e não repúdio receberam a classi- ficação de "Excelente", devido as regras de processamento de assinatura digital. A propriedade não repúdio foi assegurada pela utilização da criptografia assimétrica.

Por sua vez, o padrão XML Encryption demonstrou a capacidade de codificar o conteúdo do corpo da mensagem SOAP, fornecendo qualidade de proteção através de integridade, confiden- cialidade e autenticação única de mensagens. Por esse motivo, a propriedade confidencialidade recebeu a escala quatro de "Satisfatório".

E por fim, as afirmações declaradas da especialização WS-Policy permitiram definir como os serviços disponibilizados estão autorizados a interagir com outros usuários e serviços. Portanto, o atributo disponibilidade obteve o grau quatro, "Satisfatório", na escala.

5.1. METODOLOGIA 81 Figura 5.6: Resultados da avaliação da Questão 02

Fonte: própio autor.

Resultado da Questão 03

Uma das principais dificuldades de realizar esse cenário de teste se concentrou na tarefa de estabelecer a relação de confiança entre o provedor de identidade, pelo protocolo LDAP, e o provedor de recursos utilizando SAML. Contribuíram para essa dificuldade a falta de experiência com esse protocolo e sua complexidade. Uma vez superada essa etapa, foi necessário a configuração do servidor AD apropriado, estabelecendo a relação de confiança entre o provedor de identidade e o provedor de recursos proposto pelo padrão SAML.

Para medir os testes, pode-se avaliá-lo com base nos resquisitos da arquitetura proposta: Conforme descrito na Figura 5.7, o framework SAML apresentou um comportamento excelente na preservação dos atributos de integridade, autenticidade e autorização. O experimento analisado no estudo de caso 03, permitiu analisar a criação da solução SSO, a qual estabeleceu um círculo de confiança através do intercâmbio das mensagens SOAP entre as entidades IdP e SP. A SAML também permitiu melhorar a produtividade na redefinição das credenciais de segurança para uma mesma identidade, garantido assim a propriedade de disponibilidade. A utilização dessa abordagem se faz comum em ambiente de nível INTRANET.

O padrão WS-Security permitiu a declaração de um token de segurança, auxiliando a especialização no suporte à autenticação com proteção de integridade em nível de mensagem.

82 5. AVALIAÇÃO DA PROPOSTA Figura 5.7: Resultados da avaliação da Questão 03

Fonte: própio autor.