AndreiaFilipaPinheiroInácioAlexandre IN.pdfcolega e aluno do IST, Bruno Cheganças, pelo apoio e...

Auditorias IN

Andreia Filipa Pinheiro Inácio Alexandre

Dissertação para obtenção do Grau de Mestre em

Engenharia Eletrotécnica e de Computadores

Orientador: Prof. João Nuno De Oliveira e Silva

JúriPresidente: Prof. António Manuel Raminhos Cordeiro Grilo

Orientador: Prof. João Nuno De Oliveira e Silva

Vogal: Prof. Alberto Manuel Rodrigues da Silva

Novembro, 2018

Declaração

Declaro que o presente documento é um trabalho original da minha autoria e que cumpre todos os

requisitos do Código de Conduta e Boas Práticas da Universidade de Lisboa.

Agradecimentos

O meu mais profundo obrigado a todos os professores que durante o

meu percurso académico no Instituto Superior Técnico me incentivaram

sempre na busca incansável do conhecimento.

Gostaria de também poder demonstrar a minha imensa gratidão ao meu

colega e aluno do IST, Bruno Cheganças, pelo apoio e orientação na

concretização deste projeto e também, a toda a equipa de Operações IN

da Vodafone PT, pois sem dúvida, sem eles, nada disto poderia ter sido

possível.

Um especial agradecimento aos meus pais, Aurora e António Alexan-

dre, e ao meu companheiro de vida, André Vidal, pelo apoio e carinho

demonstrado, bem como pelo constante encorajamento na procura do me-

lhor de mim.

Um obrigado especial ao Professor João Nuno Silva pelo acompanha-

mento e orientação desta dissertação.

Estendo o meu mais profundo apreço a todos aqueles que fazem desta

escola a melhor escola de engenharia de Portugal.

Resumo

A dissertação Auditorias IN (Intelligent Network) surge no âmbito de um projeto interno da Vodafone

PT, com objetivo de colmatar a necessidade de consolidar, centralizar e controlar todos os processos de

auditoria, criados e desenvolvidos pelos membros da equipa de suporte à rede IN.

Atualmente, os procedimentos de criação de auditorias na rede IN, requerem diversas horas de trabalho

manual, com fluxos descontínuos de informação, sem um controlo centralizado, promovendo assim a

entropia dos processos e até da performance da equipa que lhe dá suporte.

Para minimizar o impacto dos processos de auditoria disruptivos nos sistemas, foi necessária a criação

de uma base de dados Oracle e de um Orquestrador em linguagem C, capaz de gerir e manter todos os

processos de auditorias, administrar os recursos computacionais da máquina, valorizando a criação de

documentação sobre cada uma das auditorias, com identificação de quem as criou, qual a origem, bem

como um controlo de versões para identificar todas as alterações efetuadas.

Em suma, esta dissertação dá ao utilizador total liberdade de criar processos de auditoria mais di-

nâmicos, seguros e escaláveis, de uma forma centralizada e transparente para os restantes colegas de

trabalho, permitindo uma análise mais precisa sobre os dados e um consequente decréscimo de entropia

na organização.

Palavras-chave: redes de telecomunicações, auditorias, orquestrador, processos de análise, catálogo, con-

trolo

Abstract

The Intelligent Network Audit thesis, comes within the scope of an internal project of Vodafone PT, ai-

ming to address the need to consolidate, centralize and control all audit processes, created and developed

by the support team members of IN network.

Currently, the procedures for creating audits in the IN network, require several hours of manual work,

with discontinuous flows of information, without centralized control, promoting the entropy of the pro-

cesses and even the performance of the team that supports it.

In order to minimize the impact of disruptive audit processes, it was necessary to create an Oracle

database and a C-language Orchestrator, capable of managing and maintaining all auditing processes,

managing the machine’s computational resources, creation of documentation on each of the audits, with

identification of who created them, what is the origin, as well as a version control to identify all the

changes made.

Therefore, this thesis gives the user complete freedom to create more dynamic, secure and scalable

auditing processes in a centralized and transparent way for the remaining co-workers, allowing a more

accurate analysis of the data and a consequent decrease of entropy within the organization.

Key words: telecommunication network, audits, orchestrator, analysis processes, catalog, control

Conteúdo

1 Introdução 1

2 Enquadramento 5

2.1 Arquitetura da rede IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Auditorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Procedimentos para auditorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Inquéritos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Criação de processos de auditoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.2 Operação e manutenção de processos de auditoria . . . . . . . . . . . . . . . . . . 14

2.4.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Sistema 19

3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Orquestrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Avaliação 31

4.1 Comparação de auditorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Vantagens de um catálogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Demonstração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Conclusões 43

5.1 Avaliação crítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A IN Audits - Inquérito 49

B IN Audits - Ficheiro de Configuração do Orquestrador 52

Lista de Figuras

1 Diagrama simplista de uma rede de comunicações móveis. . . . . . . . . . . . . . . . . . . 6

2 Diagrama de composição parcial de uma rede inteligente no que diz respeito ao charging

online. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Questão 1 e 2 do Inquérito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Questão 3 do Inquérito - opção de resposta "Sim"e "Não". . . . . . . . . . . . . . . . . . . 12




8 Questão 12 do Inquérito - escala linear entre 1 "Pouca frequência"e 5 "Muita frequência". . 14

9 Questão 10 e 11 do Inquérito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15





14 HLD - Desenho de alto nível do sistema planeado. . . . . . . . . . . . . . . . . . . . . . . 20

15 Base de Dados implementada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

16 HLD Orquestrador - Desenho de alto nível do orquestrador desenvolvido. . . . . . . . . . 24

17 HLD Orquestrador - Desenho de baixo nível do orquestrador desenvolvido. . . . . . . . . . 25

18 Fork - O processo pai cria tantos processos filhos, como o número máximo de processos

em paralelo disponíveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

19 Tabela IA_ADMIN_MAIN preenchidas com auditorias de exemplo. . . . . . . . . . . . . 35

20 Exemplo da tabela IA_USERS com a respetiva relação com a IA_USER_CONTACT. . 35

21 O agendamento das auditorias segundo a tabela IA_SCHEDULING em conformidade

com a parametrização na tabela IA_SCHED_PERIOD_UNITS. . . . . . . . . . . . . . . 36

22 A implementação das dependências das auditorias na tabela IA_AUDIT_DEPENDENCIES. 37

23 Tabela IA_COMMAND_TYPES com os tipos de comandos a serem executados pela

auditoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

24 A tabela com as metastrings disponíveis - IA_METASTRINGS . . . . . . . . . . . . . . . 37

25 A tabela com configurações - IA_SETTINGS. . . . . . . . . . . . . . . . . . . . . . . . . 38

26 A tabela em progresso das auditorias - IA_EXECUTION_PROGRESS. . . . . . . . . . . 39

27 A tabela histórico das auditorias - IA_EXECUTION_HISTORY. . . . . . . . . . . . . . 39

28 Directoria com as execuções de cada auditoria. . . . . . . . . . . . . . . . . . . . . . . . . 40

29 Ferramenta de visualização de resultados - Splunk. . . . . . . . . . . . . . . . . . . . . . . 41

Lista de Tabelas

1 Tabela de sinais utilizados no Orquestrador. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2 Ambiente Oracle Call Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1 Introdução

O projeto Auditorias IN (Intelligent Network) surge como uma necessidade de consolidação, centralização

e controlo dos processos de auditoria, criados e desenvolvidos pelos membros da equipa Operações IN,

da Vodafone Portugal.

Uma auditoria designa-se por um processo de análise, cujo objetivo é validar a integridade dos dados

aos quais se está a auditar. Por conseguinte, o auditor analisa e evidencia as medidas auditadas, avalia

as mesmas e formula uma opinião, cuja finalidade pode ser um processo de vigência ou a formulação de

correções.

Um processo de auditoria deve ser avaliativo, com o propósito final de enriquecer o controlo e a gestão

de risco dos sistemas, bem como fazer prosperar a eficácia dos processos de administração dos sistemas

aos quais se está a diligenciar.

Atualmente, cada membro da equipa Operações IN, no seguimento de um incidente ou de um problema,

projeta e desenha um processo de auditoria, podendo este ser, por exemplo, uma query, um script ou

um programa.

A auditoria é então, normalmente, desenvolvida e executada nos terminais de produção da IN, podendo,

inclusivamente, ser implementado um script específico com um cronograma bem definido para a auditoria,

na crontab da máquina.

Mas o que é afinal uma auditoria? No caso específico da Vodafone PT, na equipa de operações que faz

o suporte à rede de Intelligent Network, uma auditoria designa-se por um processo de vigência, o qual,

pode ser, por exemplo, a aferição do número de serviços afetados por um erro de configuração no custo

das chamadas efetuadas por um cliente com o tarifário Yorn e a sua devida correção.

Por outro lado, não menos importante, uma auditoria pode também implicar a aferição da perda de

receita que a empresa teve como consequência desse mesmo erro.

Contudo, atualmente, o método de trabalho contemplado, não permite o controlo de todos os processos

de auditoria criados, nem a criação instantânea de consulta de resultados, cálculo de métricas ou controlo

de alarmística.

Efetivamente, não se pode dar uma conotação incorreta à execução de queries a uma base de dados,

nem à sequencial importação dos resultados para um Microsoft Excel, à sua refinação com uso de tabelas

dinâmicas, nem ao facto de relatar as análises efetuadas aos stakeholders via e-mail. Porém, todas estas

etapas requerem diversas horas de trabalho manual, com fluxo descontínuos de informação, podendo

inclusive desprestigiar o trabalho executado, uma vez que a análise dos dados não é em tempo real. Por

outro lado, muitas das vezes os processos de auditorias são blocos mais pequenos de um quadro maior,

aumentando assim também, negativamente, a possibilidade de bottlenecks no decorrer do processo de

1

análise.

Do mesmo modo, não menos importante, este processo disruptivo atual de processos de auditorias inde-

pendentes a correrem nas máquinas, sem um controlo centralizado, podem proporcionar a deterioração

dos recursos computacionais, tais como, o CPU, a memória e o armazenamento.

Deste modo, surge a necessidade fundamental de desenvolver um modelo onde possam ser criados pro-

cessos de auditorias dinâmicos e escaláveis, economizando tempo e diminuindo a entropia. Os problemas

devem ser auditados e resolvidos num espaço de tempo mais curto, onde a transparência de resultados é

aumentada dentro da equipa e da organização. Ainda assim, todos os dados devem estar mais seguros,

pois devem estar unificados e centralizados num único local.

Por fim, os relatórios e a possibilidade de alarmística disponibilizada, devem permitir efetuar métricas

ao longo do tempo, analisando assim padrões e recorrências, dando ao utilizador a possibilidade de

configurar alertas de severidade sobre os dados auditados.

Em síntese, deve ser criado um modelo onde possa estar contemplado a criação de auditorias com crono-

gramas e dependências que o utilizador deseje. É também necessário garantir que, caso a auditoria seja

apreciativa, deve ser garantida a correção dos dados sobre aqueles aos quais o processo de auditoria está

a auditar. Consequentemente, este modelo deve também disponibilizar ao seu utilizador a possibilidade

de examinar os resultados do processo de auditoria, podendo assim o mesmo criar estatísticas e executar

alarmística sobre os mesmos.

Enumerando, o modelo proposto para este projeto caracteriza-se por:

1. Um painel de administração, responsável pela apresentação e gestão da base de dados, onde são

carregados os processos de auditoria.

2. Um motor de execução, cuja responsabilidade se centra no lançamento dos processos de auditorias

calendarizados.

3. Um processo de centralização de correções, com objetivo de analisar cada resultado do audit e

determinar se devem ser submetidas as devidas correções.

4. Um ambiente de tratamento de resultados, com objetivo de possibilitar a consulta dos resultados

de cada audit, calcular métricas e controlar as alarmísticas de execução e de resultados.

Esta dissertação vai incidir essencialmente no módulo de execução de auditorias, com a motivação de

desenvolver uma área administrativa de auditorias na Vodafone PT e validar a sua possível escalabilidade

para os mais diversos sistemas das áreas de IT (Information Technology).

A solução proposta para esta dissertação é dividida entre dois grandes módulos:

1. Desenho e execução de uma base de dados, cuja finalidade é garantir todos os pré-requisitos para

2

o correta criação e execução de um processo de auditoria.

2. Orquestrador, com objetivo final de ler a informação presente na base de dados, avaliá-la e caso

seja passível de ser implementada naquele instante, deve ser executada, garantindo o envio dos

resultados para os módulos seguintes.

A base de dados foi desenvolvida para Oracle Database, em linguagem SQL, e o Orquestrador, desen-

volvido em máquina Linux, em linguagem C.

A base de dados desenvolvida permite os seguintes pré-requisitos:

1. Controlo de versões;

2. Administração de processos de auditoria, estes definidos, de grosso modo, com ID único e estado

(ativo ou desativo).

3. Comandos a serem executados para cada auditoria;

4. Cronograma para cada processo de auditoria;

5. Dependências com os processos de auditoria;

6. Histórico de execuções;

7. Controlo de permissões de utilizadores;

O Orquestrador, cuja responsabilidade se centra no lançamento dos processos de auditorias calendari-

zados, deve garantir a correta gestão dos processos de auditoria ativos na base de dados, bem como a

correta execução dos mesmos.

Os módulos desenvolvidos nesta dissertação, podem ser implementados em qualquer sistema Red Hat/-

Linux que tenha uma base de dados Oracle na máquina. O Orquestrador é um programa singular e

independente do sistema ao qual está a ser apresentado, necessita apenas de um ficheiro de configuração

com todos os dados externos ao mesmo, como é o caso do user e password para conexão à base de dados.

Por outro lado, o ambiente de tratamento de resultados utilizado pode ser implementado num sistema

Linux, como ferramenta de indexação de dados e visualização dos mesmos em tempo-real.

É necessário referir que o Orquestrador não é responsável pela validação de erros nos processos de

auditoria, o utilizador deve garantir que todos os seus processos de auditoria são executados corretamente

no sistema. Nomeadamente, o utilizador deve garantir que os processos estão corretamente definidos,

sem erros, bem como estão regidos pelos pré-requisitos do módulo de auditorias.

Em suma, esta dissertação dá ao utilizador liberdade de criar processos de auditoria mais centralizados

e seguros, com a ajuda de uma ferramenta única, capaz de armazenar e gerir todos os processos de

auditoria criados e desenvolvidos pelos elementos de uma equipa de suporte.

3

Por outro lado, de uma forma transparente para os restantes colegas de trabalho e stakeholders, permite

uma análise mais precisa sobre os dados, bem com uma rápida manipulação dos mesmos.

4

2 Enquadramento

O conceito de auditoria está amplamente correlacionado com a deteção de erros e fraudes, bem como a

sua eventual prevenção.

A palavra "auditor"tem a origem no latim, "Auditore", que significa "aquele que ouve". [11]

A auditoria remonta ao Egito e à Babilónia, onde a mesma se baseava num método rudimentar de

apurar a exatidão de registos, comparando-os. Com as exigências decorrentes da Revolução Industrial,

a auditoria desenvolveu as suas diretrizes. Com o crescimento em expansão da dimensão das empresas

operárias, onde a obtenção de financiamento era um dos fatores críticos do sucesso, surge a necessidade

fulcral de ter um auditor para proclamar a transparência e detetar irregularidades, o que consolidou a

auditoria como uma disciplina de certificação de informação financeira.

Apesar do conceito de auditoria ser multidimensional, de um modo geral, a auditoria consiste num

processo de julgamento assente na recolha e análise de evidências ou resultados, apropriados e suficientes,

que fundamentem a opinião do auditor no que toca à conformidade de dados e/ou procedimentos. [11]

Um dos processos de auditoria que mais se encontra no mercado, é a auditoria financeira.

Este tipo de auditoria é utilizada substancialmente na redução do custo de produção de capital para

uma organização, na medida em que os investidores utilizam a informação auditada para tomarem

decisões de investimento racional. Estas auditorias tem por base credibilizar as informações constantes

nas demonstrações financeiras. [11]

Ora, este projeto, de forma análoga, visa, através de auditorias específicas de sistema, auditar e credibi-

lizar as informações presentes, conforme as diretrizes bases do sistema.

No caso em específico da Rede IN, da Vodafone PT, existe uma necessidade de auditar os sistemas,

de modo a que possamos validar a correta implementação dos mesmos, os erros que possam surgir

de incorretas configurações, responder a incidentes ou problemas detetados nos sistemas, responder

assertivamente a requisitos do marketing e inclusive, à prevenção de passíveis erros de futuro.

2.1 Arquitetura da rede IN

Um sistema de comunicação de redes móveis GSM (Global System for Mobile communication), por

definição, consiste na infraestrutura de telecomunicações que permite aos seus utilizadores em movimento

efetuar um tipo de comunicação.

Uma rede GSM é composta por diversos elementos, interligados entre si através de canais de comunicação.

A arquitetura de rede GSM pode ser subdividida em três subsistemas, os quais são chamados de BSS

5

(Base Station Subsystem), NSS (Network and Switching Subsystem) e OMS (Operations and Maintenance

System). O BSS é um sistema de estações base de transceptor (BTS - Base Transceiver Station), o NSS é

um subsistema de gestão e comutação de rede, enquanto que o OMS é um sistema de operação e suporte.

A figura 1 ilustra a arquitetura simplista de uma rede GSM.

Figura 1: Diagrama simplista de uma rede de comunicações móveis.

A rede GSM consiste em várias células ou representações geográficas no perímetro da área de cobertura,

cada uma controlada por uma estação base de transceptor BTS que facilita a comunicação móvel sem

fios entre o equipamento do utilizador e uma rede.

Assim, uma BTS pode servir várias estações móveis (MS - Mobile Station). Uma estação móvel MS é

também conhecida como UE (User Equipment), a qual se representa pelo cartão SIM (Subscriber Identity

Module) e o equipamento/terminal do utilizador. A comunicação móvel da BTS para o MS é denominada

por Downlink e, analogamente, o link do MS para a BTS é reconhecida como Uplink.

Por outro lado, as estações base de transceptor ou BTSs, são fiscalizadas pelo controlador de estações

base (BSC - Base Station Controller, o qual fornece, classicamente, a inteligência por detrás das BTSs.

Normalmente, um BSC tem dezenas ou até centenas de BTSs sob o seu controlo. O BSC tem por

obrigação efetuar a gestão e controlo de handovers de BTS para BTS, e, também controlar a frequência

e níveis de potência das BTSs dentro do seu raio de controlo.

A central de comutação móvel (MSC - Mobile Switching Center) é o componente principal do NSS, sendo

6

ela responsável pelo processamento de chamadas, operação e supervisão do sistema.

O HLR (Home Location Register) é o módulo do NSS responsável pela administração da base de dados dos

subscritores locais, ou seja, a cada vez que um serviço móvel é contratado, a informação do subscritor

é guardada no HLR da sua operadora móvel. Neste módulo estão guardadas as informações base do

cliente, o IMSI (International Mobile Subscriber Identity), o estado do registo, a chave de autenticação

e a sua localização.

Analogamente, existe o VLR (Visitors Location Register), cuja sua finalidade é reter informação perti-

nente, por um determinado período de tempo, sobre os subscritores visitantes que estejam conectados

na rede. [8]

Após a comunicação real passar por esta rede core de GSM, é trigada a rede IN. A rede IN (Intelligent

Network) é uma arquitetura de rede padrão que se destina a acrescentar valor agregado aos serviços

prestados pelas operadoras de telecomunicações, nomeadamente, construir serviços sofisticados e únicos

na rede, tais como, suportar chamadas GPRS (General Packet Radio Service), possibilidade de criar

tarifários diferenciadores, serviços como o Voice Mail, Speech to Text, bónus monetário por chamadas,

entre outros.

A rede IN oferece a possibilidade de ter serviços de pagamento e acesso convergente em várias plataformas,

redes e protocolos. Atualmente, na Vodafone PT, a rede IN suporta o universo de serviços pré-pagos e

pós-pagos para redes sem fios, residenciais e empresariais.

O serviço pré-pago fornece um meio rápido e conveniente para os subscritores obterem serviços de teleco-

municações em tempo real, contudo este serviço requer que os subscritores paguem antecipadamente pelo

serviço móvel. Os subscritores finais pré-pagos iniciam e recebem chamadas telefónicas da mesma forma

que os subscritores de assinaturas tradicionais. No entanto, os serviços pré-pagos não exigem contratos

e não recebem contas mensais.

De igual modo, o serviço pós-pago oferece aos subscritores um método de faturação convencional. As

contas pós-pagas não exigem saldo de crédito antecipado.

A faturação das comunicações para subscritores pré-pagos e pós-pagos são registadas com um sistema

Contabilidade Automática de Mensagens (AMA - Automatic Message Accounting). Assim, os sistemas

internos na IN, utilizam os dados provenientes nos registos de AMAs para gerar um custo direto nos

serviços pré-pagos e um valor de débito para os subscritores pós-pagos efetuarem o devido pagamento,

após a criação da sua fatura.

Deste modo, a rede IN é dividida, de uma forma simplista, em dois elementos de rede, o SCP (Service

Control Point), cujo principal objetivo é guardar a informação dos subscritores, tais como, a informação

da SIM e dos dados específicos do tarifário do cliente, como também retém dados dos serviços internos,

e pelo eSM (Enhanced Service Manager), responsável pelo provisioning nos serviços internos da IN. A

7

figura 2 representa a ilação dos dados atrás referidos.

Figura 2: Diagrama de composição parcial de uma rede inteligente no que diz respeito ao charging online.

Assim, deste modo, perante o universo de serviços pré-pagos e pós-pagos, residenciais e empresariais,

é imprescindível a existência de uma equipa de suporte à rede IN, capaz de auditar os seus serviços,

garantindo a qualidade e conformidade dos produtos e serviços oferecidos aos clientes, bem como da

satisfação dos mesmos.

2.2 Auditorias

As auditorias fazem parte da rotina de diversas empresas para garantir a qualidade e conformidade dos

seus produtos e/ou serviços, pelo que, na Vodafone PT são diversas as origens de execução de processos

de auditoria.

Habitualmente, as auditorias criadas tem por base um conjunto de boas práticas na gestão de serviços de

IT (Information Technology). Nomeadamente, as empresas que dependem de recursos computacionais

complexos para manter e gerir os seus negócios, podem usufruir da framework de ITIL (Information

Technology Infrastructure Library), como uma base para permitir às organizações integrar os serviços de

IT com a estratégia global da organização, com o objetivo final de entregar valor nos seus produtos e

serviços oferecidos, mantendo o nível de competência da organização e satisfação do cliente.

Os objetivos principais de execução de processos de auditorias são:

1. manter a satisfação e confiança nos negócios de IT;

2. garantir a eficiência e eficácia na entrega e no suporte dos serviços de IT disponibilizados;

3. minimizar o impacto de interrupções dos serviços nas atividades de negócio do dia a dia;

8

4. garantir que o acesso aos serviços acordados seja fornecido aos clientes autorizados.

Sintetizando, estes processos devem fornecer resultados e dados operacionais para definir oportunidade

de melhoria, bem como uma justificação para o seu investimento. Devem atender aos objetivos de política

de segurança da organização, reduzindo a duração e frequência de interrupções de serviços. Por outro

lado, devem fornecer as noções básicas para operações automatizadas, podendo efetivamente reduzir a

mão de obra não planeada e os custos adjacentes dos serviços de IT para o negócio.

No que se correlaciona diretamente com a rede IN na Vodafone PT, existem, essencialmente, quatro

tipos de causas para a criação de uma auditoria: provenientes de ordens de serviço ou queixas diretas

de clientes no que toca, por exemplo, à taxação incorreta de um produto, ou pelo report de incidentes,

service request ou problemas através de uma plataforma de ticketing, pela análise offline da faturação de

serviços dos respetivos gestores de produtos, ou pela proatividade dos colaboradores que fazem suporte

à rede em analisar os seus sistemas e produtos.

A equipa de suporte à rede IN da Vodafone PT não foge à regra. É também uma equipa, dentro da

organização da Vodafone, que utiliza as boas práticas do ITIL na análise e gestão de eventos, incidentes

ou problemas, reportados através de uma ferramenta de ticketing.

Deste modo, os processos de auditoria e vigência de serviços e produtos na rede IN, promovem também,

po si só, valor de negócio dentro da organização.

2.3 Procedimentos para auditorias

Dependendo do tipo de origem de uma auditoria, existem diversos procedimentos que um auditor pode

tomar.

Se estivermos a falar de uma auditoria que provem de um incidente ou de um service request, que não

necessita de um cronograma específico, ou seja, que pode ser feita efetuando uma análise imediata aos

sistemas, então estamos a falar de pesquisas ad hoc. Estas pesquisas ad hoc, se não forem muito pesadas

para a carga da plataforma de base de dados, podem ser executadas diretamente numa plataforma de

retenção de dados de informação, através da interface gráfica do utilizador (GUI). Caso contrário, podem

ser executadas diretamente nas máquinas, através de scripts customizados que fazem a conexão entre a

base de dados e ao sistema operacional.

Por outro lado, se estivermos a falar de um processo de auditoria que necessita de ser implementado

com um cronograma específico ou que necessite de vários períodos de execução, então é necessário criar

e implementar um script próprio ou um programa mais complexo para efetuar esta gestão.

Maioritariamente, estes processos de auditorias mais complexos necessitam da garantia de que os proces-

sos internos de retenção de dados de informação já tenham sido contemplados, de modo a não propagar

9

erros ou obter informação incorreta. É, desta forma, imprescindível garantir a correta gestão de depen-

dências entre sistemas.

Imaginemos que queremos efetuar uma auditoria, cuja origem provém de uma análise de fraude, sobre o

número de serviços pré-pagos da Vodafone PT que ao longo do tempo efetuou comunicações de voz ori-

ginadas na operadora francesa Bouygues. Neste exemplo, queremos obter ao longo do tempo, os serviços

que efetuaram as comunicações na operadora em causa, o custo associado à comunicação, juntamente

com o seu tarifário e o estado do serviço na IN.

Na Vodafone PT, era necessário obter e cruzar a informação de dois bancos de dados (da SIM e dos

registos AMA), nos períodos de execução em causa. Nomeadamente, era necessário cruzar informação

das partições diárias da SIM e dos AMAs, pelo que, se a análise fosse referente a um período mensal,

necessitávamos de efetuar uma auditoria cujas partições variassem num período de, por exemplo, trinta

dias.

Todavia, ainda era essencial considerar a necessidade de garantir a correta imparcialidade dos dados

nos cruzamentos entre tabelas, teríamos de garantir à priori que ao cruzar os dados nos referíamos

ao mesmo período de análise. Atualmente, na rede IN, este processo de análise de auditorias com

dependências entre tabelas, tem de ser acautelado manualmente por cada auditor, tendo este de ter um

conhecimento aprofundado dos processos internos de retenção de dados de informação, garantindo assim

a não propagação de erros ou a obtenção incorreta de dados.

Em suma, o auditor necessitava de criar um script customizado em que os dados da partição em análise

eram variáveis, obtendo tantos conjuntos de resultados como o número de períodos de execução. Por

outro lado, necessitava de garantir que no período ao qual iria efetuar a execução da auditoria, já estavam

contempladas as suas dependências.

Após a obtenção desses resultados, o auditor necessitaria de exportá-los para uma plataforma como,

por exemplo, o Microsoft Excel, podendo assim analisá-los e trabalhá-los, de modo a obter os resultados

específicos requisitados inicialmente pela equipa de fraude.

Ora, todas estas etapas requerem diversas horas de trabalho manual, com fluxos descontínuos de infor-

mação, podendo inclusive desprestigiar o trabalho executado. Por outro lado, este processo disruptivo

atual de processos de auditorias independentes a correrem nas máquinas, sem um controlo centralizado,

podem proporcionar a deterioração dos recursos computacionais, tais como, o CPU, a memória e o

armazenamento.

Deste modo, surge a necessidade fundamental de desenvolver um modelo onde possam ser criados pro-

cessos de auditorias dinâmicos e escaláveis, economizando tempo e diminuindo a entropia.

10

2.4 Inquéritos

Com o intuito de validar a veracidade dos requisitos iniciais para este projeto, bem como quantificar a

perceção que o público-alvo faz das fragilidades atuais do sistema de suporte à rede IN, na Vodafone

PT, foi criado um inquérito com vinte questões, dividido em três módulos: "Criação de processos de

auditoria", "Operação e manutenção de processos de auditoria "e "Análise de Resultados".

O público-alvo requisitado para responder a este inquérito, consistiu em quatorze colaboradores da

Vodafone PT, onze membros da equipa de Operações da Rede IN, um membro da equipa de Engenharia

da Rede IN, um manager da equipa de Operações da Rede IN e um manager da equipa de Aplicações e

Operações de Serviços.

Deste modo, a população escolhida denota a diversidade de conhecimento e abordagem ao projeto Au-

ditorias IN, validada com os resultados deste inquérito.

2.4.1 Criação de processos de auditoria

(a) Questão 1 do Inquérito - escala linear entre 1

"Nunca"e 5 "Diariamente".

(b) Questão 2 do Inquérito - escala linear entre 1 "Nada

custoso"e 5 "Muito custoso".

Figura 3: Questão 1 e 2 do Inquérito.

Dos quatorze inquiridos, cerca de sessenta e quatro por cento (figura 3a) sente necessidade de criar

processos de auditoria aos serviços da rede IN, dos quais cerca de sessenta e seis por cento (figura 3b)

admite que o esforço de implementar uma auditoria isolada, nos sistemas atuais, é elevado.

Os restantes inquiridos que indicaram que não tem de criar novos processos de auditoria, podem ser,

muito provavelmente, os inquiridos com cargos de administração, cujas responsabilidades não passam

pela execução de processos de auditoria.

Por outro lado, verifica-se que cerca de trinta e cinco por cento dos inquiridos não denota esforço na

implementação de um processo de auditoria. Este argumento pode estar correlacionado com o fato de

ter um conhecimento aprofundado dos procedimentos atuais de criação de auditorias, pelo que sente um

11

maior à vontade. Pode também, inclusivamente, dever-se ao facto deste elementos procederem à análise

de auditorias através de pesquisas ad hoc.

Figura 4: Questão 3 do Inquérito - opção de resposta "Sim"e "Não".

Do universo dos inquiridos, setenta e um por cento (figura 4), admite que o facto de ser necessária a

utilização de linguagens de programação, no que toca, por exemplo, à execução de scripts customizados,

resulta na consequente neguentropia na criação dos processos de auditorias.

Um dos possíveis argumentos para que os restantes inquiridos, vinte e oito por cento, tenham indicado

que as linguagens de programação não fomentavam a entropia, pode estar correlacionado com o facto dos

colaboradores terem experiência em diversas linguagens de programação, nomeadamente, as utilizadas

atualmente nos processos de auditoria na rede IN.

Por outro lado, esta resposta pode estar também correlacionada com o fato de elementos do público-

alvo terem cargos de administração, cujas responsabilidades não passam pela criação de processos de

auditoria.

(a) Questão 4 do Inquérito - escala linear entre 1 "Nada

confiante"e 5 "Muito confiante".

(b) Questão 5 do Inquérito - escala linear entre 1 "Não

acrescentaria valor"e 5 "Acrescentaria muito valor".


12

No que toca à confiança pessoal que cada inquirido sente aquando a criação de um processo de auditoria,

denota-se que mais de cinquenta por cento se sente bastante seguro quando implementa uma auditoria

corretamente, sem erros.

Contudo, cerca de trinta e cinco por cento dos inquiridos (figura 5a) indica que não consegue estabelecer

um equilíbrio na segurança, ou seja, denota insegurança na criação de processos. Esta amostragem pode

efetivamente estar correlacionado com o grau de conhecimento dos processos internos dos sistemas da

rede IN.

Porém, cem por cento dos inquiridos admite que, com a criação do modelo de Auditorias IN, a sua

experiência seria, comparativamente com a atualidade, convenientemente melhor (cerca de setenta e

oito por cento indica que "acrescentaria muito valor", enquanto que vinte e um por cento indica que

"acrescentaria valor- figura 5b).

(a) Questão 6 do Inquérito - escala linear entre 1 "Pouco

difícil"e 5 "Muito difícil".

(b) Questão 7 do Inquérito - escala linear entre 1 "Sem

quaisquer ganhos"e 5 "Proveitoso".


Cerca de setenta e oito por cento dos inquiridos (figura 6a) indicam que a complexidade dos processos

atuais de alimentação de dados, impõem dificuldade na orquestração e agendamento das auditorias,

uma vez que simulam dependências entre os processos (auditoria e processo de alimentação de dados).

Denota-se também que catorze por cento refere que é extremamente difícil compreender a orquestração

necessária, muito provavelmente, pela falta de conhecimento dos processos internos.

Contudo, verifica-se que vinte e um por cento dos inquiridos (figura 6a), indica que tem um maior

à vontade no agendamento das auditorias, muito provavelmente devido ao facto de poderem ser os

colaboradores que suportam estes mesmos processos, denotando assim um maior conhecimento de causa.

Porém, até mesmo quem tem conhecimento do sistema, não indica que o mesmo possa ser acessível.

Consequentemente, cem por cento dos inquiridos (figura 6b), admite que teria muito maior ganho, com a

criação do modelo de Auditorias IN, no que diz respeito à redução de erros, decorrentes de uma incorreta

calendarização.

13

2.4.2 Operação e manutenção de processos de auditoria


conhecimento"e 5 "Muito conhecimento".


dificuldade"e 5 "Muita dificuldade".


No que toca ao processo de operação como suporte aos processos de auditoria, inquirimos o nosso público-

alvo, sobre se estes tinham conhecimento sobre todos os processos de auditorias existente. O gráfico 7a

denota que cem por cento dos inquiridos tem um conhecimento médio ou quase nulo sobre os processos

a correr nas máquinas.

Evidencia-se também, que os inquiridos que normalmente não tem necessidade de criar processos de

auditoria (figura 3a), são aqueles que não tem qualquer conhecimento sobre os processos a correr nas

máquinas.

Os inquiridos que normalmente precisam de auditar serviços, são aqueles com maior tendência a indicar

que conhecem os processos. Uma das justificações para esta explicação, deve ser, muito provavelmente,

ao facto de conhecerem os seus próprios processos de auditorias ou até de alguns outros que sejam do

conhecimento geral da equipa.

Não obstante, desses cem por cento, metade sente dificuldade aquando necessita de confirmar a correta

operacionalização de uma ou mais auditorias (figura 7b).

Figura 8: Questão 12 do Inquérito - escala linear entre 1 "Pouca frequência"e 5 "Muita frequência".

14

Mais de cinquenta por cento dos inquiridos 8, admite que necessita de rever os processos de auditorias

aquando a nova análise dos requisitos. Os restantes cinquenta por cento, deve-se, muito provavelmente,

ao facto de grande parte das pesquisas feitas habitualmente sejam pesquisas ad hoc.


confiante"e 5 "Super confiante".

(b) Questão 11 do Inquérito - escala linear entre 1 "Muita

perda"e 5 "Muito ganho".


Por conseguinte, inquirimos a nossa população, para perceberemos o grau de confiança que sentem

atualmente, quando necessitam de efetuar uma alteração de um processo de auditoria, tendo este, a

possibilidade, de ter dependências com outros processos. Apenas sete por cento dos inquiridos indica

que se sente relativamente confiante em fazê-lo, muito provavelmente por ter um conhecimento de causa

alargado dos sistemas (figura 9a).

Conclusivamente, questionámos os inquiridos sobre o ganho que sentiriam, caso lhes fosse disponibilizado

o modelo de Auditorias IN, cuja função é efetivamente indicar as dependências entre processos. Mais de

oitenta por cento (figura 9b) respondeu que seria muitíssimo proveitoso, caso existisse esta funcionalidade

nas suas tarefas de manutenção de processos de auditoria.

Porém, dois dos inquiridos (figura 9b) indicaram que não teriam ganho nem perda, caso fosse disponibi-

lizada a ferramenta de Auditorias IN, este argumento, pode estar correlacionado com a não necessidade

de ter uma ferramenta que lhe indique as dependências entre processos, bem como com a sua atual

confiança nos sistemas.

No que toca à performance da máquina onde são colocados a correr os processos de auditoria, inquirimos a

nossa população para validarmos se já teriam tido conhecimento de algum processo que tenha deteriorado

a performance dos sistemas que o orquestram, nomeadamente, a performance da máquina e da base de

dados.

Chegámos então à conclusão de que setenta e oito por cento (figura 10a) já teve conhecimento de causa

sobre a inviabilização de processos. Os restantes vinte e um por cento, indica que não tiveram conhe-

cimento de causa, esta resposta pode estar intrinsecamente correlacionada com o período em que são

colaboradores da organização e, portanto, podem nunca ter tido conhecimento de nenhum processo que

15

tenha deteriorado a máquina.

Desses setenta e oito por cento, noventa e três por cento (figura 10b) indica que a capacidade do Or-

questrador tem para controlar o tempo máximo de execução de uma auditoria, bem como o número

máximo de tentativas, resulta numa mais valia para o controlo e gestão da performance dos sistemas que

orquestram os processos de auditoria.

Porém, sete por cento menospreza a importância de indicadores, ora, este argumento está diretamente

correlacionado com a questão anterior. O inquirido não tem conhecimento de nenhum processo que tenha

deteriorado a máquina, pelo que menospreza a importância dos indicadores de tempo e tentativas por

auditoria.

(a) Questão 13 do Inquérito - opção de resposta "Sim"e

"Não".

(b) Questão 14 do Inquérito - escala linear entre 1 "Pouca

importância"e 5 "Muita importância".


Por fim, questionámos os inquiridos sobre as alterações não documentadas efetuadas em processos de

auditoria.


"Não".

(b) Questão 16 do Inquérito - escala linear entre 1 "Pouca

importância"e 5 "Muita importância".


Embora, setenta e oito por cento dos inquiridos (figura 11a) indique que tem conhecimento de causa sobre

16

processos que não tenham sido executado ou que tenham, mas incorretamente, cem por cento (figura

11b) admite que se seria uma mais valia para a organização, ter um modelo de Auditorias IN capaz de

fomentar a documentação associada aos processos de vigência, bem como efetuar um controlo de versões

de todas as alterações efetuadas. Os restantes vinte e um por cento, podem não ter tido conhecimento

de causa, pelo que responderam negativamente à questão (figura 11a).

2.4.3 Resultados


"Não".

(b) Questão 18 do Inquérito - escala linear entre 1

"Nunca"e 5 "Sempre".


(a) Questão 19 do Inquérito - escala linear entre 1 "Sem

qualquer ganho"e 5 "Muito ganho".


qualquer ganho"e 5 "Muito ganho".


No que toca à análise de resultados, embora tenhamos evidenciado que mais de cinquenta por cento dos

inquiridos (figura 12b) necessita de trabalhar os dados, após a execução dos processos de auditoria, e que

cerca de trinta e cinco por cento (figura 12a) encontra-se satisfeito com a forma como recebe os resultados

(via e-mail), cem por cento dos inquiridos (figura 13a) indica que advinha um ganho muito proveitoso,

caso lhes fosse apresentada uma ferramenta de visualização de tendências de evolução e resultados de

17

fácil comparação, como é o caso do Splunk.

Um dos argumentos para que cem por cento dos inquiridos (figura 13a) indique que teria um ganho mais

proveitoso com a utilização do Splunk, deve-se, provavelmente, ao facto dos mesmos já utilizarem esta

ferramenta noutros contextos laborais, como uma ferramenta que indexa os seus resultados, dando logo

à partida uma gráfico de tendência ao longo do tempo, bem como é, por si só, uma ferramenta user

friendly de manutenção e pesquisa de resultados.

Por fim, sabendo que a ferramenta Splunk tem a capacidade de monitorizar resultados e estabelecer

métricas e alarmística com definição de thresholds, cem por cento dos inquiridos (figura 13b) admite que

o ganho seria de grande importância na perceção de comportamentos irregulares e na rápida resposta

aos mesmos.

Em aspeto conclusivo, podemos aferir e afirmar, dadas as respostas ao inquérito apresentado, a rece-

tividade positiva para a implementação do projeto Auditorias IN, uma vez que a grande maioria das

questões colocadas sobre as fragilidades dos procedimentos atuais em comparação com as funções do

modelo desenvolvido, revelam indicadores positivos e uma possível mais valida no desempenho de cada

colaborador dentro da organização.

Podemos concluir ainda que, apesar de em certas respostas a este inquérito a recetividade não ter

sido sempre positiva, pode indicar que nem todos inquiridos necessitam de todas as funções do modelo

apresentado, no cumprimento das suas tarefas laborais.

18

3 Sistema

Nesta secção será apresentada uma descrição completa do trabalho desenvolvido computacionalmente.

Numa primeira fase serão descritos os requisitos do modelo de dados. De seguida, será introduzida

a arquitetura do sistema, os seus inputs e outputs, bem como uma composição de todos os módulos

necessários à correta implementação de uma auditoria.

De igual forma, será descrito o modelo de base de dados implementado e, por fim, será disponibilizado

todo o processo de implementação dos sistemas, as tecnologias utilizadas, bem como as Interfaces de

Programação de Aplicações externas utilizadas.

Numa primeira fase, foi imprescindível reconhecer quais os requisitos necessários para o planeamento da

correta implementação de um modelo de auditorias.

Deste modo, foram estabelecidos os seguintes requisitos:

1. Obter controlo sobre todos os processos de auditorias criados;

2. Conhecer pormenorizadamente os resultados de todos os processos de vigência executados;

3. Criar capacidade de reação sobre todos os resultados;

4. Desenvolver a possibilidade de escalabilidade no que toca à implementação de novos processos de

auditoria;

5. Limitação do número de processos de análise a executar em simultâneo no servidor, promovendo a

gestão da capacidade de hardware;

6. Fazer uso razoável e controlado dos recursos disponíveis.

3.1 Arquitetura

Por conseguinte, após a identificação dos requisitos iniciais, foi idealizado um modelo dividido em quatro

grandes módulos. A figura 14 evidencia a composição do modelo projetado.

O primeiro módulo, denominado por Painel de Administração, deve ser uma interface gráfica de utilização

ou wizard, responsável pela gestão da informação na base de dados (figura 15), a qual será utilizada,

posteriormente, como input do Orquestrador.

O Processo Central de Correções, deve, quando necessário, receber o output das auditorias executadas

pelo Orquestrador como seu input. Tem assim como objetivo principal, analisar cada resultado dos pro-

cessos de auditoria e determinar se os mesmos são elegíveis para serem submetidas as devidas correções.

19

Se foram necessárias correções, deve ser capaz de criar o comando de correções por resultado, submeter

as devidas diligências, enviando os seus resultados para o módulo seguinte.

Como output do módulo de Orquestrador e do Processo Central de Correções, existe a ferramenta de

análise de resultados. Esta ferramenta de análise deve ser uma plataforma de inteligência operacional.

A ferramenta escolhida e já utilizada na Vodafone PT, denomina-se por Splunk.

Figura 14: HLD - Desenho de alto nível do sistema planeado.

O Splunk [5] é uma plataforma que permite indexar em tempo real dados de máquina, de modo a que os

seus utilizadores, com uma interface gráfica atrativa, consigam orquestrar e manipular os dados de uma

forma simples e intuitiva, sem grande esforço de logging. Deste modo, o Splunk vem substituir as sheets

de MS Excel, utilizadas anteriormente na manipulação dos resultados de uma auditoria, de modo a que

se possa obter uma análise eficaz e gráfica, em tempo real, dos resultados ao longo do tempo.

O Orquestrador, como módulo principal, deve ser o motor de execução de todos os processos de auditoria,

cuja responsabilidade se centra no lançamento dos mesmos e na capacidade de gerir eficazmente os

processos de vigência calendarizados na base de dados sem prejudicar a capacidade da máquina onde é

implementado, efetuando assim a uma correta gestão dos recursos da mesma.

20

3.2 Base de dados

Para o modelo de Auditorias IN atrás já evidenciado, foi necessária a criação de um modelo de dados em

base de dados Oracle, denominado "IN Audits", cuja finalidade é administrar e gerir todos os processos

de auditorias a realizar.

De modo a que seja possível uma gestão eficaz de cada alteração em cada auditoria, foi reproduzida uma

cópia das mesmas tabelas para controlo de versões.

Para identificar as tabelas de dados em tempo real e as de controlo de versões, foram criados dois

prefixos específicos para cada uma delas, IN Audits (IA) e IN Audits Versioning Control (IA_VC),

respetivamente.

IN_AUDITS.IA_EXECUTION_PROGRESS

*P ID_EXEC NUMBER (*,0)*F AUDIT_ID NUMBER (*,0)

EXEC_START_DATE NUMBER (*,0)* EXEC_PID NUMBER (*,0)

EXEC_PERIOD NUMBER (*,0)

IA_EXECUTION_PROGRESS_PK (ID_EXEC)

IA_EXECUTION_PROGRESS_FK1 (AUDIT_ID)

IA_EXECUTION_PROGRESS_PK (ID_EXEC)

IN_AUDITS.IA_EXECUTION_HISTORY

*P ID_EXEC NUMBER (*,0)* AUDIT_ID NUMBER (*,0)

EXEC_START_DATE NUMBER (*,0)EXEC_DURATION NUMBER (*,0)EXEC_RESULT_CODE NUMBER (*,0)EXEC_PERIOD NUMBER

IA_EXEC_HIST_PK (ID_EXEC)

IA_EXEC_HIST_PK (ID_EXEC)

IN_AUDITS.IA_SETTINGS

*P IA_SETTING_NAME VARCHAR2 (80 CHAR)IA_SETTING_VALUE CLOB

* IA_SETTING_ACTIVE VARCHAR2 (1 CHAR)

IA_SETTINGS_PK (IA_SETTING_NAME)

IA_SETTINGS_PK (IA_SETTING_NAME)

IN_AUDITS.IA_SCHED_PERIOD_UNITS

*P ID_SCHED_PERIOD_UNIT NUMBER (*,0)SCHED_PERIOD_UNIT_NAME VARCHAR2 (80 CHAR)

IA_SCHED_PERIOD_UNITS_PK (ID_SCHED_PERIOD_UNIT)

IA_SCHED_PERIOD_UNITS_PK (ID_SCHED_PERIOD_UNIT)

IN_AUDITS.IA_AUDIT_SCHEDULING

*F AUDIT_ID NUMBER (*,0)SCHED_START_DATE NUMBER (*,0)SCHED_PERIOD_VALUE NUMBER (*,0)

*F SCHED_PERIOD_UNIT_ID NUMBER (*,0)

IA_SCHED_AUDIT_FK (AUDIT_ID)IA_SCHED_PER_UNIT_FK (SCHED_PERIOD_UNIT_ID)

IN_AUDITS.IA_AUDIT_DEPENDENCIES

*F AUDIT_ID NUMBER (*,0)DEP_NAME VARCHAR2 (80 CHAR)

*F DEP_CMD_TYPE_ID NUMBER (*,0)DEP_CMD_TEXT CLOB

IA_AUDIT_DEPS_AUDIT_FK (AUDIT_ID)IA_AUDIT_DEPS_CMD_TYPE_FK (DEP_CMD_TYPE_ID)

IN_AUDITS.IA_METASTRINGS

*P ID_METASTRING NUMBER (*,0)MS_NAME VARCHAR2 (80 CHAR)

*F MS_CMD_TYPE_ID NUMBER (*,0)MS_ARGUMENTS_FORMAT CLOBMS_LST_CHG_DATE NUMBER (*,0)

*F MS_LST_CHG_USER_ID NUMBER (*,0)MS_LST_CHG_REASON CLOB

IA_METASTRINGS_PK (ID_METASTRING)

IA_MS_CMD_TYPE_FK (MS_CMD_TYPE_ID)IA_MS_USER_FK (MS_LST_CHG_USER_ID)

IA_METASTRINGS_PK (ID_METASTRING)

IN_AUDITS.IA_USER_CONTACT

*PF USER_ID NUMBER (*,0)*P CONTACT_TYPE VARCHAR2 (20 BYTE)

CONTACT VARCHAR2 (250 BYTE)

IA_USER_CONTACT_PK (USER_ID, CONTACT_TYPE)

IA_USER_CONTACT_IA_USERS_FK (USER_ID)

IA_USER_CONTACT_PK (USER_ID, CONTACT_TYPE)

IN_AUDITS.IA_USERS

*P ID_USER NUMBER (*,0)USER_NAME VARCHAR2 (250 CHAR)USER_ACTIVE VARCHAR2 (1 CHAR)

IA_USERS_PK (ID_USER)

IA_USERS_PK (ID_USER)IN_AUDITS.IA_COMMAND_TYPES

*P ID_CMD_TYPE NUMBER (*,0)CMD_TYPE_NAME VARCHAR2 (250 CHAR)CMD_TYPE_TEXT CLOBCMD_LST_CHG_DATE NUMBER (*,0)

*F CMD_LST_CHG_USER_ID NUMBER (*,0)CMD_LST_CHG_REASON CLOBCMD_TYPE_ACTIVE VARCHAR2 (1 BYTE)

IA_CMD_TYPES_PK (ID_CMD_TYPE)

IA_CMD_TYPES_IA_USER_FK (CMD_LST_CHG_USER_ID)

IA_CMD_TYPES_PK (ID_CMD_TYPE)

IN_AUDITS.IA_DIST_LIST

*F AUDIT_ID NUMBER (*,0)DIST_TYPE VARCHAR2 (80 BYTE)

*F USER_ID NUMBER (*,0)

IA_DIST_LIST_AUDIT_FK (AUDIT_ID)IA_DIST_LIST_IA_USERS_FK (USER_ID)

IN_AUDITS.IA_ADMIN_MAIN

*P ID_AUDIT NUMBER (*,0)ADT_EXT_ID VARCHAR2 (250 CHAR)ADT_NAME VARCHAR2 (250 CHAR)ADT_PRIORITY NUMBER (*,0)ADT_ACTIVE VARCHAR2 (1 CHAR)ADT_APP_OOS VARCHAR2 (1 CHAR)ADT_MAX_RETRIES NUMBER (*,0)ADT_TIME_TO_LIVE NUMBER (*,0)ADT_ALLW_CORRECT VARCHAR2 (1 CHAR)ADT_CMD_TEXT CLOB

*F ADT_CMD_TYPE_ID NUMBER (*,0)ADT_MISC_FIELD CLOB

*F ADT_OWR_USER_ID NUMBER (*,0)ADT_CRT_DATE NUMBER (*,0)ADT_LST_CHG_DATE NUMBER (*,0)

*F ADT_LST_CHG_USER_ID NUMBER (*,0)ADT_LST_CHG_REASON CLOB

IA_ADMIN_MAIN_PK (ID_AUDIT)

IA_ADMIN_MAIN_CMD_TYPE_FK (ADT_CMD_TYPE_ID)IA_ADMIN_MAIN_OWNR_USER_FK (ADT_OWR_USER_ID)IA_ADMIN_MAIN_CHG_USER_FK (ADT_LST_CHG_USER_ID)

IA_ADMIN_MAIN_PK (ID_AUDIT)

IN_AUDITS.IA_VC_ADMIN_MAIN

*P ID_AUDIT NUMBER (*,0)ADT_EXT_ID VARCHAR2 (250 CHAR)ADT_NAME VARCHAR2 (250 CHAR)ADT_PRIORITY NUMBER (*,0)ADT_ACTIVE VARCHAR2 (1 CHAR)ADT_APP_OOS VARCHAR2 (1 CHAR)ADT_MAX_RETRIES NUMBER (*,0)ADT_TIME_TO_LIVE NUMBER (*,0)ADT_ALLW_CORRECT VARCHAR2 (1 CHAR)ADT_CMD_TEXT CLOB

* ADT_CMD_TYPE_ID NUMBER (*,0)ADT_MISC_FIELD CLOB

*F ADT_OWNER_USER_ID NUMBER (*,0)ADT_CRT_DATE NUMBER (*,0)

*P ADT_LST_CHG_DATE NUMBER (*,0)*F ADT_LST_CHG_USER_ID NUMBER (*,0)

ADT_LST_CHG_REASON CLOB

IA_VC_ADMIN_MAIN_PK (ID_AUDIT, ADT_LST_CHG_DATE)

IA_VC_ADMIN_MAIN_CHG_USER_FK (ADT_LST_CHG_USER_ID)IA_VC_ADMIN_MAIN_OWNR_FK (ADT_OWNER_USER_ID)

IA_VC_ADMIN_MAIN_PK (ID_AUDIT, ADT_LST_CHG_DATE)

IN_AUDITS.IA_VC_AUDIT_SCHEDULING

*P AUDIT_ID NUMBER (*,0)SCHED_START_DATE NUMBER (*,0)SCHED_PERIOD_VALUE NUMBER (*,0)

* SCHED_PERIOD_UNIT_ID NUMBER (*,0)*P SCHED_LST_CHG_DATE NUMBER

IA_VC_AUDIT_SCHEDULING_PK (AUDIT_ID, SCHED_LST_CHG_DATE)

IA_VC_AUDIT_SCHEDULING_PK (AUDIT_ID, SCHED_LST_CHG_DATE)

IN_AUDITS.IA_VC_METASTRINGS

*PF ID_METASTRING NUMBER (*,0)MS_NAME VARCHAR2 (80 CHAR)

* MS_CMD_TYPE_ID NUMBER (*,0)MS_ARGUMENTS_FORMAT CLOB

*P MS_LST_CHG_DATE NUMBER (*,0)* MS_LST_CHG_USER_ID NUMBER (*,0)

MS_LST_CHG_REASON CLOB

IA_VC_METASTRINGS_PK (ID_METASTRING, MS_LST_CHG_DATE)

IA_VC_MS_USER_FK (ID_METASTRING)

IA_VC_METASTRINGS_PK (ID_METASTRING, MS_LST_CHG_DATE)

IN_AUDITS.IA_VC_AUDIT_DEPENDENCIES

*P AUDIT_ID NUMBER (*,0)DEP_NAME VARCHAR2 (80 CHAR)

* DEP_CMD_TYPE_ID NUMBER (*,0)DEP_CMD_TEXT CLOB

*P DEP_LST_CHG_DATE NUMBER

IA_VC_AUDIT_DEPENDENCIES_PK (AUDIT_ID, DEP_LST_CHG_DATE)

IA_VC_AUDIT_DEPENDENCIES_PK (AUDIT_ID, DEP_LST_CHG_DATE)

IN_AUDITS.IA_VC_COMMAND_TYPES

*P ID_CMD_TYPE NUMBER (*,0)CMD_TYPE_NAME VARCHAR2 (250 CHAR)CMD_TYPE_TEXT CLOB

*P CMD_LST_CHG_DATE NUMBER (*,0)*F CMD_LST_CHG_USER_ID NUMBER (*,0)

CMD_LST_CHG_REASON CLOB

IA_VC_COMMAND_TYPES_PK (ID_CMD_TYPE, CMD_LST_CHG_DATE)

IA_VC_CMD_TYPS_USER_FK (CMD_LST_CHG_USER_ID)

IA_VC_COMMAND_TYPES_PK (ID_CMD_TYPE, CMD_LST_CHG_DATE)

Figura 15: Base de Dados implementada.

A tabela principal denomina-se por IA_ADMIN_MAIN que, tal como o nome indica, é a tabela mestre

de administração de auditorias.

Nesta tabela, devem ser introduzidos os dados únicos de cada auditoria, nomeadamente, o identificador

único e chave primária da tabela (um ID numérico), um identificador externo, em caso necessário (por

exemplo, o ID do pedido de auditoria efetuado através da ferramenta de ticketing, o nome da auditoria

e a descrição da origem da mesma.

21

Por outro lado, devem também estar contemplados os seguintes valores: número máximo de tentativas

de execução por auditoria e o tempo máximo em segundos que a auditoria pode estar a correr. Estes

dois parâmetros serão utilizados no Orquestrador para a correta gestão da capacidade da máquina.

Por outro lado, não menos importante, nesta tabela deverá estar descrito se a auditoria em causa permite

correções, isto é, se o resultado da auditoria será o input do Processo Central de Correções.

Por fim, nesta tabela deverá estar inscrito o comando necessário para implementar a auditoria, bem

como chave estrangeira para a tabela de tipos de comandos.

Por uma questão de controlo sobre todos os processos de auditoria e respetivas alterações, na tabela

IA_ADMIN_MAIN deve estar também representado o criador da auditoria, a data de criação da mesma,

bem como a identificação do utilizador que efetuou a última alteração, a data e a descrição da razão pela

qual foi modificada.

Cada auditoria deve estar associada a um proprietário e, para tal, foi criada a tabela IA_USERS.

Esta tabela é composta por três campos: o ID_USER, identificador único e chave primária da tabela,

o USER_NAME, nome do utilizador e a flag USER_ACTIVE para validar se é um utilizador ativo ou

inibido.

Para obter mais granularidade no que toca às notificações, inclusive para ser possível o envio de relatórios

sobre as auditorias, foi necessária a criação da tabela IA_USER_CONTACT, cuja finalidade, através

de três campos, é permitir uma lista de tipo de contactos por cada utilizador (e-mail, telefone, morada,

etc).

Por conseguinte, cada auditoria deve também ter a possibilidade de poder informar os seus utilizadores

do término da sua execução, de modo a que estes possam então fazer a sua análise aos resultados. Esta

tarefa é gerida na tabela IA_DIST_LIST, cujo objetivo é efetuar o correlacionamento entre o audit e

os utilizadores passíveis de serem notificados, conforme o tipo de notificação requisitado.

Uma auditoria deve ser agendada segundo a tabela IA_SCHEDULING, cuja finalidade é definir perio-

dicamente a auditoria em horários, datas ou intervalos de tempo fixos. Deste modo, foi desenhado um

campo para definir uma data de início e um campo com o período de execução sobre o qual irá correr

a auditoria. Este período tem de ser intrinsecamente correlacionado com a definição de unidades de

período disponíveis na tabela de reference data, a IA_SCHED_PERIOD_UNITS.

Uma auditoria pode ter uma determinada dependência sobre outro processo a correr na máquina onde foi

implementada, por exemplo, a auditoria em análise deve ser executada sobre uma determinada partição

de uma tabela, a sua dependência é então o processo interno de retenção de dados de informação para

a partição em causa. Deste modo, foi necessária a criação da tabela IA_AUDIT_DEPENDENCIES.

Por outro lado, houve a necessidade da criação da tabela IA_COMMAND_TYPES, cujo objetivo é

22

permite identificar o tipo de comando ao qual uma determinada auditoria está correlacionada e os seus

argumentos de execução.

Para uma versatilidade nas auditorias foi necessária a criação de uma tabela de metastrings, cuja fi-

nalidade é, através de uma cadeia de caracteres utilizados como um espaço reservado para determinar

um conjunto de dados variáveis, inscritos na tabela auxiliar IA_SETTINGS, manipular os dados na

auditoria que correspondem ao período de execução ao qual a auditoria está a ser executada.

Para uma melhor compreensão, imaginemos que queremos efetuar uma auditoria que valida uma deter-

minada informação presente numa tabela cuja partição se refere a um determinado dia. A partição é um

dado variável, que depende do período de análise, perfazendo assim uma metastring. Ou, por exemplo,

uma auditoria necessita como parâmetro o dia em que está a ser executada, a variável "dia"é, por si só,

também uma metastring, que pode ser, por exemplo, obtida como uma chamada ao sistema utilizando o

comando /bin/date. [3].

Assim, com a tabela IA_METASTRINGS é possível efetuar essa manipulação de resultados variáveis,

de modo a que uma auditoria se adapte ao período de execução, sem que o utilizador que a tenha

desenvolvido necessite de efetuar alterações sobre a auditoria a cada período de execução.

Para a administração das auditorias em progresso e do histórico de execução das mesmas, foram criadas

as tabelas IA_EXECUTION_PROGRESS e IA_EXECUTION_HISTORY, respetivamente.

A tabela IA_EXECUTION_PROGRESS é a primeira a ser populada com os dados de execução atuais

das auditorias. Aquando o término de uma auditoria inscrita nesta tabela, os dados são reaproveitados

para a inserção na tabela de histórico (IA_EXECUTION_HISTORY ).

A tabela de progresso tem uma sequência de IDs como chave primária e a referência com o campo

ID_AUDIT como chave secundária, perfazendo uma chave composta. Nesta tabela é então inserida a

informação associada ao comando interno do sistema operacional correlacionada com a auditoria exe-

cutada, isto é, a identificação do processo, o PID da máquina (Process Identification), denominado

EXEC_PID, e a data de início da execução do comando.

Assim, quando o comando termina, é possível calcular a informação que será introduzida na tabela

de histórico, a duração da auditoria EXEC_DURATION e o código de resultado EXEC_RESULT_

CODE.

No que tocas às configurações do Orquestrador e de variáveis utilizadas pelo mesmo, esta informação

está contida na tabela de reference data, a IA_SETTINGS.

Por fim, para a correta gestão de alterações efetuadas nas tabelas acima indicadas, o controlo de versões

recaí nas seguintes tabelas IA_ADMIN_MAIN, IA_COMMAND_TYPES, IA_AUDIT_ SCHEDU-

LING e IA_AUDIT_DEPENDENCIES 15.

23

3.3 Orquestrador

Através dos dados disponibilizados na base de dados (figura 15), o Orquestrador deve ser auto-suficiente

na interpretação dos mesmos e na sua correta implementação, procedendo apenas à sua execução aquando

o agendamento de cada auditoria e aquando a validação das suas dependências.

Por fim, após a execução de cada auditoria, deve registar toda a informação fulcral do período de execução

da mesma na base de dados (data de início de execução, duração, return code, etc).

O desenho de alto nível do Orquestrador (figura 16) evidencia pormenorizadamente o processo montado

para alcançar os requisitos atrás definidos. O Orquestrador foi então desenhado segundo um ciclo infinito

cuja referência de loop é a análise de novos processos a auditar.

Este módulo tem também como base um gestor de auditorias com a capacidade de criação do limite do

número de auditorias a executar em paralelo, de modo a fomentar a correta administração dos recursos

da máquina onde foi implementado.

O Orquestrador deve também ser capaz de analisar os detalhes de cada auditoria, ou seja, deve conseguir

controlar o seu tempo de execução, de modo a que este possa ser controlado. E, por outro lado, deve

também ser capaz de controlar o número máximo de tentativas na execução de uma determinada auditoria

(figura 17).

Início do processo Há tarefas a lançarNº processos

a correr dentro do aceitável?

Lança ProcessoProcesso

lançado com sucesso?

Lança processo filho

Obter listagem e sequência de

processos a lançar

Sim

Sim Sim

Não

Aguarda novo periodo de execução

Reagenda processo

Aguarda por vaga de execução

Não

Não

Processos são assíncronos.Processo pai só deve estar ciente de que foi possível lançar o processo filho.

Processo assincrono que

lida com a execução do

processo

Figura 16: HLD Orquestrador - Desenho de alto nível do orquestrador desenvolvido.

Todos os processos de auditoria devem gerar os seus outputs e guardá-los numa diretoria específica, de

modo a que sejam posteriormente indexados segundo a ferramenta utilizada no processo de Análise de

Resultados (o Splunk). Cada auditoria deve então disponibilizar a identificação da mesma, através de

um ID e do seu período de execução.

24

Regista erro de lançamento

Lança ProcessoInicio do Processo Filho Processo executado com sucesso?

Atingiu o número máximo de tentativas?

Sim

Não

NãoIncrementa o número de tentativas

Termina processo filhoRegista o return code de sucesso

do processo

10:00 10:30

Sim

Ocorrência do erro deve ser disponibilizado no processo de analise de resultados.

Figura 17: HLD Orquestrador - Desenho de baixo nível do orquestrador desenvolvido.

Todas as características de configuração do Orquestrador devem ser disponibilizados no arranque do

mesmo segundo um ficheiro de configuração (anexo B).

3.4 Tecnologias

Um dos problemas em ter muitas opções de escolha, no que toca ao sistemas de gestão de base de dados,

é que, às vezes, é difícil identificar qual delas pode ser a melhor ferramenta para colmatar as necessidades

específicas do projeto.

Neste caso particular, a escolha foi simples. A base de dados desenhada para este projeto foi desenvolvida

em Oracle Database, sistema de gestão de base de dados relacional (RDBMs) utilizado já à priori pela

equipa para a qual o projeto foi inicialmente idealizado, a NOPPIN da Vodafone PT.

Não obstante a Oracle Database ser o sistema de gestão de base de dados utilizado na Vodafone PT, é

também referida amplamente como um dos sistemas de gestão mais utilizados em todo o mundo. [9]

Assim, apesar da principal escolha, dita anteriormente, para este modelo ser feito em Oracle, é também

possível o seu escalamento a outras diversas empresas e entidades, que também usufruam do mesmo

sistema.

O código foi desenvolvido na linguagem C em máquina Unix, propriedade da Vodafone Portugal.

Um dos fatores decisivos para a linguagem C recaí na sua universalidade e portabilidade em várias

arquiteturas de computadores, sendo, para este projeto de desenvolvimento de sistemas operacionais, a

linguagem mais usada, uma vez que os próprios sistemas são também eles desenvolvidos em C.

25

Por outro lado, não menos importante, a linguagem C permite manter o desempenho, minimizando o

tempo de CPU e até o uso da memória necessária, fatores muito importantes para um projeto em que o

desempenho é um fator fulcral no sucesso do mesmo.

Um ponto negativo no desenvolvimento em C é a alocação de memória não dinâmica. Grande parte

do projeto requer operações à base de dados, na qual é necessário conhecer à priori o número e tipo de

dados a alocar, para consequentemente alocar os mesmos conforme a sua tipologia.

No entanto, a linguagem C fornece construções projetadas para estruturar e manipular a memória de

modo independente da máquina e eficiente para o programador.

Após a escolha do modelo de dados e da sua implementação, bem como da decisão da linguagem a ser

utilizada no Orquestrador, foi necessário encontrar uma Interface de Programação de Aplicação (API)

para fazer a conexão entre o código e a base de dados - a Oracle Call Interface (OCI).

3.5 Implementação

O Orquestrador foi desenhado como um ciclo while infinito, cuja primeira instância é identificar os novos

processos de auditorias passíveis de serem executados naquele exato momento. Para isso, é efetuada

uma pesquisa inicial à base de dados, onde é identificado o agendamento das auditorias a correr naquele

determinado momento e é então criada uma queue, denominada Audits Queue, com a identificação das

auditorias e respetivos períodos de execução ao qual queremos auditar.

Após o preenchimento da Audits Queue é necessário validar se existe uma vaga no número de processos

em paralelo a correr na máquina. Para isso, foi criado um array de identificadores do processos (PIDs),

cujo tamanho é um valor configurável pelos utilizadores, numa tabela de configurações do modelo de

dados, antes do lançamento do executável, identificando assim o número máximo de processos a correr

em paralelo na máquina.

Este array é criado com um valor de default e quando existe a necessidade de correr uma auditoria,

na posição disponível do array é inserido o PID do processo que irá correr a auditoria. Quando este

terminar, com ou sem sucesso, esta posição do array é libertada e disponibilizada para um novo processo

ocorrer.

Por outro lado, para a criação de uma lógica variável entre auditorias, presente, muitas vezes, no agen-

damento das mesmas, isto é, variáveis que depende do período de execução da auditoria, foi necessário

criar uma lógica de metastrings, explicada pormenorizadamente através de exemplos na demonstração

4.3. O Orquestrador aquando a identificação de uma metastring, executa uma lógica de manipulação de

resultados conforme a informação presente na base de dados e em chamadas ao sistema para, por fim,

conseguir obter a variável para o período de execução em causa.

Após a identificação de uma possível auditoria a executar e de uma vaga de execução, o processo deve

26

efetuar as devidas validações e construções da auditoria. Por fim, o processo cria um processo cópia

do mesmo, gerado com a função nativa C fork, o qual será responsável pela gestão e execução da

respetiva auditoria. É de notar que quando criamos um processo por meio da função fork, utilizamos a

nomenclatura de que esse novo processo é o processo filho e processo pai é aquele que usou a função fork.

Assim, após a distinção entre processos, o processo pai pode continuar a análise de uma outra auditoria

presente na queue, enquanto que o processo filho é responsável pela execução da auditoria específica,

conforme todos os parâmetro de gestão da mesma.

Para exemplificar, foi criada a figura 18, onde o processo pai cria cinco processos filhos, responsáveis

por executarem as respetivas auditorias, isto é, o processo pai permite que existam cinco auditorias em

paralelo a serem executadas em simultâneo na máquina, sem que haja relação ou interdependências entre

as mesmas.

Deste modo, o processo pai é responsável pelas gestão dos cinco processos filhos, e cada processo filho é

responsável pela execução e gestão da respetiva auditoria.

0

1 2 3 4 5

Figura 18: Fork - O processo pai cria tantos processos filhos, como o número máximo de processos em

paralelo disponíveis.

No código, houve também a necessidade de criar sinais. Sinais são uma técnica usada em C para notificar

um processo de que alguma condição ocorreu.

Neste caso específico, o Orquestrador necessitou da implementação de quatro tipos de sinais:

Sinais Utilizados

Sinal Utilidade

SIGCHLD Utilizado para identificar o término de uma chamada ao sistema

SIGALRM Utilizado para definir o tempo máximo de execução de uma auditoria

SIGINT Utilizado para identificar uma interrupção de chamada ao sistema, como é o caso do Ctrl+C

SIGKILL Utilizado para causar o término imediato de uma chamada ao sistema

27

Tabela 1: Tabela de sinais utilizados no Orquestrador.

Assim, com a correta implementação destes sinais e respetivos handlers [10], foi possível efetuar uma

gestão eficaz das auditorias e dos recursos da máquina, algo que não é possível fazer aquando a execução

das mesmas, por exemplo, numa crontab.

Por outro lado, o Orquestrador tem um ficheiro de logging, parametrizado no ficheiro de configuração

(em anexoB), no qual estão expostos todos os passos intermédios efetuados pelo Orquestrador.

Como referido anteriormente, todos os resultados das auditorias são enviados em formato csv para uma

diretoria específica, no qual o nome do ficheiro contem informação do ID do audit, do período de execução

e da data de execução da auditoria em causa.

Para conseguirmos efetuar a conexão entre o código e a base de dados, foi necessária a implementação

da API Oracle Call Interface da Oracle [7].

A Oracle Call Interface é uma interface de linguagem nativa C, abrangente e de alto desempenho para

conexão de sistemas e/ou aplicações personalizados com a Oracle Database.

Para efetuar esta conexão foi criado um ambiente OCI composto por:

OCIEnv Um identificador de ambiente cuja objetivo é definir um contexto

no qual todas as funções de OCI serão invocados. Cada identifi-

cador de ambiente contém uma cache de memória, o que permite

o acesso rápido à mesma. O identificador de ambiente é também

passado como parâmetro para a chamada HandleAlloc para alocar

outros tipos de identificadores.

OCIError O identificador de erro é passado como parâmetro na maioria das

chamadas OCI, de modo a validar em caso de erro, a sua razão

de existência segundo a chamada ao OCIErrorGet.

OCIAttrSet Função utilizada para definir um atributo específico de um descri-

tor ou identificador, é exemplo o user e password que irá iniciar a

sessão.

OCISessionBegin Chamada para iniciar a sessão com o servidor

OCIStmtPrepare Prepara uma instrução PL/SQL para posterior execução.

OCIStmtExecute Função que permite enviar instruções para execução no servidor.

Tabela 2: Ambiente Oracle Call Interface

28

A Oracle Call Interface (OCI) tem como ojetivo manipular os dados e esquemas de uma base de dados

Oracle, usufruindo de funções próprias em linguagem de programação C, sem ser assim necessária a

pré-compilação do código ou pré-processamento dos dados.

Em suma, Oracle Call Interface é uma interface de programação de aplicativos que permite criar pro-

gramas que utilizam chamadas de funções para aceder um servidor base de dados Oracle, de uma forma

rápida e eficaz.[1]

29

4 Avaliação

Nesta secção será apresentado um estudo comparativo entre os procedimentos habituais na criação e

manutenção de um processo de auditoria, na equipa de suporte à rede IN, da Vodafone PT.

Para um melhor entendimento, é necessário efetuar um contexto dos sistemas da rede IN da Vodafone

PT.

A rede IN acarreta um universo de cerca de nove milhões de clientes, pré-pagos e pós-pagos, assegurando,

principalmente, o correto funcionamento dos seus produtos e serviços, nomeadamente, a correta taxação

de todas as comunicações dos serviços acautelados.

Assim sendo, existem diversas bases de dados, com um período de retenção definido pela ANACOM

(Autoridade Nacional de Comunicações), cujo objetivo é guardar a informação única e particular dos

clientes, toda a informação dos seus produtos, bem como toda a informação consequente do universo das

comunicações dos clientes.

É assim imprescindível a existência de uma equipa de suporte à rede IN, capaz de auditar os seus

serviços, garantindo a qualidade e conformidade dos produtos e serviços oferecidos aos clientes, bem

como da satisfação dos mesmos.

4.1 Comparação de auditorias

Habitualmente, todos os colaboradores, como já dito anteriormente, no seguimento de reports de inci-

dentes, service request ou problemas, através de uma plataforma de ticketing, ou pela análise offline da

faturação de serviços, ou, até mesmo, pela proatividade destes mesmos colaboradores, produziam proces-

sos de auditoria, que executavam, ou diretamente no GUI da Oracle ou através de scripts customizados

que efetuam a conexão entre as bases de dados e o servidor.

Contudo, este processo habitual disruptivo, não permite controlar todos os processos de auditoria que

são executados na máquina, nem, por conseguinte, administrar cautelosamente a carga da mesma ou até

a evolução de utilização na base de dados Oracle.

Para além das conotações negativas, como deterioração da máquina, nomeadamente CPU e memória, ou

a deterioração da base de dados, existe a entropia proveniente de uma equipa de onze elementos, cujos

procedimentos atuais não pressupõe a criação de documentação com a origem da criação dos processos de

vigências. Por outro lado, não menos importante, apenas o auditor de um determinado processo, tinha

acesso aos resultados trabalhados do mesmo, pelo que, caso um outro membro da organização tivesse

interesse em conhecer os resultados, não tinha oportunidade de o fazer, não sendo requesitando-os ao

seu criador.

31

Ora, esta sinergia e, essencialmente, a falta de controlo, fez com que fosse indispensável criar um novo

modelo de execução de processos de auditorias, surgindo assim a realização desta dissertação.

Atualmente, existem diversos processos de auditoria ou processos de correções implementados na má-

quina, sem que se tenha conhecimento da justificação da sua existência. Esta falta de sinergia, criada

muitas vezes, pela proativamente e falta de documentação dos processos, fomenta a entropia nos mesmos.

Maioritariamente, muitas das auditorias, eram efetuadas diariamente com pesquisas ad hoc por cada

elemento da equipa. Assim sendo, admitindo um horário laboral das nove horas às dezoito horas, obtemos

o período de maior carga horária na máquina. Se este processo Orquestrador for considerado o gestor

da base de dados e dos recursos da máquina, conseguimos obter maior escalabilidade, aumentando o

número de pesquisas, sem lesar a carga da máquina ou deteriorar a base de dados.

Por outro lado, não menos importante, deixa de ser necessária a criação de novos scripts customizados,

permitindo a correta manipulação de dados variáveis, aumentando a produtividade dos colaboradores e

o tempo na criação de uma auditoria.

Habitualmente, para correr uma auditoria com dados variáveis, o auditor tinha duas hipóteses: ou

executava as alterações manualmente a cada vez que tinha um dado variável, no momento exato que

queria correr a auditoria, ou criava um script customizado, em que manipulava os dados de forma a que

estes variassem no momento exato do lançamento da auditoria.

Um exemplo prático e simples de um script customizado, em linguagem perl, é o seguinte:

#!/usr/bin/perl

my $atual_date = ‘date +%D‘;

my $partition =‘/in/bin/get_partition_name.pl -1d SIM‘;

my $partition1 =‘/in/bin/get_partition_name.pl -0d SIM‘;

my $queryGSSIN = "select $atual_date as DATE, a.sim_key as MSISDN,

b.vortex_string as VortexStringAtual,

a.vortex_string as VortexStringAnterior from sim partition ($partition) a

left join sim partition ($partition1) b on a.sim_key = b.sim_key

where length(b.vortex_string) = 6

and length(a.vortex_string) = 6

and to_date(b.vortex_string, ’ddmmyy’) < to_date(a.vortex_string, ’ddmmyy’)

and a.sim_key not in (

select SIM_KEY from wo_sim

where VORTEX_STRING is not null

and wo_user != ’corc’

32

and DATA > to_date(to_char(sysdate-1, ’yy.mm.dd’),’yy.mm.dd’)

)";

my $result = ‘/in/bin/SQL_query.pl "$queryGSSIN" andreia.alexandre\@vodafone.com

-s "WOP - $atual_date"‘;

Este script, permite correr, com uma chamada a um script interno da Vodafone PT, SQL_query.pl,

uma query PL/SQL definida com o parâmetro "my $queryGSSIN", com três dados variáveis: "my

$atual_date", "my $partition" e "my $partition1".

Após a execução deste script, o criador era notificado via e-mail com um ficheiro csv com o conteúdo de

todos os seus resultados. Em caso necessário, o auditor teria de exportar os dados para um ficheiro MS

Excel, de modo a conseguir trabalhar os resultados.

Neste momento, com o modelo de Auditorias IN, bastava criar uma auditoria na base de dados espe-

cífica (figura 15), com dados variáveis definidos pelas metastrings disponíveis, cuja entrada na tabela

IA_ADMIN_MAIN, no campo ADT_CMD_TEXT fosse o seguinte:

select $TIME_DELTA#%D#-0d$, a.sim_key as MSISDN, b.vortex_string as VortexStringAtual,

a.vortex_string as VTXAnterior from sim partition ($GET_PART_NAME#SIM#-1d$) a

left join sim partition ($GET_PART_NAME#SIM#-0d$) b on a.sim_key = b.sim_key

where length(b.vortex_string) = 6

and length(a.vortex_string) = 6

and to_date(b.vortex_string, ’ddmmyy’) < to_date(a.vortex_string, ’ddmmyy’)

and a.sim_key not in ( select SIM_KEY from wo_sim

where VORTEX_STRING is not null

and wo_user != ’corc’

and DATA > to_date(to_char(sysdate-1, ’yy.mm.dd’),’yy.mm.dd’))

Ora, os dados variáveis são substituídos pelas metastrings, da seguinte forma:

‘date +%D‘ -> $TIME_DELTA#%D#-0d$

‘/in/bin/get_partition_name.pl -1d SIM‘ -> $GET_PART_NAME#SIM#-1d$

‘/in/bin/get_partition_name.pl -0d SIM‘ -> $GET_PART_NAME#SIM#-0d$

O método utilizado pelo Orquestrador para validar as metastrings passa por uma chamada a um script

interno que com os dois parâmetros de entrada, nome da tabela a validar e período requerido, o que

retorna o nome da partição requisitada.

Por outro lado, esta auditoria tem dependências sobre o carregamento das tabelas cujas partições são

variáveis "my $partition" e "my $partition1". O auditor teria de conhecer o processo interno de car-

33

regamentos de dados e validar, à priori, se as tabelas já tinham sido carregadas, antes de executar a

auditoria.

Atualmente, com o Orquestrador, foi criado um processo que valida a veracidade do carregamento das

dependências. Deste modo, o auditor não necessita de conhecer o processo de carregamento interno de

dados, bastava inserir na tabela IA_AUDIT_DEPENDENCIES a seguinte informação:

• SIM_AVAILABLE - correlacionado com a dependência da partição definida na variável "my $par-

tition1"

• SIM_YESTERDAY_AVAILABBLE - dependência com a partição indicada na variável "my $par-

tition"

O Orquestrador valida as dependências e, só em caso afirmativo, é que a auditoria é executada. O

método utilizado para validar as dependências passa por uma chamada a um script interno que com os

dois parâmetros de entrada, nome da tabela a validar e período requerido, retorna zero ou um, em caso

de sucesso ou insucesso. Internamente, este script conecta-se à base de dados e valida se o carregamento

para aquela tabela e período já terminou.

Deste modo, o auditor não necessita de ter um conhecimento extenso de processos adjacentes, basta

inserir os dados a validar nas tabelas criadas para o efeito (figura 15.

Por fim, os resultados são todos enviados para uma diretoria específica e podem ser visualizados em

tempo real, através da ferramenta de visualização, o Splunk.

Por conseguinte, deixa de ser necessária a criação de scripts customizados, a correr na crontab da máquina,

o que denota a diminuição das linhas de código necessárias à correta execução de uma auditoria bem

como, resulta numa diminuição do tempo que o auditor demora a implementar uma auditoria e na

entropia criada na validação de resultados de uma auditoria.

4.2 Vantagens de um catálogo

O fator controlo é um dos elementos da equação mais importantes para uma organização. Tentou-

se efetuar um levantamento sobre todos os processos de auditoria na máquina de suporte à rede IN,

conseguindo produzir uma amostra de cerca de trinta processos de auditoria ativos na máquina, todos

eles criados em scripts customizados, cujo objetivo é efetuar uma ou mais queries às bases de dados

IN. Contudo, como já era presumível, não conseguimos acautelar o número de processos de auditoria

efetuados com pesquisas ad hoc ao sistema.

Por outro lado, no levantamento dos processos de auditoria na máquina, deparámo-nos com a falta de

documentação da razão pela qual foram criados, pelo que, muito provavelmente, existem processos que

desempenham um papel na carga da máquina, que podiam ser destituídos ou até melhorados.

34

Ora, ter a possibilidade, através da base de dados, de obter informação como a origem, o ID externo

(que pode inclusive ser o ID da workorder proveniente do sistema de ticketing), a descrição detalhada do

porquê da criação e de todas as alterações, o utilizador que criou a auditorias, todas as suas dependências,

é a grande mais valia para este projeto. Obter controlo e poder de visualização sobre todo o universos

de processos de auditoria a correr na máquina.

4.3 Demonstração

Para iniciarmos um processo de auditoria, necessitamos da correta implementação da informação na base

de dados. Seguem as seguintes imagens a exemplificar:

Figura 19: Tabela IA_ADMIN_MAIN preenchidas com auditorias de exemplo.

Figura 20: Exemplo da tabela IA_USERS com a respetiva relação com a IA_USER_CONTACT.

Na figura 19, temos a demonstração de cinco processos de auditoria em produção:

1. Através de queixas de clientes, foi detetado um erro no sistema, do qual não conhecemos a origem.

Este erro foi reportado ao fornecedor, o qual ainda não conseguiu obter uma resposta válida. Deste

modo, é necessário validar quais os clientes afetados e efetuar as devidas correções.

2. Verificou-se que existem serviços que não tem provisionado no seu perfil a taxa diária de utilização,

pelo que serve este processo de auditoria para averiguar os serviços afetados pelos issue e efetuar

as respetivas diligências.

3. Esta auditoria permite identificar os serviços, por cada tarifário, que tem provisionado no seu perfil

um determinado bundle.

35

4. Serve esta auditoria para validar os serviços que estão bloqueados com o Net Neutrality (princípio

de neutralidade, baseia-se no princípio de que todas as informações que geram tráfego na rede

devem ser tratadas da mesma forma).

5. No seguimento de queixas de cliente, foi identificado um erro na alteração de tarifário de bandas

largas móveis. Serve esta auditoria para validar os serviços afetados pelo erro.

O caso do script customizado evidenciado no módulo anterior (4.1) encontra-se agora implementado

como a auditoria com ID dois da tabela 19.

Nestes casos específicos, como ainda não existem alterações, a correlação entre as tabelas 19 e 20, gere-se

pelo campo ADT_OWN_USER_ID da tabela 19 e do campo ID_USER da tabela 20.

Figura 21: O agendamento das auditorias segundo a tabela IA_SCHEDULING em conformidade com

a parametrização na tabela IA_SCHED_PERIOD_UNITS.

No que toca aos agendamentos das auditorias acima referidas, estas estão definidas através das tabelas

na figura 22. Foi necessária a criação da tabela de reference data (RD) com os períodos ilegíveis para o

Orquestrador.

Deste modo, as auditorias um, três e cinco têm uma periodicidade diária (SCHED_PERIOD_UNIT_ID

é igual a quatro (figura 22), o que corresponde a "DAYS"na tabela de RD) desde o dia referido no campo

SCHED_START_DATE, ou seja, 1538722800 (cinco de outubro de dois mil e dezoito, às oito horas).

Analogamente, as auditorias dois e quatro têm uma periodicidade semanal, com início a 1538211600

(vinte e nova de setembro de dois mil e dezoito, pelas dez horas).

36

Figura 22: A implementação das dependências das auditorias na tabela IA_AUDIT_DEPENDENCIES.

Figura 23: Tabela IA_COMMAND_TYPES com os tipos de comandos a serem executados pela audi-

toria.

No que tocas às dependências, conseguimos averiguar, através da tabela 22 que a auditoria tem duas

dependências, com a tabela SIM e partições identificadas com as seguintes metastrings internas:

$NOW#%Y%m%d$

$DAYS_FROM_TODAY#-1day#%Y%m%d$

Figura 24: A tabela com as metastrings disponíveis - IA_METASTRINGS

Estas duas metastrings, atrás definidas, através do cruzamento entre a tabela 23 e a tabela 24 (cru-

zamento com a chave primária da tabela 23, ID_CMD_TYPE, e o campo MS_CMD_TYPE_ID da

tabela 24), são chamadas ao sistema do tipo /bin/date com os parâmetros indicados na coluna específica

MS_ARGUMENTS_FORMAT, ficando assim com os seguintes comandos:

/bin/date +%Y%m%d

/bin/date -d ’now -1day’ +%Y%m%d$

Após a execução destes comandos, o Orquestrador identifica assim as dependências das auditorias (tabela

e período).

O mesmo acontece, analogamente, para as restantes auditorias presentes na figura 22.

37

Figura 25: A tabela com configurações - IA_SETTINGS.

É de notar que, para identificar qual o caracteres nas metastrings, o Orquestrador utiliza as variáveis na

tabela 25, nomeadamente, caracteres de início e fim, bem como a caracteres que identificam as variáveis.

Por fim, o Orquestrador evidencia que tipo de auditoria está a ser efetuada (cruzamento entre o campo

ADT_CMD_TYPE_ID da tabela 19 e do campo ID_CMD_TYPE da tabela 23), o que evidencia que

serão executadas com um script interno, com os argumentos definidos na tabela 24. Internamente, o

Orquestrador manipula os argumentos e executa o comando no sistema operacional.

Após termos os nossos dados inseridos na base de dados, o Orquestrador é iniciado com o seu executável,

dando como input o ficheiro de configuração (anexo B):

./AuditsExecution AuditsAdmin.cfg

O processo é iniciado com a análise das auditorias presentes na base de dados e com o períodos de

execução passíveis de serem efetuados atualmente. É de referir que para esta análise, o Orquestrador foi

iniciado na data de seis de outubro de dois mil e dezoito, pelas dez horas e trinta e sete minutos.

Fazendo uma análise à base de dados e, tendo em conta a data de início do processo, ficamos com as

seguintes auditorias na Audits Queue pela ordem:

(Audit ID 2, ExecutionPeriod 1538816400) -> (Audit ID 3, ExecutionPeriod 1538809200) ->

(Audit ID 4, ExecutionPeriod 1538816400) -> (Audit ID 5, ExecutionPeriod 1538809200) ->

(Audit ID 1, ExecutionPeriod 1538809200)

O Orquestrador começa por analisar o primeiro elemento na Audits Queue, verificando se todas as suas

dependências são válidas, em caso afirmativo, prossegue para a interpretação de metastrings no comando,

caso existam, e, por fim, prossegue para a construção do comando final a executar para a determinada

auditoria.

Após a construção da auditoria, cria um processo filho que fica responsável pela gestão da auditoria.

Neste caso em particular, para a auditoria com ID igual a dois, o processo filho fica com um alarme de

sete mil e duzentos segundos num loop com valor máximo de duas tentativas de execução.

38

O método de execução de auditoria, nestes casos específicos, como auditorias do tipo query, é feita

através de um script interno, cujo objetivo é executar a auditoria na respetiva base de dados e enviar os

resultados para uma diretoria específica de resultados.

Enquanto o primeiro processo filho é iniciado, o processo pai insere a informação relevante da primeira

auditoria na Audits Queue na base de dados, tabela IA_EXECUTION_PROGRESS. De seguida, remove

o audit atrás analisado da queue e prossegue para a análise do próximo elemento da mesma.

O Orquestrador volta a validar as dependências desta nova auditoria, neste caso específico será a auditoria

com ID igual a três, faz a interpretação das metastrings, caso existam, e executa a construção do comando

a lançar. Cria um novo processo filho com a devida gestão dos parâmetros da nova auditoria e, prossegue

para o próximo elemento na queue.

Assim, após todos os elementos da Audits Queue terem sido lançados e encontrarem-se em progresso, a

tabela IA_EXECUTION_PROGRESS da base de dados tem o seguinte aspeto:

Figura 26: A tabela em progresso das auditorias - IA_EXECUTION_PROGRESS.

Por outro lado, enquanto as auditorias estão em progresso, o processo pai espera que existam novas audi-

torias para serem lançadas (tempo definido com o parâmetro ORCH_SLEEP_DURATION no ficheiro

de configuração, em anexo B), ou espera que um dos processos filho termine (sinal SIGCHLD, figura 1).

Caso um processo filho termine, o orquestrador limpa a informação presente na tabela IA_EXECUTION

_PROGRESS e complementa essa informação com a duração de execução e o resultado, inserindo-a na

tabela IA_EXECUTION_HISTORY.

Figura 27: A tabela histórico das auditorias - IA_EXECUTION_HISTORY.

Após todas as auditorias terem terminado, o log do Orquestrador teria o seguinte aspecto:

== Starting program ==

== 2018.10.06 10:37:19 : Audit ID 2 for execution period 1538816400 is going to start ==




39


== 2018.10.06 10:37:33 : No audits to execute - sleeping for 60 seconds ==


== 2018.10.06 10:39:25 : PID 4959 has ended with return code=0 ==



















(...)

Para o modelo de Auditorias IN (figura 14), os resultados das auditorias são armazenados numa diretoria

própria, cuja finalidade seria, aquando necessária, o input do Processo Centralizado de Correções, ou

input da ferramenta de visualização de resultados, o Splunk.

Figura 28: Directoria com as execuções de cada auditoria.

Por fim, os dados poderiam ser visualizados através da ferramenta de Splunk. Serve a imagem 29 para

exemplificar.

40

Figura 29: Ferramenta de visualização de resultados - Splunk.

41

5 Conclusões

Esta dissertação teve como grande objetivo propor e construir um modelo de auditorias que fosse de

encontro às necessidades específicas da equipa de suporte à rede IN, da Vodafone PT.

Após fazer o levantamento dos requisitos, foi desenhado e posteriormente implementado um modelo

de base de dados que pudesse satisfazer todas as necessidades que atualmente a equipa de suporte à

rede IN tem, como ainda foi idealizado um modelo que fosse facilmente escalável a outras equipas com

necessidades semelhantes de auditorias a sistemas.

Após implementada a base de dados, surgiu a necessidade de ter um modelo de Orquestrador, que

pudesse, de uma forma humildemente semelhante a uma crontab de sistema, efetuar a gestão e calenda-

rização das auditorias previamente inseridas na base de dados.

Este Orquestrador foi implementado em linguagem C e em máquinas Linux, de modo a que pudesse ser

facilmente implementado em outros sistemas idênticos.

Ao longo do desenvolvimento deste projeto foram evidenciadas fragilidades, não com razões que impeçam

o correto funcionamento do modelo, mas que eventualmente possam limitar a panóplia de utilizações do

mesmo.

5.1 Avaliação crítica

Durante a execução deste projeto foram evidenciadas fragilidades que podem a vir a ser colmatas com

a reestruturação da base de dados e do código. Nesta secção irá ser efetuada uma análise a cada uma

destas instabilidades do sistema e irá ser proposta uma nova solução para as mesmas.

1. Garantir que não há SQL Injection

Os ataques por injeção de SQL representam uma ameaça séria à segurança de aplicações.

No caso específico deste projeto, podemos sofrer desta vulnerabilidade, no que toca ao tipo de

injeção SQL através de inputs de utilizadores, podendo propositadamente desconstruir a base de

dados. [4]

Para a correção desta fragilidade, é sugerido o bind das variáveis através da API OCI da Oracle.

Deste modo, a informação dos dados e da query são enviados em separado para o servidor Oracle.

2. Ordenação da Queue dos Audits

O projeto atualmente desenhado, ordena a queue de auditorias passíveis de serem executadas,

segundo a prioridade definida na tabela IA_ADMIN_MAIN do modelo de base de dados, e sempre

inserindo as novas auditorias no final da queue.

43

Efetivamente, se idealizarmos que num determinado momento existe um número elevado de audi-

torias, superiores ao número de processos em paralelo possíveis de correr na máquina, em que a

sua prioridade é baixa, após lançarmos os primeiros x processos, na segunda pesquisa às auditorias

passíveis de serem executadas, se existir uma auditoria com maior prioridade que as restantes na

queue, esta será introduzida no final da mesma. Ora, apesar da prioridade ser superior às restantes,

uma vez que as restantes já estavam inseridas na queue, esta nova auditoria só irá correr após todas

as anteriores serem executadas.

Contudo, não poderíamos apenas ordenar a queue conforme a sua prioridade, pois, analogamente

ao caso anterior, cairíamos numa situação em que auditorias com prioridades muito baixas, muito

provavelmente, nunca iriam ser executadas, pois ficariam sempre no final da queue de execuções.

Assim sendo, a solução pertinente encontrada para este cenário era efetuar a ordenação conforme

a prioridade da auditoria e o período de tempo que já se encontra na queue. O objetivo seria então

criar uma reference data com a definição da prioridade da auditoria e do tempo limite de espera

em que esta pode ficar na queue de execuções.

3. Auditorias encadeadas

Um dos cenários pertinentes para o projeto é ter a capacidade de ter uma auditoria cuja de-

pendência se centra na execução de outra auditoria. Neste momento, este cenário é passível de

ser implementado efetuando a sua gestão através da calendarização sequencial de auditorias. No

entanto, seria interessante o Orquestrador ter a capacidade de correlacionar duas auditorias.

A solução proposta para este cenário é a adição de duas novas colunas na tabela IA_AUDIT

_DEPENDENCIES, uma coluna para identificar se estamos perante uma dependência interna

ou externa ao programa e, uma outra coluna, conseguirmos indicar o período delta de análise

de períodos de execução que queremos validar a dependência. Assim, seria possível efetuar uma

validação com dependência internas num determinado período temporal.

4. Dois sinais desencadeados ao mesmo tempo

No Orquestrador foi utilizada a função signal() para alertar o programa aquando a presença de

um sinal a ser despoletado, como é o caso, por exemplo, do término das auditorias, com o sinal

SIGCHLD.

Contudo, no manual Linux da função signal() podemos ler a seguinte indicação "Se várias instâncias

de um determinado sinal padrão forem entregues enquanto o sinal estiver bloqueado de momento,

apenas uma instância será inserida na queue."[2]

Ora, corremos o risco de várias auditorias terminarem ao mesmo tempo e apenas uma ser atendida,

fazendo com que os PIDs das restantes auditorias permaneçam no array de processos paralelos

válidos para serem executados, mesmo já não havendo evidência dos mesmos no sistema.

A sugestão de solução recaí então sobre ter um a função recorrente, executada em períodos regulares

de tempo, cuja finalidade é validar a veracidade do array de PIDs, validando se os PIDs ainda se

44

encontram a correr na máquina e, em caso negativo, efetuando a respetiva limpeza do mesmo no

array.

5. Interface de Programação de Aplicação - OCI

No decorrer do desenvolvimento do projeto, os diferentes módulos de gestão foram testados em

separado. Porém, aquando a execução dos módulos em conjunto, foi identificado uma fragilidade

com os handlers da API, no que toca a statements não sequenciais ao servidor. Quando era

efetuada uma determinada query ao servidor e quando, após identificação do primeiro resultado,

esta necessitava de efetuar nova pesquisa sobre aquele valor capturado, o Orquestrador reutilizava

o statement global, pelo que perdia o contexto de memória da pesquisa anterior.

Este cenário poderia ser facilmente corrigido se criássemos um ambiente OCI para cada módulo

de pesquisa. Porém, ao sobrecarregar a base de dados, com inícios de sessões temporárias e por

pesquisa, quanto maior fosse o número de auditorias, mais sobrecarregada ficaria a base de dados,

incorrendo numa deterioração da mesma.

Deste modo, o objetivo seria ter uma ambiente OCI global, que pudesse ser utilizado por todas as

relações à base de dados, o atualmente implementado, contudo com statements identificáveis em

cada query.

Assim, a solução proposta incide sobre ter variável global para identificar o último statement prepare

e uma variável local para identificar o statement da função localmente. Se, no momento de executar

a operação, estas duas variáveis fossem diferentes, teríamos de repetir a execução de prepare e então

só depois passaríamos à de execute.

Esta solução não seria a mais clara e eficaz, pelo que, se alterássemos a linguagem, provavelmente,

poderíamos encontrar outra API que já conseguisse criar novos statements por operação.

6. Base de Dados não dinâmica

A base de dados Oracle, atualmente desenhada para este projeto não pressupõe que possam existir

alterações no seu modelo de dados. Consoante o código implementado, todas as conexões da

API OCI da Oracle estão desenvolvidas hardcoded, uma vez que a linguagem utilizada para o

Orquestrador desenvolvido, pressupõe que seja conhecida à priori todas os tipos de variáveis a

alocar.

Deste modo, não há a possibilidade de alterar a estrutura do modelo de dados, sem que também

haja a necessidade de alterar o código implementado em conformidade.

A solução proposta para este cenário é a reestruturação do código implementado, é essencial en-

contrar uma linguagem menos vulnerável, cuja implementação esteja substancialmente orientada a

objetos.

45

5.2 Trabalhos futuros

Para além de ser necessária a correção das fragilidades acima mencionadas, será imprescindível adicionar

também ao Orquestrador a validação de que apenas só uma instância do mesmo se encontra a correr na

máquina, ou poderemos incidir na gestão incorreta dos recursos da máquina ou até mesmo na deterioração

da base de dados.

Por outro lado, no que toca à equipa de suporte à rede IN da Vodafone PT, atualmente este modelo já

foi aceite e encontra-se numa fase embrionária de utilização e testes, já em produção.

Para trabalhos futuros, será necessária a criação de um Painel de Administração, intuitivo para o utili-

zador, de modo que as novas funcionalidades core do Orquestrador e da sua correlação com o modelo de

dados, possam sobressair e serem evidenciadas ainda mais o seu âmago.

Para finalizar, e já numa perspetiva interna dos sistemas da rede IN na Vodafone PT, será necessário

implementar o Processo Centralizado de Correcções, que com a receção dos resultados finais do Orques-

trador, efetuará as devidas diligências e correções nos sistemas internos da organização.

46

Referências

[1] Rod Basapur, Mamata;Ward. Oracle Call Interface Programmer’s Guide, 18c. https://docs.

oracle.com/en/database/oracle/oracle-database/18/lnoci/index.html, 2018. [Online; ac-

cessed October-2018].

[2] Unix & Linux Forums. CentOS 7.0 - man page for signal (centos section 7). https://www.unix.

com/man-page/centos/7/signal/, 2013. [Online; accessed October-2018].

[3] Unix & Linux Forums. POSIX 1003.1 - man page for date (posix section 1p). https://www.unix.

com/man-page/posix/1p/date/, 2013. [Online; accessed October-2018].

[4] William G Halfond, Jeremy Viegas, Alessandro Orso, et al. A classification of sql-injection attacks

and countermeasures. In Proceedings of the IEEE International Symposium on Secure Software

Engineering, volume 1, pages 13–15. IEEE, 2006.

[5] Splunk Inc. O que é o Splunk? https://www.splunk.com/pt_br. [Online; accessed October-2018].

[6] Kevin Loney. Oracle Database 11g The Complete Reference. McGraw-Hill, Inc., 2008.

[7] Oracle. Oracle C and C++ Interfaces. https://www.oracle.com/database/technologies/

appdev/oci.html. [Online; accessed October-2018].

[8] Rodolfo Pedó Pirotti and Marcos Zuccolotto. Transmissão de dados através de telefonia celular:

arquitetura das redes gsm e gprs. Revista Liberato, Novo Hamburgo, 10(13):81–89, 2009.

[9] The Statistics Portal Statista. Ranking of the most popular database management sys-

tems worldwide, as of February 2018. https://www.statista.com/statistics/809750/

worldwide-popularity-ranking-database-management-systems/. [Online; accessed October-

2018].

[10] W Richard Stevens and Stephen A Rago. Advanced programming in the UNIX environment.

Addison-Wesley, 2013.

[11] Daniel Martins Geraldo Taborda. Auditoria–Revisão Legal das contas e outras funções do revisor

oficial de contas. 2ª Edição, Edições Sílabo–Lisboa. ISBN, 2015.

47

https://docs.oracle.com/en/database/oracle/oracle-database/18/lnoci/index.html

https://docs.oracle.com/en/database/oracle/oracle-database/18/lnoci/index.html

https://www.unix.com/man-page/centos/7/signal/

https://www.unix.com/man-page/centos/7/signal/

https://www.unix.com/man-page/posix/1p/date/

https://www.unix.com/man-page/posix/1p/date/

https://www.splunk.com/pt_br

https://www.oracle.com/database/technologies/appdev/oci.html

https://www.oracle.com/database/technologies/appdev/oci.html

https://www.statista.com/statistics/809750/worldwide-popularity-ranking-database-management-systems/

https://www.statista.com/statistics/809750/worldwide-popularity-ranking-database-management-systems/

A IN Audits - Inquérito

Q1 - Com que frequência é que sente necessidade de criar novos processos de análise aos serviços IN OCS

e IN SI? (Entenda-se o acrónimo IN OCS como a abreviatura de Intelligent Network - Online Charging

System e, analogamente, IN SI como Intelligent Network - Internal Services.)

Q2 - Classifique a sua perceção do atual esforço de implementação de uma auditoria isolada?

Q3 - Uma vez que o processo atual de criação de auditorias implica, maioritariamente, a utilização de

linguagens de programação, sente que esta necessidade é uma fonte de entropia no processo?

Q4 - Classifique o grau de confiança que sente na correta implementação de um processo de auditoria,

tendo em conta a passível introdução de erros no desenvolvimento?

Q5 - Se a criação de processos de auditoria fosse passível de ser implementada através de uma ferramenta,

sem necessidade de desenvolvimento de lógicas particulares para o processo, classifique de 1 a 5 a sua

perceção do quão melhor iria ser a sua experiência na criação destes processos de análise?

Q6 - Classifique o grau de dificuldade que a complexidade dos processos atuais de alimentação de dados,

impõem na clara compreensão da orquestração necessária para uma correta execução de uma determinada

análise?

Q7 - Atendendo à sua resposta na questão anterior, se a ferramenta anteriormente mencionada lhe

indicasse quais as dependências da análise a efetuar, classifique o ganho que anteciparia na redução de

erros, decorrentes de uma incorreta calendarização da execução?

Q8 - No processo atual de criação de auditorias, sente que tem conhecimento de todos os processos de

auditorias existentes, assim como das correspondentes calendarizações e dependências?

Q9 - Classifique o grau de dificuldade que sente quando necessita de confirmar a correta operacionalização

de uma ou mais auditorias? Entenda-se por "operacionalização"como a execução de uma auditoria sem

erros, independentemente do resultado ser o esperado.

Q10 - Suponha que tem de desabilitar um atual processo de análise em produção. Classifique a confiança

que tem na execução desta tarefa, sabendo que a incorreta alteração desse processo, muito provavelmente,

implicaria a não execução de outras auditorias.

Q11 - Se a ferramenta lhe proporcionar a garantia que a edição que está a fazer só afeta uma determinada

auditoria, classifique o ganho de confiança, face à sua resposta na pergunta anterior.

Q12 - Com que frequência é que sente necessidade de rever os processos de auditoria criados, tendo em

consideração a revisão dos requisitos?

Q13 - Por experiência pessoal, já teve conhecimento de algum processo de análise que tenha inviabilizado

49

a execução de outros processos ou que tenha deteriorado a performance dos sistemas que o orquestram?

Q14 - Atendendo à sua resposta na questão anterior, se lhe fosse disponibilizada uma ferramenta na qual

era possível controlar o tempo máximo de execução e o número máximo de tentativas de execução de

um processo de auditoria, classifique de 1 a 5 a mais valia que se teria no controlo e gestão dos recursos?

Q15 - Por experiência pessoal, houve algum processo de análise que não tenha sido executado, ou que

tenha, mas de forma incompleta, por inerência a alterações não documentadas do próprio ou dos processos

que o orquestram?

Q16 - Classifique a mais valia que advinha da implementação de uma ferramenta com controlo de versões

e documentação associada.

Q17 - Na sua opinião, a forma como são atualmente anunciados os resultados dos processos de auditorias

vai de encontro às suas necessidades?

Q18 - Com que frequência é que necessita de trabalhar os resultados das auditorias hoje implementadas?

Q19 - Atendendo à sua resposta à pergunta anterior, se existisse um modelo de Auditorias IN que lhe

disponibilizasse uma ferramenta de visualização de resultados que permitisse uma fácil comparação entre

execuções do mesmo audit, assim como a visualização de tendências de evolução, classifique de 1 a 5, o

ganho que advinha do trabalho que hoje emprega na manipulação de resultados?

Q20- Se lhe fosse disponibilizada uma ferramenta de visualização de resultados com a capacidade de

monitorização de resultados e capacidade de criação de alarmística com definição de thresholds, classifique

de 1 a 5, o ganho que teria na perceção de comportamentos irregulares e na rápida resposta aos mesmos.

50

Respostas ao inquérito

Inquiridos Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20

1 4 3 Sim 2 5 5 5 1 4 2 5 4 Sim 5 Sim 5 Não 4 5 5

2 4 3 Sim 3 5 4 5 1 4 2 5 3 Sim 4 Sim 5 Sim 4 5 5

3 3 4 Não 3 5 4 5 2 3 4 3 3 Não 3 Sim 4 Não 4 5 5

4 4 4 Não 4 4 3 4 1 3 2 5 3 Sim 4 Sim 5 Sim 2 5 5

5 4 3 Sim 4 5 4 5 3 3 3 5 4 Sim 5 Sim 5 Sim 2 4 5

6 4 4 Sim 4 5 4 5 3 3 3 3 4 Sim 5 Não 4 Não 5 5 5

7 4 4 Sim 3 5 5 5 2 4 3 5 2 Sim 5 Sim 5 Sim 3 5 5

8 2 3 Sim 5 5 4 5 1 4 3 4 3 Sim 5 Sim 4 Não 3 5 5

9 3 3 Não 3 4 3 4 3 3 3 4 3 Sim 4 Sim 4 Não 3 4 4

10 4 4 Sim 3 5 4 4 3 4 3 5 4 Não 5 Não 5 Não 4 5 5

11 4 4 Sim 4 4 4 4 2 4 2 4 2 Não 4 Não 4 Não 3 4 4

12 4 4 Sim 4 5 3 5 2 3 3 5 3 Sim 5 Sim 4 Sim 4 5 5

13 2 4 Não 4 5 4 5 2 3 3 4 3 Sim 4 Sim 5 Não 4 5 5

14 3 4 Sim 4 5 4 5 1 5 2 5 2 Sim 5 Sim 5 Não 2 5 5

51

B IN Audits - Ficheiro de Configuração do Orquestrador

###################################################################################

#

# This f i l e conta in s the parameters c o n f i g u r i n g the Audit Administrator p r o c e s s e s .

#

# S e n s i t i v e parameters that can ’ t appear in c l e a r t ex t ( password , f o r example )

# should be encrypted by EncryptConfig .

#

###################################################################################

#

# L i s t o f eMail that must r e c e i v e the alarms

#

ALARM_EMAILS=andre ia . alexandre@vodafone . com

#

# Local f o l d e r s .

#

# Direc tory where p r o c e s s e s s t o r e temporary & log f i l e s .

WORK_DIR=/in /IN_Audits/ l o g s

#

# Database connect ion data .

#

AUDITS_DB_NAME=GSSINDB

AUDITS_DB_USER=in_audits

AUDITS_DB_PWD=pass123

#

# Parameter i zab le v a r i a b l e s .

#

LOG_PERIOD_SECONDS=86400

ORCH_SLEEP_DURATION=60

###################################################################################

52

AndreiaFilipaPinheiroInácioAlexandre IN.pdfcolega e aluno do IST, Bruno Cheganças, pelo apoio e...

Documents

Transcript of AndreiaFilipaPinheiroInácioAlexandre IN.pdfcolega e aluno do IST, Bruno Cheganças, pelo apoio e...