Buscar

Segurança Auditoria de Sistemas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 108 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 6, do total de 108 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 9, do total de 108 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

ISBN 978-65-5821-129-7
9 786558 211297
Código Logístico
I000600
Segurança e auditoria 
de sistemas 
Wagner Mendes Voltz
IESDE BRASIL
2022
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
© 2022 – IESDE BRASIL S/A. 
É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito do autor e do 
detentor dos direitos autorais.
Projeto de capa: IESDE BRASIL S/A. Imagem da capa: geen graphy/Shutterstock
 Blue Andy / shutterstock 
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
V899s
Voltz, Wagner Mendes
Segurança e auditoria de sistemas / Wagner Mendes Voltz. - 1. ed. - 
Curitiba [PR] : IESDE, 2022.
104 p. : il.
Inclui bibliografia
ISBN 978-65-5821-129-7
1. Computadores - Medidas de segurança. 2. Proteção de dados. 3. 
Centros de processamento de dados - Auditoria. 4. Centros de processa-
mento de dados - Medidas de segurança. I. Título.
22-76762 CDD: 005.8
CDU: 004.056
Wagner Mendes Voltz Especialista em Administração com ênfase em 
Gestão da Tecnologia da Informação pela Faculdade 
de Administração e Economia (FAE). Graduado em 
Tecnologia em Informática pela Universidade Federal 
do Paraná (UFPR). Atua como professor desde 
2012 e como analista de sistemas desde 2005. Tem 
experiência na área de ciência da computação com 
ênfase em metodologia e técnicas de computação. 
Ministra as disciplinas de Programação Orientada 
a Objetos, Desenvolvimento em Java com Testes 
Unitários, Desenvolvimento em Java Web, Padrões de 
Projeto, Desenvolvimento em Android, Qualidade de 
Código-Fonte, Metodologias Ágeis, Gestão da Qualidade 
em Projetos e Sistemas Operacionais.
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
SUMÁRIO
1 Auditoria de sistemas da informação 9
1.1 Fundamentos da auditoria de sistemas da informação 10
1.2 Técnicas para auditoria de sistemas 18
1.3 Plano de contingência e de recuperação de desastres 22
2 Execução de auditorias 31
2.1 Auditoria de controles 31
2.2 Auditoria de sistema 36
2.3 Auditoria de hardware 45
2.4 Auditoria de controle de acesso 53
3 Segurança de sistemas da informação 58
3.1 Conceitos e princípios fundamentais da segurança 59
3.2 Risco, ameaça e vulnerabilidade 67
3.3 Família de normas ISO 27000 73
4 Modelos de maturidade para segurança da informação 79
4.1 SSDLC e modelo SAMM 80
4.2 Área de negócio: governança 88
4.3 Área de negócio: design 91
4.4 Área de negócio: implementação 94
4.5 Áreas de negócio: verificação e operação 96
 Resolução das atividades 102
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
Você já parou para pensar como é o mundo atual? 
Será que uma decisão de um país asiático pode influenciar 
a sua vida no Brasil? Será que uma nevasca nos EUA pode 
afetar o seu dia a dia? E como você consegue ter acesso a 
todas essas informações? Pois é, boa parte do mundo está 
conectada a uma grande rede de troca de informações 
(internet) e utilizamos computadores e aparelhos móveis, 
como smartphones e tablets, para ficarmos conectados a ela. 
São milhões de dispositivos acessando à internet ao 
mesmo tempo e cada um deles utiliza um conjunto de 
hardware e software para realizar o acesso. Mas será que esses 
dispositivos são seguros? O hardware e o software deles estão 
sem vulnerabilidades? Quanto às informações que as pessoas 
estão acessando, será que elas são íntegras, confidenciais e 
estão disponíveis? Como garantir que tudo esteja seguro? 
As respostas para essas perguntas serão respondidas neste 
livro, por meio do estudo de como é realizada uma auditoria 
de sistemas e de como são aplicados conceitos de segurança 
em ambientes computacionais.
Esta obra foi preparada para proporcionar uma experiência 
teórica e prática, ou seja, se você trabalha em uma empresa 
de tecnologia da informação, poderá aplicar, no seu dia a dia, 
os questionários e conteúdos propostos.
Nesta jornada, apresentaremos os conceitos de auditoria 
e como aplicá-los na área de sistemas da informação. Você 
aprenderá que o trabalho de um auditor de sistemas da 
informação envolve conhecer diversas normativas regulatórias, 
assim como áreas computacionais, como hardware, software 
e controles de acessos. Esses temas serão apresentados 
nos Capítulos 1 e 2. A partir dos Capítulos 3 e 4, o foco será 
em como desenvolver um sistema de gestão e segurança 
da informação (SGSI) orientado a normas internacionais ISO 
27000 e a SAMM. 
APRESENTAÇÃOVídeo
8 Segurança e auditoria de sistemas
Esperamos que, após a leitura, você seja capaz de aplicar uma auditoria 
em sistemas da informação e consiga iniciar a implantação de um SGSI em um 
time que trabalha com software. E aí, animado para esta aventura?
Bons estudos!
Auditoria de sistemas da informação 9
1
Auditoria de sistemas 
da informação
Em nosso dia a dia, as pessoas se relacionam com diversos outros 
indivíduos e interagem com vários aparelhos tecnológicos. Ao reali-
zar uma compra no comércio, é criado um relacionamento chamado 
cliente – fornecedor. Ainda, ao pagar um boleto, cria-se outro relaciona-
mento, denominado sacado – sacador. Esse conjunto de interações entre 
uma pessoa e os demais elementos é chamado de sistema e, quando esse 
sistema (ou parte dele) está em um meio digital, como computadores e 
smartphones, ele é intitulado sistema de informação.
Todo sistema deve seguir um processo, a fim de torná-lo produtivo e 
eficiente. Alguns deles têm as suas normas estabelecidas pelo governo 
em forma de lei, enquanto outros dispõem de normas estabelecidas 
por órgãos competentes no tema. A ação de verificar se os processos 
estão em conformidade é intitulada auditoria e, quando esse processo 
está focado na análise de conformidade de hardware, software e redes, é 
chamado de auditoria de sistemas de informação.
Neste capítulo, traremos os fundamentos que compõem o tema 
auditoria de sistemas de informação, bem como as técnicas para aplicar 
essa auditoria. Por fim, abordaremos os meios de elaboração de um plano 
que garanta a manutenção dos sistemas de informação, caso aconteça 
um desastre, como o ataque hacker. 
Com o estudo deste capítulo, você será capaz de:
 • conhecer as bases que alicerçam o tema auditoria de sistemas;
 • descrever as principais técnicas para executar o processo de au-
ditoria de sistemas;
 • detalhar o que é um plano de contingência e de recuperação de 
desastres e entender como criá-lo.
Objetivos de aprendizagem
10 Segurança e auditoria de sistemas
1.1 Fundamentos da auditoria de 
sistemas da informação Vídeo
Um sistema é composto de um conjunto de elementos que se 
inter-relacionam. Em alguns casos, ele possui diversos subsistemas, 
como é o caso do corpo humano, com os sistemas circulatório, respi-
ratório, urinário, entre outros. Logo, um sistema pode ser facilmente 
compreendido quando é constituído por poucos elementos de rela-
cionamento. Quando existe um novo elemento querendo se relacionar 
com o sistema, este pode vir a ser um novo subsistema, tornando o 
primeiro mais complexo e confuso de se entender.
Uma empresa, por exemplo, pode ser considerada um sistema, pois 
fazem partedela as pessoas que atuam como colaboradoras, os pró-
prios sistemas digitais (softwares), os aparelhos (hardware) utilizados 
para acessar os softwares e os processos de trabalhos. Todos esses ele-
mentos se relacionam, a fim de entregar valor ao cliente. Além disso, a 
empresa cria relações com outras empresas, mediante a terceirização 
de serviços, não nos esquecendo do relacionamento entre a empresa 
e os seus clientes. 
Nesse sentido, toda empresa que utiliza computadores e softwares 
pode ser um potencial consumidor dos serviços de auditoria de siste-
mas de informação; já quando é a produtora de softwares, o trabalho 
de auditoria é ampliado, para atender às especificações de como se 
criar um software.
Para Imoniana (2013, p. 17), “a filosofia de auditoria em tecnolo-
gia de informação está calcada em confiança e em controles internos. 
Estes visam confirmar se os controles internos foram implementados e 
se existem; caso afirmativo, se são efetivos”.
Como mencionado, o trabalho de auditoria serve para validar se os 
processos estão sendo executados conforme o definido e, caso não 
estejam, a pessoa auditora precisa recomendar quais ações devem ser 
executadas para normalizar o processo. 
Se, em algum ponto da auditoria, for identificada a inexistência de 
um processo para determinada situação, cabe ao auditor recomendar 
tanto a definição quanto a implantação de um dado processo que possa 
ser auditável e seguro. Por exemplo, um auditor identificou que não 
Auditoria de sistemas da informação 11
existe controle de acesso à sala dos servidores da empresa. Sem esse 
controle, as informações da empresa podem ser roubadas, bem como 
os sistemas de rede e servidores danificados, tudo sem a identifica-
ção de quem praticou as ações. O auditor deve descrever essa situação 
como de risco e sugerir a adoção de um controle eletrônico de acesso 
ao servidor, que evidencie a hora de ingresso e quem entrou na sala. 
A adoção de um sistema de acesso por meio da biometria já transforma 
essa não conformidade em um processo definido e rastreável.
No exemplo citado, percebe-se que a empresa corre um grande risco, 
pois, em uma sala de servidores, há diversos computadores que custam 
milhares de reais, além de dados sigilosos que podem ficar vulneráveis. 
Caso essas informações sejam modificadas ou até sequestradas, o dano 
gerado pode ser incalculável para a imagem da empresa.
O processo de auditoria tem por objetivo gerar a segurança no uso 
dos computadores e dos softwares utilizados por uma organização. 
Além disso, visa elevar a qualidade dos processos da empresa e, assim, 
maximizar a performance das operações, promovendo a melhora do 
custo-benefício relativo aos altos investimentos comuns às áreas de TI.
A auditoria de sistemas de informação não se trata de uma ativida-
de recente, pois teve início em meados de 1960, quando as empresas 
começaram a ter computadores e softwares próprios.
As primeiras auditorias seguiam os modelos e processos existentes 
na época e, com o passar do tempo, houve a necessidade de 
especializá-las segundo as diversas áreas da TI. No quadro a seguir, 
está um resumo das especializações pelas quais a auditoria de siste-
mas passou ao longo dos anos.
Quadro 1
Histórico da auditoria de sistemas de informação
Intervalo de ano Foco da auditoria Áreas auditadas
1998-2001 Operações da área de TI
 • Microinformática.
 • Segurança física.
 • Segurança lógica.
 • Redes locais.
2002-2003 Sistemas de informação
 • Sistemas informatizados de 
departamentos.
 • Administração do centro de servi-
ço de informática.
(Continua)
12 Segurança e auditoria de sistemas
Intervalo de ano Foco da auditoria Áreas auditadas
2004-2005 Gestão de TI
 • Administração da infraestrutura 
de TI.
 • Gerência e desenvolvimento orga-
nizacional de TI.
 • Administração de banco de dados.
 • Administração de sites.
2006-2008
Auditoria baseada nas 
áreas de conhecimento 
de TI.
 • Administração de redes.
 • Administração de dados.
 • Gestão do ciclo de vida de siste-
mas de informação.
 • Gerência de mudanças.
2009-2011
Baseada em processos, 
conforme normas 
internacionais.
 • Processos definidos no Cobit.
 • Governança de TI.
 • Garantia da segurança de sistemas.
 • Gestão de investimentos em TI.
2011 - atualmente
Adição de auditoria em 
ambientes distribuídos, 
como nuvem (cloud).
 • Gestão de ambientes distribuídos, 
em especial nuvem.
Fonte: Elaborado pelo autor.
Conforme o Quadro 1, pode-se perceber que, com o passar dos anos, 
novas áreas da tecnologia foram sendo auditadas. Isso aconteceu em 
razão dos diversos avanços da tecnologia. Com relação aos processos 
de auditoria, raramente eles são descartados; a abordagem é sempre 
a de adotar novos temas, sem se esquecer dos anteriores, sendo que 
as demais abordagens passam a ser tratadas como camadas. Com a 
continuidade das auditorias, a empresa vai avançando nessas camadas 
e desenvolvendo processos de TI mais maduros. 
Para realizar o trabalho de auditoria de sistemas de informação, é preciso co-
nhecer os seus princípios. São eles:
• a auditoria não deve ser baseada em opiniões ou avaliações pessoais;
• a auditoria deve apresentar imparcialidade e ser pragmática;
• todo elemento em um sistema pode ser auditável e estar conforme ou 
não conforme uma situação ideal; 
• o auditor deve se basear em evidências (fatos e registros) que possam ser 
consultadas ao longo do tempo.
Quando a auditoria é feita em sistemas computacionais, à medida 
que é executada, muitos processos podem ser automatizados. Ao se 
Auditoria de sistemas da informação 13
finalizar a automatização de um item, a empresa passa a ter um novo 
patamar de segurança, aumentando a governança na TI. Um exemplo 
de automação é a adoção da prática intitulada DevOps. 
DevOps é o nome dado ao trabalho de automatizar a entrega de um 
software. Ele é constituído por um conjunto de técnicas e ferramentas 
que envolve desde o versionamento do código-fonte do software até a 
sua disponibilização para os clientes utilizarem. Em alguns lugares, esse 
trabalho é manual e sem rastreabilidade. Quando o DevOps é adotado, 
é possível entregar versões de software de modo rastreável, repetiti-
vo, sem falhas e auditáveis. Segundo Humble e Kim (2018), empresas 
que adotam o DevOps apresentam menores taxas de bugs em seus 
produtos e conseguem entregar diversas versões por dia, tratando-se 
de um diferencial competitivo na prestação de serviço. Logo, conforme 
é reduzido o time-to-market, ou seja, o tempo gasto no processo de 
desenvolvimento de algo até chegar ao cliente, é possível vender mais 
e gerar maior satisfação para o cliente.
Planejar
La
nç
ar
 ve
rs
ão
Disponibilizar
Op
er
aç
ãoMonitoramento
Testa
r
Construir
Pro
gra
ma
r
Ph
ak
aw
an
 W
on
gp
et
an
an
/S
hu
tte
rs
to
ck
Figura 1
Ciclo DevOps de trabalho 
O trabalho de auditoria pode ser realizado por uma ou mais pessoas 
e o número necessário vai depender do tamanho da organização. 
Esses profissionais podem ser colaboradores da própria empresa ou 
mesmo funcionários terceirizados que prestarão o serviço. Em ambos 
os cenários, é importante que a pessoa auditora tenha as seguintes 
competências e valores:
14 Segurança e auditoria de sistemas
 • Ética: a conduta do profissional de auditoria deve ser íntegra e de 
aderência ao código de ética profissional definido pelas associa-
ções de auditores de tecnologia da informação. 
 • Sigilo, privacidade e confidencialidade: o profissional de audi-
toria lida com informações que podem ser estratégicas para uma 
organização e cabe a ele mantê-las sob sigilo e confidencialidade.
 • Independência profissional: o auditor de tecnologia da informa-
ção deve ser independente, deixando transparecer tal postura 
nas suas atitudes e no seu comportamento. 
 • Planejamento: o auditor deve saber planejar as suas atividades 
para atingir o seu objetivo.
 • Pragmático e observador: o auditor deve ser prático e com 
abordagem baseada em evidências.• Criação de apresentações coerentes: as conclusões devem ser 
baseadas em fatos e os relatórios devem ser precisos.
 • Bom relacionamento (diplomacia): o auditor deve ter um bom 
relacionamento em todas as esferas da organização e evitar 
atritos pessoais.
 • Domínio sobre o tema: a auditoria pode ser realizada por meio 
de diversas técnicas e métodos e o auditor deve dominá-los. 
A constante atualização de conhecimento, referente aos modelos 
de auditoria, e a vivência das técnicas fazem com que o profissional de 
auditoria se desenvolva e atenda às expectativas das empresas. Com 
base nessas informações, pergunta-se: como o auditor faz o seu traba-
lho? A resposta para essa dúvida é dividida em quatro pontos:
 • entender o contexto e delimitar o escopo de trabalho;
 • definir um ou mais tipos de auditorias que serão realizadas;
 • estabelecer uma ou mais abordagens de auditoria;
 • definir a organização do trabalho.
Para que a auditoria alcance o resultado esperado, é necessário 
entender o contexto do cliente e deixar claro quais são os limites do 
trabalho. Ao delimitar o escopo de atuação, as expectativas ficam ali-
nhadas e o cliente recebe o serviço contratado. 
Para exemplificar a importância desse ponto, vamos imaginar que 
um auditor externo tenha sido contratado para auditar o sistema de fo-
lha de pagamento desenvolvido pela empresa. Ao receber essa deman-
Auditoria de sistemas da informação 15
da, o profissional não delimitou o escopo de atuação e foi direto para as 
validações dos itens previstos. Ao finalizar o trabalho, o auditor entrega 
o relatório final à diretoria, que questiona o documento por não ha-
ver evidências de auditoria sobre o controle de acesso aos servidores 
cloud. Essa informação é importantíssima, pois o software de folha de 
pagamento tem informações sigilosas e se encontra disponível na web.
Conclui-se, então, que o auditor não realizou a validação sobre o 
controle de acesso aos servidores cloud porque imaginou que o tra-
balho era somente referente aos processos de programação e de 
versionamento do código-fonte. Ao entregar a auditoria incompleta, 
a diretoria solicitou que o documento fosse refeito, não efetuando o 
pagamento por esse retrabalho, uma vez que o erro foi do consultor. 
Esse pequeno cenário demonstra como pode ser grave a entrega 
de um trabalho que não está alinhado com o cliente, podendo gerar a 
insatisfação e o prejuízo para ambas as partes. 
Após delimitar o escopo, é importante definir quais tipos de audito-
ria serão realizados, podendo ser selecionados um ou mais tipos. 
O quadro a seguir traz uma lista de auditorias.
Quadro 2
Tipos de auditoria
Tipo de auditoria Objetivo
Auditoria durante o desenvolvimento de 
sistemas.
Auditar todo o ciclo de construção do 
software, desde a sua concepção até a 
disponibilização em produção.
Auditoria de sistemas em produção.
Auditar todo o ambiente de produ-
ção e como o software se comporta 
nesse ambiente.
Auditoria no ambiente tecnológico.
Auditar a infraestrutura, as redes, os 
acessos e a governança de TI.
Auditoria em eventos específicos.
Auditar uma situação específica, como 
um ataque hacker.
Fonte: Elaborado pelo autor.
Os tipos de auditoria mencionados no Quadro 2 podem ser execu-
tados internamente, por uma empresa especializada ou por um órgão 
certificador, e cada atividade tem um nome em específico, conforme o 
quadro a seguir.
16 Segurança e auditoria de sistemas
Quadro 3
Responsáveis pela auditoria
Tipo de auditoria Responsáveis
Auditoria de primeira parte
É a auditoria realizada por uma equipe 
interna da organização.
Auditoria de segunda parte
É a auditoria realizada por uma equipe 
externa, a fim de certificar a integrida-
de. Por exemplo, um cliente quer vali-
dar se o fornecedor está aderente a um 
processo específico.
Auditoria de terceira parte
É a auditoria realizada por um órgão 
certificador oficial, por exemplo: órgão 
certificador ISO 27001.
Fonte: Elaborado pelo autor.
Na sequência, o auditor precisa definir a abordagem de trabalho 
a ser aplicada, para gerar o relatório final de auditoria. O profissional 
pode usar uma ou mais abordagens, sendo que a mais efetiva é aque-
la cujo auditor entende o contexto do cliente e consegue selecionar a 
opção que traz mais benefícios. As abordagens são:
 • Comparação do cenário atual com os critérios de auditoria: 
é analisada uma lista de itens, comparando com o cenário atual 
da empresa. Cada item é marcado como “em conformidade”, 
mediante evidências. Já os itens não aderentes devem ser 
marcados pela auditoria como “não conformes” e conter o deta-
lhamento dos motivos para a não conformidade.
 • Baseado em critérios oficiais: acontece a auditoria com base 
em alguma documentação oficial, como a ISO 27001 ou o Cobit. 
 • Ao redor do computador: não existe o envolvimento de 
muita tecnologia. O foco maior é em processos e tudo o que 
está em volta do parque tecnológico. Então, “essa abordagem 
envolve custos baixos” (IMONIANA, 2013, p. 19).
 • Por meio do computador: “envolve mais do que a mera 
confrontação de documentos-fonte”, de acordo com Imoniana 
(2013, p. 20). Aqui, são utilizados dados de testes para simu-
lação, e o auditor precisa de maior conhecimento acerca do 
processo de desenvolvimento e entrega de software.
 • Com o computador: é realizada a auditoria do sistema de 
informação pelo auditor, segundo os processos automatiza-
dos, garantindo maior cobertura de itens auditados, já que 
em processos manuais algum item pode ficar esquecido. 
Auditoria de sistemas da informação 17
Chegamos, então, ao último passo, que é a organização do tra-
balho de auditoria. Já houve a delimitação do escopo de trabalho 
e a definição dos tipos de auditoria e de quais abordagens serão 
utilizadas. Agora, é necessário organizar o trabalho para que nada 
seja esquecido. Para isso, é preciso cumprir as seguintes atividades:
 • planejar;
 • escolher a equipe;
 • programar a equipe;
 • executar os trabalhos e supervisionar;
 • validar o relatório final.
Na atividade de planejamento, desenha-se a matriz de risco. 
Essa matriz é atualizada gradativamente, à medida que a auditoria 
é executada. Nessa lista ficam evidentes quais são os itens em não 
conformidade e que estão colocando a empresa em risco. Além 
dessa matriz, a atividade de planejamento prevê o mapeamento da 
sequência de atividades a ser realizada. Essa sequência servirá de 
insumo para determinar o cronograma de trabalho e a quantidade 
de horas investida para gerar um relatório final. 
Com o total de horas definido, é possível dimensionar a equipe 
de trabalho necessária para realizar a auditoria em tempo aceitá-
vel. A escolha da equipe é a segunda atividade da organização do 
trabalho, devendo-se comparar o tamanho do desafio com a expe-
riência de cada auditor. 
A terceira atividade é a programação da equipe. O líder desse 
time de auditores irá, diariamente, validar a programação de ati-
vidades e distribuir novas tarefas, de acordo com as atividades 
correntes finalizadas. O acompanhamento da execução de traba-
lho é considerado a quarta atividade da organização; conforme os 
itens são finalizados, os relatórios são produzidos e a matriz de 
risco é preenchida. Com a conclusão de todas as atividades, o time 
de auditoria deve validar o relatório final e apresentá-lo à empresa. 
A reunião de apresentação costuma envolver pessoas de 
influência, para que os itens em não conformidade sejam prioriza-
dos. A decisão sobre qual item terá prioridade deve ser tomada por 
essas pessoas, bem como a definição de um prazo para a conclu-
são do item não conforme. Para finalizar a reunião, é estipulada 
uma nova data de auditoria e o processo é realizado.
No vídeo Fundamentos 
de auditoria de sistemas, 
disponível no canal 
Sidney Verginio da Silva, 
o professor apresenta os 
pilares de fundamento à 
auditoria de sistemas de 
informação. 
Disponível: https://www.youtube.
com/watch?v=U9q8Fk7sEjs&ab_
channel=SidneyVerginiodaSilva.Acesso em: 3 jan. 2022.
Vídeo
18 Segurança e auditoria de sistemas
Vale dizer que seguir os fundamentos da auditoria garante que 
os benefícios dessa prática sejam alcançados, tornando a empresa 
envolvida mais madura ao entregar os softwares.
1.2 Técnicas para auditoria de sistemas 
Vídeo
O processo de auditoria de sistemas de informação pode ser reali-
zado por meio de técnicas variadas. Segundo Imoniana (2013, p. 54), as 
técnicas têm por objetivo auxiliar o profissional a auditar 100% de de-
terminado tema e podem ser executadas utilizando a voz, as imagens, 
os documentos ou até os processos automatizados.
Ao aplicar, pelo menos, uma técnica de auditoria, o processo se torna 
mais produtivo e com custo operacional reduzido, gerado pelo retraba-
lho. Além disso, quando se aplica uma técnica, a qualidade é assegurada 
e o valor agregado é garantido. Assim, Imoniana (2013, p. 54) descreve 
em quais tarefas as técnicas de auditoria podem ser aplicadas:
 • Testes de controle gerais: um exemplo é validar se as versões 
aprovadas realmente estão em ambiente de produção. 
 • Testes de detalhes de transações: um exemplo é o recálculo de 
saldos após um conjunto de transações. Essa tarefa visa garantir 
a repetição de cenários, baseando-se em cenários específicos.
 • Analítico e substantivo: essa tarefa serve para identificar 
inconsistências ou anormalidades nos registros. 
 • Amostragem: essa tarefa gera insumos para serem inseridos no 
software de auditoria.
A técnica mais tradicional é composta de entrevistas e questioná-
rios. Os questionários podem ser feitos em papel ou com um re-
curso digital e trazem perguntas para validar a conformidade de um 
processo, o acesso a determinado recurso de hardware ou o acesso a 
um software propriamente. 
A aplicação desses questionários se dá por meio de entrevistas com 
pessoas cruciais na empresa, geralmente indicadas pela diretoria. Even-
tualmente, pode-se utilizar a prática de amostragem, para evitar a repe-
tição das pessoas que respondem ao questionário de auditoria. Nessa 
amostragem, é feito um sorteio de nomes e o número de pessoas sele-
cionadas é baseado na quantidade de papéis presente na empresa, por 
Auditoria de sistemas da informação 19
exemplo: se uma empresa possui 40 funcionários e a maioria deles é 
desenvolvedora de software, esse grupo deverá compor a maior parte 
da amostra de selecionados para responder ao questionário.
Figura 2
Técnica de entrevista
Na
dy
a_
Ar
t/
Sh
ut
te
rs
to
ck
Ao fim das entrevistas, os questionários ficarão armazenados e, na 
próxima auditoria, será realizada uma nova rodada de questionários, 
bem como serão comparados os resultados entre essa auditoria e a 
anterior. Essa prática é fácil e barata para ser viabilizada, mas pode ser 
muito demorada devido ao processo de entrevistas e à quantidade de 
pessoas que responde às questões.
Contudo, a técnica de questionários é muito eficiente para a valida-
ção de conformidade de processos. Quando existe a necessidade de 
auditar os dados de um software ou mesmo saber se ele está realizando 
a operação prevista, são necessárias outras técnicas; entre elas estão:
 • dados de testes;
 • rastreamento e mapeamento;
 • análise da lógica de programação;
 • simulação paralela.
Cada uma dessas técnicas apresenta uma finalidade, por exemplo, 
quando é preciso confirmar a efetividade do algoritmo programado, 
utiliza-se a técnica de análise da lógica de programação. Essa técnica 
pode ser realizada manualmente ou com softwares específicos que 
validam os algoritmos escritos em formato de código-fonte. O auditor 
20 Segurança e auditoria de sistemas
deve conhecer a documentação do sistema e validar se o software está 
operando em conformidade com o definido nos documentos.
Quando se deseja acompanhar determinado processamento de 
transações, é possível utilizar a técnica anterior, podendo ser amplia-
da com a adoção de itens de rastreabilidade e o mapeamento de exe-
cução. Essa prática também é chamada de accountability e pode ser 
implementada por meio do uso de frameworks que gerenciam os logs 
de operações durante a execução do software. Com esses gerenciado-
res de log, há como saber qual usuário executou uma operação e o 
horário em que se deu a transação.
Para automatizar a técnica de análise da lógica de programação, 
utiliza-se a técnica de dados de teste, que é comumente aplicada com o 
objetivo de testar os controles programados. Para que essa técnica seja 
efetiva, é necessário incluir vários cenários de testes. Automatizando os 
testes e os dados de entrada, é possível repeti-los por diversas vezes ou 
pelo menos uma vez antes da liberação de uma nova versão. 
Por fim, há a técnica de simulação paralela, que envolve o uso de 
um programa específico para fazer a mesma operação do software. Por 
meio dessa técnica, o auditor busca confrontar os resultados de ambos 
os softwares, na expectativa de que os resultados sejam semelhantes. 
Um exemplo de aplicação dessa técnica é quando há necessidade de 
auditar um software que emita nota fiscal eletrônica. A simulação pa-
ralela pode ser feita pelo auditor, usando um software disponibilizado 
pela Receita Federal para simular a criação de notas fiscais. O resulta-
do esperado é que tanto a nota fiscal em PDF quanto o arquivo XML 
tenham os dados semelhantes. Caso haja divergência, o auditor deve 
evidenciar quais informações estão distorcidas.
A aplicação das técnicas mencionadas é conhecida como técnicas de 
auditoria assistidas por computador (TAAC). Imoniana (2013, p. 63) de-
talha os passos que devem ser observados na realização de um TAAC:
 • estabelecer os objetivos da aplicação de TAAC;
 • determinar quais são os dados a serem utilizados para as técnicas;
 • determinar a forma de acesso aos dados;
 • identificar os arquivos e bancos de dados a serem testados;
 • entender as entidades de relacionamentos das tabelas de dados 
onde a base de dados é examinada;
Auditoria de sistemas da informação 21
 • definir os testes e procedimentos de testes, inclusive as 
transações, as contas e os grupos de contas afetados;
 • definir os relatórios esperados;
 • programar, junto ao cliente e à sua área de informática, as cópias 
de arquivos ou base de dados que devem ser geradas em um 
período predefinido;
 • identificar o auditor que processará a aplicação de TAAC;
 • estimar os custos de TAAC;
 • certificar-se de que os processos de TAAC foram adequadamente 
executados e os papéis de trabalho documentados;
 • avaliar os resultados.
Um cuidado que o auditor deve ter é o de aplicar a técnica corre-
ta, segundo um processo definido. Alguns exemplos desses processos 
são: ISO 27001, ISO 12207, ISO 9126 e Cobit.
A ISO 27001 é aplicada para avaliar e auditar os processos de segu-
rança da informação de uma empresa. Quando o foco são os processos 
de engenharia de software e o seu ciclo de vida, a abordagem proposta 
pela ISO 12207 pode ser tomada por base. Já quando há necessidade 
de se auditar os processos de qualidade, a abordagem da ISO 9126 é 
a adequada. Toda ISO é considerada uma norma internacional que re-
sulta de diversos processos e cada uma tem a sua abordagem distinta. 
Logo, caso uma empresa esteja aderente a determinada norma, passa 
a ter o direito de usar o selo de certificação. 
Outro modelo de certificação é o Cobit, acrônimo para Control 
Objectives for Information and Related Technologies. Cobit é considerado 
um framework de boas práticas para a governança da tecnologia da 
informação e é representado por componentes que se inter-relacionam.
Go
od
_S
to
ck
/S
hu
tte
rs
to
ck
Figura 3
Cobit
22 Segurança e auditoria de sistemas
Ao aplicar uma técnica de auditoria com base no Cobit, serão analisa-
dos os requisitos de negócio, os recursos de TI e os processos de TI. Nos 
requisitos de negócio serão observados os aspectos de efetividade, efi-
ciência, confidencialidade, integridade, disponibilidade, conformidade e 
confiabilidade. Já no item recursosde TI serão analisados os aspectos de 
aplicações (softwares) utilizados, infraestrutura, informações e pessoas. 
Por fim, serão explorados os processos de TI, segundo os aspectos de 
domínio, processos e atividades. A figura a seguir é conhecida como 
cubo do Cobit e sintetiza os pontos a serem auditados.
Figura 4
Cubo do Cobit
Pr
oc
es
so
s 
de
 T
I
Requisitos de negócios
Efe
tiv
ida
de
Efi
ciê
nc
ia
Co
nfi
de
nc
ial
ida
de
Int
eg
rid
ad
e
Dis
po
nib
ilid
ad
e
Co
nfo
rm
ida
de
Co
nfi
ab
ilid
ad
e
Domínios
Processos
Atividades
Ap
lic
aç
õe
s
In
fr
ae
st
ru
tu
ra
In
fo
rm
aç
ão Pe
ss
oa
s
Re
cu
rso
s d
e T
I
Fonte: Adaptada de Souza; Ferreira, 2013.
Como visto, as técnicas para serem utilizadas durante o processo 
de auditoria de sistemas de informação têm suas particularidades, as 
quais geram resultados específicos; nesse sentido, mesclá-las ajuda o 
auditor a obter êxito em seu trabalho. Além do uso das técnicas, o audi-
tor deve aplicá-las com base em algum modelo, como a ISO ou o Cobit.
1.3 Plano de contingência e de 
recuperação de desastres Vídeo
Um dos itens a ser avaliado em auditoria de sistemas de informação 
é se há um plano de contingência e recuperação de desastres. Situações 
como ataques, indisponibilidade de servidores e roubo de informações 
são exemplos de desastres em um sistema de informação. 
No vídeo Técnicas para 
auditoria de sistemas infor-
matizados, publicado pelo 
canal Tribunal Regional do 
Trabalho da 2ª Região, Hi-
talo Fernandes Miné Diniz 
apresenta o case de boas 
práticas e técnicas de 
auditoria em sistemas in-
formatizados aplicados ao 
setor judiciário do Tribunal 
Regional do Trabalho (TRT) 
de Minas Gerais. 
Disponível em: https://www.
youtube.com/watch?v=epCYKx-
mjiEE&ab_channel=TribunalRegio-
naldoTrabalhoda2%C2%AARegi%-
C3%A3o. Acesso em: 3 jan. 2022.
Vídeo
Auditoria de sistemas da informação 23
Imagine a seguinte situação: uma empresa possui diversos portais 
de vendas na web. Um deles foi atualizado recentemente, pois no-
vas funcionalidades foram desenvolvidas pelos programadores e 
elas permitirão reduzir o tempo de espera para o pagamento de uma 
compra. Mas algo passou despercebido nessa atualização: uma re-
gra de acesso ao banco de dados foi deixada no código-fonte, o que 
permite a entrada de qualquer usuário. Com isso, um hacker conseguiu 
acessar a base de dados e apagou informações referentes a endereços 
de entrega; sem isso, os pedidos não podem ser enviados aos clientes. 
Além dessa alteração não autorizada de dados, o hacker conseguiu 
criptografar os dados de produção e exige um valor em dólares para 
devolver o acesso à base de dados. A empresa está parada. E agora? 
O que fazer?
O exemplo trazido mostra claramente uma situação de desastre, de 
modo que é preciso um “plano B” para retomar a operação de vendas 
de maneira segura. Esse plano é chamado de contingência, para que os 
negócios da empresa continuem em funcionamento. Um processo de 
contingência deve estar mapeado em um documento chamado plano 
de contingência e de recuperação de desastres. Esse documento também 
é conhecido como DR (do inglês disaster recovery). Para Imoniana (2013, 
p. 167), “esse plano detalha as medidas operacionais necessárias e do-
cumentadas que devem ser seguidas em casos de indisponibilidade de 
algum recurso de informática, evitando que o tempo no qual os equipa-
mentos permaneçam parados, acarrete perdas materiais aos negócios 
da empresa”. A inexistência desse documento pode comprometer os 
contratos e a vida da empresa, caso sofra algum desastre.
Além da existência desse documento, a sua aplicação em situações 
controladas é indispensável, pois, então, será possível ter a certeza de 
que o plano é efetivo e atende às necessidades de contingenciar os 
negócios da organização.
Cada ação de contingência presente no material deve trazer um 
responsável designado. Sugere-se, assim, que as pessoas selecionadas 
sejam diferentes daquelas que executam as funções operacionais dia-
riamente, para evitar conflitos de responsabilidades. 
Esses responsáveis designados formarão um grupo ou uma equipe 
de contingência. Eles precisam contar com um meio de comunicação 
rápido na troca de mensagens, que esteja sempre disponível, permi-
tindo o envio de documentos, áudios, vídeos e textos. Os aplicativos 
24 Segurança e auditoria de sistemas
de mensagens instantâneas, como Telegram ou WhatsApp, são boas 
sugestões para a comunicação da equipe de contingência.
O auditor deve se certificar de que as perguntas a seguir apresentam 
respostas afirmativas; com isso, tem-se um plano de contingência efeti-
vo. Esta lista é baseada nas afirmações de Imoniana (2013, p. 168):
• Há planos de contingência desenvolvidos que contemplam todas as 
necessidades de contingência da organização?
• Os planos abrangem os aspectos físico, lógico, de redes, de proprie-
dade intelectual, de pessoas e de transações nos softwares?
• Existe uma equipe de contingência definida?
• A equipe de contingência está preparada para as eventualidades?
• A equipe de contingência tem um meio efetivo e ininterrupto 
de comunicação?
• Os planos de contingência foram testados nos últimos dois meses?
• Os backups estão atualizados com dados do dia anterior?
• Os backups podem ser recuperados com pouca ou 
nenhuma dificuldade?
• Existem relatórios gerenciais que facilitam o acompanhamento de 
tentativas de ataques que podem ocasionar desastres?
• Se existem, esses relatórios são confiáveis?
• As políticas de acesso às ferramentas foram revisadas nos últimos 
três meses?
• Existem servidores com atualizações críticas pendentes?
• Existem sistemas operacionais com atualizações críticas pendentes?
• Existem softwares piratas ou sem licença no ecossistema de informá-
tica da empresa?
• Existem softwares com atualizações críticas pendentes?
• As bibliotecas e os frameworks utilizados no desenvolvimento de 
software possuem atualizações críticas pendentes?
M
on
ki
k/
Sh
ut
te
rs
to
ck
Auditoria de sistemas da informação 25
Caso alguma dessas perguntas não tenha uma resposta afirma-
tiva, o auditor deve atribuir uma classificação de risco para ela. Essa 
classificação vai de alto risco e risco intermediário até baixo risco. Além 
disso, o auditor deve detalhar qual foi a evidência que comprometeu a 
resposta afirmativa da pergunta analisada.
A seguir, vamos conhecer um exemplo de plano de contingência, 
mais focado nos recursos de redes.
NOME DO DOCUMENTO: plano de contingência para redes.
DATA CRIAÇÃO: 20/01/2020.
DATA ÚLTIMA ATUALIZAÇÃO: 22/12/2020.
Escopo do plano 
Este plano aborda somente os casos com níveis de risco alto e/ou interme-
diário no ambiente de redes da empresa XPTO. 
Classificação de softwares críticos que dependem essencialmente 
de redes
• Portal e-Commerce XPTO.
• Software de folha de pagamento.
Análise de riscos potenciais
Os riscos potenciais no ambiente de redes são:
Riscos de tecnologia da informação Alto Médio Baixo
Switch – equipamento responsável pelo 
gerenciamento de informações na rede
X
Hub – equipamento responsável por re-
transmitir sinal na rede
X
Fibra ótica – fornecedor A X
Fibra ótica – fornecedor B X
Malwares na rede local X
Contingência em relação aos recursos com riscos
a) Switch: caso o principal switch pare de funcionar, todas as rotas de 
comunicação da empresa devem ser alteradas automaticamente 
para o switch secundário que está em outro grupo de IP. O segundo 
switch deve conter os dados do switch principal, com diferença de 
dados de, no máximo, um dia.
M
on
ki
k/
Sh
ut
te
rs
to
ck
(Continua)
26 Segurança e auditoria de sistemas
b) Hub: não há contingência para esse aparelho, pois ele apresenta risco 
baixo. Caso algum pare de funcionar, deve ser substituído por um 
novo ou, então, os funcionários deverão utilizar o Wi-Fi da organiza-
ção em vez da rede cabeada via hub.
c) Fibra ótica – fornecedor A: se a comunicação com a internet por meio 
dessa fibrafalhar, automaticamente o sistema de redundância deve 
entrar em operação, utilizando o fornecedor de fibra ótica B.
d) Fibra ótica – fornecedor B: se a comunicação com o fornecedor 
B estiver indisponível, independentemente da disponibilidade do 
fornecedor A, deve-se enviar um alerta automático para o grupo de 
contingência para o eventual uso de comunicação via dados móveis, 
de preferência 4G ou superior. 
e) Malwares na rede local: bloquear automaticamente as máquinas 
identificadas com o malware e adicionar o IP desses computadores a 
uma lista de computadores sem acesso à rede local de dados.
Matriz de responsabilidades
Nome Responsabilidade Telefone de contato
Wagner 
Mendes Voltz
Disponibilidade de acesso 
à internet via fibra ótica 
ou redes móveis.
(12) 3456-7890
Cleber Molina
Gerenciamento e dispo-
nibilidade contínua dos 
switches.
(09) 8765-4321
Micheli Acrabri
Bloquear a propagação 
de malwares na rede local.
(99) 9876-6542
Airton Senna
Bloquear a propagação 
de malwares na rede local.
(88) 1111-2222
M
on
ki
k/
Sh
ut
te
rs
to
ck
No exemplo apresentado, temos um plano de contingência para re-
des. Esse não pode ser o único plano de contingência de uma empresa, 
pois diversos outros pontos precisam ser observados quando se tra-
ta de tecnologia da informação. Esse documento deve ser verificado a 
Auditoria de sistemas da informação 27
cada três meses e uma simulação de desastre deve ser feita a cada dois 
meses, para validar se o documento está aderente. 
A soma dos vários planos de contingência deve compor o business 
continuity planning (BCP), que é o planejamento da empresa para 
enfrentar incidentes nos processos operacionais que possam pôr em 
risco as missões empresariais e, sobretudo, a saúde financeira. Se-
gundo Imoniana (2013), com o BCP, são assegurados a continuidade 
do desenvolvimento de produtos ou serviços e o apoio aos consumido-
res, de modo ininterrupto, bem como a viabilidade corporativa, mesmo 
após a exposição a um desastre.
O BCP é composto dos seguintes itens: 
 • Plano de reinicialização de negócios ou, em inglês, business 
resumption planning (BRP), no qual são mapeados os processos 
essenciais e críticos para que o negócio continue operando em con-
formidade com os níveis planejados, mantendo o nível esperado 
de perdas, sem surpresa. Esse documento não pode ser apenas de 
TI; as áreas de marketing e relacionamento com o cliente precisam 
estar em sinergia com esse plano, de modo que o cliente não se 
sinta prejudicado pela eventual interrupção dos serviços prestados.
 • Gestão de crises, ou crisis management (CM), que é um comitê que 
busca respostas às crises pontualmente e em tempo hábil, a fim de 
minimizar os efeitos sobre a lucratividade e a imagem corporativa. 
 • Planos de contingência e de recuperação de desastres de todas as 
áreas envolvidas com a continuidade de negócio da organização. 
 • Testes de emergência e de recuperação ou, em inglês, emergency 
preparedness (EP), que são os testes periódicos para validar se 
os planos de contingência estão aderentes ao que foi definido 
e, também, para validar o funcionamento do comitê de crise e a 
reinicialização dos negócios (BRP). Esses testes devem ser plane-
jados e controlados; caso algum ponto falhe, o comitê de crise 
deve solicitar a priorização do problema encontrado junto à dire-
toria, para que a correção seja feita o mais rápido possível. 
Auditar frequentemente o BCP garante um fluxo definido e repeti-
tivo de retomada de negócios em meio a situações inesperadas, redu-
zindo o risco de descontinuidade das operações. Além disso, a auditoria 
28 Segurança e auditoria de sistemas
no BCP garante que a alta direção perceba maturidade e confiança na 
retomada de operações, uma vez que eles receberão os relatórios que 
atestam a integridade do BCP. Ao realizar o processo de auditoria do 
BCP, são mantidas as responsabilidades pelas atualizações dos pro-
cessos com os seus respectivos promotores. Imoniana (2013, p. 195) 
sugere o seguinte quadro para checar a integridade do BCP: 
Quadro 4
Validação do BCP 
Controles/Procedimentos de testes
Sim / Não 
/ Não 
avaliado
Respostas 
e observa-
ções
Gestão de crise
As funções de gestão de crises de continuidades são 
delineadas?
Existe alguma pessoa a que se deve recorrer quanto às 
questões de continuidade?
Quem é essa pessoa? Cite o nome e o papel que ela 
exerce.
Descreva, sucintamente, a atribuição dessa pessoa e 
como ela atua na gestão de crises.
Os funcionários são conscientizados a respeito da im-
portância estratégica de BCP? 
Reuniões periódicas são realizadas para transmitir 
questões de continuidade para os funcionários?
Existem evidências, em agendas, de que as reuniões do 
BCP estão ocorrendo?
Teste de validade
Com qual prazo se pode obter informações e orienta-
ções sobre a continuidade das operações? 
Qual é o prazo para obter dados sobre continuidade? 
24h? 1 semana? 10 dias? 30 dias? Outro?
Somente as pessoas autorizadas possuem acesso a es-
sas informações?
Teste de integridade
A empresa possui um banco de dados onde todas as 
orientações quanto aos possíveis problemas de conti-
nuidades são contempladas e as respostas apontadas?
As informações que explicam o BCP são genéricas?
As informações que explicam as estratégias e os compo-
nentes dessas estratégias são detalhadas?
Quando foi realizado o último teste do BCP?
(Continua)
Auditoria de sistemas da informação 29
Controles/Procedimentos de testes
Sim / Não 
/ Não 
avaliado
Respostas 
e observa-
ções
Treinamentos para a equipe do BCP são feitos periodi-
camente?
Quem promove esses treinamentos?
Quando será o próximo teste do BCP?
Existem controles que garantem a comunicação entre o 
sistema de gestão de risco da empresa e o BCP?
Quando foi realizada a última atualização do BCP?
Você considera que falta algum ponto a ser coberto pelo 
BCP?
Existe procedimento que propicie melhoria contínua 
por meio de benchmarking?
Fonte: Imoniana, 2013, p. 195.
Em tempos de transformação digital, em que as empresas estão 
aderindo cada vez mais à digitalização de serviços, ter um plano realista 
e eficiente para a contingência dos negócios é vital para evitar perdas 
financeiras. Quando esse plano vai além da TI, torna-se o BCP, e todas 
as áreas passam a ser envolvidas. Manter a atualização e a efetivida-
de desse plano é de responsabilidade do comitê de crise, e o auditor 
será um parceiro na validação da efetividade do BCP e dos planos de 
contingência.
No vídeo Backup X Disaster 
Recovery, disponível no 
canal ADDEE, Rodrigo 
Gonzala fala sobre as 
semelhanças e diferenças 
existentes entre esses 
dois temas. 
Disponível em: https://www.
youtube.com/watch?v=IIy4Gtan-
XxI&ab_channel=ADDEE. Acesso 
em: 3 jan. 2022.
Vídeo
CONSIDERAÇÕES FINAIS 
Neste capítulo foram apresentados os fundamentos que alicerçam a 
auditoria de sistemas de informação. Esse trabalho é realizado por um au-
ditor competente e com domínio sobre as diversas abordagens e técnicas 
existentes. O seu papel e o resultado entregue após as auditorias reali-
zadas fazem com que a empresa tenha a continuidade dos seus negó-
cios. O auditor não deve ser visto como carrasco ou “dedo duro” (que só 
aponta as falhas dos outros), mas sim como um parceiro, que garante 
a efetividade nos processos, a identificação de riscos nos negócios e as 
oportunidades de melhorias. 
30 Segurança e auditoria de sistemas
ATIVIDADES
Atividade 1
O processo de auditoria pode ser realizado de diversas maneiras 
e cada abordagem tem um nome. Diferencie as abordagens de 
auditoria de segunda parte e de terceira parte.
Atividade 2
Ao realizar uma auditoria, o auditor deve utilizar mais de uma 
técnica. Explique o porquê.
Atividade 3
Você é um auditor e percebeu que a equipe de contingência está 
utilizando e-mails para a comunicação. Você considera essa prática 
aderente ao plano de contingência da organização? Justifique a 
sua resposta.
REFERÊNCIAS
HUMBLE, J.; KIM, G. Accelerate:the science of lean software and devops – building and 
scaling high performing technology organizations. IT Revolution, 2018. 
IMONIANA, J. O. Auditoria de sistemas de informação. 2. ed. São Paulo: Atlas, 2013.
SOUZA, J.; FERREIRA, A. N. Metamodelo do framework COBIT de governança de 
TI. JISTEM – Journal of Information Systems and Technology Management, v. 10, p. 529, 2013.
Execução de auditorias 31
2
Execução de auditorias
A rotina de um profissional auditor é composta de muitos detalhes, e para 
a execução das auditorias, diversos itens devem ser analisados. Quando elas 
se referem ao ambiente de tecnologia da informação (TI), algumas perguntas 
importantes a se fazer são:
 • Existem controles para reduzir os riscos de fraudes?
 • Como é realizada a aquisição, o desenvolvimento e a manutenção de 
softwares?
 • Como é a gestão de aquisição e uso dos diversos hardwares da empresa?
 • Existe controle no acesso a informações lógicas?
 • Todos esses itens podem ser auditados de alguma maneira?
Ao responder a essas perguntas, o auditor consegue obter insumos para 
demonstrar a importância da sua atuação na organização. Neste capítulo, deta-
lharemos como deve ser a execução da auditoria em cada um dos itens observa-
dos. Ao final do estudo, esperamos que você consiga aplicar as várias auditorias 
em uma empresa que tenha um setor de tecnologia da informação. Vamos en-
tender como elas são executadas?
Com o estudo deste capítulo, você será capaz de:
 • compreender como executar a auditoria de sistemas operacionais e 
organizacionais;
 • entender como executar a auditoria em softwares que sofrem alterações;
 • compreender como executar a auditoria em ativos computacionais de uma 
organização;
 • entender como executar a auditoria dos privilégios de acesso dentro de 
sistemas.
Objetivos de aprendizagem
2.1 Auditoria de controles 
Vídeo
Todos os processos de auditoria devem ser iniciados com o escopo de tra-
balho estabelecido e a clareza sobre qual objetivo deve ser alcançado. Todos os 
itens de auditoria precisam ser respondidos com evidências que comprovem a 
resposta dada pelo entrevistado.
32 Segurança e auditoria de sistemas
Em uma empresa de tecnologia da informação, é necessário audi-
tar os controles, visando dificultar as fraudes nos processos manuais e 
tecnológicos que possam existir. Imoniana (2013, p. 89) explica que “o 
principal objetivo de auditoria dos controles organizacionais da área de 
informática é testar a grande essência de controle interno, promover a 
eficiência das operações e fomentar a maior adesão às políticas pres-
critas pela gerência com maior foco na responsabilidade”.
O controle interno de uma empresa pode ser dividido em duas cate-
gorias: organizacional e operacional. Enquanto o primeiro olha o todo da 
organização, o segunda visa manter a operação funcionando com eficiên-
cia. Por meio deles, a empresa busca alcançar os objetivos de negócios, 
reduzir os riscos de fraudes e as perdas financeiras, bem como minimizar 
a saída de colaboradores (turnover). Entre as atividades que são de respon-
sabilidade do controle organizacional, podemos citar as seguintes:
• Definição das responsabilidades operacionais dos colaboradores.
• Coordenação do orçamento para a informática.
• Desenvolvimento e implementação das políticas globais de 
informática.
• Definição dos modelos de contrato dos colaboradores.
• Intermediação de contratos de prestação de serviços com terceiros 
que trabalham com tecnologia da informação.
• Criação e desenvolvimento de políticas salariais e plano de carreira.
• Desenvolvimento de plano de capacitação.
• Definição de política para prêmios e bonificações.
Quando os controles organizacionais estão ou não definidos, mas 
não são efetivos, os gerentes passam a lidar com os colaboradores de 
pouca iniciativa, pois estes não sabem como serão avaliados, nem como 
poderão evoluir em suas carreiras. Isso gera desmotivação, que pode 
se misturar ao sentimento de injustiça, caso não haja clareza sobre a 
forma de a empresa realizar promoções e bonificações. Um exemplo 
de bonificação que costuma gerar insatisfação quando não é bem de-
finida é a divisão dos lucros (PLR), pois alguns colaboradores podem 
receber consideráveis valores e outros uma quantia insignificante.
Outro sintoma que identifica problemas nos controles organiza-
cionais é a desorganização no trabalho. A falta de objetividade sobre 
quais são as responsabilidades de cada papel desempenhado faz com 
Execução de auditorias 33
que o trabalho fique desordenado e pouco produtivo. Dessa forma, os 
gerentes não têm certeza se os colaboradores estão burlando algum 
processo ou se alguém está deixando de fazer um trabalho essencial 
(como pagar um imposto ou realizar o apontamento de horas tra-
balhadas na execução de um serviço, para que o gestor tenha uma 
noção do valor investido no trabalho).
Para resolver esses problemas, a empresa deve identificar as res-
ponsabilidades de cada tarefa desempenhada. Isso deve compor a 
descrição dos cargos, na qual devem estar claras quais são as tare-
fas de cada pessoa e quais funções se conectam. As atividades com 
responsabilidades compartilhadas são chamadas de zona cinzenta. 
Ela pode tornar o trabalho menos eficaz, porque mais de um respon-
sável por algo causa a lentidão do sistema produtivo, já que serão 
duas pessoas para tomar uma decisão e, talvez, nenhuma delas de-
seje se responsabilizar.
O exemplo a seguir é uma proposta para a descrição de políticas 
de responsabilidades e descrição de cargos que pode ser aplicada pelo 
auditor na execução do trabalho:
Descrição de cargos
Cargo: desenvolvedor de software
O cargo contempla as seguintes funções:
 • Transformar em código-fonte as necessidades do usuário, conforme a prio-
rização do gerente de produto.
 • Criar código-fonte com testes unitários.
 • Apontar corretamente as horas investidas em cada trabalho.
Zona cinzenta para esse cargo:
Função Zona cinzenta ligada a qual outro cargo?
Atualização de sistemas em 
produção
Administrador dos servidores
Testes de negócio Testadores
M
on
ki
k/
Sh
ut
te
rs
to
ck
(Continua)
O ditado popular que 
diz “cachorro com dois 
donos morre de fome” 
pode ser comparado à 
chamada zona cinzenta, 
pois ela faz com que uma 
tarefa seja negligenciada 
justamente por ter mais 
de um responsável.
Curiosidade
34 Segurança e auditoria de sistemas
Cargo: testador
O cargo contempla as seguintes funções:
 • Criar testes de aceitação no momento de definição do trabalho a ser 
desenvolvido.
 • Validar se todos os cenários estão corretos para gerar a versão do software.
 • Apontar corretamente as horas investidas em cada trabalho.
Zona cinzenta para esse cargo:
Função Zona cinzenta ligada a qual outro cargo?
Definir testes de aceitação Gerente do produto
Testes de negócio Testadores
M
on
ki
k/
Sh
ut
te
rs
to
ck
Uma boa prática é realizar a criação dessas descrições em peque-
nos grupos, contendo uma pessoa do RH (recursos humanos), um ou 
mais gerentes e alguns colaboradores que atuam nesses cargos, pois 
nada melhor que ouvir as pessoas que estão no dia a dia do trabalho 
apresentarem as suas funções. A disseminação do conteúdo definido é 
de responsabilidade de cada gerente junto aos seus liderados.
Com esse descritivo, é possível aperfeiçoar os controles e definir as 
políticas organizacionais, como as políticas para evolução na carreira e 
que geram reajustes salariais. Outra política fácil de definir com a des-
crição de cargos é o controle de acesso a dados da empresa. Quando 
não há entendimento dos cargos, a gestão do acesso às ferramentas e 
aos dados fica comprometida.
O auditor, ao se deparar com a situação de ausência desses contro-
les, deve elaborar um relatório detalhado, evidenciando os pontos de me-
lhoria, e atribuir criticidade alta para a solução desse problema. Quando há 
esses controles, também precisa utilizar algum documento para eviden-
ciar o que foi auditado. O quadro a seguir trazuma sugestão de perguntas 
propostas para a execução da auditoria de controles organizacionais.
Execução de auditorias 35
Quadro 1
Perguntas de auditoria para controles organizacionais e operacionais
Cliente: Data:
Auditoria realizada por:
Sim / Não / 
Não avaliado
Respostas e 
observações
Segregação de responsabilidades da área de informática
Existe a separação de atividades consideran-
do a descrição de cargos? Evidencie.
Existem regras de acesso aos dados confor-
me os descritivos de cargos?
Explique, com as suas palavras, qual é a descri-
ção do seu cargo. A explicação dada atende ao 
que está no documento oficial da organização?
Quais são as zonas cinzentas do seu cargo?
A implementação de normas administrativas visa, constantemente, deli-
mitar as responsabilidades de cada um.
Quando foi a última vez que o seu gestor ex-
plicou as responsabilidades do seu cargo? Foi 
a menos de 5 meses?
Políticas salariais e plano de carreiras
A empresa possui um plano de cargos e sa-
lários?
Quando foi a última revisão desse plano?
Treinamento do pessoal
Existem planos de treinamento para todos do 
seu cargo?
Você percebe que há planos de treinamento 
para outros cargos?
Prêmios e bonificações
Existem planos para premiar e bonificar não só 
por produtividade, mas também por excelência?
A política de premiação e bonificação é clara 
e pública?
Fonte: Adaptado de Imoniana, 2013, p. 90.
Por meio do Quadro 1, bem como do entendimento do objetivo dos 
controles, o auditor conseguirá validar o processo e garantir as evidên-
cias para sugerir melhorias ou atestar a excelência da área de TI.
No vídeo Auditoria e 
segurança da informação: 
controles organizacio-
nais, o professor Giulio 
Domenico Bordin apre-
senta um plano referente 
à definição dos controles 
organizacionais pela área 
de TI, com o apoio da 
gerência da área de RH.
Disponível em: https://
www.youtube.com/
watch?v=f4LkMD57dZM&t=71s . 
Acesso em: 6 jan. 2022.
Vídeo
36 Segurança e auditoria de sistemas
2.2 Auditoria de sistema 
Vídeo
O mundo está passando por uma transformação que foi acelerada 
pela Pandemia de Covid-19. Diversas empresas estão migrando a sua 
operação física para o digital, por meio do uso da internet e do desen-
volvimento de aplicativos que conectem o consumidor à empresa.
Dada essa necessidade, uma empresa pode optar por ter a sua pró-
pria equipe de tecnologia para o desenvolvimento de software ou ter-
ceirizar a uma especializada. Todo o processo de aquisição de software, 
desenvolvimento, manutenção e documentação de sistemas é o foco 
da auditoria de sistemas. Segundo Imoniana (2013, p. 96), a auditagem 
visa responder às perguntas:
 • Há procedimento de formalização sobre a real necessidade de 
um novo sistema?
 • As especificações são feitas de modo diligente, confrontando os 
conhecimentos dos usuários com os do analista de sistemas, vi-
sando dar suporte aos projetos?
 • O desenvolvimento de testes e a instalação na produção aconte-
cem sem traumas para os usuários?
 • Há informações apresentadas para que os usuários possam de-
cidir entre a aquisição e o desenvolvimento interno?
 • O desenvolvimento segue os padrões e utiliza todas as ferramen-
tas para alinhá-lo com os sistemas já existentes?
 • As questões básicas operacionais, de funcionalidade, tecnologia, 
pós-vendas, segurança e de análise de custos e benefícios, entre 
outras são esclarecidas quando da decisão de compras externas?
 • Os usuários são treinados para utilizar os sistemas com todos 
os potenciais que possuem?
 • As manutenções são feitas sem a interrupção das operações 
normais da empresa?
 • As documentações são consistentes e disponíveis para orientar 
os usuários?
O auditor precisa entender qual é o modelo de gestão de softwares 
adotado pela empresa para iniciar a auditoria. Na Figura 1, a seguir, te-
mos a representação dos fluxos possíveis. Tudo começa com a análise 
da necessidade e viabilidade de um software. Caso a empresa entenda 
que, realmente, deva existir esse novo software, dois caminhos podem 
ser seguidos: a aquisição de uma solução pronta ou o desenvolvimen-
to do software de modo personalizado. Na segunda opção, o auditor 
deverá observar as etapas de especificação, programação e testes do 
software e, na sequência, as etapas de testes de integração, implanta-
ção, documentação e controle de versão. Essas últimas etapas também 
fazem parte da auditoria em softwares que foram adquiridos.
Figura 1
Fluxo de auditoria de sistema
Análise da 
necessidade e 
viabilidade de um 
novo software
Auditar a 
especificação
Desenvolvimento personalizado
Auditar a 
programação
Auditar os 
testes no 
software
Aquisição de 
solução 
pronta
Auditar os 
testes de 
integração
Auditar a 
implantação
Auditar a 
documentação
Auditar o 
controle de 
versão
Fonte: Elaborada pelo autor.
Toda alteração em um software gera riscos à operação dos ne-
gócios, pois pode não ser implementada conforme o esperado, pro-
vocando, assim, os erros – também conhecidos como bugs –, que 
podem inviabilizar a sequência de um processo. Por exemplo, em 
diversas cidades brasileiras o transporte coletivo é realizado por 
ônibus que não possuem cobradores de passagem. O pagamento é 
feito via cartões aproximados a um aparelho que libera a catraca de 
acesso ao ônibus.
Figura 2
Forma eletrônica de pagamento do transporte coletivo
Execução de auditoriasExecução de auditorias 3737
Ro
ss
He
le
n/
Sh
ut
te
rs
to
ck
38 Segurança e auditoria de sistemas
Esse aparelho possui um software responsável pela leitura do car-
tão e validação da quantidade de créditos que o passageiro tem. Caso 
o software sofra uma atualização e apresente erros, muitas pessoas 
não poderão usar o transporte coletivo, pois o pagamento por apro-
ximação de cartão estará indisponível. Um erro como esse costuma 
gerar um impacto negativo na vida das pessoas, e a auditoria de siste-
mas objetiva reduzir esse risco.
Além da auditoria de sistemas, várias práticas são realizadas duran-
te o desenvolvimento e a implantação (ou atualização) de um software. 
Entre elas, podemos citar a codificação de software guiada por testes 
unitários, o uso das práticas de DevOps e a implantação de uma ge-
rência de configuração do software. As três geram rastreabilidade do 
fluxo de trabalho e das alterações executadas em um software, sendo 
possível fazer a auditoria de modo automatizado, bem como retornar 
a cenários anteriores do software. No exemplo anterior, se a empresa 
que fez a alteração no software tem DevOps e gerência de configura-
ção, rapidamente é feito um downgrade (retorno à versão anterior) e o 
sistema de pagamento do ônibus é normalizado.
Enquanto um programador está trabalhando na codificação de um 
software, ele precisa testar as alterações manualmente. Alguns desses 
testes são passíveis de esquecimento, dependendo da complexidade 
do software. Uma forma de automatizar esse procedimento é aplicar 
a prática de testes unitários, ou seja, frações de código-fonte que rea-
lizam testes automatizados nos códigos-fonte alterados pelo progra-
mador. Com isso, os testes podem ser repetidos quantas vezes forem 
necessárias pelo próprio computador.
Os testes unitários são essenciais para adotarmos a gerência de 
configuração e DevOps. As duas práticas estão interconectadas, e po-
demos afirmar que a gerência de configuração é o conceito, enquanto 
o DevOps são as diversas ferramentas que aplicam esse conceito.
O gerenciamento de configuração inclui os controles de mudanças 
que documentam os procedimentos de alterações e como serão im-
No vídeo Engenharia de 
software – aula 07: geren-
ciamento de configuração, a 
professora Juliana Saraiva 
apresenta o processo 
de gerenciamento de 
configuração, que é uma 
implementação auditável 
de mudanças em software.
Disponível: https://www.youtube.
com/watch?v=gMEm4BY_I6c. 
Acesso em: 6 jan. 2022.
Vídeo
https://www.youtube.com/watch?v=gMEm4BY_I6c
https://www.youtube.com/watch?v=gMEm4BY_I6c
Execuçãode auditorias 39
plementadas as solicitações de mudança que podem ser submetidas à 
aprovação por um comitê ou por pessoas com autoridade para aprovar 
ou recusar (HELDMAN, 2006). A prática de DevOps traz ferramentas 
como os versionadores de código-fonte e as de construção de versões 
de software, que implementam esses controles de mudança.
Ao realizar uma mudança em um software, o programador poderá 
incluir novos códigos, alterar um com erro ou melhorar um em funcio-
namento para torná-lo mais compreensível. A cada alteração, algumas 
regras devem ser seguidas pelos programadores, testadores e implan-
tadores de novas versões do software:
 • A documentação de sistemas deve ser atualizada, e a nova publi-
cação atualizada em produção.
 • As mudanças no programa devem ser testadas pelo desenvol-
vedor e testador e pelo solicitante da alteração (podendo ser al-
guém interno ou mesmo o usuário final).
 • A aprovação da mudança deve ser documentada e com base em 
evidências de testes manuais e automatizados.
 • As mudanças de programa sem autorização não podem ser im-
plementadas em ambiente de produção. Consequentemente, as 
modificações indevidas devem ser descobertas por meio de com-
paração de versões.
 • A versão documentada deve ser comparada àquela em uso e, 
periodicamente, a uma cópia controlada pelos auditores. Um 
software pode ser usado para executar esse procedimento.
A atualização dos documentos de um sistema costuma ser negli-
genciada por diversas equipes que desenvolvem o software. Por passar 
por atualizações de versão constantemente, é comum um documento 
ficar rapidamente desatualizado. Para evitar esse risco, a documenta-
ção deve ser enxuta e de fácil acesso.
A documentação de um sistema é composta de variados materiais 
escritos, diagramas, áudio e vídeo que auxiliam na explicação de como 
um software funciona. Os documentos são úteis tanto ao usuário final 
quanto a quem tem que fazer a manutenção no software.
40 Segurança e auditoria de sistemas
Figura 3
Diagrama para documentação de um software
nu
llp
lu
s/
Sh
ut
te
rs
to
ck
Na documentação não devem existir senhas ou descrição de como 
acessar os servidores de produção. Outras boas práticas são:
 • Os documentos devem ser armazenados em um local digital que 
conte com controle de acesso (IMONIANA, 2013).
 • Os documentos devem seguir um padrão de escrita e nomen-
clatura (convenção).
 • A escrita deve seguir narrativas.
 • Os diagramas são mais interpretativos do que os textos longos:
 ◦ Para documentos técnicos, usar os diagramas previstos no 
padrão UML (unified model language).
 ◦ Para documentação de processos, usar os diagramas previstos 
no padrão BPMN (business process model and notation).
 • Ao utilizar textos, dar preferência aos modelos usados 
mundialmente:
 ◦ Documentação de itens a serem alterados ou desenvolvidos, 
seguir o modelo de histórias do usuário (user story).
 ◦ Documentação de testes, seguir o modelo BDD (behavior 
driven development).
 • Todos do time podem alterar a documentação, mediante o con-
trole de acesso.
 • Pode haver revisores antes de ser aprovada a alteração.
Execução de auditorias 41
Quando a empresa não adota as boas práticas de documentação, 
tampouco de mudança de software, o papel do auditor deve ser o 
de reportar a baixa maturidade do modelo de trabalho e apontar a 
necessidade imediata de ações para melhorar esse fluxo.
A seguir trouxemos uma sequência de quadros que podem ser 
utilizados pelo auditor na avaliação dos itens previstos para a audi-
toria de sistemas.
Quadro 2
Análise da necessidade e viabilidade de um novo software
Objetivo: avaliar se as pessoas responsáveis foram envolvidas na análise e 
definição da aquisição ou do desenvolvimento de um software.
Cliente: Data:
Auditoria realizada por:
Análise da necessidade e viabilidade 
de um novo software
Sim / Não / 
Não avaliado
Respostas e 
observações
Existe um projeto apresentando a real ne-
cessidade de um novo software?
Esse projeto influencia algum indicador es-
tratégico da organização?
Os tomadores de decisão da organização 
foram envolvidos nessa análise?
A decisão sobre a viabilidade foi pautada 
em custo-benefício?
Fonte: Elaborado pelo autor.
Quadro 3
Aquisição de um novo software
Objetivo: avaliar se, durante o processo de aquisição de um software, foram 
seguidos os procedimentos previstos, evitando formas de favorecimento a 
fornecedores e gastos desnecessários.
Cliente: Data:
Auditoria realizada por:
Aquisição de sistemas Sim / Não / Não avaliado
Respostas e 
observações
Houve análise de mais de um orçamento para a 
aquisição de um sistema?
(Continua)
42 Segurança e auditoria de sistemas
Objetivo: avaliar se, durante o processo de aquisição de um software, foram 
seguidos os procedimentos previstos, evitando formas de favorecimento a 
fornecedores e gastos desnecessários.
Cliente: Data:
Auditoria realizada por:
Aquisição de sistemas Sim / Não / Não avaliado
Respostas e 
observações
Os tomadores de decisão da organização foram 
envolvidos nessa análise?
A decisão sobre a viabilidade foi pautada em 
custo-benefício?
Os critérios de manutenção do software foram 
analisados e definidos?
Os critérios de atualização em produção do 
software foram analisados e definidos?
Os critérios para acesso às novas versões do 
software foram analisados e definidos?
Fonte: Elaborado pelo autor.
Quadro 4
Especificação de sistemas
Objetivo: avaliar o trabalho de análise e definição de requisitos para mu-
danças no software.
Cliente: Data:
Auditoria realizada por:
Especificação de sistemas Sim / Não / Não avaliado
Respostas e 
observações
Os responsáveis pela análise das sugestões 
de mudanças são conhecidos? Quem são 
essas pessoas?
As solicitações de alteração no sistema estão 
sempre alinhadas com os responsáveis pelo 
processo?
Os documentos para descrever alterações se-
guem um padrão?
Os documentos para descrever alterações 
estão em um local acessível e com controle 
de acesso?
As mudanças são priorizadas de acordo com 
critérios claros de benefícios ao usuário?
Fonte: Elaborado pelo autor.
Execução de auditorias 43
Quadro 5
Programação
Objetivo: avaliar o trabalho do programador referente à escrita de 
código-fonte.
Cliente: Data:
Auditoria realizada por:
Programação Sim / Não / Não avaliado
Respostas e 
observações
As alterações de código-fonte são desenvolvi-
das seguindo a especificação?
As alterações são realizadas seguindo as boas 
práticas da linguagem de programação?
É possível rastrear o responsável pela altera-
ção no código-fonte?
Existe um processo de revisão de 
código-fonte? Ele é repetitivo?
Cada alteração no código-fonte gera um novo 
teste unitário?
Fonte: Elaborado pelo autor.
Quadro 6
Testes
Objetivo: avaliar o trabalho do testador referente à integridade das altera-
ções solicitadas pelo analista e implementadas pelo desenvolvedor.
Cliente: Data:
Auditoria realizada por:
Testes Sim / Não / Não avaliado
Respostas e 
observações
Os testes são realizados em todas as alterações 
do software?
Existem testes automatizados? A abrangência 
deles está crescendo durante o tempo de vida 
do software?
Existem rotinas de testes de interfaces?
Existem rotinas de testes de usabilidade?
Existem rotinas de testes de lógica de negócio?
Existem rotinas de testes de permissão de 
acesso a telas?
Fonte: Elaborado pelo autor.
44 Segurança e auditoria de sistemas
Quadro 7
Documentação
Objetivo: avaliar se os documentos foram atualizados e se estão disponíveis 
para consulta.
Cliente: Data:
Auditoria realizada por:
Documentação Sim / Não / Não avaliado
Respostas e 
observações
A documentação está atualizada?
A documentação está acessível?
São priorizados mais diagramas do que textos 
longos?
Existem mecanismos para a documentação ser 
acessada pelo usuário?
Existe distinção entre documentação para o 
usuário e documentação do time que desenvol-
ve o software?
Fonte: Elaborado pelo autor.
Quadro 8
ManutençãoObjetivo: avaliar o processo de gerência de configuração, evidenciando o 
controle das mudanças no software.
Cliente: Data:
Auditoria realizada por:
Manutenção Sim / Não / Não avaliado
Respostas e 
observações
É possível rastrear as alterações já realizadas em 
uma versão de software? Como?
É possível reverter uma versão de software rapi-
damente?
O processo de manutenção e atualização do 
software não causa impactos ao usuário?
As solicitações de mudança estão documentadas 
e foram aprovadas pelos responsáveis?
Fonte: Elaborado pelo autor.
Ao realizar o processo de auditoria de sistemas, muitos pontos de 
melhoria poderão ser identificados, pois o desenvolvimento de software 
Execução de auditorias 45
envolve diversos detalhes. Em empresas nas quais há essa atividade 
como atuação principal, a auditoria deve ser frequente (mensal), e à me-
dida que as melhorias são implementadas, a maturidade e o profissiona-
lismo na entrega de software serão percebidos pelos usuários.
2.3 Auditoria de hardware 
Vídeo Na seção anterior abordamos a auditoria de software, mas para que 
ela exista e seja acessada pelos usuários, é necessário à empresa diver-
sos aparelhos para esse fim. Eles podem ser computadores, notebooks, 
servidores, dispositivos de rede, mouse, teclado, entre outros, e todos 
fazem parte do conceito de hardware. Segundo Imoniana (2013, p. 102):
o controle de hardware objetiva implantar os procedimentos 
de segurança física sobre os equipamentos instalados em am-
biente de informática de uma organização. Aponta como os 
contatos físicos dos usuários aos variados recursos são con-
trolados, além de auxiliar no monitoramento de seu uso ade-
quado para agregar valor aos negócios empresariais.
Ao realizar a auditoria do hardware, o auditor deve ter algumas per-
guntas em mente:
• Se uma pessoa visitante entrar nessa organização, o que conseguirá 
fazer com o hardware?
• O que um colaborador consegue fazer com o hardware da empresa?
• O que um funcionário terceirizado consegue fazer com o hardware 
da empresa?
• O que os colaboradores que não trabalham na sede da empresa estão 
fazendo com o hardware cedido a eles?
• Quem é o responsável pela gestão do hardware?
• Existe o controle orçamentário, a gestão de estoque e do inventário de 
hardware da organização? Quais são esses controles?
• Existe inventário de software da organização? O que está instalado 
nos hardwares?
• Se acontecer um problema no hardware, a empresa continua a operar?
46 Segurança e auditoria de sistemas
Dependendo das respostas e evidências que o auditor encontrar, 
diversos riscos poderão ser identificados e muitos deles devem ser re-
portados imediatamente, para que alguma providência seja tomada 
pela organização. Os riscos que costumam ser constatados na audito-
ria de hardware são:
 • Ausência de um controle de acesso interno aos equipamentos, 
servidores e backups.
 • Instalação de softwares não homologados.
 • Substituição de peças por outras não homologadas e sem 
autorização.
 • Uso incorreto da rede de dados.
A restrição de acesso de pessoas ao ambiente de computador é 
chamada de segurança física. Ela pode ser feita por biometria ou leitura 
de um crachá de autorização. Essa restrição é muito comum em salas de 
servidores – nenhum desconhecido deve transitar pela empresa, por 
isso é tão importante a identificação por crachá, mesmo que seja a de 
visitante, pois assim é possível rastrear a entrada e saída de pessoas.
Figura 4
Mecanismo de restrição de acesso por crachá
Ol
ivi
er
 L
e 
M
oa
l/S
hu
tte
rs
to
ck
Essa restrição pode ser ampliada quando há políticas definidas so-
bre como deve ser a utilização do hardware, quais softwares podem 
ser instalados e qual é o processo a ser realizado quando é preciso de 
manutenção em um hardware. Essas políticas devem ser de conheci-
mento dos colaboradores e frequentemente atualizadas.
Execução de auditorias 47
Outro controle importante que a auditoria de hardware irá validar 
é a gestão de hardware e como está o inventário de peças e software. 
Essa análise é feita em todo o parque tecnológico da empresa e pode 
ser manual, mas essa abordagem costuma ser ineficiente, pois cons-
tantemente novos softwares são instalados por colaboradores e, em 
determinadas organizações, os profissionais trabalham de modo distri-
buído, em regime home office ou em outras sedes da empresa.
Para resolver esse problema, vários softwares podem ser utili-
zados para o inventário de hardware e software. Estes costumam 
ser instalados em cada computador, que envia para um servidor os 
dados referentes. Quando temos essa lista, é possível criar alertas 
que identificarão possíveis alterações feitas por algum colaborador. 
O software OCS Inventory Review é uma excelente opção para criar 
um inventário, pois, além de ter uma interface amigável, é gratuito e 
constantemente atualizado.
Os seguintes hardwares devem fazer parte do inventário e conter 
informações de fabricante, modelo e série:
 • processador;
 • memória;
 • unidade de armazenamento (disco rígido, fitas de armazenamen-
to e ssd);
 • monitores;
 • notebooks;
 • placas de vídeo, som e rede;
 • impressoras;
 • dispositivos de internet móvel (modem 3G ou superior);
 • celulares e smartphones;
 • thin client (computadores com poucos recursos instalados e que 
se conectam a servidores);
 • servidores presentes na empresa;
 • servidor de banco de dados;
 • servidores na nuvem (cloud).
Quanto ao inventário de software, ele deve conter informações so-
bre o fabricante, modelo e série de cada software instalado no compu-
tador, sem esquecer do sistema operacional. O software em uso para 
No vídeo OCS Inventory 
Review, você conhecerá 
os recursos de uma 
ferramenta gratuita e open 
source (código livre) para 
inventariar o hardware de 
uma empresa.
Disponível em: https://www.
youtube.com/watch?v=2_
ZZu2Doems. Acesso em: 6 jan. 2022.
Vídeo
https://www.youtube.com/watch?v=2_ZZu2Doems
https://www.youtube.com/watch?v=2_ZZu2Doems
https://www.youtube.com/watch?v=2_ZZu2Doems
48 Segurança e auditoria de sistemas
o inventário deve ser capaz de bloquear aqueles não autorizados pela 
empresa, evitando o uso de softwares piratas e suspeitos de conter 
brechas de segurança.
A rede de dados é um item que deve fazer parte do inventário, já 
que ela é composta de diversos hardwares, entre eles dispositivos de 
rede sem fio (wi-fi), roteadores, switches, hubs e firewall. A gestão do trá-
fego de dados nesses dispositivos é um item a ser observado, pois cada 
pessoa conectada a um hardware de rede deve ter privilégios restritos. 
Por exemplo, um visitante na empresa deve estar conectado a uma 
rede exclusiva e sem acesso aos demais computadores da corporação. 
Já um colaborador deve ter acesso aos recursos de rede referentes ao 
trabalho que desempenha.
Além desses aparelhos, é importante a gestão de outros apare-
lhos, como catracas de acesso e dispositivos de biometria. Também 
deve haver especial atenção à gestão das fitas de backup e de arma-
zenamento delas.
Figura 5
Exemplo de fita backup
Kj
et
il K
ol
bj
or
ns
ru
d/
Sh
ut
te
rs
to
ck
A auditoria de hardware deve acompanhar as necessidades do mun-
do atual, e uma dessas demandas é o correto descarte de aparelhos 
eletrônicos, sem contaminar o meio ambiente, pois o lixo eletrônico 
(e-lixo) é composto de baterias e outros materiais tóxicos que podem 
Execução de auditorias 49
contaminar o solo e a água. Por isso, é importante o auditor estar capa-
citado para saber quais são as políticas de descarte de computadores.
A seguir apresentamos uma sequência de quadros que podem ser 
utilizados pelo auditor para a avaliação dos itens previstos na auditoria 
de hardware.
Quadro 9
Controle de acesso físico ao ambiente de informática
Objetivo: avaliar se existem controles para o acesso físico aos computadores 
e servidores e se são efetivos.
Cliente: Data:
Auditoria realizada por:
Controle de acesso físico ao ambiente de 
informática

Outros materiais