Análise Técnica Sistema RH Alagoas

Relatório de Análise Técnica
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. SEGESP AL – Secretaria de Estado da Gestão Pública da
.
.
.
.
.
. Alagoas
.
.
.
.
. ANÁLISE DE SEGURANÇA DO SISTEMA INFORMATIZADO
.
.
.
. DE RECURSOS HUMANOS - ELÓGICARH
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008

.
.
.
.
.
.
.
.
.
. RELATÓRIO DE ANÁLISE TÉCNICA
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ATENÇÃO
.
.
.
.
.
.
.
. As informações existentes neste documento e em seus anexos são para uso restrito da SEGESP – sendo seu sigilo
.
. protegido por lei. A leitura e publicação indevidas poderão causar perdas materiais, financeiras e de vantagem
.
. competitiva. Caso não seja destinatário, saiba que sua leitura, divulgação e cópia são proibidas. O uso impróprio
.
.
.
. será tratado pela legislação em vigor, por acordos de sigilo e pelas normas internas da Módulo e da Organização
.
. contratante dos serviços
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. São Paulo
.
. Av. Eng. Luis Carlos Berrini, 550 - 5º andar
.
. Brooklin - São Paulo - SP
.
. CEP: 04571-000
.
.
.
.
Tel/Fax: (+11) 5504-3600
.
.
.
.
.
. Rio de Janeiro
.
.
.
.
Rua da Quitanda, 106 Centro
.
. 20091-005 - Rio de Janeiro - RJ
.
. Pabx: (+21) 2206-4600
.
. Fax: (+21) 2206-4720
.
.
.
.
.
.
.
. Brasília
.
. SCN, Quadra 5, Bloco A
.
. Centro Empresarial Brasília Shopping and Towers
.
. Torre Norte, sala 918
.
. Brasília - DF
.
.
.
.
CEP: 70.715-900
.
. Tel: (+61) 3218-7500
.
. Fax: (+61) 3218-7506
.
.
.
.
.
.
. Nova Iorque
.
. 52 Vanderbilt Avenue - 14th floor
.
.
.
.
New York, N.Y. 10017
.
. Tel.: (212) 609-0340
.
. Cel.: (973) 563-2402
.
.
.
.
.
.
.
.
.
.
.
.
.

MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 2/22

.
.
.
.
.
.
.
.
.
. RELATÓRIO DE ANÁLISE TÉCNICA
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sumário
.
.
.
.
.
. CENÁRIO ............................................................................................. 4
.
.
.
. OBJETIVO ........................................................................................... 5
.
.
.
. ESCOPO DA ANÁLISE TÉCNICA DE SEGURANÇA ................... 5
.
.
.
. ANÁLISE DE SEGURANÇA .............................................................. 5
.
.
.
. AUDITORIA E MONITORAMENTO ELETRÔNICO ................................................... 6
.
. CONTAS E SENHAS .......................................................................................... 6
.
. CONTROLE DE ACESSO .................................................................................... 9
.
. CRIPTOGRAFIA .............................................................................................. 11
.
.
.
. COMUNICAÇÃO DE DADOS .............................................................................. 13
.
. IDENTIFICAÇÃO E AUTENTICAÇÃO ................................................................... 14
.
. PRIVILÉGIOS DE USUÁRIO............................................................................... 17
.
. TOLERÂNCIA A FALHAS .................................................................................. 17
.
. DOCUMENTAÇÃO ........................................................................................... 18
.
.
.
. CONCLUSÃO ..................................................................................... 20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.


RELATÓRIO DE ANÁLISE TÉCNICA

CENÁRIO
Em 1996 o Estado de Alagoas terceirizou a operação do seu Sistema Integrado de RH, denominado
ElógicaRH para a Elógica S/A, fornecedora do sistema, que se manteve como prestadora desta
terceirização até o início de 2007. A operação reiniciou a ser operada pelo funcionalismo público no início
de 2007, através da passagem do sistema e de seus processos para a SEGESP.

Ao fim do prazo contratual original, se seguiu um período de meses durante os quais as partes
negociaram novos termos e condições para a prorrogação contratual por 12 meses e o encerramento da
operação do sistema pela Elógica, com a transferência da referida operação para o funcionalismo do
Estado, mediante treinamento apropriado.

Durante a transição e operação do sistema ElógicaRH, foram identificados erros e comportamentos no
sistema que expunham informações sensíveis como senhas de usuário administrador do banco de dados
do sistema, permitindo e criando um meio de acesso a usuários não autorizados. Estas descobertas
foram relatadas ao fornecedor, ao qual foram solicitados os ajustes e acertos necessários para que
fossem sanadas.

Diversas medidas foram tomadas em busca da solução dos problemas encontrados mas, conforme
descrito pela SEGESP, apenas alguns foram resolvidos.

Este relatório tem o propósito de apresentar um parecer técnico com base na análise dos resultados
alcançados face às melhores práticas de mercado.

A análise foi baseada em normas e melhores práticas para o Desenvolvimento de Sistemas e Segurança
da Informação, a saber, ISO 15408 Common Criteria.



OBJETIVO
Realizar uma análise técnica de segurança no Sistema Informatizado de Recursos Humanos utilizado pela
SEGESP AL, denominado ElógicaRH, e realizar testes para a comprovação da ocorrência dos erros no
sistema que expõem o usuário e senha do administrador.

Este relatório descreve com a verdade, e com todas as circunstâncias, o que foi observado.

ESCOPO DA ANÁLISE TÉCNICA DE SEGURANÇA
Para efeito desta análise foram considerados somente os ativos diretamente relacionados com o Sistema
Informatizado de Recursos Humanos – ElógicaRH, conforme apresentado a seguir:

• Servidor de Aplicação – 10.10.0.1;

• Servidor de Banco de Dados 01;

• Servidor de Banco de Dados 02.

ANÁLISE DE SEGURANÇA
Foi realizada uma análise de segurança no Sistema Informatizado de Recursos Humanos – ElógicaRH, de
forma criteriosa, com o objetivo de identificar as possíveis falhas de segurança através da não aplicação
e/ou aplicação incorreta dos controles de segurança recomendados pelas normas internacionais e que
na sua ausência podem propiciar o acesso não autorizado, manipulação indevida, perda, divulgação e
não rastreabilidade das informações no Sistema ElógicaRH.

O resultado da análise de segurança é apresentada a seguir.



Auditoria e Monitoramento Eletrônico

As informações sensíveis, confidenciais e valiosas são os mais prováveis alvos de ataques e tentativas de
ataque. Todos os sistemas que possuam informações deste tipo devem ser configurados para registrar
acessos e alterações em dados sensíveis mantidos pela aplicação, pois a falta de um mecanismo de
auditoria torna bem mais difícil a tarefa de identificar a ação e responsabilizar o autor, introduzindo a
falta de rastreabilidade.

• Referências: Common Criteria: FAU_GEN.1, FDP_ACF.1, nível básico.

Resultado da Análise

Não foi identificado qualquer tipo de mecanismo e/ou registro de auditoria no

Sistema Informatizado de Recursos Humanos – ElógicaRH em uso pela SEGESP.

Contas e Senhas

A tentativa de quebra de senha por força bruta é, de forma geral, o primeiro método testado por um
atacante, pois é de simples aplicação e pode gerar resultados significativos. Para evitar este tipo de
ataque, utilizam-se medidas passivas (métrica da senha, troca periódica de senha) e medidas ativas
(bloqueio após um determinado número de tentativas com falha).

• Referências: Common Criteria: AVA_SOF.1, FIA_SOS.1, FIA_UAU.3, FIA_AFL.1, FMT_SAE.1,
FIA_ATD.1, FTA_TSE.1, FPT_TSM.1.


Apos vários teste não foi observada a exigência de métricas que definam a

complexidade mínima da senha e da troca da senha.



Não houve bloqueio da senha mesmo apos várias tentativas de autenticação

com uso de senha errada.

As senhas do sistema devem ser armazenadas cifradas de forma irreversível pelo sistema, o que pode
ser obtido através do uso de algoritmos e funções de "hash", que convertem, de forma irreversível a
informação em um dado pequeno, ou seja, o dado apenas pode ser transformado de texto para cifrado,
mas não pode ser decifrado para o texto original. O uso de "hash" garante que sequer o administrador
do banco de dados conheça as senhas do sistema. Esta estratégia evita problemas de ataque oriundo do
pessoal interno, ataques de invasores que consigam ganhar acesso ao banco de dados e problemas
legais quanto a responsabilização dos usuários mal intencionados das aplicações, evitando que aleguem
que a senha era de conhecimento de outros dentro da organização.

• Referências: Common Criteria: FIA_UAU.3


Foram identificados senhas de acesso aos banco de dados armazenadas sem

nenhum tipo de criptografia na tabela TBSRV conforme evidência abaixo, na

coluna SENHADB.



(Observar que o usuário PRODFP possui a senha r0u553au, armazenada em

texto claro).

Quando são executadas tarefas que realizem acesso ao banco de dados,

identificamos que as senhas não possuem qualquer tipo de criptografia no

arquivo de texto C:/RHcexecucao_DLL.LOG, conforme evidências abaixo: (Foi

utilizado o usuário PRODFP com a senha TESTE123).



A criação da senha pelo pessoal interno permite que os mesmos possam se fazer passar pelos usuários ,
indevidamente, ao utilizarem o sistema. Este modelo de criação de senhas também impede a
responsabilização do usuário autêntico por eventual uso indevido do sistema, visto que outras pessoas
conhecem sua senha. Assim a aplicação deve ser desenvolvida de forma que exista um mecanismo de
escolha da senha para os novos usuários sem a interferência do pessoal interno.

• Referências: FIA_SOS.2, FMT_MOF.1, FMT_SMR.1.


Não foram identificados mecanismos de escolha de senha para os novos

usuários. As senhas são criadas pela equipe de suporte do sistema e informadas

aos usuários finais.

Controle de acesso

Sistemas web, "web services" e outros são baseados em protocolos sem sessão, ou seja, cada solicitação
de informações ao servidor é independente da outra. Isso implica em que os dados acessados na
primeira solicitação sejam inacessíveis às demais solicitações. Neste tipo de sistema é importante que o
controle de acesso seja verificado em cada página e em cada informação apresentada, pois os
parâmetros de chamada ou links podem ser manipulados muito facilmente. Assim o controle de acesso
em sistemas distribuídos que utilizem protocolos sem sessão, como http, deve ser verificado a cada
evento.

• Referências: Common Criteria: FPT_TDC.1, FPT_RVM.1, FPT_SSP.1, FTP_TRP.1, FTP_ITC.1.


Por não termos acesso ao código fonte do sistema, não foi possível determinar a

implementação correta e adequada deste controle.



Em sistemas multicamadas, cada camada interposta gera maior possibilidade de contorno dos
mecanismos de acesso. Por exemplo, a verificação dos direitos de acesso na camada de apresentação,
ou seja, na camada mais próxima ao usuário, possibilita que este possa depurar ou alterar
deliberadamente tal camada. Quanto mais próximo dos dados, menor a possibilidade de quebra ou
contorno dos mecanismos de controle de acesso, ou seja, o controle de acesso é tão mais eficaz quanto
mais próximo dos dados for implementado. Assim, em sistemas multicamadas, o controle de acesso
deve ser feito na camada mais próxima possível dos dados.

• Referências: Common Criteria: AVA_CCA.1, FDP_ACF.1, FDP_ACC.1, FDP_IFC.1, FDP_IFF.1,
FPT_TDC.1, FPT_RVM.1.



implementação correta e adequada deste controle.

O sistema de controle de acesso deve ser aplicado diretamente nos dados armazenados, indicando
direitos para cada usuário ou grupo, o que pode ser implementado incluindo uma lista de controle de
acesso ou outra forma discricionária de controle de acesso.

• Referências: Common Criteria: FDP_ACC.1, FDP_ACF.1.



implementação correta e adequada desta recomendação.



O controle de acesso deve ser uniforme em todo o sistema, utilizando-se uma única rotina de verificação
no sistema, evitando inconsistências relacionadas aos direitos de acesso aos objetos da aplicação, ou
seja, garantindo que as alterações na política de controle de acesso fiquem efetivas em todo o código.
Esta recomendação também facilita a auditoria de códigos maliciosos, pois qualquer condição para
controle de acesso, fora do padrão, é automaticamente inválida.

• Referências: Common Criteria: FDP_ACC.1, FDP_ACF.1, FPT_TDC.1, FPT_RVM.1.




O controle de acesso independente do código do sistema, fora do contexto do usuário logado, evita que
este possa depurar o mecanismo de implementação, alterando seu comportamento e obtendo acesso
privilegiado indevido. Também evita que a rotina de verificação seja executada com direitos do usuário
final do sistema. Isto, em última análise, permitiria que o usuário tivesse algum direito sobre a tabela de
direitos de acesso. Assim o controle de acesso deve ser realizado por componente isolado do sistema.

• Referências: Common Criteria: FDP_ACC.1, FDP_ACF.1, FPT_SEP.2, FPT_TDC.1, FPT_RVM.1.




Criptografia

Algoritmos proprietários, desenvolvidos internamente, geralmente são facilmente vulneráveis a ataques
por criptoanálise. De fato, os algoritmos públicos seguros, RSA, DES, 3DES, IDEA, etc., são escolhidos
justamente por serem insusceptíveis a estes ataques. Desta forma os algoritmos de criptografia



utilizados no sistema para a proteção de dados sensíveis e senhas dos usuários devem ser baseados em
padrões reconhecidos do mercado.

• Referências: Common Criteria: FCS_CKM.1, FCS_CKM.2, FCS_COP.1.


Não foi identificada a utilização de criptografia para a proteção de dados

sensíveis ou senhas, conforme a evidencia abaixo na qual o nome e senha do

usuário que conecta a aplicação ao banco de dados são expostas:



Comunicação de dados

Interfaces desprotegidas entre um sistema e outros são pontos vulneráveis que podem ser explorados
por um atacante. Para evitar que a visualização indevida, ou mesmo, que ocorra manipulação dos dados,
deve-se cuidar para que os dados estejam protegidos quanto à confidencialidade e à integridade na
comunicação entre sistemas. Assim o sistema aplicativo deve ser desenvolvido de forma que os dados
enviados para outros sistemas sejam protegidos contra quebra de confidencialidade no trajeto.

• Referências: Common Criteria: FCS_CKM.1, FCS_CKM.2, FCS_COP.1.


A comunicação entre o servidor de aplicação e os bancos de dados é realizada

através do protocolo padrão SQL sem criptografia, como também a

comunicação entre o cliente web HTTP com o servidor de aplicação, da mesma

forma, ocorre sem criptografia, conforme as evidências abaixo:



Identificação e autenticação

As credenciais coletadas do usuário (login e senha) precisam ser enviadas para o mecanismo de
autenticação, e o resultado da autenticação (a autorização ou chave de sessão) deve ser devolvido por
este. Um ataque simples consiste em interceptar uma autenticação correta e obter a chave de sessão ou
gravar os dados trafegados entre cliente e servidor e, em seguida, enviar novamente estes dados
obtendo como resposta uma chave de sessão válida. Um caso particular ocorre quando as credenciais
são enviadas em claro para o servidor, o que, evidentemente, torna este ataque ainda mais simples.
Assim a senha deve ser verificada por meio de mecanismo que impeça fraudes de repetição,
interceptação ou quebra de integridade na comunicação entre o cliente e o servidor.

• Referências: Common Criteria: FIA_UAU.3, FIA_UAU.4.






A comunicação com servidores e outros componentes do sistema, em particular quando esta
comunicação passa por redes sem o devido controle, ou por servidores intermediários de terceiros, pode
levar a desvios de rota, conduzindo as informações a um sistema que simule a outra parte da
comunicação, possibilitando a obtenção ou alteração indevida de informações. Assim todos os demais
componentes do sistema devem ser autenticados pelo aplicativo antes da comunicação em sistemas
distribuídos.

• Referências: Common Criteria: FTP_ITC.1, FTP_TRP.1.


Não foram identificados mecanismos que garantam a autenticação dos

componentes do sistema antes da comunicação.

O usuário ou atacante pode alegar desconhecer o caráter legal e confidencial das informações ao acessar
o sistema. A exibição de uma mensagem de advertência durante a autenticação tem como propósito
deixar claro que o sistema em questão pertence à empresa e é de uso restrito pelos usuários
autorizados, informando também que os acessos serão gravados em registros de auditoria (logs).

A mensagem também ajuda a aumentar a consciência dos usuários sobre a importância da segurança
das informações armazenadas no sistema e de sua responsabilidade sobre a segurança. Do ponto de
vista legal, é recomendável deixar claro que o uso do sistema ou serviço é restrito e que o acesso
indevido poderá ter conseqüências. Desta forma, uma mensagem de advertência precisa ser exibida aos
usuários durante a autenticação no sistema.

• Referências: Common Criteria: FTA_TAB.1


Não foram observadas tais mensagens de advertência durante o processo de

logon dos usuários ou em qualquer outro momento do uso do sistema.



Após a autenticação do usuário, deve ser apresentada a data e a hora da última autenticação bem
sucedida e se houve falhas de autenticação desde então. Este controle permite que o usuário identifique
se houve algum acesso indevido a sua conta, pois ele pode confrontar a hora do último acesso bem
sucedido indicado com seu último acesso real. O usuário poderá também identificar se houve tentativas
mal sucedidas de acesso a sua conta, pois na eventualidade dele mesmo ter errado a senha, saberá disto
e poderá confrontar a informação.

• Referências: Common Criteria: FTA_TAB.1


Durante o processo de autenticação, não foi observada a apresentação da data

e hora da última autenticação bem sucedida ou de tentativas de logon mal

sucedidas desde então.

Mensagens trocadas entre sistemas ou internamente ao sistema, entre seus diversos componentes,
podem estar sujeitas a posterior negação de sua autoria. O caso mais típico é o usuário que altera uma
informação sensível no sistema e depois nega ter feito esta alteração. Este tipo de repúdio pode ocorrer
entre instituições e mesmo entre equipes em uma mesma empresa, provocando constrangimentos ou
conseqüências piores. Assim o sistema aplicativo deve ser desenvolvido de forma que as transações
críticas do sistema possuam mecanismos que identifiquem inequivocamente sua autoria.

• Referências: Common Criteria: FCO_NRO.1, FCO_NRR.1, FTP_ITC.1, FTP_TRP.1.


Não foram identificados quaisquer tipo de mecanismo e/ou registro de auditoria

que identifiquem a autoria das ações e transações críticas no sistema.



Privilégios de usuário

Em sistemas utilizados por vários usuários, é importante adotar um prazo de validade do privilégio de
acesso, para evitar que os usuários mantenham tais privilégios após terem sido movidos de área ou
quando desligados da empresa ou ainda, quando o gestor da área é substituído. Assim os privilégios do
usuário devem ser configurados para expirar periodicamente, sendo necessário requisitar renovação.

• Referências: Common Criteria: FMT_SAE.1, FMT_MOF.1, FMT_MSA.1.


Não foram identificadas funcionalidades de expiração de contas no sistema.

Tolerância a falhas

O sistema aplicativo deve ser desenvolvido de forma a possuir capacidade de tolerância a falhas e
retorno à operação. Falhas de hardware, de software, de sistemas de comunicação e do usuário são
eventos esperados, em maior ou menor grau, na vida útil de qualquer sistema. Estes incidentes podem
provocar paralisações indesejáveis nas operações no negócio, causar retrabalhos, constrangimentos
junto a clientes, e outras conseqüências indesejáveis. O sistema deve portanto, ser dotado de recursos
que garantam os aspectos básicos de segurança, como a confidencialidade e a integridade dos dados
críticos, e quaisquer outros aspectos de segurança importantes. Deve-se também buscar o retorno do
sistema a um estado seguro e operacional no menor tempo possível.

• Referências: Common Criteria: FPT_PHP.1, FPT_PHP.2, FPT_FLS.1, FPT_RCV.1, FDP_ROL.1.


Não foram identificados no sistema funcionalidades ou características de

arquitetura que garantam a alta disponibilidade da aplicação ou do banco de



dados.

Por não termos acesso ao código fonte do sistema, não foi possível determinar

se existem controles no banco de dados e na aplicação que garantam a

integridade das informações em caso de falha de hardware e software, tais

como funções que verifiquem os parâmetros de entrada e o retorno das funções

chamadas internamente e controles de transação em banco de dados (Begin

Trans, Commit, rollback).

Documentação

A especificação de um sistema documenta os requisitos do mesmo e sua arquitetura básica, e deve ser
produzida durante o planejamento. Um planejamento ineficaz acarreta problemas na arquitetura da
segurança do sistema, com ausência de funções de controle de segurança necessárias para o
atendimento aos objetivos de segurança. Portanto, é importante que todas as necessidades de
segurança específicas sejam avaliadas, consideradas e formalizadas na especificação do sistema. Além
disto, esta documentação será útil para o aceite do sistema e para futuras auditorias de segurança. A
documentação deve possuir as características abaixo:

Os objetivos e especificação da segurança no projeto do sistema;

As principais ameaças ao sistema;

A legislação e as normas de segurança pertinentes ao sistema;

Uma estratégia para atingir cada objetivo de segurança indicado;

Um manual do administrador contendo informações de segurança;

Descrição de quais partes do código do sistema aplicativo, caso alteradas, exigem revisão da
segurança;



Um manual do administrador contendo procedimentos para o caso de incidentes ou falhas de
segurança;

Os requisitos de arquitetura e implementação para o atendimento de cada objetivo de
segurança;

Os testes mínimos necessários para garantir que os objetivos de segurança estão atendidos no
sistema;

Os procedimentos de instalação e configuração do sistema aplicativo ressaltando os aspectos
de segurança.

• Referências: Common Criteria: ADV_FSP.1, ADV_HLD.1, ADV_RCR.1, Classe ASE, CEM 1.0.


Não foi apresentada documentação que possua as características descritas

acima, ou parte delas.



CONCLUSÃO
Iniciamos o trabalho colhendo as experiências vividas na operação diária do sistema ElógicaRH instalado
e operado pela SEGESP. Junto a este trabalho, buscamos informações sobre a empresa desenvolvedora,
a Elógica, através do site oficial da empresa (http://www.elógica.com), com o intuito de compreender o
tempo existência da empresa, do software e o grau de maturidade em desenvolvimento e fornecimento
de soluções para Recursos Humanos e Administração de Pessoal.

Trata-se de uma empresa que relata ter mais de 30 anos de atuação em TI, possuindo uma equipe
composta por 130 colaboradores e algumas centenas de clientes. O sistema ElógicaRH está instalado em
sua versão 16 na SEGESP, demonstrando que, desde 1996, o sistema passa por um processo evolutivo.

Entendemos então, que as credenciais fornecidas pela empresa ao mercado associam os seus produtos a
um alto nível de qualidade e garantia de segurança, dada a experiência relatada.

O sistema atende a área de Recursos Humanos e Administração de Pessoal, lidando com informações
confidenciais e pessoais. Por estas características, o sistema atende a áreas extremamente cautelosas
quanto a divulgação das informações por elas custodiadas e que, se divulgadas, podem trazer
repercussões de diversas ordens e prejuízos às partes envolvidas, como o constrangimento por
exposição de informações pessoais, e ações legais contra a empresa usuária do sistema.

Ainda no que tange a área de Administração de Pessoal, toda a folha de pagamento da empresa é
controlada pelo sistema ElógicaRH, significando que a confiabilidade dos dados do sistema é uma
característica fundamental. Os salários dos funcionários são controlados pelo sistema desde o seu
cadastramento até o envio dos arquivos de pagamento aos bancos.

Espera-se que a empresa fornecedora de um sistema com tais atribuições exerça um controle de
qualidade com forte foco em segurança das informações, garantindo que seus clientes não sejam
expostos a riscos oriundos de sua operação.

Entretanto, através de análise criteriosa no sistema ElógicaRH, dentro dos limites impostos pela falta do
acesso ao código-fonte, foi-nos possível identificar que:

O sistema expõe credenciais de acesso do usuário administrador do banco de dados (usuário e
senha) em mais de um ponto.

o Seja por uma falha de arquitetura de aplicação, por uma definição para o
desenvolvimento de sistemas ou por um descuido ou falta de zelo de sua equipe, estas



informações não podem ser expostas pelo sistema. Desta forma ferem-se os preceitos de
confidencialidade dos dados armazenados no sistema.

O sistema armazena, em texto claro, as credenciais de acesso ao banco de dados.

o Desta forma, o sistema permite que usuários mal intencionados façam acessos indevidos
com credenciais de acesso de administrador do sistema.

O sistema não possui um registro de transações em formato de log, que permita a identificação
dos passos executados pelos usuários.

o Não é possível recompor as ações executadas pelos usuários nem tampouco identificar as
alterações efetuadas no sistema ou nos dados pelos usuários.

O sistema não oferece claramente características de alta disponibilidade.

o Esta característica é fundamental quando se administra o pagamento de funcionários de
uma instituição. A indisponibilidade do sistema, seja por uma falha de hardware ou
software, traz prejuízos a empresa cliente e a seus funcionários.

Lembramos que a Módulo Security Solutions não é especializada em Recursos Humanos ou
Administração de Pessoal mas sim especializada em Segurança da Informação, com larga experiência em
Contingência e Continuidade de Negócios, Gestão de Riscos, Governança de Segurança, Governança de
TI, Leis e Regulamentações, entre outras. Este relatório não aborda as funcionalidades do sistema mas
apenas suas características de segurança observáveis ao armazenar e lidar com as informações.

Ante o exposto neste relatório, somos levados a concluir que o sistema ElógicaRH não atende às
características esperadas de um sistema que se propõe a atender as áreas de Recursos Humanos e
Administração de Pessoal. Mesmo possuindo as funcionalidades necessárias para a execução destas
atividades, em diversos pontos pudemos observar que informações que deveriam ser resguardadas e
acessadas apenas pelos usuários gestores e administradores do sistema eram disponibilizadas aos
usuários normais enquanto operavam o sistema.

É sabido que a melhor forma de se implementar segurança é durante o planejamento e concepção da
solução. Assim, todos os mecanismos agirão de forma proativa, dentro de cenários previamente
visualizados pelos arquitetos da solução. O que observamos durante a análise indica que o



desenvolvimento do sistema não adotou esta prática e que o seu controle de qualidade não capturou e
sanou as falhas apresentadas, ainda existentes no sistema.

As exposições de senha e falhas encontradas no sistema ElógicaRH propiciam um ambiente de grande
risco para a empresa contratante. Neste cenário, pessoas mal intencionadas podem facilmente e sem
deixar traços de suas atividades, alterarem dados, modificarem informações sensíveis e exporem
informações confidenciais.

Todo este cenário se traduz em um alto risco operacional para a SEGESP, uma empresa pública, usuária
do sistema avaliado e a todos os funcionários suportados pelo sistema.


Análise Técnica Sistema RH Alagoas

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (15)

Semelhante a Análise Técnica Sistema RH Alagoas

Semelhante a Análise Técnica Sistema RH Alagoas (20)

Análise Técnica Sistema RH Alagoas