REPÚBLICA DE ANGOLA

MINISTÉRIO DAS TELECOMUNICAÇÕES E TECNOLOGIAS DE INFORMAÇÃO

MINISTÉRIO DA EDUCAÇÃO
INSTITUTO DE TELECOMUNICAÇÕES
ITEL

Relatório do Projecto de Aptidão

Profissional (PAP)
Sistema de Detenção de Vulnerabilidades

Luanda, 2023
 REPÚBLICA DE ANGOLA
MINISTÉRIO DAS TELECOMUNICAÇÕES E TECNOLOGIAS DE INFORMAÇÃO
MINISTÉRIO DA EDUCAÇÃO
INSTITUTO DE TELECOMUNICAÇÕES
ITEL

Sistema de Detenção de Vulnerabilidades

Módulos de: Gestão de Utilizadores e Gestão de
Vulnerabilidades

Nome: Angelino Francisco Nº de processo: 13179

Nome: João Estuléne Nº de processo: 13623

Orientador: Prof. Anderson Salvador

Luanda, 2023
 DEDICATÓRIA
Dedicamos este trabalho, primeiramente, aos nossos pais que com muito
empenho têm feito do nosso conhecimento e desenvolvimento uma realidade, e também
todos os nossos caríssimos professores que têm se esforçado a nos ensinar o suficiente
para elaboração do projecto, e sem esquecer os nossos amados colegas que de forma
directa ou indirecta têm feito o nosso aprendizado o mais empolgante possível.

I
 RESUMO
Ao longo deste relatório iremos abordar sobre o Sistema de Detenção de
Vulnerabilidades. Apresentamos o tema em três vertentes onde incluem: introdução,
desenvolvimento e conclusão.

Durante a introdução, fez – se a contextualização do tema, bem como, a importância que

este representa a nível global e local. Por outro lado, durante o desenvolvimento
explicamos sobre os dois módulos que envolve o tema, onde se destaca:

➢ Modulo de Gestão de utilizadores: neste módulo, apresentamos o ambiente geral

do sistema, onde explicamos funcionalidades que o administrador(técnico) tem a
fazer em relação aos demais usuários, destacando – se a gestão de usuários,
definição de acesso, consultas de atividades, e a gestão de relatórios.
➢ Modulo de Gestão de Vulnerabilidades: neste módulo, falamos sobre a gestão e
funcionalidades inerentes ao lado dos usuários normais (especialista) do sistema,
destacando - se desde já a pesquisa de vulnerabilidades, geração de relatórios, e
a definição do tipo de testes;

Por fim, ao fazermos a conclusão apresentamos a perspectiva a que se destina este

projecto, bem como as realizações futuras que poderemos implementar.

Palavras chave

• Vulnerabilidades
• Teste
• Falhas
• Relatório
• Tecnologias
• Scanner
• Detenção
• Automatização
• Pesquisa / Pesquisar

II
 ABSTRACT
Throughout this report we will address the Vulnerability Detection System. We present
the theme in three aspects which include: introduction, development and conclusion.

During the introduction, the theme was contextualized, as well as the importance it
represents at a global and local level. On the other hand, during development we
explained about the two modules that involve the theme, where it stands out:

➢ User Management Module: in this module, we present the general environment

of the system, where we explain functionalities that the administrator (technician)
has to do in relation to other users, highlighting - user management, access
definition, activity queries, and report management.
➢ Vulnerability Management Module: in this module, we talk about the
management and functionalities inherent to the users (specialist) side of the
system, highlighting from now on the research of vulnerabilities, generation of
reports, and the definition of the type of tests;

Finally, as we conclude, we present the perspective for which this project is intended, as
well as the future achievements that we can implement.

Key words

• Vulnerabilities
• Test
• Fails
• Reports
• Technologies
• Scanner
• Detection
• Automatization
• Research / to research

III
 ÍNDICE GERAL

DEDICATÓRIA ....................................................................................................................... I
RESUMO .............................................................................................................................. II
ABSTRACT ........................................................................................................................... III
ÍNDICE GERAL ..................................................................................................................... IV
ÍNDICE DETALHADO............................................................................................................ V
ÍNDICE DE TABELAS ........................................................................................................... VII
1 INTRODUÇÃO ............................................................................................................. IX
2 REQUISITOS DO SISTEMA......................................................................................... XIII
3 TECNOLOGIAS E FERRAMENTAS .............................................................................. XVI
4 ARQUITETURA DO SISTEMA..................................................................................... XIX
5 MÓDULO DE GESTÃO DE UTILIZADORES ................................................................. XXI
6 MÓDULO DE GESTÃO DE VULNERABILIDADES ....................................................... XXX
7 CONCLUSÕES E RESULTADOS OBTIDOS ............................................................... XXXIX
8 PERSPECTIVAS FUTURAS ............................................................................................XL
9 ANEXOS .....................................................................................................................XLI
10 REFERÊNCIAS BIBLIOGÁFICAS ..................................................................................XLII

IV
 ÍNDICE DETALHADO

DEDICATÓRIA ....................................................................................................................... I
RESUMO .............................................................................................................................. II
ABSTRACT ........................................................................................................................... III
ÍNDICE GERAL ..................................................................................................................... IV
ÍNDICE DETALHADO............................................................................................................ V
ÍNDICE DE TABELAS ........................................................................................................... VII
1 INTRODUÇÃO ............................................................................................................. IX
1.1 Considerações Iniciais ......................................................................................... IX
1.2 Objectivos ............................................................................................................ IX
1.2.1 Objectivo Geral ............................................................................................ IX
1.2.2 Objectivos Específicos .................................................................................. IX
1.3 Problemática ........................................................................................................ X
1.4 Solução Desenvolvida........................................................................................... X
1.5 Estrutura do Relatório ......................................................................................... XI
2 REQUISITOS DO SISTEMA......................................................................................... XIII
2.1 Requisitos Funcionais ........................................................................................ XIII
2.2 Requisitos não Funcionais ................................................................................. XIV
2.3 Requisitos de Interface....................................................................................... XV
3 TECNOLOGIAS E FERRAMENTAS .............................................................................. XVI
3.1 Tecnologias Utilizadas ....................................................................................... XVI
3.1.1 Tecnologias de Desenvolvimento .............................................................. XVI
3.1.2 Tecnologias de Modelagem ...................................................................... XVII
3.2 Ferramentas Utilizadas..................................................................................... XVII
3.2.1 Servidores Utilizados................................................................................ XVIII
3.2.2 Plataforma Utilizada ................................................................................ XVIII
4 ARQUITETURA DO SISTEMA..................................................................................... XIX
4.1 Arquitetura Lógica ............................................................................................. XIX
4.2 Arquitetura Física ............................................................................................... XX
5 MÓDULO DE GESTÃO DE UTILIZADORES ................................................................. XXI
5.1 Objectivo do Módulo ........................................................................................ XXI
5.2 Requisitos Funcionais ........................................................................................ XXI
5.2.1 Documentação de Diagrama .................................................................... XXII
5.3 Identificação dos Atores.................................................................................. XXIII
5.4 Modelagem ..................................................................................................... XXIII
5.5 Implementação ............................................................................................... XXIV

V
 5.6 Camada de Apresentação ............................................................................... XXVI
5.7 Camada de Negócio ....................................................................................... XXVII
5.8 Camada de Persistência ................................................................................ XXVIII
6 MÓDULO DE GESTÃO DE VULNERABILIDADES ....................................................... XXX
6.1 Objectivo do Módulo ....................................................................................... XXX
6.2 Requisitos Funcionais ....................................................................................... XXX
6.2.1 Documentação de Diagrama ................................................................... XXXI
6.3 Identificação dos Atores................................................................................. XXXII
6.4 Modelagem ................................................................................................... XXXIII
6.5 Implementação ............................................................................................. XXXIII
6.6 Camada de Apresentação .............................................................................. XXXV
6.7 Camada de Negócio ...................................................................................... XXXVI
6.8 Camada de Persistência ............................................................................... XXXVII
7 CONCLUSÕES E RESULTADOS OBTIDOS ............................................................... XXXIX
7.1 Conclusões..................................................................................................... XXXIX
7.2 Resultados Obtidos ....................................................................................... XXXIX
8 PERSPECTIVAS FUTURAS ............................................................................................XL
8.1 Perspectivas Futuras ...........................................................................................XL
9 ANEXOS .....................................................................................................................XLI
10 REFERÊNCIAS BIBLIOGÁFICAS ..................................................................................XLII

VI
 ÍNDICE DE TABELAS
Tabela 1 Requisitos Funcionais do Sistema ..................................................................... XIII
Tabela 2 Requisitos não Funcionais do Sistema .............................................................. XIV
Tabela 3 Requisitos de Interface do Sistema .................................................................... XV
Tabela 4 Tecnologias de Desenvolvimento .................................................................... XVII
Tabela 5 Tecnologias de Modelagem ............................................................................. XVII
Tabela 6 Servidores Utilizados ....................................................................................... XVIII
Tabela 7 Plataforma Utilizada ........................................................................................ XVIII
Tabela 8 Requisitos Funcionais de Gestão de Utilizadores ............................................. XXI
Tabela 9 Documentação do Diagrama de Caso de Uso de Gestão de Utilizadores ....... XXII
Tabela 10 Tecnologias usadas na implementação de Gestão de Utilizadores ............... XXV
Tabela 11 Requisitos Funcionais de Gestão de vulnerabilidades ................................... XXX
Tabela 12 Document. do Diagrama de Caso de Uso de Gestão de vulnerabilidades ... XXXI
Tabela 13 Tecnologias usadas na implementação de Gestão de vulnerabilidades ..... XXXV

VII
 ÍNDICE DE FIGURAS
Figura 1 Arquitetura Lógica do Sistema ........................................................................... XIX
Figura 2 Arquitetura Física do Sistema ............................................................................. XX
Figura 3 Modelagem de Gestão de Utilizadores ........................................................... XXIII
Figura 4 Implementação de Gestão de Utilizadores ...................................................... XXIV
Figura 5 Camada de Apresentação de Gestão de Utilizadores...................................... XXVI
Figura 6 Camada de Negócio de Gestão de Utilizadores ............................................. XXVII
Figura 7 Camada de Persistência de Gestão de Utilizadores....................................... XXVIII
Figura 8 Modelagem de Gestão de vulnerabilidades .................................................. XXXIII
Figura 9 Implementação de Gestão de vulnerabilidades ............................................ XXXIV
Figura 10 Camada de Apresentação de Gestão de vulnerabilidades ........................... XXXV
Figura 11 Camada de Negócio de Gestão de Vulnerabilidades ................................... XXXVI
Figura 12 Camada de Implementação de Gestão de Vulnerabilidades ...................... XXXVII
Figura 13 Scannner de vulnerabilidades de Aplicações Web ...........................................XLI
Figura 14 Scanner de Vulnerabilidades para Analise de Trafego .....................................XLI

VIII
 1 INTRODUÇÃO

1.1 Considerações Iniciais

O scanner de vulnerabilidade é uma ferramenta de segurança da
informação indispensável para diagnosticar brechas e falhas em sistemas. Sua função
é monitorar continuamente as redes, aplicações e dispositivos em busca de pontos
vulneráveis a ciberataques e erros, além de reportar as alterações em detalhes,
categorizar os riscos e sugerir ações corretivas.

Dessa forma, as empresas podem identificar, corrigir e mitigar riscos, protegendo

seus ativos e aprimorando sua infraestrutura a cada nova vulnerabilidade descoberta.

Neste trabalho, vamos abordar e descrever o funcionamento do sistema de deteção

de vulnerabilidade (AngoHunt ), tendo como principal foco as aplicações web.

1.2 Objectivos
1.2.1 Objectivo Geral
• Desenvolver um sistema de deteção de vulnerabilidade

1.2.2 Objectivos Específicos

➢ Realizar levantamento de requisitos;
➢ Definir as Tecnologias para o desenvolvimento;
➢ Criar Diagramas;
➢ Desenvolver a dashboard (Front e Back);
➢ Criar a base de dados;
➢ Realizar testes de viabilidade do sistema;

IX
1.3 Problemática
A maioria dos sistemas computacionais são inseguros e os ataques contra tais
sistemas, especialmente as aplicações web, tem sido um problema grave tanto para as
organizações que as criam, quanto a seus usuários. Com o intuito de resolver tal problema
as organizações têm gastado montantes nas equipas interna de segurança constituídas
por um número específico de especialistas.

Por se tratar de área de extrema importância, as organizações a nível Internacional

têm procurado, cada vez mais, meios de automatização para melhorar a assertividade no
diagnóstico das falhas bem como, as melhores soluções corretivas para cada situação que
são programas chamados scanner de vulnerabilidades, o que atualmente não existe em
Angola.

1.4 Solução Desenvolvida

A fim de solucionar o problema ora descrito, será desenvolvido um sistema de

detenção de vulnerabilidades que possa auxiliar empresas e especialistas em segurança

a encontrarem falhas em aplicações web de uma forma automatizada, de modo a poupar

esforço e gastar menos energias.

O sistema será segmentado em diferentes partes, onde usuários e administradores

poderão gerir suas contas, selecionar o tipo de teste, aceder a relatórios e gerir todos os

usuários, fazer a gestão de relatórios, gerenciar vulnerabilidades, respectivamente.

O sistema será desenvolvido com um conjunto tecnologias no lado do servidor, para

ter a capacidade de diagnosticar possíveis falhas que possam ocorrer em sistemas web.

X
1.5 Estrutura do Relatório
O presente Relatório está constituído por 10 capítulos dentre os quais são
destacados os seguintes:

Capítulo 1: com este capítulo será desenvolvido assuntos inerentes as descrições

introdutivas do projecto, contendo os seguintes temas: Considerações Iniciais, Objectivo
Geral, Objectivos Específicos, Problemática, Solução Desenvolvida e a Estrutura do
Relatório.

Capítulo 2: ao longo deste capítulo serão apresentados temas ligados aos

requisitos do sistema, como também as condições necessárias para o funcionamento do
sistema. O capítulo está constituído da seguinte forma: Requisitos Funcionais, Requisitos
não Funcionais e Requisitos de Interface.

Capítulo 3: neste capítulo serão abordadas questões relacionadas as tecnologias

e ferramentas que foram utilizadas para o desenvolvimento do projecto e os programas
usados na modelagem do Sistema. Os dois grandes assuntos que preenchem este capítulo
são: Tecnologias Utilizadas e, Ferramentas Utilizadas.

Capítulo 4: Arquitetura Lógica e Arquitetura Física são as formas como está

estruturado o projecto. Apresentamos a forma como está esquematizada a Arquitetura
do projecto neste capítulo.

Capítulo 5: demonstramos o módulo de utilizadores do sistema neste capítulo. No

módulo de utilizadores é possível fazer a criação e a gestão dos usuários do sistema,
incluindo as regras de segurança, por onde são aplicadas métricas para garantir a
segmentação de usuários. O capítulo é constituído pelos respectivos subtítulos: Objectivo
do Módulo, Requisitos Funcionais, Identificação dos Atores, Modelagem, Camada de
Implementação, Camada de Negócio e Camada de Persistência

Capítulo 6: no decorrer deste capítulo é descrito o módulo de gestão de

vulnerabilidades. Dentro deste módulo é descrito a principal função da aplicação onde
também é possível realizar a gestão de relatórios. Os subtítulos que constituem este

XI
capítulo são: Objectivo do Módulo, Requisitos Funcionais, Identificação dos Atores,
Modelagem, Camada de Implementação, Camada de Negócio e Camada de Persistência.

Capítulo 7: É importante realçar as conclusões obtidas durante a elaboração do

relatório, relatando todos os resultados provenientes de pesquisas que foram feitas
durante a criação do projecto. Este capítulo é constituído por: Conclusões e Resultados
obtidos.

Capítulo 8: projectamos funcionalidades e recurso mais sofisticados que poderão

ser utilizados, em perspectivas futuras.

Capítulo 9: todos os documentos e arquivos de maior preponderância foram

anexados neste capítulo.

Capítulo 10: tornamos evidentes os conteúdos que foram utilizados na elaboração

do relatório e desenvolvimento do projecto em referências bibliográficas.

XII
 2 REQUISITOS DO SISTEMA
Requisito é o que um sistema ou componente deve possuir para satisfazer um
contrato, padrão ou especificação. De forma mais geral um requisito é uma condição
necessária para satisfazer um objetivo. Abaixo é apresentado tabelas com os requisitos
do sistema:

2.1 Requisitos Funcionais

Requisito Descrição

Permite realizar operações de conta como: criar, atualizar,

Gerir conta
verificar conta
Possibilita controlar usuários do sistema, com as opções
Gerir usuário de: criar, atualizar, verificar e eliminar usuários.

Faz uma busca das possíveis vulnerabilidades de acordo o

Pesquisar falha domínio do sistema que é feito a busca.

Garante que os relatórios possam ser guardados,

Gerir relatório atualizados e eliminados.

Permite gerar relatórios de acordo o tipo de teste que foi

Gerar relatório realizado.

Determina quais buscas serão realizadas de acordo os

Definir teste tipos de teste.

Permite visualizar as atividades mais frequentes de forma

Consultar atividade gráfica, tendo em conta a sua quantidade de uso.

Submete as dúvidas de usuários relacionados com o

Reportar dúvida
funcionamento do sistema.
Tabela 1 Requisitos Funcionais do Sistema

XIII
2.2 Requisitos não Funcionais

Requisito Descrição

Apenas utilizadores autorizados poderão visualizar as

Autenticação de usuários informações do sistema

O sistema é fácil de usar e de se realizar a operações a

Facilidade de uso do sistema que se dedica, tornando -se fácil de apreender

O sistema permite realizar no mínimo 1 pesquisa por

Quantidade de pesquisas usuário, por cada tipo de teste

As principais linguagens usadas foram: javascript,

Linguagens utilizadas python

O sistema foi projectado para ser exequível em

Plataformas de execução plataformas de tela grande

O sistema é reutilizável a nível de código,

componentes e arquitetura
Reutilização do sistema

Para permitir a integridade do sistema, será gerado

um relatório por cada tipo de busca realizada.
Integridade do sistema

Tabela 2 Requisitos não Funcionais do Sistema

XIV
2.3 Requisitos de Interface

Requisito Descrição

O sistema terá o mesmo modelo de interface

Design de interface(UI) para todos os utilizadores, de fácil interação

A construção do sistema teve em conta o

Experiência de usuário(UX) contacto do usuário(leigos) com o sistema,

A estrutura do sistema é unicamente projectada

Organização do sistema para dispositivos de telas maiores, computador

O uso de cores mais escuras são dedicadas ao

backgroud, as mais claras para realce de
Utilização de cores na aplicação
importantes funções, e as neutras para
operações gerais
Tabela 3 Requisitos de Interface do Sistema

XV
 3 TECNOLOGIAS E FERRAMENTAS

3.1 Tecnologias Utilizadas

Tecnologia é um produto da ciência e da engenharia que envolve um conjunto de
instrumento, métodos e técnicas que visam a resolução de problemas. As tecnologias
usadas no sistema são destacadas abaixo:

3.1.1 Tecnologias de Desenvolvimento

Considera – se como Tecnologias de Desenvolvimento linguagens ou frameworks
que podem ser usados para o desenvolvimento de softwares. Durante o Desenvolvimento
do projecto, foram usadas as seguintes tecnologias:

Tecnologias Descrição
Embedded JavaScript templating (EJS) é uma engine
EJS de visualização transportar dados do back-end para o
front-end, incorporando JAVASCRIPT no HTML
Linguagem de tipagem dinâmica usada para
Javascript desenvolvimento de softwares, aplicado no lado do
servidor na construção do sistema.
Linguagem de programação de alto nível. Bastante
Python usado em Data science, machine learning e
desenvolvimento web.
É uma linguagem explicitamente projetada, destinada
a resolver problemas com linguagens e ferramentas
Go
existentes, enquanto aproveita nativamente as
arquiteturas de hardware modernas.

XVI
 SQL (Structured Query Language): Linguagem de Consulta
Estruturada ou SQL, no projecto foi usado a linguagem
SQL para a construção da base de dados.
Tabela 4 Tecnologias de Desenvolvimento

3.1.2 Tecnologias de Modelagem

Tecnologias Descrição
Unified Modeling Language, é linguagem
padrão utilizada para modelar e documentar as
UML
diversas fases do desenvolvimento de sistemas.

É uma ferramenta que permite a modelagem e

gestão de base de dados. Com ela, pode - se criar
MYSQL Workbench 8.0 CE
diagramas EER, gerar scripts SQL, backups, gestão de
privilégios, criar funções, etc.

É uma ferramenta de modelagem de diagramas, que

foi utilizada na construção da arquitetura lógica do
Draw.io sistema.

Tabela 5 Tecnologias de Modelagem

3.2 Ferramentas Utilizadas

Ferramentas de programação são utilizadas para auxiliar os desenvolvedores, como
editores, compiladores, depuradores e assim por diante. Devem ser integradas ao
ambiente de modelagem e ao ambiente de teste, durante o desenvolvimento do

XVII
software. A seguir, são apresentadas as ferramentas utilizadas para o desenvolvimento
do projecto:

3.2.1 Servidores Utilizados

Servidores Descrição

Usado para armazenar e gerenciar dados de forma

Servidor de Dados
MYSQL organizada dentro da estrutura cliente – servidor

Utilizado para o armazenamento, processamento e

Servidor de aplicação entrega dos arquivos(sites) da aplicação
Node.js

Tabela 6 Servidores Utilizados

3.2.2 Plataforma Utilizada

Plataformas Descrição

É um editor de texto de código fonte aberto, utilizado

Visual Studio Code para desenvolvimento de softwares. Suportaa

diferentes linguagens de programação
É uma ferramenta que permite executar comandos do
sistema operacional e outros tipos dee comandos no
Comand Line(cmd) computador.

É um navegador de internet usado para renderizar

Microsoft Edge, Mozilla tecnologias web.

FIREFOX

Tabela 7 Plataforma Utilizada

XVIII
 4 ARQUITETURA DO SISTEMA
A arquitetura de um sistema descreve a estrutura, comportamento e relações entre
as entidades a ele pertencentes. Ela é uma descrição, sistematização ou formalização das
interações entre as entidades e seu comportamento. Demonstra as formas como um
sistema pode trabalhar para executar tarefas. Assim como há diferentes tipos de
sistemas, há diferentes tipos de arquitetura de sistemas onde incluem:

4.1 Arquitetura Lógica

Na figura abaixo é apresentado a arquitetura lógica do sistema sob o diagrama de
caso de uso geral da aplicação, que descreve as funcionalidades e serviços do sistema que
podem ser executadas por um utilizador normal (usuário) ou utilizador
privilegiado(administrador). As funções designadas por gerir (conta, usuário, relatório)
representam um conjunto de funcionalidades que podem ser executadas dentro da
aplicação, passando por: -Criar, - Atualizar, - Verificar e – Excluir.

Usuário Administrador

Figura 1 Arquitetura Lógica do Sistema

XIX
4.2 Arquitetura Física
Na figura abaixo é apresentado a arquitetura física do sistema que representa a
infraestrutura sobre a qual estará funcionando o projecto. Do lado direito pode - se
enxergar a comunicação entre os servidores web e base de dados, e a internet e o servidor
web, respectivamente. No lado esquerdo, pode - se visualizar o intercâmbio entre os
dispositivos finas(computadores ) e a internet, que é considerado como lado do cliente.

Servidor web
PC2 NODE.JS

INTERNET

PC1
Servidor de
Dados MYSQL

Figura 2 Arquitetura Física do Sistema

XX
 5 MÓDULO DE GESTÃO DE UTILIZADORES

5.1 Objectivo do Módulo

A finalidade deste módulo consiste em representar todo processo de gestão de
utilizadores, passando pela modelagem, implementação, regra de negócio, inclusive a
representação esquemática da base de dados deste módulo. Com diagrama de caso de
uso, bem como a documentação deste, faz – se necessário averiguar quais requisitos
estão relacionados para serem apresentados.

5.2 Requisitos Funcionais

Identificação Requisitos

RF01 Gerir conta

RF02 Gerir usuário

RF03 Definir acesso

RF04 Recuperar conta

RF05 consultar usuário ativo

RF06 Visualizar usuário inativo

RF07 Consultar atividade

RF08 Reportar dúvida

Tabela 8 Requisitos Funcionais de Gestão de Utilizadores

XXI
5.2.1 Documentação de Diagrama
Projecto: AngoHunt

Caso de uso: Gerir usuário

Descrição sucinta: Este caso de uso é responsável pela inclusão de um novo usuário, seja
ele normal ou administrador, bem como alteração dos dados, consulta, atualização e
exclusão de usuários.

Fluxo de Eventos Normais

Nome do fluxo Descrição

O referido usuário poderá informar os seus dados, a

Registrar usuário normal saber: nome, senha e email

O administrador poderá informar os seus dados de

Cadastrar administrador acesso, tendo um atributo admin de valor lógico para

diferenciar com usuários normais.
1. O usuário faz consulta dos seus dados e o
sistema gera opções de alteração
Consultar e atualizar
dados de usuários 2. O administrador tem o acesso a todas as
contas, podendo efectivar qualquer alteração
Excluir usuário 1. O usuário exclui a sua conta
2. Administrador exclui a conta de qualquer
usuário

Tabela 9 Documentação do Diagrama de Caso de Uso de Gestão de Utilizadores

XXII
 5.3 Identificação dos Atores
Os atores representam os papéis desempenhados pelos diversos usuários. Atores
podem ser pessoas que interagem com o sistema, um hardware que dispara uma
interação, ou um outro software que comunica com o sistema.

Ator (usuário normal) Ator (administrador)

5.4 Modelagem
A modelagem é uma das principais atividades que levam à implementação de um
bom software. Utiliza vários modelos para projetar um determinado sistema. Os
melhores tipos de modelos são aqueles que permitem a escolha do grau de detalhamento
das informações, tal como é apresentado a seguir:

Usuário adminstrador

Figura 3 Modelagem de Gestão de Utilizadores

XXIII
5.5 Implementação
Camada de Implementação é uma lógica de interface que representa o código
responsável pela apresentação, controle da página e tela de navegação.

MVC (Model View Controller) é uma arquitetura de projeto onde seu objetivo é
separar o código da aplicação em três camadas fazendo com que cada área só trabalhe
com itens que competem à elas.

Figura 4 Implementação de Gestão de Utilizadores

Model (M)

O model no padrão MVC, é utilizado para armazenar informações, trabalhando

como um espelho da tabela do banco de dados.

XXIV
View(V)

O view no padrão MVC, servirá apenas para exibir as informações enviadas pelo
controller, aqui não existirá nenhuma lógica ou regra de negócio, apenas a interface do
usuário.

Controller(C)

o controller é o responsável por fazer o intermédio entre o modelo e a visão.

É o responsável também por toda lógica do sistema. Retornando somente os itens
necessários para a comunicação entre o modelo e a visão. Abaixo apresentamos de forma
sucinta, as tecnologias que constituem cada uma das partes no presente módulo:

Model View Controller

SQL EJS, HTML5, CSS3 Javascript

Tabela 10 Tecnologias usadas na implementação de Gestão de Utilizadores

XXV
5.6 Camada de Apresentação

Figura 5 Camada de Apresentação de Gestão de Utilizadores

Na figura acima, pode – se enxergar a interface principal de gestão de utilizadores.

O controlo dos utilizadores é feito pelos administradores. Com o gráfico é possível
consultar as atividades que mais são realizadas no sistema conforme a quantidade de uso
feito pelos usuários.

Ainda é possível consultar os usuários que estejam a utilizar o sistema em tempo

real, em Frequentes, bem como, usuários que não estejam. Nesta interface, também
podemos ter acesso a todos os usuários da aplicação em Todos, onde também é possível
definir o acesso de usuários ao sistema, fazer alterações nos dados de todos os utilizadores
e inclusive excluir usuários.

XXVI
5.7 Camada de Negócio

Figura 6 Camada de Negócio de Gestão de Utilizadores

De acordo a figura, a camada de negócio do módulo presente é composta por quatro

(4) entidades, nomeadamente users, atividade, frequência e contacto, cujas restrições de
mapeamento aplicadas são:

• Um para muitos (1:n)

• Muitos para muitos (n:n).

Esta última, origina uma nova tabela ao ser convertido ao modelo relacional como foi
apresentado na camada de persistência

XXVII
5.8 Camada de Persistência

Figura 7 Camada de Persistência de Gestão de Utilizadores

Ao observar – se a figura, nota – se que a camada de persistência do corrente

módulo é composta por cinco (5) tabelas, nomeadamente: atividade, tarefa, frequência,
users, contacto.

A tabela users é responsável por armazenar os dados dos utilizadores do sistema.

Esta tabela tem como atributo “ isadmin ” do tipo lógico, para diferenciar os utilizadores
normais (quando o valor for falso) dos administradores (quando o valor for verdadeiro).

A tabela frequência tem a função de fazer um registro instantâneo dos utilizadores

ativos e inativos do sistema, armazenando informações como a hora e a data que este
acedeu ou saiu do sistema nos atributos hora e data, respectivamente.

XXVIII
 A tabela atividade armazena as atividades de maior uso no sistema, a quantidade
de uso, tendo como referência os usuários que as realizaram.

A tabela contacto tem a função de armazenar dúvidas, questões e problemas que

os usuários normais queiram reportar e manter contacto com os administradores, sejam
estes falhas de testes, relatórios implícitos, soluções obsoletas, falhas no sistema entre
outras. E por fim, a tabela tarefa serve como ponte de intermédio das tabelas atividade e
users em virtude da restrição de mapeamento (n:n) como explicado na camada de
negócio.

XXIX
 6 MÓDULO DE GESTÃO DE VULNERABILIDADES

6.1 Objectivo do Módulo

O objectivo deste módulo consiste em representar todo processo de gestão de
vulnerabilidades, passando pela modelagem, implementação, regra de negócio, inclusive
a representação esquemática da base de dados deste módulo. Com diagrama de caso de
uso, bem como a documentação deste, faz – se necessário averiguar quais requisitos
estão relacionados para serem apresentados.

6.2 Requisitos Funcionais

Identificação Requisitos

RF01 Gerar relatório

RF02 Gerir relatório

RF03 Submeter relatório

RF04 Pesquisar vulnerabilidade

RF05 Definir Teste

RF06 Filtrar Relatório

Tabela 11 Requisitos Funcionais de Gestão de vulnerabilidades

XXX
6.2.1 Documentação de Diagrama
Projecto: AngoHunt

Caso de uso: Gerir relatório

Descrição sucinta: Este caso de uso é responsável pela criação de relatórios específicos
para cada tipo de teste, de modo que usuário possa consultar relatórios com base nas
pesquisas que este realiza. Com este caso de uso, ainda é possível atualizar e excluir os
dados de cada relatório.

Fluxo de Eventos Normais

Nome do fluxo Descrição

O técnico do sistema poderá criar relatórios com base

Criar relatórios numa presente no sistema.

O usuário especialista poderá consultar os relatórios

Consultar relatórios para ter uma noção mais abrangente do tipo de falha
que o sistema detectou.
Os técnicos da aplicação irão atualizar os relatórios

Atualizar relatórios sempre que verificarem locais de ameaças novas no

mesmo tipo de teste.
Excluir relatórios O usuário especialista, poderá eliminar os relatórios
que já se fizeram o seu devido uso, bem como o
técnico poderá excluir os relatórios que já foram
vistos e classificados.

Tabela 12 Documentação do Diagrama de Caso de Uso de Gestão de vulnerabilidades

XXXI
6.3 Identificação dos Atores
Os atores representam os papéis desempenhados pelos diversos usuários. Atores
podem ser pessoas que interagem com o sistema, um hardware que dispara uma
interação, ou um outro software que comunica com o sistema.

Ator (especialista) Ator (técnico)

XXXII
6.4 Modelagem

Figura 8 Modelagem de Gestão de vulnerabilidades

A modelagem é uma das principais atividades que levam à implementação de um

bom software. Utiliza vários modelos para projetar um determinado sistema. Os
melhores tipos de modelos são aqueles que permitem a escolha do grau de detalhamento
das informações, tal como foi apresentado na figura acima.

6.5 Implementação
Camada de Implementação é uma lógica de interface que representa o código
responsável pela apresentação, controle da página e tela de navegação.

XXXIII
 MVC (Model View Controller) é uma arquitetura de projeto onde seu objetivo é
separar o código da aplicação em três camadas fazendo com que cada área só trabalhe
com itens que competem à elas.

Figura 9 Implementação de Gestão de vulnerabilidades

Model (M)

O model no padrão MVC, é utilizado para armazenar informações, trabalhando

como um espelho da tabela do banco de dados.

View(V)

O view no padrão MVC, servirá apenas para exibir as informações enviadas pelo
controller, aqui não existirá nenhuma lógica ou regra de negócio, apenas a interface do
usuário.

Controller(C)

o controller é o responsável por fazer o intermédio entre o modelo e a visão.

É o responsável também por toda lógica do sistema. Retornando somente os itens

XXXIV
necessários para a comunicação entre o modelo e a visão. Abaixo apresentamos de forma
sucinta, as tecnologias que constituem cada uma das partes no presente módulo:

Model View Controller

MYSQL EJS Javascript

NOSQL HTML5, CSS3 Python

Tabela 13 Tecnologias usadas na implementação de Gestão de vulnerabilidades

6.6 Camada de Apresentação

Figura 10 Camada de Apresentação de Gestão de vulnerabilidades

Na figura acima, pode – se visualizar a interface principal de gestão de

vulnerabilidades, onde encontra – se descrito quatro principais casos de uso. Na parte
central da interface é possível realizar pesquisas de vulnerabilidades com base no tipo de

XXXV
teste definido pelo utilizador. Os resultados da pesquisa serão apresentados abaixo onde
inclui a possibilidade de gerar relatórios de acordo a pesquisa realizada.

Ainda é possível aceder ao local onde são guardados todos os relatórios gerados ao
pressionar o botão relatórios, a partir da qual o utilizador tem a possibilidade de submeter
os relatórios ao administrador, bem como, excluir aqueles que não achar conveniente.

6.7 Camada de Negócio

Figura 11 Camada de Negócio de Gestão de Vulnerabilidades

De acordo a figura, a camada de negócio do módulo presente é composta por três (3)
entidades, nomeadamente users, relatório e atividade, cujas restrições de mapeamento
aplicadas são:

• Um para muitos (1:n)

• Muitos para muitos (n:n).

Entre a entidade users e atividade existe uma restrição do tipo muitos para muitos
(n:n), fazendo com que a camada a seguir contenha uma tabela a mais para o registro
normalizado dos dados, chamada “ tarefa” conforme mostrado na figura seguinte.

XXXVI
6.8 Camada de Persistência

Figura 12 Camada de Implementação de Gestão de Vulnerabilidades

Ao observar – se a figura, nota – se que a camada de persistência do corrente

módulo é composta por quatro (4) tabelas, nomeadamente: users, relatório, tarefa e
atividade.

A tabela users é responsável por armazenar os dados dos utilizadores do sistema.

Esta tabela tem como atributo “ isadmin ” do tipo lógico, para diferenciar os usuários
especialistas (quando o valor for falso) dos técnicos da aplicação (quando o valor for
verdadeiro).

A tabela relatório tem a função de fazer o registro de todos os relatórios criados em

virtude dos testes executados pelos usuários especialistas. Todo o relatório será

XXXVII
armazenado com a devida data de criação, para que possa ser excluído caso o seu
conteúdo seja obsoleto com o tempo.

A tabela atividade tem a função de armazenar os testes realizados pelos usuários

especialistas, tendo como principais informações a quantidade de uso do tipo de teste a
ser efetuado e o nome do teste executado. E por fim, a tabela tarefa serve para interligar
as tabelas users e atividade em virtude da restrição de mapeamento (n:n) como
explicado na camada de negócio.

XXXVIII
 7 CONCLUSÕES E RESULTADOS OBTIDOS

7.1 Conclusões
Ao findar da elaboração do trabalho, concluímos que com o scanner de
vulnerabilidades é possível reduzir, grandemente, o esforço aplicado pelos especialistas
em segurança cibernética, pois estas ferramentas ajudam a monitorar continuamente as
redes, aplicações e dispositivos, possibilitando as empresas a aprimorarem sua
infraestrutura a cada nova vulnerabilidade descoberta.

Por outro lado, é possível diagnosticar brechas e falhas, extremamente complexos,

em sistemas que resultariam em perdas de tempo e verbas caso fossem dedicados aos
métodos tradicionais.

7.2 Resultados Obtidos

O scanner de vulnerabilidades a nível das aplicações web pode diagnosticar vários
tipos de ameaças. Com o nosso projecto, limitamos essa quantidade em três (3)
categorias, onde inclui: Emumeration(Enumeração), Vulnerability(Vulnerabilidade) e
Scanner(Escaneamento).

O projecto desenvolvido usa a detenção qualitativa para fazer o scanner em sistemas

alvos, como também, permite consultar a quantidade de ameaças encontradas num
determinado alvo.

XXXIX
 8 PERSPECTIVAS FUTURAS

8.1 Perspectivas Futuras

Para que se desenvolva um scanner de vulnerabilidade de grande escala, é preciso
considerar um conjunto de ferramentas e tecnologias que vão além dos estudos
abordados neste trabalho.
Portanto, pretendemos aprimorar o sistema incrementando novas funcionalidades
tais como:
• Monitoramento de Redes
• Reportar alterações em detalhes de forma automatizada
• Sugerir acções corretivas de forma automática.

XL
 9 ANEXOS

Figura 14 Scanner de Vulnerabilidades para Analise de Trafego

Figura 13 Scannner de vulnerabilidades de Aplicações Web

XLI
 10 REFERÊNCIAS BIBLIOGÁFICAS
DEVEMIDIA. Desenvolvimento em Camadas 3: Conceitos. Fonte:
https://www.devmedia.com.br. Acesso em 28 de 11 de 2022.
JACQUES. Padrão Camadas: Arquitetura em 3 camadas. Fonte:
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/camadas.html. Acesso em
28 de 11 de 2022.
LIMA, A. Diferença entre Arquitetura de Sistema e Arquitetura de Software. Fonte:
https://acervolima.com. Acesso em 26 de 11 de 2022.

XLII