[Apostila] Auditoria de Sistemas - TCU

TRIBUNAL DE CONTAS DA UNIÃOSecretaria-Geral de Controle ExternoSecretaria de Auditoria e Inspeções

MANUAL DE AUDITORIA DE SISTEMAS

Brasília, setembro de 1998.

TRIBUNAL DE CONTAS DA UNIÃO

Presidente:

Ministro Homero Santos

Vice-Presidente:

Ministro Iram de Almeida Saraiva

Ministros:Adhemar Paladini GhisiCarlos Átila Álvares da SilvaMarcos Vinicios Rodrigues VilaçaHumberto Guimarães SoutoBento José BugarinAntônio Valmir Campelo Bezerra

Auditores:

José Antônio Barreto de MacedoLincoln Magalhães da Rocha Benjamin Zymler

Procurador-Geral:

Walton Alencar Rodrigues

Subprocuradores-Gerais:

Jatir Batista da Cunha Lucas Rocha FurtadoPaulo Soares Bugarin

Procuradores:

Maria Alzira FerreiraMarinus Eduardo Vries MarsicoUbaldo Alves CaldasCristina Machado da Costa e Silva

Comissão Permanente de Regimento:

Ministro Adhemar Paladini Ghisi (Presidente)Ministro Humberto Guimarães Souto (Membro)Ministro Antônio Valmir Campelo Bezerra (Membro)Auditor José Antônio Barreto de Macedo (Suplente)

Comissão Permanente de Jurisprudência:

Ministro Carlos Átila Álvares da Silva (Presidente)Ministro Marcos Vinicios Rodrigues Vilaça (Membro)

TRIBUNAL DE CONTAS DA UNIÃOSecretaria-Geral de Controle ExternoSecretaria de Auditoria e Inspeções


Brasília, setembro de 1998.

Tribunal de Contas da UniãoInternet: http://www.tcu.gov.br

SAFS Lt. 01CEP: 70.042-900 - Brasília (DF)

Secretário-Geral de Controle Externo:

José Nagel

Secretário de Auditoria e Inspeções:

Cláudio Souza Castello Branco

Diretor de Informações para Planejamento e Execução de Auditorias:

André Luiz Furtado Pacheco

Chefe do Serviço de Avaliação de Sistemas de Administração Pública

Daniel Dias Pereira

Analistas de Finanças e Controle Externo - Área de Controle Externo:

Adriana de Oliveira Beal (PDTI)Cláudia Augusto DiasRoberta Ribeiro de Queiroz Martins

657.6:681.3 Brasil. Tribunal de Contas da UniãoB823m Manual de Auditoria de Sistemas /

Tribunal de Contas da União. – Brasília: TCU, Secretaria de Auditoria e Inspeções, 1998.

107p. Conteúdo: Portaria n. 455-GP, de

30 de setembro de 1998.

1. TCU - Manual de Auditoria de Sistemas. 2. Auditoria de Sistemas.I. Título

Ficha Catalográfica elaborada pela Divisão de Documentação do TCU.

Portaria nº 455, de 30 de setembro de 1998.

Aprova o Manual de Auditoria de Sistemas do Tribunal de Contas da União.

O PRESIDENTE DO TRIBUNAL DE CONTAS DA UNIÃO, no uso de suas atribuições legais e regimentais e tendo em vista o disposto no artigo 35 da Instrução Normativa nº 09, de 16 de fevereiro de 1995, resolve:

Art. 1º Fica aprovado o Manual de Auditoria de Sistemas do Tribunal de Contas da União, contendo os procedimentos operacionais e as estratégias metodológicas a serem utilizadas na realização de auditorias de sistemas.

Art. 2º Esta Portaria entra em vigor na data de sua publicação.

HOMERO SANTOS

APRESENTAÇÃO

Um número cada vez maior de sistemas computacionais controla operações de grande relevância no contexto das organizações, tornando imperativa a preparação do TCU para enfrentar o desafio de auditar uma Administração Pública cada vez mais informatizada.

A utilização da tecnologia da informação para a manipulação e armazenamento de dados nos órgãos auditados introduz novos riscos para o controle externo, acrescentando outras variáveis às questões relacionadas ao planejamento e execução de atividades de fiscalização.

Com o objetivo de aperfeiçoar as atividades de auditoria desenvolvidas pelo corpo técnico do Tribunal, enfrentando a dificuldade de se auditar entidades com alto grau de informatização, instituí, em 18 de agosto de 1997, um Grupo de Trabalho com o objetivo de desenvolver e incrementar a aplicação da tecnologia da informação às atividades de fiscalização no âmbito do TCU.

Este manual, desenvolvido pela Secretaria de Auditoria e Inspeções - SAUDI e pelos componentes do mencionado Grupo de Trabalho, é fruto deste esforço de dotar o TCU dos instrumentos necessários à modernização de sua atividade fiscalizatória.

Homero SantosPresidente

SUMÁRIO

Página

LISTA DE QUADROS................................................................................................ 12

LISTA DE SIGLAS..................................................................................................... 13

INTRODUÇÃO........................................................................................................... 14

PARTE 1 - TECNOLOGIA DA INFORMAÇÃO E ATIVIDADE DE FISCALIZAÇÃO -AVALIAÇÃO DA CONFIABILIDADE DE DADOS PROCESSADOS POR COMPUTADOR

1. REQUISITOS PARA A UTILIZAÇÃO DE EVIDÊNCIA PROVENIENTE DE DADOS PROCESSADOS POR COMPUTADOR.......................................................................... 16

2. MÉTODOS DE AVALIAÇÃO DE DADOS PROCESSADOS POR COMPUTADOR........ 17

3. TÉCNICAS E PROCEDIMENTOS DE AVALIAÇÃO LIMITADA DA CONFIABILIDADE DOS DADOS................................................................................................................... 183.1. Determinação do uso dos dados.................................................................... 183.2. Determinação dos dados que deverão ter sua confiabilidade avaliada......... 193.3. Levantamento do conhecimento prévio sobre os sistema e/ou os dados...... 203.4. Avaliação dos controles do sistema de processamento dos dados............... 20 3.4.1.Indícios de ineficácia dos controles de sistema.................................... 21 3.4.2.Parecer sobre a eficácia dos controles de sistema............................... 223.5. Determinação do risco de confiabilidade dos dados...................................... 223.6. Teste de dados............................................................................................... 24 3.6.1.Auditoria sem o auxílio do computador................................................. 24 3.6.2.Confrontação dos dados de entrada e saída do computador com

fontes independentes............................................................................ 25 3.6.3.Duplicação manual dos processos executados pelo computador......... 25 3.6.4.Verificações ditadas pelo senso comum............................................... 25 3.6.5.Observações sobre o uso da auditoria sem o auxílio do computador.. 26 3.6.6.Auditoria com o auxílio do computador................................................. 263.7. Divulgação da fonte dos dados e da confiabilidade atribuída aos mesmos.. 27 3.7.1.Papéis de trabalho................................................................................ 27 3.7.2.Informações que devem constar do relatório........................................ 27 3.7.3.Modelos a serem utilizados nos relatórios............................................ 28

4. ROTEIRO PARA AVALIAÇÃO DOS CONTROLES DE SISTEMA.................................. 294.1. Controles gerais............................................................................................. 29

7

4.1.1.Controles organizacionais.................................................................... 29 4.1.2.Controles de projeto, desenvolvimento e modificação de

sistemas................................................................................................ 30 4.1.3. Controles de segurança....................................................................... 31

4.2. Controles aplicativos...................................................................................... 31 4.2.1. Controles da entrada de dados............................................................ 31 4.2.2. Controles de processamento de dados................................................ 32 4.2.3. Controles da saída de dados............................................................... 32

4.3. Avaliação extensiva dos controles de sistema............................................... 334.4. Avaliação moderada dos controles de sistema.............................................. 344.5. Avaliação reduzida dos controles de sistema................................................ 34

5. ESTUDO DE CASO......................................................................................................... 355.1. Situação hipotética......................................................................................... 355.2. Informações básicas sobre a área auditada................................................... 355.3. Procedimentos de avaliação.......................................................................... 355.4. Determinação do uso planejado para os dados............................................. 355.5. Levantamento dos elementos de conhecimento prévio sobre os dados e o

sistema............................................................................................................ 365.6. Avaliação dos controles do sistema............................................................... 36

5.6.1. Avaliação extensiva.............................................................................. 375.6.2. Avaliação moderada.............................................................................. 37

5.7. Determinação da confiabilidade de dados..................................................... 375.8. Teste de dados............................................................................................... 37

5.8.1. Teste extensivo..................................................................................... 375.8.2. Teste reduzido...................................................................................... 39

5.9. Conclusão....................................................................................................... 39

PARTE 2 - AUDITORIA DE SISTEMAS DE INFORMAÇÃO

1. CONTROLES GERAIS ......................................................................................... 41

1.1. Controles Organizacionais................................................................................. 431.1.1. Organização do departamento de tecnologia da informação .................... 431.1.2. Segregação das funções............................................................................ 431.1.3. Unidades organizacionais bem definidas................................................... 441.1.4. Atividades dos funcionários controladas e políticas claras de

seleção, treinamento e avaliação de desempenho........................................ 451.1.5. Política de segregação de funções e controles de acesso......................... 461.1.6. Recursos computacionais gerenciados de forma eficiente e econômica .. 47

1.2. Programa Geral de Segurança...................................................................... 481.2.1. Princípios da gestão da segurança............................................................. 481.2.2. Avaliação do risco....................................................................................... 48

8

1.2.3. Estrutura de segurança............................................................................... 491.2.4. Avaliação periódica do risco........................................................................ 501.2.5. Documentação do programa de segurança.................................................

50

1.2.6. Estrutura de gerência de Segurança com atribuição clara de responsabilidade............................................................................................ 50

1.2.7. Políticas de segurança eficazes.................................................................. 511.2.8. Supervisão da eficácia do programa de segurança ................................... 51

1.3. Continuidade do Serviço ............................................................................... 521.3.1. Avaliação da vulnerabilidade das operações computadorizadas e

identificação dos recursos que os apoiam.................................................. 531.3.2. Adoção de medidas para prevenir e minimizar danos e interrupções

potenciais.................................................................................................... 531.3.2.1. Procedimentos de cópia de Segurança (backup)..............................

53

1.3.2.2. Controles de ambiente...................................................................... 531.3.2.3. Treinamento do pessoal para responder a emergências.................

53

1.3.2.4. Medidas de prevenção de interrupções inesperadas....................... 541.3.3. Desenvolvimento e documentação de um plano geral de

contingência................................................................................................ 541.3.3.1. Documentação do plano de contingência......................................... 541.3.3.2. Alternativas de processamento de dados e telecomunicação ........ 55

1.3.3.3. Teste periódico do plano de contingência e realização dos ajustes apropriados ..................................................................................... 55

1.4. Controles de Acesso........................................................................................... 551.4.1. Classificação dos recursos de informação de acordo com sua

importância e vulnerabilidade .................................................................... 571.4.2. Manutenção de lista atualizada de usuários autorizados e seu nível de

acesso.........................................................................................................

57

1.4.3. Implantação de controles lógicos e físicos para prevenção ou detecção de acesso não autorizado........................................................................... 58

1.4.3.1. Controles lógicos sobre arquivos de dados e programas de software 60

1.4.3.2. Controles lógicos sobre a base de dados ........................................ 601.4.3.3. Controles lógicos sobre acesso remoto............................................ 60

1.4.4. Supervisão do acesso, investigação de indícios de violação de segurança e adoção das medidas corretivas ............................................ 61

1.5. Controles de Software de Sistema............................................................... 621.5.1. Acesso limitado ao software de sistema..................................................... 63

1.5.1.1. Caminhos de acesso.........................................................................

63

1.5.2. Acesso e uso supervisionado do software de sistema .............................. 631.5.3. Controle das alterações do software de sistema........................................ 64

1.5.3.1. Instalação do software de sistema.................................................... 64

9

1.6. Controles de Desenvolvimento e Alteração de softwares aplicativos................ 651.6.1. Características de processamento e modificações no programa são

devidamente autorizadas............................................................................ 651.6.2. Todos os softwares novos ou revisados são testados e aprovados........... 66

1.6.2.1. Alterações de emergência................................................................ 671.6.3. Bibliotecas de controle do software............................................................ 67

1.6.3.1. Identificação e inventário de programas........................................... 671.6.3.2. Restrições de aceso à biblioteca...................................................... 671.6.3.3. Controle do movimento de programas e dados entre bibliotecas .... 67

2. CONTROLES DE APLICATIVOS.......................................................................... 682.1. Controles da Entrada de Dados...................................................................... 68

2.1.1. Documentos ou telas de entradas de dados ............................................

68

2.1.2. Rotinas de preparação dos dados (batch)................................................ 692.1.3. Autorização para entrada de dados.......................................................... 692.1.4. Retenção de documentos de entrada (sistema batch)............................. 702.1.5. Validação dos dados de entrada.............................................................. 702.1.6. Tratamento de erros................................................................................. 712.1.7. Mecanismos de suporte para entrada de dados....................................... 72

2.2. Controles do Processamento de Dados.................................................... 722.2.1. Integridade do processamento................................................................. 722.2.2. Validação do processamento.................................................................... 732.2.3. Tratamento de erros do processamento................................................... 73

2.3. Controles da Saída de Dados......................................................................... 732.3.1. Revisão dos dados de saída....................................................................... 732.3.2. Distribuição dos dados de saída................................................................. 732.3.3. Segurança dos dados de saída................................................................... 74

3. DESENVOLVIMENTO DE SISTEMAS.................................................................. 753.1. Fase 1: Planejamento..................................................................................... 753.2. Fase 2: Elaboração do plano de desenvolvimento e início do projeto........... 763.3. Fase 3: Organização do projeto..................................................................... 773.4. Fase 4: Elaboração do projeto do sistema..................................................... 773.5. Fase 5: Revisão e aprovação pelos dirigentes.............................................. 783.6. Fase 6: Desenvolvimento e Implantação........................................................

78

3.6.1. Teste do sistema.................................................................................. 79 3.6.2. Implementação..................................................................................... 79 3.6.3. Bibliotecas de controles....................................................................... 80

3.7. Fase 7: Revisão de pós-implementação........................................................ 80

4. BANCO DE DADOS .............................................................................................. 814.1. Dicionário de dados ....................................................................................... 814.2. Armazenamento de dados ............................................................................ 824.3. Acesso ao banco de dados ........................................................................... 82

10

4.4. Bancos de dados distribuídos ....................................................................... 824.5. Administração de banco de dados ................................................................ 834.6. Administração de dados ................................................................................ 844.7. Avaliação de Banco de Dados....................................................................... 84

4.7.1. Controles de Administração de dados................................................. 844.7.2. Controles de Administração de banco de dados ................................. 854.7.3. Controles de acesso ao banco de dados e dicionário de dados ......... 854.7.4. Controles sobre o conteúdo e alterações no dicionário de dados ....... 854.7.5. Disponibilidade e recuperação do banco de dados.............................. 864.7.6. Integridade do banco de dados ............................................................ 86

5. REDES DE COMPUTADORES ............................................................................ 875.1. Avaliação das Redes de Comunicação de Computadores ........................... 88

5.1.1. Gerência de rede.................................................................................. 885.1.2. Segurança dos dados .......................................................................... 89

5.1.2.1. Integridade dos dados................................................................ 905.1.3. Segurança da rede................................................................................ 90

5.1.3.1. Controle de acesso...................................................................... 90 5.1.3.2. Segurança de comunicação na rede........................................... 91

5.1.4. Segurança física .................................................................................. 915.1.5. Plano de contingência........................................................................... 915.1.6. Operação da rede................................................................................. 92 5.1.6.1. Falhas e interrupções de serviço................................................ 925.1.7. Software de rede................................................................................... 92 5.1.7.1. Controle de alterações................................................................ 93

6. MICROCOMPUTADORES ....................................................................................

94

6.1. Controles do software em uso........................................................................ 956.2. Controles de segurança................................................................................. 956.3. Controles sobre a operação........................................................................... 96

GLOSSÁRIO............................................................................................................. 97

BIBLIOGRAFIA.......................................................................................................... 102

RELAÇÃO DOS DOCUMENTOS ELABORADOS NA ÁREA DE FISCALIZAÇÃO E CONTROLE EXTERNO......................................................................................... 104

FOLHA DE SUGESTÕES.......................................................................................... 105

11

LISTA DE QUADROS

PARTE 1 – TECNOLOGIA DA INFORMAÇÃO E ATIVIDADE DE FISCALIZAÇÃO

Página

1 - Determinação da necessidade ou não de avaliação da confiabilidade dos dados, quando outras evidências comprobatórias estão disponíveis

19

2 - Determinação da extensão da avaliação dos controles do sistema 21

3 - Determinação do risco de confiabilidade dos dados, a partir do conhecimento prévio sobre o sistema e o uso planejado para os dados

23

4 - Determinação dos risco de confiabilidade ajustado dos dados 23

5 - Determinação da extensão do teste de dados 24

PARTE 2 – AUDITORIA DE SISTEMAS DE INFORMAÇÃO

6 - Exemplo de estrutura organizacional para o Departamento de Tecnologia da Informação

44

12

LISTA DE SIGLAS

CIPFA..........................................The Chartered Institute of Public Finance and Accountancy

EFS.............................................Entidade Fiscalizadora Superior

GAO............................................United States General Accounting Office

ICAS............................................The Institute of Chartered Accountants of Scotland

INTOSAI......................................International Organization of Supreme Audit Institutions

NAO.............................................National Audit Office

TCU.............................................Tribunal de Contas da União

13


PARTE 1 - TECNOLOGIA DA INFORMAÇÃO E ATIVIDADE DE FISCALIZAÇÃO

AVALIAÇÃO DA CONFIABILIDADE DE DADOS PROCESSADOS POR COMPUTADOR

INTRODUÇÃO

Grande parte dos órgãos e entidades sob a jurisdição do TCU já utiliza maciçamente a tecnologia da informação para automatizar sua operação e registrar, processar, manter e apresentar informações. Por isso, cada vez mais as equipes de auditoria terão que usar como evidência dados provenientes de sistemas informatizados.

Não se deve partir do princípio de que dados extraídos de computadores são confiáveis. Embora ofereçam vantagens para as organizações, os sistemas informatizados podem também representar grandes riscos. É possível que erros e fraudes não sejam detectados por causa da enorme quantidade de dados controlados pelos sistemas, da possível discrepância entre o que está armazenado e o que é efetivamente apresentado em relatórios de saída, e da mínima necessidade de intervenção humana nos processos.

Este Manual foi elaborado com o intuito de orientar os Analistas do Tribunal em suas atividades de fiscalização, devendo ser utilizado em auditorias em geral, como parte das tarefas de planejamento e execução, em complemento às normas e procedimentos de auditoria adotados pelo TCU.

A primeira parte deste Manual, aplicável a qualquer auditoria, possibilita avaliar se os dados processados por computador, que servirão de evidência para os achados de auditoria, são confiáveis, ou seja, completos e exatos. A segunda parte é voltada especificamente para as auditorias de sistemas, onde os sistemas computacionais serão analisados detalhadamente.

Seguindo as instruções da primeira parte deste Manual, os usuários estarão capacitados a constatar, com segurança, se as informações que irão fundamentar o relatório são íntegras e se possuem um grau de precisão adequado ao alcance dos objetivos de auditoria.

Para o bom aproveitamento das informações apresentadas, é recomendável que os usuários já possuam conhecimentos elementares de informática, abrangendo hardware dos computadores, softwares aplicativos, redes de comunicação e outras noções apresentadas em cursos introdutórios ao Processamento Eletrônico de Dados.

15

REQUISITOS PARA A UTILIZAÇÃO DE EVIDÊNCIA PROVENIENTE DE DADOS PROCESSADOS POR COMPUTADORES1.

Ao utilizar dados fornecidos por computador para fundamentar achados de auditoria, a equipe precisa levar em consideração as seguintes questões :

Qual a importância desses dados para o alcance dos objetivos da auditoria? Os dados podem ser considerados completos e exatos? O que se sabe sobre

o sistema que os processou?

Quando os dados processados por computador são utilizados pela equipe de auditoria ou incluídos no relatório apenas com o propósito de fornecer um histórico ou relatar fatos não significativos para os resultados do trabalho, a citação da fonte dos dados no relatório normalmente será suficiente para estabelecer a confiabilidade das informações apresentadas. Se esses dados servirem como o principal instrumento para se atingir os objetivos de auditoria, a equipe deve atestar sua confiabilidade, mediante a prática de procedimentos de avaliação tanto dos dados quanto do sistema que os processou. Os dados somente poderão ser considerados confiáveis se forem completos (sem omissões ou inclusões indevidas capazes de distorcer as análises) e exatos (sem incorreções significativas nos valores atribuídos). Eles não precisam estar 100% corretos, mas têm que representar "adequadamente" o universo auditado. Na prática, pode ser que a equipe de auditoria tenha que estimar, com a ajuda de métodos estatísticos, o valor provável do erro máximo dos dados, ou "limite superior do erro", e compará-lo com o nível de materialidade, a ser estabelecido levando-se em conta o uso previsto para os dados.

A determinação da confiabilidade dos dados é necessária independentemente de serem eles fornecidos pela organização auditada ou extraídos dos sistemas pela própria equipe de auditoria.

A análise da confiabilidade dos dados processados por computador deve ser iniciada ainda na fase de planejamento da auditoria, sempre que os estudos preparatórios permitam identificar e investigar as fontes dos dados que irão servir para se alcançar os objetivos de auditoria.

Se os dados a serem utilizados não forem suficientemente confiáveis para atender aos objetivos da auditoria, eles não servem de evidência primária, e a equipe terá que planejar um procedimento alternativo. As seguintes opções devem ser consideradas e discutidas com os superiores:

obter os dados de outras fontes, cuja confiabilidade possa ser confirmada; coletar dados primários para atender aos objetivos, em vez de utilizar fontes

secundárias (esse procedimento somente pode ser adotado se for possível completar o trabalho no tempo previsto para a auditoria);

redefinir os objetivos da auditoria, para eliminar a necessidade de utilizar dados não confiáveis;

utilizar os dados, explicando sua limitação e abstendo-se de extrair conclusões ou recomendações;

interromper a tarefa se nenhuma outra alternativa for possível.

16

MÉTODOS DE AVALIAÇÃO DE DADOS PROCESSADOS POR COMPUTADOR

2.

A eficácia da utilização dos procedimentos aqui recomendados dependerá da capacidade da equipe de auditoria em julgar a qualidade dos controles do sistema e a extensão e forma do teste dos dados. Erros nesse julgamento podem trazer conseqüências indesejáveis: um aprofundamento excessivo da investigação desperdiça recursos valiosos, enquanto um esforço insuficiente põe em risco a confiabilidade do trabalho. Em algumas circunstâncias, a equipe poderá concluir ser necessária a presença de um especialista na área de auditoria de sistemas informatizados para auxiliá-la no trabalho. Para que esse auxílio possa ser providenciado, o coordenador da equipe deverá informar o fato ao responsável pela supervisão do trabalho.

Existem basicamente dois métodos para a avaliação da confiabilidade de dados extraídos de computadores:

Avaliação do sistema: testa e avalia com profundidade todos os controles num sistema informatizado, abrangendo suas aplicações e produtos. Os procedimentos utilizados são: (1) exame dos controles gerais e de aplicativos do sistema; (2) teste da observância dos controles; e (3) teste dos dados produzidos pelo sistema. Apesar de oferecer uma melhor compreensão da finalidade e da forma de operação do sistema, este tipo de avaliação tende a consumir muito tempo e exige a participação de um especialista na área de Auditoria de Sistemas Informatizados.

Avaliação limitada: é direcionada para dados específicos. Por essa razão, ela normalmente requer uma avaliação menos profunda dos controles gerais e de aplicativos, podendo ser realizada por equipes compostas, somente, por técnicos generalistas. Os controles pertinentes são examinados na extensão necessária para julgar o grau de abrangência dos testes a serem feitos nos dados visando a determinar sua confiabilidade.

Há casos em que opção pela avaliação do sistema será mais vantajosa. Por exemplo: quando uma unidade técnica utiliza repetidamente dados do mesmo sistema informatizado em suas atividades de fiscalização. Nessas circunstâncias, uma avaliação extensiva, periodicamente atualizada, pode revelar-se menos onerosa, a longo prazo, que sucessivas avaliações limitadas dos dados. Para execução de uma avaliação extensiva deve-se utilizar os capítulos 1 e 2 da Parte 2 deste Manual. Na maioria das auditorias, entretanto, o segundo método de avaliação é adequado e suficiente, podendo ser aplicado através das técnicas e procedimentos constantes dos itens 3 e 4 seguintes.

17

TÉCNICAS E PROCEDIMENTOS DE AVALIAÇÃO LIMITADA DA CONFIABILIDADE DOS DADOS3.

Para se determinar a confiabilidade de dados processados por computador, pelo método de avaliação limitada, são utilizados os seguintes passos:

1) Determinação do uso dos dados - decidir quais os dados processados por computador irão ser utilizados para se alcançar dos objetivos de auditoria, assim como de que maneira esses dados serão utilizados, identificando aqueles que: (a) provavelmente irão servir como única evidência para um achado; (b) poderão ser confirmados por outras fontes independentes; (c) servirão apenas como referência para os trabalhos, não influindo nos resultados da auditoria;

2) Definição dos dados que deverão ter sua confiabilidade avaliada;

3) Levantamento do conhecimento prévio sobre o sistema e/ou os dados;

4) Avaliação dos controles do sistema de processamento dos dados - restrita aos controles relevantes do sistema, que podem reduzir o risco de erro para um nível aceitável;

5) Determinação do risco de confiabilidade dos dados e da extensão do teste de dados;

6) Teste de dados - execução de procedimentos para avaliar a integridade e autenticidade dos dados e a exatidão do seu processamento por computador;

7) Divulgação da fonte dos dados e da confiabilidade atribuída aos mesmos.

Sempre que possível, as atividades relacionadas aos passos 1 a 3 devem ser executadas durante a etapa de planejamento da auditoria. Entretanto, em muitos casos não será possível obter ainda nessa fase as informações necessárias. Nessas situações ou quando durante os trabalhos surgirem novas evidências ou achados que exijam o uso de outros dados processados por computador, todas as etapas poderão ser cumpridas no período de execução da auditoria.

A seguir, são apresentados as técnicas e procedimentos associados a cada etapa da avaliação da confiabilidade dos dados.

3.1. Determinação do uso dos dados

Quando uma auditoria requer o uso de dados processados por computador, o primeiro passo é decidir como eles serão utilizados para se alcançar os objetivos de auditoria. Normalmente, os dados são utilizados como:

única evidência para fundamentar um achado; evidência auxiliar, ou de ratificação; ou informação geral (histórico, descrições etc.).

18

TÉCNICAS E PROCEDIMENTOS DE AVALIAÇÃO LIMITADA DA CONFIABILIDADE DOS DADOS

Inicialmente, deve-se identificar os dados e sistemas a serem utilizados. Em seguida, cada grupo de dados deve ser classificado de acordo com sua utilidade (única evidência, comprovação auxiliar ou dado de informação geral).

3.2. Definição dos dados que deverão ter sua confiabilidade avaliada

A partir da definição do uso a ser dado às informações provenientes de sistemas informatizados, pode-se determinar quais os grupos de dados que precisarão ter sua confiabilidade avaliada, antes de poderem ser utilizados como evidência no relatório de auditoria. Com base na classificação definida no passo anterior, tem-se uma das seguintes situações:

Dados classificados como única evidência - quando os dados processados por computador são o único suporte para um objetivo de auditoria, o grau de confiabilidade exigido deles é alto, devendo a equipe de auditoria proceder a um rigoroso teste de avaliação dos dados e do sistema.

Dados classificados como evidência auxiliar - quando os dados processados por computador podem ser ratificados por outras comprovações de auditoria, o grau de confiabilidade exigido vai depender do quanto as outras evidências seriam suficientes para, vistas isoladamente, respaldar as conclusões.

Dados classificados como de informação geral - menor risco de se usar dados informatizados ocorre quando esses têm uma função apenas informativa, não contribuindo para os resultados da auditoria. Nesse caso, a citação da fonte dos dados e a garantia de que estes são os melhores disponíveis satisfarão os padrões de confiabilidade esperados do relatório, a menos que haja razão para se acreditar que uma falta de rigor nos dados pode distorcer os resultados do trabalho.

O Quadro a seguir resume as implicações dos três usos possíveis para os dados.

Quadro 1 - Determinação da necessidade ou não de avaliação da confiabilidade dos dados quando outras evidências comprobatórias estão disponíveis.

TIPO DE USOCARACTERÍSTICAS DAS OUTRAS EVIDÊNCIAS

EXIGÊNCIA DE AVALIAÇÃO DOS DADOS PROCESSADOS POR COMPUTADOR

Única evidência - SIM

Evidência auxiliar

Fonte primária de informação (ex.: comprovação física da existência de um bem, documento bancário que confirma um valor declarado etc.)

NÃO

Fontes auxiliares que por si sós não podem ser consideradas suficientes (ex.: entrevista com funcionários da unidade)

SIM

Informação geral Fontes primárias ou auxiliares NÃO

Inexistentes NÃO*

(*) A menos que haja razões para se acreditar que uma falta de rigor nos dados pode de alguma forma distorcer os resultados do trabalho

3.3. Levantamento do conhecimento prévio sobre o sistema e/ou os dados19


Nos casos em que se inferiu a necessidade de avaliação da confiabilidade dos dados, a próxima etapa consiste no levantamento de todas as informações disponíveis sobre o sistema e os dados.

Informações favoráveis sobre a confiabilidade do sistema ou dos dados podem reduzir o risco de confiabilidade, e diminuir o trabalho de avaliação dos controles do sistema e de teste de dados. Informações desfavoráveis levarão ao aumento do risco, exigindo maior cuidado na avaliação dos controles e na realização de testes de dados, os quais deverão ser suficientes para garantir que as informações que irão servir de evidência sejam completas e exatas.

Os seguintes exemplos ilustram como a equipe pode saber mais sobre os dados ou o sistema que os processou:

Os mesmos dados já foram utilizados em auditorias anteriores, após ter sido estabelecida sua confiabilidade. O risco de se utilizar os mesmos dados novamente em outro relatório seria baixo, mas seria necessário averiguar se os dados não foram modificados após a última auditoria.

Os controles do sistema que processou os dados foram avaliados em uma auditoria recente e considerados adequados. Após certificar-se de que nenhuma mudança significativa ocorreu no sistema desde aquela avaliação, a equipe de auditoria pode reduzir a extensão do teste de dados que irá determinar sua confiabilidade.

Uma auditoria de sistemas informatizados, executada recentemente, abrangeu o sistema responsável pelo processamento dos dados sob exame, ainda que em outra aplicação. Os resultados dessa avaliação do sistema, após confirmada a ausência de alterações significativas em sua operação, podem ser utilizados para definir a amplitude dos testes a serem realizados nos dados.

3.4. Avaliação dos controles do sistema de processamento dos dados

Durante a fase de execução da auditoria, e antes de se proceder ao teste de dados (procedimento que, em última instância, irá determinar a sua confiabilidade), normalmente é indicada a avaliação dos controles presentes no sistema de processamento desses dados.

Segundo princípios geralmente aceitos de auditoria, quanto menor a confiabilidade dos controles gerais ou de aplicativo (ou se esses não forem avaliados), maior a extensão do teste necessário para determinar a confiabilidade dos dados.

A abrangência da avaliação dos controles depende do conhecimento prévio sobre os dados e o sistema. O quadro 3 mostra como pode ser definida a extensão da avaliação dos controles a partir das informações obtidas:

20


Quadro 2 - Determinação da extensão da avaliação dos controles do sistema

CONHECIMENTO PRÉVIO SOBRE O SISTEMA OU OS DADOS

USO PLANEJADO PARA OS DADOS

AMPLITUDE DA AVALIAÇÃO DOS CONTROLES DO SISTEMA

As informações são insuficientes ou avaliações anteriores detectaram erros significativos nos controles do sistema ou nos próprios dados.

Única evidência para possíveis achados

Extensiva

Evidência auxiliar Moderada

Informações gerais (histórico, descrição etc.)

Desnecessária*

A confiabilidade do sistema ou dos dados já foi avaliada e considerada adequada em trabalhos anteriores.


Moderada

Evidência auxiliar Reduzida

Informações gerais (histórico, descrição etc.)

Desnecessária

(*) A menos que haja razões para se acreditar que uma falta de rigor nos dados pode de alguma forma distorcer os resultados do trabalho. Nesse caso, a equipe deve decidir entre avaliar a existência e eficácia dos elementos-chave de controle, desistir do uso das informações ou confirmar sua validade através de outras fontes.

No item 4 deste módulo, são apresentados os procedimentos para a avaliação dos controles dos sistemas, nos três níveis indicados (extensivo, moderado e reduzido).

A seguir, apresentam-se os indícios que podem caracterizar a inadequação dos controles de sistema, e um método para a classificação desses controles, de acordo com o grau de eficácia a eles atribuído.

3.4.1. Indícios de ineficácia dos controles de sistema

Ainda que bem planejados e projetados, se aplicados de forma inconsistente ou incorreta, os controles de sistema serão ineficazes. Há muitas razões para que os controles sejam desconsiderados ou ignorados pelo pessoal envolvido, tais como falta de tempo, fadiga, tédio, falta de atenção, controles que oneram a operação do sistema e até mesmo conluio para ganho pessoal. Por esse motivo, a equipe deve selecionar os procedimentos de controle mais significativos e confirmar sua eficácia.

A documentação de um sistema bem controlado deve ser completa e atualizada. A ausência dessa documentação pode indicar que não existem controles, que eles não são compreendidos ou são inadequadamente aplicados. Outros sinais que sugerem vulnerabilidade de dados a erros podem ser:

sistemas antigos, que exigem muita manutenção;

grande volume de dados;

atividades de atualização muito freqüentes;

numerosos tipos de transação e de fontes de dados;

21


grande número de elementos de dados codificados (por exemplo, itens do estoque representados por meio de códigos numéricos, em vez do nome do bem, podem dificultar a identificação até mesmo de erros grosseiros);

alta rotatividade de pessoal (digitadores, operadores, programadores, analistas) e treinamento inadequado ou em escala insuficiente;

estruturas de dados complexas ou desorganizadas;

falta de padrões para o processamento de dados, especialmente quanto à segurança, acesso e controle de mudança de programas.

Entrevistas com funcionários com grande conhecimento da organização podem auxiliar a equipe no entendimento dos controles do sistema. A evidência testemunhal, entretanto, sempre que possível, deve ser corroborada através de observação direta e outros testes, como prevê o Manual de Auditoria do TCU.

3.4.2. Parecer sobre a eficácia dos controles do sistema

Após avaliar os controles do sistema, a equipe deverá dar um parecer sobre a sua eficácia, isso é, sua capacidade de prevenir erros e detectar e corrigir aqueles que venham a ocorrer.

De acordo com os resultados da análise efetuada, a equipe de auditoria irá classificá-los em:

Controles sólidos - quando assumir-se que o sistema como um todo está capacitado a prevenir, detectar e corrigir qualquer erro significativo nos dados;

Controles adequados - quando forem detectadas deficiências nos controles, mas de modo geral esses demonstrarem ser suficientes para prevenir os erros mais significativos, e acusar os que venham a ocorrer; ou

Controles fracos/indeterminados - quando identificar-se a ausência ou ineficácia dos controles de sistema, e, conseqüentemente, oportunidades de introdução de dados incorretos no sistema.

A opinião da equipe quanto ao grau de eficácia dos controles dependerá de evidência que seja ao mesmo tempo relevante e confiável. Assim como em outras atividades de auditoria (conforme prevê o Manual de Auditoria do TCU), pode ser necessário definir índices de materialidade e outros critérios a serem observados como base de comparação, julgamento e apreciação de desempenho.

3.5. Determinação do risco de confiabilidade dos dados

O risco de confiabilidade dos dados é definido como sendo o "risco de que os dados utilizados não sejam suficientemente confiáveis para o fim a que se destinam" , ou seja, o risco de que esses não sejam exatos e completos o suficiente para servir de fundamento para achados de auditoria.

A partir das informações reunidas e do uso planejado para os dados, pode-se identificar o risco de confiabilidade envolvido, a ser definido como alto, moderado ou baixo, como mostra o quadro abaixo.

22


Quadro 3 - Determinação do risco de confiabilidade dos dados, a partir do conhecimento prévio sobre o sistema e o uso planejado para os dados.

CONHECIMENTO PRÉVIO SOBRE O SISTEMA OU OS DADOS

USO PLANEJADO PARA OS DADOS

RISCO DE CONFIABILIDADE

As informações são insuficientes ou avaliações anteriores detectaram erros significativos nos controles do sistema ou nos próprios dados.


Alto

Evidência auxiliar ModeradoInformações gerais (histórico, descrição etc.)

Baixo

A confiabilidade do sistema ou dos dados já foi avaliada e considerada adequada em trabalhos anteriores.


Moderado

Evidência auxiliar BaixoInformações gerais (histórico, descrição etc.)

Muito baixo

O risco de confiabilidade dos dados pode ser ajustado pelos resultados da avaliação dos controles do sistema, como mostra o quadro a seguir.

Quadro 4 - Determinação do risco de confiabilidade ajustado dos dados

RISCO DE CONFIABILIDADE INICIALMENTE CALCULADO

AVALIAÇÃO DOS CONTROLES DO SISTEMA =

RISCO DE CONFIABILIDADE AJUSTADO

Alto Fracos/Indeterminados AltoAdequados Alto a moderadoSólidos Moderado a baixo

Moderado Fracos/Indeterminados ModeradoAdequados Moderado a baixoSólidos Baixo

Baixo Fracos/Indeterminados BaixoAdequados Baixo a muito baixoSólidos Muito baixo

Muito baixo normalmente não necessária e de alto custo-benefício

Muito baixo

Com a determinação do risco de confiabilidade ajustado, define-se a extensão do teste de dados, como mostra o quadro 5.

23


Quadro 5 - Determinação da extensão do teste de dados.

RISCO DE CONFIABILIDADE ABRANGÊNCIA DO TESTE DE DADOS

Alto Extensivo

Moderado Moderado

Baixo Reduzido

3.6. Teste de dados

Os princípios de auditoria exigem que qualquer evidência (independentemente de sua fonte ou formato) seja confiável, relevante e suficiente. O teste dos dados tem o objetivo de estabelecer a consistência deles em relação ao uso planejado.

Algum teste de dados sempre será necessário quando se pretende avaliar a confiabilidade de informações processadas por computador. Mesmo quando os controles do sistema são bem projetados e, de modo geral, eficazes, a exatidão dos dados não é garantida. Ainda que a equipe possa fiar-se em bons controles para reduzir a amplitude do teste dos dados, como demonstra o quadro 5, a avaliação dos controles do sistema não pode substituí-lo.

Embora seja improvável que qualquer sistema de computador contenha dados completamente livres de erro, o conceito de confiabilidade não exige dados perfeitos. Ele pressupõe, no entanto, a execução de procedimentos para avaliar a integridade e autenticidade dos dados e a exatidão do seu processamento por computador, abrangendo:

Testes da integridade dos dados: determinam se o universo contém todos os elementos de dados e registros relevantes para o objetivo de auditoria, no período abrangido. A omissão de dados é particularmente danosa se ela representar um segmento específico da população total (exemplo, todos os pagamentos efetuados a um mesmo fornecedor).

Testes de autenticidade dos dados: verificam se os dados computadorizados refletem com exatidão sua fonte (os registros de entrada de dados devem reproduzir fielmente os documentos-fonte).

Testes de exatidão do processamento: informam se todos os registros relevantes foram processados de forma completa, e se todos os processamentos atenderam aos objetivos pré-estabelecidos.

Existem duas maneiras de se testar dados processados por computador. Elas são diferenciadas pela participação ou não do sistema computadorizado no processo. O método apropriado, ou a combinação de métodos, vai depender da natureza do sistema envolvido.

3.6.1. Auditoria sem o auxílio do computador

A auditoria sem o auxílio do computador parte do princípio de que as técnicas e procedimentos que o computador utiliza para processar dados não precisam ser considerados, desde que exista uma trilha de auditoria visível e/ou o resultado do processo possa ser manualmente verificado. Existem três formas de se realizar esse tipo de auditoria: confrontação dos dados de entrada e saída do computador com fontes independentes,

24


duplicação manual dos processos executados pelo computador e verificações ditadas pelo senso comum, as quais serão descritas a seguir.

3.6.2. Confrontação dos dados de entrada e saída do computador com fontes independentes

Este procedimento confronta os dados mantidos pelo computador com os dados provenientes de outras fontes (tais como relatórios de inspeção, arquivos, registros documentais), ou compara dados com contagens físicas ou inspeções que confirmem quantidades, tipos e condições de bens tangíveis. Relatórios de programas do governo e outros documentos produzidos por terceiros (tais como universidades, auditorias independentes e organizações privadas) também podem fornecer uma base de dados útil para comparação.

Outras fontes independentes das quais pode-se obter confirmação incluem:

bancos (extratos bancários, etc.);

almoxarifado (bens armazenados, volume de saída, etc.);

instituições de treinamento (número de estudantes ou valor dos contratos).

3.6.3. Duplicação manual dos processos executados pelo computador

Outro meio de se evitar o uso do computador ao confirmar a confiabilidade dos dados é selecionar transações, duplicar manualmente os processos do computador e comparar os resultados com a saída de dados. Esse procedimento poderia ser usado, por exemplo, em uma auditoria na área de licitações e contratos, em que os dados relativos aos contratos auditados fossem processados por um sistema informatizado. Nesse caso, a equipe poderia utilizar uma fórmula matemática para o cálculo do reajuste dos preços contratuais, a ser aplicada a uma amostra de contratos, para a posterior confrontação com os valores calculados pelo sistema auditado.

3.6.4. Verificações ditadas pelo senso comum

É possível, também, revelar problemas potenciais de confiabilidade, por meio de verificações ditadas pelo senso comum. As questões a seguir são exemplos de testes que podem ser executados, especialmente nos casos em que for concluído que um teste reduzido de dados já é suficiente para atender aos objetivos do trabalho (quando testes extensivos ou moderados forem necessários, essas verificações devem ser completadas com outros testes mais abrangentes):

os valores são pequenos demais (o custo mensal de manutenção dos veículos da entidade é igual a R$ 0,01) ou muito altos (uma bolsa de estudante no valor de R$ 200.000,00).

os campos de dados não estão todos preenchidos (as datas de pagamento mensal de um contrato estão em branco).

os resultados são inválidos (o valor do inventário é um número negativo).

25


3.6.5. Observações sobre o uso da auditoria sem o auxílio do computador

Apesar de os testes mencionados indicarem a precisão dos dados mantidos pelo computador, é muito difícil identificar todas as situações que ameacem a integridade e a autenticidade dos dados, assim como a exatidão do processamento. Quando a autenticidade dos dados do computador estiver sob suspeita (ou seja, quando existir a possibilidade da presença de dados fictícios), deve ser considerada a hipótese de complementação dos testes através do rastreamento de uma amostra de dados da saída do computador até os seus documentos-fonte. Se a dúvida for quanto à integridade dos dados (isto é, quando houver suspeita de que os dados não estão completos), uma amostra válida de documentos-fonte pode ser acompanhada até se chegar aos dados de saída do sistema, para confirmar se todos os documentos de origem foram devidamente inseridos.

A utilidade de se auditar sem o auxílio do computador diminui à medida que aumenta o número e a complexidade das decisões por ele tomadas, podendo tornar-se inviável quando o processamento dos dados abranger muitos elementos e operações que dificultem a análise manual dessas informações.

3.6.6. Auditoria com o auxílio do computador

Auditar com o auxílio do computador, no contexto deste manual, significa utilizar testes programados em computador para auxiliar a medição da confiabilidade dos dados.

Após a determinação da integridade e exatidão dos documentos-fonte, utilizam-se testes programados por computador (que podem ser desenvolvidos pela própria equipe de auditoria) para examinar a legitimidade dos dados e identificar defeitos que poderiam torná-los não confiáveis.

Uma vantagem de se auditar com o auxílio do computador é que esse método pode ser usado independentemente da complexidade do sistema ou do número de decisões que o computador tem que tomar durante o processo. Tal procedimento proporciona, além de rapidez e exatidão, uma amplitude muito maior de teste do que seria possível com outros métodos.

Para se desenvolver um teste de dados programado em computador, é necessário identificar quais os elementos de dados que afetam os objetivos de auditoria. Todos os dados significativos para os resultados da auditoria devem ser testados.

Quando um elemento de dado significativo para a auditoria é derivado (isto é, calculado pelo computador baseado em outros elementos de dados), a equipe deve também testar os elementos de dados de origem. Por exemplo, o elemento “salário líquido” pode ser empregado como evidência para atingir um objetivo de auditoria. Se o dicionário de dados do sistema indicar que um programa de computador usa três outros elementos de dados (salário por hora de trabalho, horas trabalhadas e deduções) para calcular esse valor, erros em quaisquer desses elementos acarretariam erros no valor do pagamento. Dessa forma, a equipe deve determinar a exatidão de cada um desses elementos.

Alguns sistemas possuem ambiente de processamento de dados de teste, com funções idênticas às do ambiente de operação normal. Esse ambiente é comumente utilizado para testes de sistemas e aplicativos antes de sua aprovação pelos usuários, e pode ser aproveitado pela equipe de auditoria para o processamento e análise de dados de teste.

26


3.7. Divulgação da fonte dos dados e da confiabilidade atribuída aos mesmos

Concluído o processo de avaliação da confiabilidade dos dados, é necessário documentar os resultados obtidos, mediante o preenchimento de papéis de trabalho e a inclusão de um parecer no relatório de auditoria.

3.7.1. Papéis de trabalho

Os papéis de trabalho devem ser documentados de forma a deixarem claro:

os objetivos de auditoria que serão fundamentados por dados processados por computador;

o grau de importância desses dados para os objetivos de auditoria, e as fontes adicionais que podem confirmá-los;

as informações coletadas sobre os dados, o sistema que os processa e seus controles.

3.7.2. Informações que devem constar do relatório

Quando os dados processados por computador são usados apenas para elaboração de histórico, descrição, ou informação geral sobre o órgão, e não têm influência sobre os resultados de auditoria, geralmente será suficiente a citação da fonte dos dados no relatório. Para os dados processados por computador que sejam cruciais para os objetivos de auditoria, o relatório deve assegurar aos leitores que a informação em que se baseia é confiável. Especificamente, devem ser informados:

a abrangência da avaliação dos controles, quando a confiança atribuída aos controles do sistema é utilizada para reduzir o teste de dados;

os tipos de teste de dados executados, seu propósito, e as taxas de erro encontradas nas três áreas de operação (entrada, processamento e saída de dados);

qualquer fator conhecido que limite a confiabilidade dos dados, e o tipo de influência que essa limitação teria sobre os resultados e conclusões apresentados

Se uma amostragem foi usada para determinar a confiabilidade dos dados, o relatório deverá incluir o objetivo de sua utilização, os tamanhos do universo e da amostra, a base para o dimensionamento da amostra, o tipo de amostra (randômica, sistemática etc.) e os erros porventura detectados.

No caso de a confiabilidade dos dados não ter sido determinada no nível desejado, o relatório deverá incluir uma declaração clara dessa situação. A equipe deverá considerar a conveniência de se apresentar conclusão ou proposta de determinação baseada nesses dados.

3.7.3. Modelos a serem utilizados nos relatórios

A seguir, apresentam-se exemplos que ilustram as formas como podem ser apresentados os resultados da avaliação da confiabilidade dos dados em relatórios:

27


Dados confiáveis são utilizados:

“Para alcançar o objetivo de auditoria, nos baseamos em dados processados pelo sistema (citar a base de dados utilizada). Avaliamos a confiabilidade desses dados através dos controles gerais e de aplicação relevantes, e os consideramos adequados. Também conduzimos testes suficientes nos dados. Baseados nesses testes e avaliações, concluímos que os dados são suficientemente confiáveis para serem utilizados como evidência para fundamentar as conclusões e proposições apresentadas."

Dados não confiáveis não são utilizados:

“Para alcançar o objetivo de auditoria, nos baseamos em dados processados pelo sistema (citar a base de dados utilizada). A avaliação dos controles dos sistema e o resultado dos testes de dados demonstram uma taxa de erro que coloca em dúvida a validade dos dados. Uma vez que o objetivo de auditoria depende de informações baseadas nesses dados, e fatos e provas suficientes para servir de evidência independente não estão disponíveis, não nos foi possível prover projeções, conclusões ou propostas de determinação específicas.”

A confiabilidade não foi estabelecida:“Para alcançar o objetivo de auditoria, nos baseamos em dados processados pelo sistema (citar a base de dados utilizada). Não estabelecemos a confiabilidade desses dados porque (citar as razões). Desta forma, estamos impossibilitados de prover projeções, conclusões ou determinações sobre esses dados. Com exceção do acima informado, o trabalho foi conduzido de acordo com os padrões previstos nas normas e procedimentos de auditoria adotados por este Tribunal.

28

4. ROTEIRO PARA AVALIAÇÃO DOS CONTROLES DE SISTEMA

Neste item são apresentados os conceitos básicos sobre controles de sistemas informatizados, os elementos que determinam a eficácia desses controles, e os roteiros para as avaliações (1) extensiva, (2) moderada e (3) reduzida. As verificações sugeridas não são obrigatórias, devendo a equipe de auditoria decidir sobre os itens adequados a cada situação concreta. O tempo e esforço gastos com a avaliação dos controles do sistema devem ser proporcionais à sua possível influência na redução do teste de dados: o “custo” de avaliação dos controles não pode ultrapassar o “benefício” da diminuição de trabalho na fase de teste de dados.

Se for concluído que os controles do sistema são insuficientes para limitar o teste de dados ou que continuar a avaliação dos controles será mais custoso que efetuar um teste extensivo de dados, a fase de avaliação dos controles do sistema deve ser interrompida. Nesses casos, a equipe deve passar para a etapa de teste extensivo de dados, como se os controles do sistema fossem fracos ou inexistentes.

Os controles dos sistemas informatizados são classificados em dois grupos principais: controles gerais, que se aplicam a todos os processamentos executados em um ambiente informatizado, visando garantir que o ambiente computacional como um todo seja seguro e confiável; e controles de aplicação ou de aplicativos, incorporados diretamente em aplicações individuais, com o objetivo de garantir um processamento confiável e exato.

É apresentado, a seguir, um roteiro com os aspectos mais importantes desses controles, quando o propósito da avaliação é permitir uma redução no volume de testes de dados.

4.1. Controles Gerais

São controles que se aplicam a todos os processamentos executados em um ambiente informatizado, visando a garantir que o ambiente computacional como um todo seja eficiente, eficaz, seguro e confiável. Estão relacionados à organização, projeto, desenvolvimento, modificação e segurança dos sistemas

4.1.1. Controles Organizacionais:

Objetivo - garantir a organização das responsabilidades do pessoal envolvido nas funções de processamento de dados e os padrões estabelecidos para o seu funcionamento eficiente.

Procedimentos de controle - verificar a existência dos seguintes elementos de controle:

Participação ativa da alta administração e dos gestores do sistema nas decisões que afetam o processamento de dados.

Avaliações rotineiras das funções de processamento de dados pela auditoria interna ou externa.

29

ROTEIRO PARA AVALIAÇÃO DOS CONTROLES DE SISTEMA

Evidência de ações efetivas de acompanhamento em relação às recomendações de auditoria.

Adequada segregação de funções dentro da operação do processamento de dados. As seguintes funções devem ser preferivelmente executadas por diferentes indivíduos ou grupos: análise de sistemas;

programação de aplicações;

teste de aceitação;

controle de alteração de programa;

controle de dados;

manutenção de sistemas de software; e

manutenção de arquivos informatizados, e operação do equipamento de informática.

4.1.2. Controles de projeto, desenvolvimento e modificação de sistemas

Objetivo - assegurar que os sistemas atendam às necessidades dos usuários, sejam desenvolvidos com economicidade, sejam totalmente documentados e testados e incluam os controles internos apropriados.


Procedimentos formais para requisitar, aprovar, testar e implementar mudanças no sistema.

Método formal de abordagem para o desenvolvimento de sistemas.

Envolvimento dos usuários no desenvolvimento dos requisitos dos sistemas

Documentação atualizada sobre o sistema, incluindo: documentos de requisitos funcionais; requisitos de coleta de dados; características de projeto dos sistemas e subsistemas; manual do usuário; manual de operação do sistema; estratégia para teste do sistema automatizado, incluindo procedimentos de

teste e critérios de avaliação; relatórios de análise de teste, documentando os resultados e conclusões

dos testes efetuados.

30


4.1.3. Controles de segurança

Objetivo - garantir que os computadores e os dados processados estão adequadamente protegidos contra roubo, perda, acesso não autorizado e desastres naturais.


Análise de risco periódica;

Responsabilidades pela segurança dos computadores formalmente estabelecidas;

Acesso ao centro de processamento de dados controlado por algum mecanismo físico (porta trancada, crachás de segurança, etc.);

Permanência de pelo menos duas pessoas na sala de computação durante todo o expediente;

Responsabilidade pelo armazenamento de dados magnéticos claramente documentada;

Plano de recuperação de desastres, periodicamente testado;

Senhas individuais de acesso aos sistemas, alteradas periodicamente e não sujeitas a divulgação pelos usuários; e

Software de controle do acesso aos computadores, encarregado de identificar os usuários e verificar a permissão de uso das pessoas que tentam ganhar acesso.

4.2. Controles de aplicativos

Objetivo - garantir que o processamento seja confiável e exato, a partir de controles incorporados diretamente em programas aplicativos, nas três áreas de operação (entrada, processamento e saída de dados).


4.2.1. Controle da entrada de dados

São projetados para garantir que os dados sejam convertidos para um formato padrão e inseridos na aplicação de forma precisa, completa e tempestiva. Controles a serem verificados:

Procedimentos documentados para a inserção de dados na aplicação;

Procedimentos de autorização física ou eletrônica para os registros de entrada;

Medidas de segurança para limitar o acesso aos terminais de entrada e validar a inscrição de usuários;

Validação de todos os campos de dados, antes de sua entrada no sistema;

31


Rejeição e armazenagem automática de dados que não atendam aos requisitos de entrada em um arquivo de dados de processamento interrompido;

Procedimentos documentados para o tratamento de erros (identificação, correção e reprocessamento de dados rejeitados pela aplicação);

Análise periódica do arquivo de processamento interrompido para examinar a taxa de erro de entrada de dados e a situação dos registros não corrigidos;

Medidas corretivas para redução de taxas de erro excessivas;

Controle da integridade dos dados de entrada, por meio da confrontação entre total de registros inseridos (registros rejeitados + registros aceitos) e o total de documentos de origem.

4.2.2. Controles do processamento de dados

São utilizados para garantir que os dados sejam manipulados pelo computador de uma forma precisa, completa e tempestiva. Devem ser verificados:

Procedimentos documentados sobre os métodos de processamento utilizados (ex.: fórmulas usadas para o cálculo de juros, tabelas consultadas para o cálculo do vencimento básico etc.);

Registro histórico que armazene eventos registrados pelo computador e seus operadores, durante o processamento de aplicações;

Proteção contra o acesso e alteração de programas aplicativos através de terminais de operação;

Proteção dos sistemas on-line contra a atualização simultânea de arquivos por diferentes usuários;

Testes de integridade de arquivos para garantir que os arquivos do aplicativo foram completamente processados.

4.2.3. Controles da saída de dados

Presentes para garantir a integridade e a correta e tempestiva distribuição dos dados de saída. Devem ser verificados os seguintes pontos:

Procedimentos documentados para confirmação da validade dos produtos de saída, e sua distribuição adequada;

Entrevista periódica dos usuários, para determinar se os dados produzidos continuam sendo necessários ou úteis;

Produtos de saída etiquetados para identificar o nome do produto, nome do destinatário e data e hora de produção;

Procedimentos documentados sobre os métodos para relatar, corrigir e reprocessar produtos de saída com erros;

Conferência dos montantes de registros de entrada e de saída com totais de controle, para garantir que nenhum dado foi extraviado ou adicionado durante o processo; e

32


Armazenamento dos documentos de origem em uma seqüência lógica, para fácil recuperação.

4.3. Avaliação extensiva dos controles de sistema

A partir dos procedimentos para avaliação de cada grupo de controles apresentados nos itens anteriores, deve ser elaborado um roteiro para avaliação extensiva dos controles de sistema.

Os principais pontos que definem a adequação dos controles gerais são:

Grau de comprometimento da administração com o projeto e a operação dos sistemas:

os métodos de supervisão e acompanhamento da administração e do desempenho dos sistemas; e

ações corretivas em relação às recomendações da auditoria interna e reclamações dos usuários.

Organização das funções dos sistemas, incluindo a atribuição formal das responsabilidades e segregação de funções, no sentido de garantir que funções críticas e responsabilidades de autorizar, processar, registrar e revisar transações sejam atribuídas a diferentes indivíduos.

Segurança física das instalações, especialmente quanto às restrições de acesso.

Segurança lógica (controle de acesso aos sistemas e dados através de senhas e outros métodos) que ajudam a garantir a confiabilidade dos dados reduzindo o risco de ocorrer entrada ou modificação não autorizada de dados.

33


Os principais elementos que definem a adequação dos controles de aplicativos são:

Existência de procedimentos que garantam que os programas aplicativos e suas modificações subseqüentes sejam autorizados e testados antes de sua implementação.

Freqüência das alterações no sistema e motivo de sua realização.

Procedimentos adequados de controle e documentação das alterações nos programas.

Procedimentos de revisão, aprovação, controle e edição de dados de entrada, para garantir sua integridade e prevenir erros.

Existência de documentação e fluxogramas atualizados para os sistemas.

Confrontação entre registros de saída e entrada (para confirmar que todos os registros válidos de entrada foram processados, e somente esses).

Procedimentos de detecção de erro e correção.

Opinião dos usuários sobre a confiabilidade dos dados.

Relatórios da auditoria interna e outros estudos de avaliação.

4.4. Avaliação moderada dos controles de sistema

O roteiro da avaliação extensiva pode servir de base para a elaboração do programa de avaliação moderada, que deverá enfatizar os elementos-chave de controle, e se direcionar, mediante o conhecimento prévio dos dados, para onde a ocorrência de falhas é mais provável.

4.5.Avaliação reduzida dos controles de sistema

Quando o conhecimento prévio dos dados indicar que a confiabilidade do sistema já foi avaliada e considerada adequada em trabalhos anteriores, a avaliação dos controles deverá se resumir à atualização das informações existentes. A equipe de auditoria deve determinar se:

alguma modificação foi feita no sistema após o trabalho anterior; os elementos-chave de controle ainda estão atuando; eventuais recomendações feitas sobre os controles do sistema foram

implementadas.

34

ESTUDO DE CASO

5.

Nesta seção é apresentado um exemplo da aplicação dos procedimentos mencionados neste módulo para determinar a confiabilidade de evidências processadas por computador.

5.1. Situação hipotética

Uma equipe é designada para auditar a folha de pagamento da Empresa Pública X, devendo determinar se:

o pagamento dos salários está sendo feito de acordo com a legislação pertinente;

as deduções sobre os salários estão corretas, e foram transferidas para as contas apropriadas;

existem controles suficientes para garantir que não haja desvio de valores destinados ao pagamento da folha.

5.2. Informações básicas sobre a área auditada

A Empresa X tem 500 funcionários, cuja folha de pagamento é preparada pelo Setor de Pagamento do seu Departamento de Pessoal. O Setor de Pagamento usa um sistema informatizado denominado “Folha de Pagamento” para o cálculo dos salários e deduções. Esse sistema foi desenvolvido pelo Centro de Processamento de Dados (CPD) da Empresa, e é administrado pelo Setor de Pagamento, que também é responsável por solicitar ao CPD quaisquer alterações necessárias no sistema.

5.3. Procedimentos de avaliação

Uma vez que os dados que irão fundamentar o trabalho de auditoria deverão ser extraídos do sistema informatizado “Folha de Pagamento”, antes de iniciar a auditoria propriamente dita, a equipe de auditoria deverá proceder à avaliação da confiabilidade desses dados.

O objetivo dessa avaliação é determinar se as declarações contidas no sistema correspondem efetivamente à situação real auditada, respondendo à pergunta: “os dados provenientes do sistema 'Folha de Pagamento', que serão utilizados como evidência para os objetivos de auditoria, são confiáveis - completos e exatos?”

Aplicando-se os procedimentos indicados no capítulo 3 deste módulo, a confiabilidade dos dados será avaliada com o propósito de obter-se uma segurança razoável de que os dados do sistema “Folha de Pagamento” não contêm erros capazes de comprometer a credibilidade das análises e conclusões da equipe de auditoria.

5.4. Determinação do uso planejado para os dados

Para determinar o uso planejado para os dados provenientes do sistema “Folha de Pagamento”, a equipe deve analisar os seguintes pontos:

35

ESTUDO DE CASO

Os dados serão realmente importantes para se atingir os objetivos de auditoria? O sistema será utilizado apenas para estabelecer um histórico da folha de pagamento, ou seus dados vão ser diretamente utilizados como evidência nas conclusões do relatório?

Os dados do sistema “Folha de Pagamento” são a única fonte de informação sobre as despesas com o pagamento de pessoal, ou fazem parte de um conjunto maior de evidências comprobatórias?

Nesse exemplo, será utilizada a hipótese de que os dados do sistema "Folha de Pagamento" são os únicos capazes de fornecer as informações necessárias para a realização da auditoria.

Tendo sido planejado o uso a ser feito dos dados processados pelo sistema “Folha de Pagamento”, e identificada a necessidade de avaliação da sua confiabilidade pode-se passar ao levantamento das informações disponíveis sobre esse sistema.

5.5. Levantamento dos elementos de conhecimento prévio sobre os dados e o sistema

A equipe de auditoria deve formular questões como estas:

O TCU utilizou esta mesma base de dados como suporte para achados de auditoria em outros trabalhos recentes? Se a resposta for sim, qual foi a avaliação da confiabilidade desses dados naquela ocasião?

A Auditoria Interna da Empresa X avaliou recentemente o sistema, ou a confiabilidade desses dados? Se a resposta for sim, qual foi a opinião emitida sobre esses dados? Foram feitas recomendações para melhorar os controles do sistema? O Departamento de Pessoal e o CPD adotaram as medidas necessárias para implementar essas recomendações?

O que os funcionários do Departamento de Pessoal e outros usuários do sistema dizem sobre a exatidão dos dados? Com que freqüência eles encontram erros nesses dados? Qual a importância desses erros?

Os funcionários têm relatado problemas ou dúvidas quanto à exatidão dos valores declarados no sistema? Eles confiam nos dados para desempenhar suas funções, ou mantêm registros manuais em separado?

Outras fontes de informação tendem a confirmar ou contradizer os dados processados por computador?

5.6. Avaliação dos controle do sistema

A extensão dos trabalhos de avaliação dos controles do sistema vai depender do resultado do levantamento anterior. Como os dados serão utilizados como única evidência, a avaliação dos controles deverá ser extensiva ou moderada, dependendo das informações obtidas sobre a confiabilidade do sistema ou dos dados (ver quadro 2).

A seguir, apresentam-se os procedimentos a serem adotados em cada situação:

5.6.1. Avaliação extensiva

36

ESTUDO DE CASO

Hipótese: os dados do sistema “Folha de Pagamento” são os únicos disponíveis como evidência para os objetivos de auditoria, e as informações conhecidas sobre o sistema não permitem considerá-lo confiável.

A avaliação deve seguir os procedimentos indicados no capítulo 4 deste módulo, abrangendo todos os aspectos dos controles gerais e de aplicativos

5.6.2. Avaliação moderada

Hipótese: determinada unidade do TCU utilizou informações da mesma base de dados para fundamentar achados em relatório elaborado nos últimos 6 meses. Naquela ocasião, a equipe concluiu que os controles do sistema eram eficientes, e que os dados eram confiáveis.

Nessa situação, a avaliação extensiva dos controles do sistema não seria necessária. A confiança no sistema seria determinada com base principalmente nas informações conhecidas, associadas a um teste reduzido para indicar se:

alguma modificação foi feita no sistema após o trabalho anterior;

os elementos-chave de controle continuam operando;

eventuais recomendações feitas sobre os controles do sistema foram implementadas.

A avaliação dos controles do sistema concluirá com o parecer da equipe de auditoria, que deverá classificá-los como sólidos, adequados ou fracos.

5.7. Determinação da confiabilidade dos dados

Com base na tabela do quadro 3, o risco de confiabilidade, no caso hipotético aqui tratado, poderá ser classificado como alto ou moderado. Com a avaliação dos controles, obtém-se o risco de confiabilidade ajustado, que poderá ser reduzido ou mantido no mesmo nível, caso haja, respectivamente, uma avaliação positiva ou negativa dos controles do sistema (quadro 4). Conhecendo-se risco de confiabilidade ajustado dos dados, obtém-se, de acordo com o quadro 5, o grau de abrangência a ser atribuído ao teste de dados.

5.8. Teste de dados

A seguir, apresentam-se os procedimentos que poderiam ser adotados nas duas situações extremas possíveis (risco de confiabilidade alto, exigindo a execução de um teste extensivo dos dados, e risco de confiabilidade baixo, autorizando a realização de um teste mínimo). Em ambas situações, utilizou-se o método da “auditoria sem o auxílio do computador”, possível nesse caso porque o resultado do processamento dos dados pode ser manualmente verificado.

5.8.1. Teste extensivo

Hipótese: a equipe de auditoria determinou que:

o sistema “Folha de Pagamento” é a única fonte disponível para os dados a serem utilizados como evidência;

37

ESTUDO DE CASO

nenhum trabalho do TCU ou do controle interno determinou recentemente a confiabilidade desses dados;

os controles gerais e de aplicação mostraram-se deficientes.

Nesse caso, o risco de confiabilidade é alto, e os resultados do teste de dados por si sós deverão determinar a confiança nos dados. Assim, a abrangência dos testes será extensiva, como indica o quadro 5.

Todos os testes deverão então ser executados em amostras estatisticamente válidas (v. seção Técnicas de Auditoria do Manual de Auditoria do TCU), ou, se possível, realizados em todos os registros, através de uma ferramenta automatizada de extração e análise de dados.

O primeiro teste de dados consistiria na confirmação de que os dados de entrada foram inseridos de forma exata e completa. Isso pode ser conseguido por meio dos seguintes procedimentos:

comparar o total de registros de entrada do computador com fontes independentes (e confiáveis) da mesma informação (ex.: relação do pessoal em atividade arquivado no Departamento de Pessoal; relatório da Contabilidade que informe o número de funcionários que receberam salário no mês investigado; etc.), para verificar se todos os funcionários que recebem salário foram efetivamente cadastrados no sistema;

para uma amostra válida de registros, fazer uma confrontação entre os registros existentes no computador e as fontes primárias desses dados (ex.: para a maioria dos campos, a fonte primária seria a pasta funcional do servidor, onde poderia ser verificada a exatidão dos campos “tempo de serviço”, "cargo" etc.), para averiguar se todos os campos importantes dos registros foram preenchidos corretamente e qual a taxa de erro de entrada dos dados no sistema.

Os próximos testes seriam projetados para avaliar a exatidão e integridade dos dados de saída do sistema, podendo incluir:

classificação dos registros em ordem alfabética dos beneficiários do pagamento, para permitir a identificação de possíveis duplicatas e eventuais discrepâncias entre a lista de nomes constante no sistema e a relação do pessoal em atividade fornecida pelo Departamento de Pessoal;

utilização de fórmulas para recalcular elementos de dados gerados pelo computador (ex.: cálculo do valor do anuênio devido a partir dos dados “vencimento básico” e do “tempo de serviço”), para confirmar a correção do processamento efetuado nos dados de entrada;

comparação do total de registros constantes no relatório final da folha de pagamento com o total de registros de entrada, para garantir que todos os dados de entrada foram processados e todos os funcionários cadastrados no sistema estão presentes nesse relatório final;

se os valores dos pagamentos informados pelo sistema estão dentro de parâmetros “razoáveis” (não são quantias irrisórias ou extremamente elevadas) e não extrapolam os limites legais;

38

ESTUDO DE CASO

se a soma dos valores dos pagamentos mensais corresponde ao valor da despesa com pagamento de pessoal declarado pelo setor de contabilidade da Empresa.

5.8.2. Teste reduzido

Para uma pequena amostra de funcionários, deve-se comparar os registros funcionais e de pagamento obtidos do computador com os documentos-fonte dessas informações (formulários de entrada de dados no computador, fichas funcionais etc.).

Se esses testes básicos produzirem taxas significativas de erros, a abrangência do teste deve ser expandida, utilizando-se os procedimentos indicados para o teste extensivo. Se a taxa de erro for aceitável, baseada nessa atualização do trabalho anterior de confiabilidade a equipe concluiria que os dados são confiáveis.

5.9. Conclusão

A partir do resultado dos testes de dados e das respectivas taxas de erro encontradas, a equipe estará apta a avaliar a confiabilidade dos dados (que poderá ser relatada de acordo com um dos modelos constantes deste módulo), e a iniciar os trabalhos necessários para atender aos objetivos de auditoria.

39


PARTE 2 - AUDITORIA DE SISTEMAS DE INFORMAÇÃO

1 CONTROLES GERAIS

Controles gerais consistem na estrutura, políticas e procedimentos que se aplicam às operações do sistema computacional de uma organização como um todo. Eles criam o ambiente em que os sistemas aplicativos e os controles irão operar.

Durante uma auditoria em que seja necessário avaliar algum sistema informatizado, seja ele financeiro, contábil, de pagamento de pessoal etc., é preciso inicialmente avaliar os controles gerais que atuam sobre o sistema computacional da organização.

Controles gerais deficientes acarretam uma diminuição da confiabilidade a ser atribuída aos controles das aplicações individuais. Por essa razão, os controles gerais são normalmente avaliados separadamente, e antes da avaliação dos controles dos aplicativos que venham a ser examinados em uma auditoria de sistemas informatizados.

Quando o objetivo da auditoria de sistemas informatizados é a avaliação de um aplicativo específico (por exemplo, sistema de processamento da folha de pagamento de uma entidade, ou de controle de empréstimos de uma instituição bancária), a equipe de auditoria pode muitas vezes economizar tempo, antecipando atividades de auditoria, ao planejar testes que avaliem controles tanto do ambiente geral quanto do aplicativo. Por exemplo, como parte da avaliação dos controles gerais, a equipe irá testar controles que abrangem alterações de programas.

Existem seis categorias de controles gerais que devem ser consideradas em auditorias:

controles organizacionais: políticas, procedimentos e estrutura organizacional estabelecidos para organizar as responsabilidades de todos os envolvidos nas atividades relacionadas à área da informática;

programa geral de segurança: oferece a estrutura para: (1) gerência do risco, (2) desenvolvimento de políticas de segurança, (3) atribuição das responsabilidades de segurança, e (3) supervisão da adequação dos controles gerais da entidade;

continuidade do serviço: controles que garantem que, na ocorrência de eventos inesperados, as operações críticas não sejam interrompidas, ou sejam imediatamente retomadas, e os dados críticos sejam protegidos.

controles de software de sistema: limitam e supervisionam o acesso aos programas e arquivos críticos para o sistema, que controlam o hardware do sistema computacional e protegem as aplicações presentes;

controles de acesso: limitam ou detectam o acesso a recursos computacionais (dados, programas, equipamentos e instalações), protegendo esses recursos contra modificação não autorizada, perda e divulgação de informações confidenciais;

controles de desenvolvimento e alteração de softwares aplicativos: previnem a implementação ou modificação não autorizada de programas.

41

Para cada uma dessas seis categorias, este manual identifica os elementos críticos que irão determinar a qualidade dos controles auditados e apresenta as técnicas e procedimentos de auditoria recomendáveis para a avaliação desses controles.

De modo a facilitar a utilização dessas informações em auditorias, o manual contém um roteiro que reúne todas as técnicas e procedimentos distribuídos nos diversos itens. O roteiro apresentado deve servir apenas como referência para a equipe de auditoria, que deverá determinar, em cada caso, quais as técnicas e procedimentos a serem aplicados e a extensão dos testes a serem realizados, levando em conta o âmbito da auditoria e a complexidade da organização auditada.

Além do roteiro apresentado a seguir a equipe de auditoria deve utilizar os Procedimentos de Auditoria de Sistemas (PA-02) para planejar e executar um trabalho mais completo e com maior nível de detalhe.

42

1.1. Controles Organizacionais

1.1.1. Organização do departamento de tecnologia da informação

Como estabelecido no glossário de termos técnicos deste manual, o termo "departamento de tecnologia da informação" (ou DTI) será utilizado para substituir o antigo CPD (Centro de Processamento de Dados), representando o departamento responsável por todos os serviços relacionados à área de informática, (redes de computadores, centrais de telecomunicação etc.)

O DTI precisa ter uma estrutura organizacional bem definida, com as responsabilidades de suas unidades organizacionais claramente estabelecidas, documentadas e divulgadas, e políticas de pessoal adequadas, quanto à seleção, segregação de funções, treinamento e avaliação de desempenho. Essa estrutura deve gerenciar racionalmente os recursos computacionais da organização, de modo a suprir as necessidades de informação de forma eficiente e econômica.

1.1.2. Segregação de funções

A segregação de funções tem como objetivo evitar que um indivíduo venha a controlar todos os estágios críticos de um processo (por exemplo, um programador com permissão para independentemente escrever, testar e aprovar alterações de programa).

Freqüentemente, a segregação de funções é alcançada pela divisão de responsabilidades entre dois ou mais grupos organizacionais. Com essa divisão, a probabilidade de que erros e ações indevidas sejam detectadas aumenta sensivelmente, visto que as atividades de um grupo ou indivíduo irão servir para checar as atividades do outro.

A ausência ou inadequação da segregação de funções de informática aumenta o risco de ocorrência de transações errôneas ou fraudulentas, alterações impróprias de programa e danos em recursos computacionais.

A extensão da segregação de funções a ser aplicada em uma organização irá depender do seu tamanho e do risco associado às suas instalações e atividades. Uma organização de grande porte terá mais flexibilidade em separar funções-chave que organizações pequenas, que dependem de poucos indivíduos para executar suas operações. Da mesma forma, atividades que envolvem transações financeiras de alto valor, ou que de alguma outra forma são bastante arriscadas, devem ser divididas entre diversos indivíduos e sujeitas a uma supervisão mais rigorosa.

Um exemplo de estrutura organizacional para o DTI, que permite uma adequada segregação de funções, está ilustrado no quadro 6, a seguir.

43

Gerente de T.I.(ou de Processamento de Dados)

CONTROLES GERAIS

Quadro 6: Exemplo de estrutura organizacional para o Departamento de Tecnologia da Informação (organização de tamanho médio)

Por causa da natureza da operação dos computadores, a segregação de funções por si só não garante que somente atividades autorizadas sejam executadas pelos funcionários, especialmente operadores de computador. Para auxiliar na prevenção e detecção de ações não autorizadas ou incorretas, é também necessária uma supervisão gerencial efetiva e procedimentos formais de operação.

Os elementos críticos para a avaliação dos controles organizacionais são:

Unidades organizacionais bem definidas, com níveis claros de autoridade, responsabilidades e habilidades técnicas necessárias para exercer os cargos;

Atividades dos funcionários controladas através de procedimentos de operação e supervisão documentados e políticas claras de seleção, treinamento e avaliação de desempenho;

Política de segregação de funções e controles de acesso para garantir na prática a segregação de funções;

Recursos computacionais gerenciados de forma a suprir as necessidades de informação de forma eficiente e econômica.

A seguir é apresentado um roteiro contendo os elementos críticos dos controles organizacionais.

1.1.3. Unidades organizacionais bem definidas

Foram definidas, para cada unidade organizacional do DTI:

seus principais objetivos e padrões de desempenho; os diversos níveis de autoridade, as responsabilidades de cada cargo e as

habilidades técnicas necessárias para exercê-los.

Os funcionários do DTI:

Gerente de Operações Gerente de SistemasGerente de Suporte Técnico

Especialista Técnico

Líderes de Turno

Supervisor de Controle de

Dados

Administrador de Banco de

Dados

Líderes de Projetos

Operadores Analistas/Programadores

44

CONTROLES GERAIS

exercem atividades compatíveis com as estabelecidas formalmente pela organização;

possuem capacitação técnica compatível com o previsto no respectivo plano de cargos.

1.1.4. Atividades dos funcionários controladas e políticas claras de seleção, treinamento e avaliação de desempenho

Pontos a serem verificados: existem instruções documentadas para o desempenho das atividades dentro

do DTI, que são seguidas pelos funcionários; manuais de instrução indicam como operar softwares de sistema e

aplicativos. o pessoal tem supervisão adequada, inclusive nas trocas de turno de

operação de computadores; todas as atividades dos operadores do sistema computacional são

automaticamente armazenadas no registro histórico de operação; supervisores revisam periodicamente o registro histórico de operação, e

investigam qualquer anormalidade; a inicialização do sistema é supervisionada e executada por pessoal

autorizado e os parâmetros informados durante o carregamento inicial do sistema operacional (initial program load - IPL) estão de acordo com os procedimentos estabelecidos;

é feito um planejamento das necessidades de pessoal especializado e existem políticas definidas, métodos e critérios para o preenchimento de vagas que permitem aferir as reais habilidades técnicas dos pretendentes;

existe um programa de treinamento de pessoal na área de tecnologia da informação, com recursos suficientes para capacitar o pessoal técnico;

existe um programa de avaliação de desempenho eficaz.

45

CONTROLES GERAIS

1.1.5. Política de segregação de funções e controles de acesso

Funções distintas são desempenhadas por diferentes indivíduos, incluindo as seguintes:

gerência dos sistemas de informação; projeto de sistemas; programação de aplicativos; programação de sistemas; teste e garantia de qualidade; gerência de biblioteca/gerência de alteração; operação de computador; controle de dados; segurança de dados; administração de dados.

A seguir estão destacados os principais pontos a serem verificados quanto à política de segregação de funções em um DTI.

Nenhum indivíduo deve ter o controle completo sobre funções de processamento incompatíveis (exemplos: entrada de dados e verificação da validade dos dados; entrada de dados e conferência dos dados de saída; cadastro de notas fiscais e recebimento de bens, e assim por diante). Observar as atividades dos técnicos para determinar se estão em conformidade com a segregação de funções pretendida.

Os técnicos de processamento de dados e os gerentes de segurança não devem estar encarregados de inserir dados ou executar transações nos sistemas de informação que atendem às áreas-fim da organização.

Os procedimentos normais de operação do DTI são adequadamente documentados e ações indevidas são identificadas.

São previstas rotações periódicas de pessoal e substituições no período de férias, tendo em vista que indivíduos desempenhando funções incompatíveis e conduzindo ações fraudulentas podem ser descobertos quando substituídos por motivo de férias ou rotação de pessoal.

As descrições das atribuições dos cargos refletem os princípios de segregação de funções. Examinar as descrições para uma amostra de cargos dentro da administração de segurança e no grupo de usuários.

Todos os funcionários estão cientes de suas funções e responsabilidades, e desempenham essas responsabilidades de acordo com as descrições do cargo. Entrevistar ocupantes dos cargos cujas descrições foram examinadas. Verificar se as suas atividades e responsabilidades conferem com o formalmente estabelecido.

A alta administração oferece recursos e treinamento adequados para garantir que os princípios de segregação de funções sejam conhecidos, seguidos e institucionalizados dentro da organização.

46

CONTROLES GERAIS

As responsabilidades por restringir o acesso de funcionários em atividades críticas de operação e programação foram claramente definidas, divulgadas e aplicadas.

Existem controles lógicos e físicos de acesso para auxiliar na restrição das atividades dos funcionários às ações autorizadas, de acordo com as responsabilidades dos respectivos cargos.

O desempenho dos funcionários é supervisionado periodicamente e controlado para garantir que as atividades de cada um sejam compatíveis com as atribuições dos respectivos cargos.

A alta administração realiza avaliações periódicas do risco, para determinar se as técnicas de controle para segregação de funções estão funcionando como esperado e mantendo o risco em níveis aceitáveis. Este procedimento deve ser executado em conjunto com os previstos no item 2.1 - SEG-1.

1.1.6. Recursos computacionais gerenciados de forma eficiente e econômica

As tarefas executadas pelo DTI obedecem a um cronograma adequado, de forma a permitir que os recursos computacionais sejam utilizados com eficiência e que as solicitações dos usuários possam ser atendidas. Entrevistar usuários e proprietários de recursos computacionais para detectar eventuais distorções na alocação de recursos e/ou conflitos causados por falhas no planejamento da distribuição da carga de trabalho.

A capacidade do hardware instalado é suficiente para atender a demanda nos horários de pico e manter a qualidade do serviço para os usuários. Entrevistar usuários e analisar os registros de utilização do hardware - log accounting - para detectar desbalanceamento da configuração do sistema, pela caracterização de dispositivos - unidades de disco, impressoras, terminais etc. - que estejam com folga ou sobrecarregados.

Existe um plano definido ou um acordo entre o DTI e os grupos de usuários, quanto à disponibilidade dos recursos computacionais, com prioridades de processamento adequadas às necessidades da organização.

Foram estabelecidas metas pela alta administração quanto à disponibilidade de processamento de dados e serviços on-line.

A alta administração periodicamente avalia e compara os desempenhos de serviço com as metas previstas e pesquisa junto aos departamentos usuários para saber se as necessidades de disponibilidade dos sistemas estão sendo atendidas.

47

CONTROLES GERAIS

1.2. Programa Geral de Segurança

O programa de segurança da entidade inclui suas políticas de segurança e o respectivo plano de implementação.

Esse programa deve estabelecer uma estrutura para a avaliação do risco, o desenvolvimento e implementação de procedimentos eficazes de segurança e a supervisão da eficácia desses procedimentos. Sem um programa bem elaborado, os controles de segurança podem ser inadequados, as responsabilidades podem não estar claras, não serem compreendidas e propriamente implementadas, e os controles podem ser aplicados de forma inconsistente. Tais condições podem levar a uma proteção insuficiente de recursos críticos ou vulneráveis e, possivelmente, a um desperdício de recursos para implantação de controles em situações de baixo risco.

1.2.1. Princípios da gestão da segurança

A gestão da segurança é regida pelos seguintes princípios básicos: Os dispositivos de proteção da segurança devem ser consistentes com a

vulnerabilidade dos dados que estão sendo protegidos. A proteção de segurança deve acompanhar os dados durante todas as etapas

do seu processamento e transmissão, e permanecer efetiva em todas as situações.

Estes princípios são postos em prática determinando-se o grau de vulnerabilidade dos dados1, sob o ponto de vista de sua integridade, caráter confidencial e disponibilidade, e através da aplicação concreta de um Plano de Segurança que abranja os seguintes aspectos de proteção: elemento humano, fatores físicos, práticas e procedimentos, hardware, software, aplicações e elementos de apoio à segurança.

1.2.2. Avaliação do risco

Uma avaliação completa do risco deve ser o ponto de partida para o desenvolvimento ou modificação do plano e das políticas de segurança da organização. Essa avaliação é importante porque é através dela que se identifica todas as ameaças e vulnerabilidades do sistema e se decide quais riscos serão aceitos e quais deverão ser reduzidos através de controles de segurança.

A avaliação do risco deve considerar a vulnerabilidade inerente aos dados (ou seja, sua susceptibilidade a erros materiais causados por omissão ou inserção incorreta ou indevida de dados), e o risco adicional a que os sistemas e os dados podem estar sujeitos, em função do seu uso por usuários internos e externos e eventuais tentativas de acesso por estranhos não autorizados.

Essa análise deve também contemplar revisões da configuração do sistema e da rede, e observação e teste dos controles de segurança já implantados. Ainda que o pessoal envolvido em atividades de segurança possa oferecer uma visão valiosa sobre as vulnerabilidades existentes, a avaliação geral do risco deve ser feita por pessoal independente, para garantir sua objetividade.

1 V. termo "vulnerabilidade de dados" no Glossário deste manual.48

CONTROLES GERAIS

Avaliação do risco e gerência do risco são esforços contínuos. Ainda que a avaliação geral do risco possa ser feita mais espaçadamente (a cada ano ou dois), o risco deve ser reavaliado toda vez que houver mudança na operação da organização, ou em influências externas que afetem essa operação.

1.2.3. Estrutura de segurança

As organizações de grande porte que possuam uma estrutura completa de administração da segurança apresentarão os seguintes cargos, que podem assumir diferentes denominações em cada caso:

Superintendente de segurança: administrador sênior que tem a responsabilidade final pela segurança da organização. Ele é o elo de ligação com os outros órgãos e entidades da Administração e presta contas por todas as questões de segurança dentro da organização.

Diretor de segurança: gerente sênior, com autoridade delegada pelo Superintendente de Segurança, com a responsabilidade de administrar as questões rotineiras de segurança dentro da organização.

Gerente de segurança computacional: gerente sênior, com autoridade delegada pelo Superintendente de Segurança, que presta contas ao Diretor de Segurança, tendo a responsabilidade de administrar a rotina da administração da segurança das questões de informática e tecnologia de toda a organização.

Equipe de segurança: grupo de indivíduos provenientes de diversos setores da organização, designados para realizar o exame da segurança e efetuar recomendações para a correção das vulnerabilidades detectadas. A equipe de segurança deve preferivelmente ser chefiada por um membro influente do grupo de usuários, de forma a que suas recomendações possam ser mais facilmente aceitas pelos dirigentes e usuários, do que se partissem de "especialistas técnicos".

Os elementos críticos que definem a qualidade dos controles do programa de segurança são:

Avaliação periódica do risco; Documentação do programa de segurança; Estrutura de gerência de segurança com atribuição clara de

responsabilidades; Políticas de segurança eficazes; Supervisão da eficácia do programa de segurança.

A seguir é apresentado um roteiro contendo os elementos críticos do Programa de Segurança.

49

CONTROLES GERAIS

1.2.4. Avaliação periódica do risco

Os riscos são periodicamente avaliados, de acordo com políticas documentadas para essa avaliação.

As avaliações do risco são realizadas por pessoal suficientemente independente (não diretamente responsável pelas questões de segurança), sendo revistas toda vez que algum sistema, instalação ou outra condição se altere.

A avaliação do risco leva em conta a vulnerabilidade inerente dos dados, e o risco adicional acrescentado pelos diversos caminhos de acesso passíveis de utilização por usuários e estranhos não autorizados.

As avaliações gerais de risco mais recentes estão de acordo com as políticas estabelecidas e atendem aos demais requisitos acima indicados.

1.2.5. Documentação do programa de segurança

O plano de segurança: foi documentado e aprovado pela alta gerência e pelos setores afetados; cobre todas as instalações e operações essenciais; é mantido atualizado, com revisões periódicas e ajustes que reflitam as

mudanças nas condições de operação e nos riscos.

1.2.6. Estrutura de gerência de segurança com atribuição clara de responsabilidades

O plano de segurança: estabelece uma estrutura de gerência de segurança com independência,

autoridade e conhecimento suficientes; prevê a existência de gerentes de segurança dos sistemas de informação tanto

em nível geral quanto nos níveis subordinados; identifica precisamente o proprietário de cada recurso computacional e os

responsáveis pela gerência do acesso a esses recursos; define as responsabilidades de segurança nos seguintes níveis: (1)

proprietários e usuários dos recursos de informação; (2) pessoal de processamento de dados; (3) alta gerência; e (4) administradores de segurança;

é periodicamente revisto e atualizado, estando em dia com as necessidades da entidade.

1.2.7. Políticas de segurança eficazes

50

CONTROLES GERAIS

Existe um programa de treinamento sobre as políticas de segurança, que inclui treinamento inicial de todos os novos funcionários e usuários; e treinamento periódico de atualização, e este está sendo seguido. Examinar os registros das atividades de treinamento.

Entrevistas com o pessoal que utiliza recursos computacionais demonstram que os funcionários estão cientes de suas responsabilidades quanto à segurança.

Os registros funcionais dos empregados que lidam com informações confidenciais e/ou trabalham em funções de segurança demonstram que estes possuem o conhecimento e a experiência requeridos na descrição dos cargos. Examinar uma amostra de registros funcionais e compará-la com a descrição contida no plano de cargos.

A entidade exige dos funcionários e usuários externos com acesso a informações confidenciais que assinem uma declaração de confidencialidade. Verificar as políticas de acordo com confidencialidade e examinar uma amostra de registros para constatar se esses usuários assinaram a declaração.

Não existem funcionários "proprietários" de informações críticas ou confidenciais (há previsão de mudanças de turno ou trocas de função entre funcionários com acesso a essas informações periodicamente, e as tarefas dos funcionários são redistribuídas durante suas férias).

Os registros funcionais indicam que efetivamente é feito um revezamento de pessoal nas tarefas de maior risco.

Os processos de transferência e demissão incluem procedimentos de segurança tais como:

devolução de crachás, chaves, passes de identificação, etc.; notificação da gerência de segurança para a pronta desativação de senhas de

acesso; imediata retirada do funcionário do local de trabalho; definição do período em que o funcionário afastado ficará sujeito à guarda do

sigilo das informações confidenciais às quais teve acesso.

1.2.8. Supervisão da eficácia do programa de segurança

A alta administração atua prontamente na correção de deficiências detectadas no programa de segurança.

As ações corretivas são testadas após terem sido implementadas para confirmar sua eficácia e, quando necessário, supervisionadas periodicamente. Verificar a situação das recomendações mais recentes da auditoria interna e se as medidas corretivas adotadas foram testadas quanto à sua eficácia.

1.3. Continuidade do Serviço

51

CONTROLES GERAIS

A perda da capacidade de processar, recuperar e proteger informações mantidas eletronicamente pode ter um impacto significativo na habilidade da organização em desempenhar sua missão.

Por essa razão, as organizações precisam ter procedimentos estabelecidos para proteger recursos de informação, minimizar o risco de interrupções não planejadas e recuperar operações críticas, em caso de interrupções. Esses planos devem considerar as atividades executadas nos ambientes de suporte em geral, tais como centros de processamento de dados, bem como nos ambientes de operação de aplicações específicas. Para se garantir que os planos de recuperação irão funcionar como previsto, eles devem ser testados periodicamente em exercícios de simulação de "desastres".

Embora freqüentemente chamados de planos de recuperação de desastres, os controles para garantir a continuidade do serviço devem enfocar todas as possibilidades de interrupção existentes, sejam elas interrupções relativamente insignificantes, tais como falta temporária de energia e destruição acidental de um arquivo, até problemas sérios, como incêndios ou desastres naturais que requeiram o restabelecimento das operações em outro local.

Se os controles não são adequados, mesmo interrupções menos graves podem resultar em perda ou processamento incorreto de dados, ocasionando prejuízos financeiros, esforços dispendiosos de recuperação e informações gerenciais ou financeiras inexatas ou incompletas. Para algumas operações, tais como as que envolvem cuidados médicos ou segurança pública, interrupções de sistema podem até mesmo resultar em danos pessoais ou perda de vidas.

Para diminuir as interrupções de serviço, é essencial que os controles estabelecidos sejam conhecidos e adotados pela gerência e pelo pessoal envolvido. O comprometimento da alta administração é importante para garantir que recursos adequados sejam dedicados para o planejamento de emergência, treinamento e testes necessários. O pessoal responsável por atividades de manutenção da continuidade de serviço, tais como realização de cópias de segurança de arquivos, precisa estar bem informado dos riscos da não realização dessas tarefas.

Os elementos críticos para a avaliação da continuidade do serviço são:

Avaliação da vulnerabilidade das operações computadorizadas e identificação dos recursos que as apoiam.

Adoção de medidas para prevenir e minimizar danos e interrupções potenciais.

Desenvolvimento e documentação de um plano geral de contingência. Teste periódico do plano de contingência e realização dos ajustes

apropriados.

A seguir é apresentado um roteiro contendo os elementos críticos da Continuidade de Serviço.

52

CONTROLES GERAIS

2.2.1. Avaliação da vulnerabilidade das operações computadorizadas e identificação dos recursos que as apoiam

A organização preparou uma lista de dados, operações e sistemas críticos que: informa a prioridade de cada item; foi aprovada pelos gestores responsáveis; reflete a situação atual dos recursos computacionais.

Os recursos que dão suporte às operações críticas foram identificados e documentados, incluindo hardware, software, fornecedores, documentação do sistema, telecomunicações, instalações e suprimentos de escritório e recursos humanos.

As prioridades de processamento emergencial foram documentadas e aprovadas pela alta administração e a gerência de processamento de dados.

1.3.2. Adoção de medidas para prevenir e minimizar danos e interrupções potenciais

1.3.2.1. Procedimentos de cópia de segurança (backup)

Cópias de segurança dos arquivos e da documentação dos sistemas são providenciadas e deslocadas para um local externo de armazenamento, com freqüência suficiente para evitar problemas em caso de perda ou dano dos arquivos em uso.

O local externo de armazenamento está localizado geograficamente distante da sede da organização e é protegido por controles ambientais e controles de acesso físico.

1.3.2.2. Controles de ambiente

Dispositivos de supressão e prevenção de incêndio foram instalados e estão em funcionamento (detetores de fumaça, extintores de incêndio etc).

Controles físicos foram implementados para evitar outros desastres, tais como inundação, elevação excessiva da temperatura etc. Os controles físicos são periodicamente testados.

Foi providenciada uma fonte substituta de suprimento de energia elétrica que permita, em caso de falha da fonte principal, a conclusão segura das operações em andamento.

Bebidas, alimentos e outros itens que possam danificar os equipamentos são proibidos no ambiente de computação. Verificar a existência e o cumprimento de normas de procedimentos a esse respeito.

1.3.2.3. Treinamento do pessoal para responder a emergências

Os procedimentos de emergência são periodicamente testados.

53

CONTROLES GERAIS

Os funcionários do centro de processamento de dados receberam treinamento para os casos de emergência, tendo sido informados de suas responsabilidades na ocorrência de eventos do gênero. Verificar se existem registros de treinamentos periódicos previstos e efetuados, para procedimentos de emergência envolvendo fogo, inundação e disparo de alarmes.

1.3.2.4. Medidas de prevenção de interrupções inesperadas

Existem políticas e procedimentos atualizados de manutenção de hardware, gerência de problemas e gerência de alteração de programas para prevenir interrupções inesperadas da operação.

Existe hardware de reserva que garanta, em casos de problemas com o equipamento principal, a disponibilidade do sistema para aplicações críticas e vulneráveis.

Manutenções periódicas de hardware e software são programadas e executadas de acordo com as especificações dos fornecedores, em circunstâncias que minimizem o impacto na operação e na utilização pelos usuários, e permitam a realização dos testes necessários.

Existe flexibilidade suficiente nas operações de processamento de dados para acomodar a manutenção regular e um número razoável de manutenções não previstas.

Mudanças nos equipamentos de hardware e no software associado são programadas de forma a minimizar o impacto da operação e utilização pelos usuários e permitir a execução dos testes necessários.

As mudanças de hardware são informadas com antecedência para os usuários, de forma a impedir que o serviço seja interrompido inesperadamente.

1.3.3. Desenvolvimento e documentação de um plano geral de contingência

1.3.3.1. Documentação do plano de contingência

Existe um plano de contingência devidamente documentado que: reflete as condições atuais da organização; foi aprovado pelos grupos mais afetados, incluindo a alta administração, DTI e

gerentes proprietários dos sistemas; atribui as responsabilidades de recuperação de forma clara; inclui instruções detalhadas para restaurar a operação, tanto do sistema

operacional quanto das aplicações críticas; identifica a instalação alternativa de processamento e o local externo de

armazenamento de cópias de segurança; inclui procedimentos a serem seguidos quando o centro de processamento de

dados estiver impossibilitado de receber ou transmitir dados; identifica os sistemas e os arquivos de dados críticos; é detalhado o suficiente para ser compreendido por todos os gerentes da

organização; foi distribuído para todas as pessoas apropriadas.

54

CONTROLES GERAIS

O plano prevê pessoal substituto, de forma a poder ser implementado independentemente de indivíduos específicos.

Os departamentos usuários possuem procedimentos de processamento manual e/ou periférico para uso até a restauração da operação.

Pelo menos duas cópias do plano de contingência atualizado estão armazenadas com segurança em diferentes locais.

O plano de contingência é periodicamente reavaliado e, se for o caso, revisto para refletir alterações no hardware, software e pessoal.

1.3.3.2. Alternativas de processamento de dados e telecomunicação

Existem acordos com outros órgãos ou entidades para estabelecer um centro de processamento de dados e de telecomunicação substituto, que:

ofereça condições de operação num espaço de tempo compatível com os riscos da operação interrompida;

tenha capacidade suficiente de processamento; apresente grande probabilidade de estar disponível para uso em caso de

necessidade.

1.3.3.3. Teste periódico do plano de contingência, e realização dos ajustes apropriados

O plano de contingência foi testado em condições que simulem um desastre. Examinar as políticas de teste e os relatórios da sua execução.

Os resultados dos testes foram documentados e um relatório com as "lições aprendidas" foi providenciado e encaminhado para a alta administração.

O plano de contingência e os acordos relacionados foram ajustados para corrigir quaisquer deficiências constatadas durante o teste.

1.4. Controles de Acesso

Os controles de acesso têm o propósito de oferecer uma garantia razoável de que os recursos computacionais (arquivos de dados, programas aplicativos, instalações e equipamentos relacionados aos computadores) são protegidos contra modificação ou divulgação não autorizada, perda ou dano. Eles incluem controles físicos, tais como manutenção dos computadores em salas trancadas para limitar o acesso físico, e controles lógicos (softwares de segurança projetados para prevenir ou detectar acesso não autorizado a arquivos críticos).

Controles de acesso inadequados diminuem a confiabilidade dos dados processados pelo sistema e aumentam o risco de destruição ou divulgação indevida de dados. Os seguintes exemplos ilustram as possíveis conseqüências de tais vulnerabilidades:

Obtendo acesso irrestrito a arquivos de dados, um indivíduo pode fazer mudanças não autorizadas para ganho pessoal ou para obter informações

55

CONTROLES GERAIS

controladas. Por exemplo, uma pessoa poderia: alterar o número da conta de um pagamento, desviando um desembolso para ela mesma; alterar quantidades de inventário, para esconder um furto; alterar uma quantia a receber; obter informações confidenciais a respeito de transações ou indivíduos.

O acesso a programas aplicativos utilizados para processar dados permite a modificação não autorizada desses programas, ou introdução de códigos de programação mal-intencionados, que poderiam ser utilizados para obter acesso a arquivos de dados, resultando em situações similares às indicadas no item anterior. Por exemplo, um funcionário poderia alterar o programa de cálculo dos salários e gerar um pagamento indevido para ele mesmo.

Sem a presença de controles nos terminais ou equipamentos de telecomunicação que permitem entrada nos sistemas computacionais da entidade, um indivíduo pode obter acesso a informações confidenciais ou de uso controlado que estejam em meios magnéticos ou impressos; substituir dados ou programas; furtar ou danificar intencionalmente equipamentos e programas de computador.

Os objetivos de limitação do acesso visam a garantir que:

os usuários tenham acesso somente aos recursos necessários para executarem suas tarefas;

o acesso a recursos de alto risco, tais como softwares de segurança, seja limitado a poucos indivíduos;

os funcionários estejam impedidos de executar funções incompatíveis ou além da sua responsabilidade.

Se esses objetivos são atingidos, o risco de modificação ou divulgação indevida de dados pode ser reduzido, sem interferência nas necessidades práticas dos usuários. O equilíbrio apropriado entre necessidades do usuário e requerimentos de segurança exige uma análise cuidadosa da vulnerabilidade e importância de cada recurso de informação disponível, em confronto com as tarefas executadas pelos usuários.

A implementação de controles de acesso apropriados exige primeiro a determinação do nível e tipo de proteção adequados a cada recurso e a identificação das pessoas que precisam ter acesso a esses recursos. Essas definições devem ser efetuadas pelos proprietários dos recursos. Por exemplo, os chefes de departamentos precisam determinar a importância dos seus programas e dados e que nível de acesso é apropriado para o pessoal que usa o sistema informatizado para executar, avaliar e relatar as operações do departamento. Da mesma forma, gerentes encarregados do desenvolvimento e modificação de sistemas devem determinar a vulnerabilidade dos recursos de hardware e software sob o seu controle e o nível de acesso necessário para os analistas de sistema e programadores, e assim por diante.

Os elementos críticos que determinam a adequação dos controles de acesso são:

56

CONTROLES GERAIS

Classificação dos recursos de informação de acordo com sua importância e vulnerabilidade;

Manutenção de lista atualizada de usuários autorizados e seu nível de acesso; Implantação de controles lógicos e físicos para prevenir ou detectar acesso

não autorizado; Supervisão do acesso, investigação de indícios de violação da segurança e

adoção das medidas corretivas apropriadas.

A seguir é apresentado um roteiro contendo os elementos críticos do Controle de Acesso.

1.4.1. Classificação dos recursos de informação de acordo com sua importância e vulnerabilidade

Existem políticas e procedimentos documentados para a classificação dos recursos de informação pelos critérios de importância e vulnerabilidade dos dados.

Os proprietários dos recursos estão cientes dos critérios de classificação estabelecidos e efetuaram a classificação dos principais recursos sob sua responsabilidade.

A classificação dos recursos foi baseada em avaliações de risco, documentada e aprovada pela alta administração e é periodicamente revisada.

1.4.2. Manutenção de lista atualizada de usuários autorizados e níveis de acesso

As autorizações de acesso são: documentadas em formulários padronizados e mantidas em arquivo

organizado; aprovadas pelo proprietário do recurso computacional; transmitidas para os gerentes de segurança de uma forma protegida.

Os proprietários dos recursos computacionais periodicamente revisam as autorizações de acesso para verificar se continuam necessárias e adequadas.

O número de usuários autorizados ao acesso remoto dos sistemas é limitado e justificativas para esse acesso são documentadas e aprovadas pelos proprietários dos recursos (v. item 4.3.3 para controles adicionais de acesso remoto).

Os gerentes de segurança revisam as autorizações de acesso e discutem quaisquer autorizações questionáveis com os proprietários dos recursos.

Todas as mudanças no perfil de segurança são automaticamente registradas e revisadas periodicamente pela alta administração.

57

CONTROLES GERAIS

Atividades não usuais são investigadas.

A segurança é notificada imediatamente quando usuários do sistema são demitidos ou transferidos.

As autorizações de acesso temporárias são: documentadas em formulários padrão e mantidas em arquivo; aprovadas pela gerência encarregada; comunicadas de uma forma protegida para o serviço de segurança; automaticamente desativadas após um período determinado.

Existem formulários padrão para documentar a aprovação para compartilhamento de arquivos de dados com outras entidades. Examinar formulários e entrevistar os responsáveis pela manutenção dos dados.

Antes do compartilhamento de dados ou programas com outras entidades, são formalizados acordos que definem como esses arquivos e programas serão protegidos. Examinar os documentos de autorização de compartilhamento e os acordos de segurança.

1.4.3. Controles lógicos e físicos para prevenção e detecção de acesso não autorizado

Todas as ameaças significativas para a segurança física dos recursos mais vulneráveis foram identificadas. Verificar a disposição física dos recursos.

O acesso físico é limitado aos funcionários que precisam rotineiramente dos recursos computacionais, através de vigias, crachás de identificação, cartões magnéticos para acionar portas de acesso etc. Observar os pontos de acesso às instalações durante a hora de funcionamento e fora do expediente; verificar a lista de pessoas com acesso autorizado às instalações quanto à adequação dos nomes incluídos.

A gerência revisa regularmente a lista de pessoas com acesso físico a instalações críticas.

Existem obstáculos físicos para o acesso à sala de computadores, fitoteca e outras instalações críticas.

Todas as entregas e retiradas de fitas magnéticas e outros meios de armazenar dados são autorizadas e registradas.

Chaves, cartões magnéticos de acionamento de portas e outros dispositivos de acesso de reserva (que não estão sendo usados pelos funcionários) são mantidos pela gerência de segurança de forma protegida.

58

CONTROLES GERAIS

Visitantes em áreas críticas, tais como sala do computador central e fitoteca, são formalmente registrados e acompanhados. Verificar o registro de entradas de visitantes; entrevistar os vigias e responsáveis pela segurança; observar o trânsito de pessoas pelas áreas críticas nos períodos dentro e fora do expediente normal.

Procedimentos adequados de abandono da área de risco em situações de emergência e de retorno do pessoal após a normalização da situação impedem o acesso de pessoal não autorizado às áreas críticas durante o evento (ameaça de incêndio e outros que exijam a desocupação do local).

As senhas são: únicas para indivíduos específicos, não grupos; controladas pelos usuários e não sujeitas a divulgação; alteradas periodicamente (entre 30 e 90 dias); não apresentadas na tela durante sua digitação; compostas de pelo menos seis caracteres alfanuméricos e impedidas de

repetição antes de seis trocas pelo menos.

Existem restrições quanto ao uso de nomes e palavras facilmente desvendáveis (analisar uma lista gerada pelo sistema de senhas em uso).

As senhas fornecidas para o primeiro acesso dos usuários são imediatamente alteradas.

Códigos de identificação e senhas de uso compartilhado pelos funcionários não são permitidos.

Os sistemas não permitem mais que três tentativas de log-on (entrada em comandos para iniciar uma sessão) com senhas inválidas.

Uma relação do pessoal em atividade, periodicamente atualizada, é usada para verificar automaticamente a lista de usuários autorizados do sistema para remoção da senha de funcionários demitidos ou transferidos.

Contas de acesso inativas são supervisionadas e removidas quando deixam de ser necessárias. Verificar as especificações do software de segurança, examinar uma lista gerada pelo sistema de usuários inativos e determinar por que o acesso desses usuários não foi cancelado.

Os usuários detentores de outros dispositivos de acesso, tais como códigos e cartões magnéticos, têm consciência da necessidade de sua guarda cuidadosa; de que estes não podem ser emprestados ou compartilhados; e de que sua perda deve ser imediatamente comunicada aos responsáveis.

Identificação de caminhos de acesso: é feita uma análise dos caminhos lógicos de acesso todas as vezes que ocorrem mudanças no sistema.

59

CONTROLES GERAIS

1.4.3.1. Controles lógicos sobre arquivos de dados e programas de software

Softwares de segurança são usados para restringir o acesso aos arquivos de dados e programas.

O acesso aos softwares de segurança é restrito aos administradores de segurança.

As sessões de acesso a sistemas via terminais de computador são terminadas automaticamente após um período de inatividade do operador.

Os responsáveis pela administração da segurança configuram o software de segurança para restringir o acesso não autorizado a arquivos de dados, bibliotecas de dados, procedimentos de operação em lote (batch), bibliotecas de código fonte, arquivos de segurança e arquivos de sistema operacional. Testar os controles tentando obter acesso a arquivos restritos.

1.4.3.2. Controles lógicos sobre a base de dados

Controles sobre os gerenciadores de banco de dados (SGBD ou DBMS) e dicionários de dados foram implementados para:

restringir o acesso a arquivos de dados nos níveis de leitura de dados, campos, etc.;

controlar o acesso ao dicionário de dados usando perfis de segurança e senhas;

manter trilhas de auditoria que permitam supervisionar mudanças nos dicionários de dados;

prever formas de pesquisa e atualização de funções de aplicativos, funções de SGBD e dicionário de dados.

O uso das facilidades de SGBD é limitado aos funcionários cujas atribuições exigem esse acesso.

O acesso ao software, às tabelas de segurança do SGDB, e a perfis de segurança do dicionário de dados é controlado e restrito ao pessoal autorizado.

1.4.3.3. Controles lógicos sobre acesso remoto

Um software de comunicação foi implementado para: identificar o terminal em uso, de forma a restringir o acesso por meio de

terminais específicos; checar IDs (códigos de identificação do usuário) e senhas para acesso a

aplicativos específicos; controlar o acesso através de conexões entre sistemas e terminais; restringir o uso de facilidades de rede em aplicações específicas; interromper automaticamente a conexão ao final de uma sessão; manter registros da atividade na rede; restringir o acesso a tabelas que definem opções de rede, recursos e perfis de

operador;

60

CONTROLES GERAIS

permitir que somente usuários autorizados desconectem componentes da rede;

supervisionar o acesso discado, através do controle da fonte de chamadas, ou pela interrupção da chamada e retorno da ligação para números de telefone previamente autorizados;

restringir o acesso interno aos softwares de telecomunicações; controlar mudanças nesses softwares; garantir que dados não sejam acessados ou modificados por um usuário não

autorizado, durante sua transmissão ou enquanto temporariamente armazenados;

restringir e supervisionar o acesso ao hardware de telecomunicações ou instalações.

Números para discagem remota não são publicados e são periodicamente alterados.

Ferramentas de criptografia foram implementadas para proteger a integridade e confidencialidade de dados e softwares vulneráveis ou críticos.

Existem procedimentos para apagar dados confidenciais e programas instalados em recursos a serem descartados pela entidade (leiloados, doados etc.).

1.4.4. Supervisão do acesso, investigação de evidências de violações de segurança e adoção de medidas corretivas

Trilhas de auditoria são mantidas e todas as atividades envolvendo acesso e modificação de arquivos vulneráveis ou críticos são registradas.

Violações de segurança e atividades suspeitas, tais como tentativas frustradas de entrada no sistema, são relatadas para a gerência e investigadas (examinar os relatórios sobre atividades suspeitas).

Os gerentes de segurança investigam as violações de segurança e relatam os resultados para a alta administração.

Medidas de disciplina são tomadas para corrigir as violações de segurança detectadas.

Políticas de controle de acesso são modificadas quando violações de segurança são detectadas.

61

CONTROLES GERAIS

1.5. Controles de Software

Software de sistema é o conjunto de programas projetados para operar e controlar as atividades de processamento de um equipamento computacional.

Normalmente, um software de sistema é utilizado para dar suporte e controlar uma variedade de aplicações que possam ser executadas num mesmo hardware de computador.

O software de sistema auxilia a controlar e coordenar a entrada, processamento, saída e armazenamento dos dados relativos a todas as aplicações executadas no sistema. Alguns softwares de sistema podem alterar dados e códigos de programa em arquivos, sem deixar uma trilha de auditoria.

São exemplos de software de sistema: software de sistema operacional; utilitários de sistema; sistemas de bibliotecas de programas; software de manutenção de arquivos; software de segurança; sistemas de comunicação de dados; sistemas de gerência de base de dados (SGBD).

O controle sobre o acesso e a alteração do software de sistema são essenciais para oferecer uma garantia razoável de que os controles de segurança baseados no sistema operacional não estão comprometidos, prejudicando o bom funcionamento do sistema computacional como um todo.

Se os controles nessa área forem inadequados, indivíduos não autorizados podem utilizar o software de sistema para desviar dos controles de segurança, bem como ler, modificar ou apagar informações e programas críticos ou vulneráveis. Softwares de sistema com controles ineficazes podem ser utilizados, ainda, para neutralizar controles presentes em programas aplicativos, diminuindo significativamente a confiabilidade da informação produzida pelas aplicações existentes no sistema computacional, e aumentando o risco de fraude e sabotagem.

As preocupações com o controle de software de sistema são similares às de controle de acesso discutidas na seção 4 e de controle de mudança de software a serem apresentados da seção 6. Entretanto, por causa do alto nível de risco associado com atividades de software de sistema, a maioria das entidades possui um conjunto separado de procedimentos de controle para essas atividades.

Os controles de software de sistema são avaliados através dos seguintes elementos críticos:

Acesso limitado ao software de sistema; Acesso e uso supervisionado do software de sistema; Controle das alterações do software de sistema.

62

CONTROLES GERAIS

A seguir é apresentado um roteiro contendo os elementos críticos do Software de Sistema.

1.5.1. Acesso limitado ao software de sistema

Existem políticas e procedimentos atualizados para a restrição do acesso ao software de sistema.

O acesso ao software de sistema é restrito a um número limitado de pessoas, cujas responsabilidades exijam esse acesso. (Programadores de aplicativos e operadores de computador não devem possuir autorização de acesso ao software de sistema.)

Os documentos com justificativa e aprovação da gerência para o acesso ao software de sistema são mantidos em arquivo.

O nível de acesso permitido aos programadores de sistema é periodicamente reavaliado pelos gerentes para ver se a permissão de acesso corresponde às necessidades de serviço. Verificar a última vez que o nível de acesso foi revisto.

1.5.1.1. Caminhos de acesso

O sistema operacional é configurado para impedir que os controles do software de segurança e de aplicativos sejam ignorados. Testar os parâmetros do sistema operacional para verificar se ele está configurado para manter a integridade do software de segurança e dos controles de aplicativos.

Todos os acessos a arquivos do software de sistema são automaticamente registrados.

Todas as senhas e códigos de entrada no sistema vindos de fábrica foram substituídos.

Controles físicos e lógicos foram instalados para proteger os terminais com acesso ao software de sistema, incluindo restrições ao acesso remoto a esses terminais.

1.5.2. Acesso e uso supervisionado do software de sistema

Existem políticas e procedimentos documentados e atualizados para o uso de utilitários do software de sistema.

As responsabilidades no uso de utilitários de sistema foram claramente definidas e compreendidas pelos programadores de sistema.

As responsabilidades pela supervisão do uso de utilitários de sistema estão definidas e são exercidas pela gerência de informática.

O uso de utilitários de sistema é registrado em relatórios produzidos pelo software de controle de acesso ou outro mecanismo de registro de acesso.

63

CONTROLES GERAIS

Os registros de acesso ao software de sistema e aos seus utilitários são periodicamente examinados pela gerência de informática, e atividades suspeitas ou não usuais são investigadas.

Revisões gerenciais são efetuadas para determinar se as técnicas de supervisão do uso do software de sistema estão funcionando como previsto e mantendo os riscos dentro de níveis aceitáveis (avaliações periódicas do risco).

1.5.3. Controle das alterações do software de sistema

Existem políticas e procedimentos atualizados para identificar, selecionar, instalar e modificar software de sistema, bem como identificar, documentar e solucionar problemas com esse software.

A implantação de novas versões do software de sistema ou seus utilitários segue procedimentos de segurança, que incluem:

justificativa documentada para a alteração; realização de testes conduzidos num ambiente próprio e não no ambiente de

operação normal; parecer técnico sobre os resultados do teste; revisão dos resultados dos testes e das opiniões documentadas, pelo gerente

de T.I.; autorização do gerente de T.I. para colocar a nova versão do software de

sistema em uso.

Existem procedimentos para controlar alterações de emergência, incluindo a forma de autorização e documentação das alterações de emergência, relatório do fato à gerência e revisão da alteração por um responsável pelo controle dessas alterações.

1.5.3.1. Instalação do software de sistema

A instalação é programada de forma a minimizar o impacto no processamento de dados, sendo comunicada com antecedência para os usuários.

A migração para o uso do novo software testado e aprovado é feita por um grupo independente, responsável pelo controle da biblioteca.

Versões ultrapassadas do software do sistema são removidas das bibliotecas de programas em uso.

A instalação de todo software de sistema é documentada e registrada, para estabelecer uma trilha de auditoria e permitir a supervisão da gerência de informática.

O software de sistema conta com o suporte do fornecedor.

O software de sistema e sua documentação são mantidos atualizados. Entrevistar a gerência e os programadores de sistema a respeito da atualização do software de sistema e sua documentação, e examinar a documentação para constatar se as alterações mais recentes foram incorporadas.

64

CONTROLES GERAIS

1.6. Controles de Desenvolvimento e Alteração de softwares Aplicativos

Softwares aplicativos são projetados para executar determinado tipo de operação, a exemplo do cálculo da folha de pagamento ou de controle de estoque. Tipicamente, diversas aplicações podem operar dentro de um mesmo conjunto de software de sistema.

Os controles sobre a modificação de programas aplicativos ajudam a garantir que somente programas e modificações autorizadas sejam implementadas.

Sem um controle apropriado, existe o risco de que características de segurança possam ser omitidas ou contornadas, intencionalmente ou não, e que processamentos errôneos ou códigos fraudulentos sejam introduzidos. Por exemplo:

um programador pode modificar código de programa para desviar dos controles e obter acesso a dados confidenciais;

a versão errada de um programa pode ser implementada, perpetuando processamentos errados ou desatualizados;

um vírus pode ser introduzido, prejudicando o processamento.

A principal preocupação deste item é com o controle exercido sobre os sistemas de software em operação (programas que manipulam os dados financeiros e informações utilizadas em auditorias, que sofrem a maior parte das alterações de software). Entretanto, os mesmos riscos e controles se aplicam aos sistemas em desenvolvimento.

Os elementos críticos para a avaliação dos controles de mudança e desenvolvimento de software são:

Características de processamento e modificações no programa são devidamente autorizadas

Todos os softwares novos ou revisados são testados e aprovados Bibliotecas de controle do software

A seguir é apresentado um roteiro contendo os elementos críticos do Controle de Alteração de Softwares Aplicativos

1.6.1. Características de processamento e alterações nos programas são devidamente autorizadas

Foi desenvolvida uma metodologia de desenvolvimento de sistemas que: fornece uma abordagem estruturada de desenvolvimento, compatível com os

conceitos e práticas geralmente aceitos, incluindo o envolvimento ativo dos usuários durante o processo;

é suficientemente documentada, sendo capaz de oferecer orientação a funcionários com diversos níveis de conhecimento e experiência;

oferece meios de controlar mudanças nos requisitos de projeto que ocorram durante a vida do sistema;

inclui requisitos de documentação.

O pessoal envolvido no desenvolvimento e teste de software foi treinado para utilizar a metodologia de desenvolvimento adotada pela entidade.

65

CONTROLES GERAIS

Formulários de solicitação de alteração de software são utilizados para documentar pedidos e autorizações de mudança.

As solicitações de alteração são submetidas à aprovação tanto dos usuários do sistema quanto do DTI.

Os softwares de domínio público ou de uso pessoal são objeto de políticas restritivas (é importante que a entidade tenha políticas claras com respeito ao uso de softwares de domínio público ou de propriedade pessoal do funcionário no trabalho. Permitir aos funcionários que utilizem seus próprios softwares, ou mesmo disquetes para armazenamento de dados que foram usados em outro lugar, aumenta os riscos de introdução de vírus, de violação de patentes e de processamento errado de dados, causado pela utilização de programas inadequados).

1.6.2. Todos os softwares novos ou alterados são testados e aprovados

Foram desenvolvidos padrões para os testes de software, que indicam as responsabilidades de cada parte envolvida (usuários, analistas de sistema, programadores, auditores, controle de qualidade etc.).

Planos de teste são documentados e aprovados.

Testes da rotina alterada e sua integração com o sistema são executados e aprovados de acordo com o plano de teste, utilizando um número suficiente de condições válidas e inválidas.

Uma amostra suficiente de transações e dados é utilizada para representar as várias atividades e condições que serão encontradas no processamento.

O ambiente de teste é diverso do ambiente real (de processamento) e os dados reais não são usados no teste de alterações de programas, exceto para construir arquivos de dados de teste.

Os resultados dos testes são revistos e documentados.

Alterações de programa são colocadas em uso somente após a aprovação formal dos usuários e da gerência de desenvolvimento de sistemas.

Quando o sistema novo ou modificado é posto em operação, a documentação é atualizada em relação ao software, hardware, pessoal de operação e usuários.

A gerência de informática e/ou os administradores de segurança periodicamente revisam as alterações introduzidas nos softwares para determinar se os controles de acesso e controles de alteração foram respeitados.

1.6.2.1. Alterações de emergência

66

CONTROLES GERAIS

Existem procedimentos de alterações de emergência documentados.

As alterações de emergência são: documentadas e aprovadas pelo supervisor de operação; formalmente relatadas à gerência de operação para as providências

necessárias; aprovadas, ainda que depois de realizadas, pelos gerentes de

desenvolvimento proprietário do sistema.

Existem procedimentos padrão para distribuição de software novo ou alterado a ser implementado.

Informações sobre a alteração, incluindo a data de sua realização, são fornecidas para todos os setores que mantenham uma cópia do sistema.

1.6.3. Bibliotecas de controle do software

1.6.3.1. Identificação e inventário de programas

Existe um software de gerenciamento da biblioteca para: produzir trilhas de auditoria de alterações no programa; manter números de versão dos programas; registrar e relatar alterações de programa; manter informações sobre datas de criação de módulos em uso; manter cópias de versões anteriores; controlar atualizações paralelas.

1.6.3.2. Restrições de acesso à biblioteca

Bibliotecas separadas são mantidas para programas em desenvolvimento e manutenção, programas em teste e programas em uso (em produção).

Códigos-fonte são mantidos em biblioteca própria.

O código em uso, código-fonte e cópias extras dos programas são protegidos por software de controle de acesso e por características de segurança do sistema operacional.

1.6.3.3. Controle do movimento de programas e dados entre bibliotecas.

Um grupo independente de usuários e programadores controla o movimento de programas e dados entre bibliotecas.

Reproduções do código do programa, antes e depois da alteração, são arquivadas e comparadas para garantir que somente as mudanças aprovadas foram implantadas.

67

2 CONTROLES DE APLICATIVOS

Controles de aplicativos são aqueles incorporados diretamente em programas aplicativos, nas três áreas de operação (entrada, processamento e saída de dados), com o objetivo de garantir um processamento confiável e acurado.

A avaliação dos controles de aplicativo deve sempre ser executada em conjunto com a verificação dos controles gerais do sistema informatizado, bem como da legalidade do processamento efetuado (isto é, se o seu produto final está de acordo com as leis em vigor e se está acarretando ou não desvio de recursos públicos).

O presente módulo tem por objetivo apresentar os controles que devem ser verificados em trabalhos de fiscalização que incluam a avaliação de um ou mais programas aplicativos da organização auditada.

2.1. Controles da Entrada de Dados

Os controles desta categoria são projetados para garantir que os dados são convertidos para um formato padrão e inseridos na aplicação de forma precisa, completa e tempestiva.

Os controles de entrada de dados devem detectar transações não autorizadas, incompletas, duplicadas ou errôneas, e assegurar que sejam controladas até serem corrigidas.

2.1.1. Documentos ou telas de entrada de dados

Existem procedimentos documentados para a inserção de dados na aplicação.

Os documentos ou telas de entrada garantem a entrada de dados de maneira exata e consistente.

Os campos de dados de preenchimento obrigatório são facilmente identificáveis na tela.

Existem padrões para as telas de entrada, quanto à sua apresentação, disposição dos campos e acionamento de teclas.

68

DESENVOLVIMENTO DE SISTEMAS

2.1.2. Rotinas de preparação dos dados (batch)

Existem rotinas para a preparação dos dados a serem preenchidos em cada documento.

Há pessoas claramente identificadas como responsáveis pela preparação, revisão e autorização da entrada de dados.

Existem rotinas escritas para cada atividade do processo de preparação de dados, com instruções claras e adequadas.

2.1.3. Autorização para entrada de dados

Nem sempre é possível se ter procedimentos de autorização antes da entrada de dados. Em sistemas de entrada de dados on-line, são indispensáveis as rotinas de validação de dados para compensar a ausência da autorização. O sistema deve checar automaticamente se o usuário está cadastrado para usar aquele aplicativo e se os dados por ele preenchidos satisfazem a certas condições.

A organização deve estabelecer rotinas que impeçam o uso não autorizado ou o mal uso de microcomputadores ou terminais durante a entrada de dados.

As verificações abaixo indicadas devem ser utilizadas para entrada de dados batch ou on-line:

no caso de aplicativos em que a entrada de dados ocorre em terminais ou microcomputadores, há procedimentos de segurança para o uso, manutenção e controle de códigos de identificação do operador e do terminal ou estação de trabalho.

os códigos de identificação do operador e do terminal são checados no processo de autorização de entrada de dados.

existem procedimentos documentados para que, em caso de transmissão eletrônica de documentos, a rota utilizada e os procedimentos de autorização sejam registrados.

os microcomputadores e terminais usados pela organização para a entrada de dados estão localizados em salas fisicamente seguras.

as rotinas de entrada de dados da organização asseguram que esta atividade só pode ser executada por funcionários com determinado nível de acesso.

as rotinas de entrada de dados da organização prevêem a gerência e utilização de senhas para prevenir o uso não autorizado de microcomputadores e terminais.

existem números e códigos de identificação únicos e individuais para possibilitar o controle do acesso aos dados.

existem mecanismos de segurança para gerenciar o acesso batch a arquivos de dados.

Verificações para aplicações com entrada de dados batch:

69


a aprovação da entrada de dados está limitada aos indivíduos especificados pela organização em documento escrito.

o pessoal responsável pela autorização da entrada de dados não executa outras tarefas incompatíveis pelo princípio da segregação de funções (v. módulo de Controles Gerais, Controles Organizacionais - Segregação de Funções - item 1.2.).

Na entrada de dados on-line deve ser verificado se:

existem controles lógicos e físicos nos terminais e microcomputadores para prevenção e detecção de entrada de dados não autorizados.

foram instalados mecanismos de segurança para gerenciar a autorização de acesso às transações on-line e aos registros históricos associados.

os mecanismos de segurança da organização garantem que todas as tentativas de acesso, com ou sem sucesso, são gravadas em logs que registram data e hora do evento de acesso e identificam o usuário.

2.1.4. Retenção de documentos de entrada (sistema batch)

Os documentos originais devem ser retidos pela organização por um determinado período de tempo com intuito de facilitar a recuperação ou reconstrução de dados.

Existem procedimentos documentados para retenção de documentos-fonte na organização.

Os documentos ficam retidos por tempo suficiente para permitir a reconstrução de dados, caso sejam perdidos durante a fase de processamento.

Os documentos são mantidos em arquivos organizados, para fácil recuperação.

O departamento que originou os documentos mantém cópias dos mesmos.

Somente as pessoas devidamente autorizadas têm acesso aos documentos arquivados.

Existem procedimentos documentados para remover e destruir os documentos quando expirado o tempo de retenção, e estes são obedecidos.

2.1.5. Validação dos dados de entrada

A organização deve estabelecer rotinas que assegurem que os dados de entrada são validados e editados de forma a espelharem corretamente os documentos originais.

Existem procedimentos documentados que definem o formato dos dados para assegurar a entrada de dados no campo correto e com o formato adequado.

Nas rotinas de entrada de dados existem informações de ajuda (help) para facilitar a entrada de dados e reduzir o número de erros.

70


Existem mecanismos para a validação, edição e controle da entrada de dados (terminais inteligentes ou software dedicado a essa função).

Os campos essenciais para o correto processamento posterior dos dados são de preenchimento obrigatório.

Existem rotinas para detectar, rejeitar e impedir a entrada de dados incorretos no sistema.

A validação dos dados é executada em todos os campos relevantes do registro ou tela de entrada.

As rotinas de validação de dados testam a presença de : códigos de aprovação e autorização; dígitos de verificação em todas as chaves de identificação; dígitos de verificação ao final de uma seqüência (string) de dados numéricos; códigos válidos; valores alfanuméricos ou numéricos válidos; tamanhos válidos de campo; campos combinados; limites válidos, razoabilidade dos valores ou faixa de valores válida; campos obrigatórios preenchidos; símbolos; registros de entrada completos; campos repetitivos, eliminando a necessidade da entrada dos mesmos dados

mais de uma vez.

A organização utiliza totais de controle de processamento em lote (batch), gerados pelos terminais de entrada de dados ou pelo software dos microcomputadores, para assegurar que todos os dados enviados em lote foram recebidos corretamente.

A rotina de entrada de dados da organização estabelece um registro histórico dos dados, proporcionando uma trilha de auditoria.

2.1.6. Tratamento de erros

A organização deve estabelecer rotinas para correção e re-submissão de dados de entrada incorretos.

Existem rotinas para identificação, correção e re-submissão de dados incorretos.

71


A rotina de entrada de dados possui procedimentos automáticos ou manuais que permitem que dados errôneos sejam prontamente corrigidos e re-submetidos;

Existe controle sobre os erros ocorridos na entrada de dados, sendo possível identificá-los, juntamente com as medidas que foram tomadas para corrigi-los e o tempo transcorrido entre a sua ocorrência e sua correção.

As mensagens de erro geradas pela rotina de entrada de dados são suficientemente claras e fáceis de serem entendidas pelo usuário do terminal ou microcomputador, facilitando a correção e a re-submissão dos dados.

2.1.7. Mecanismos de suporte para entrada de dados

A organização possui um grupo de controle responsável pelas seguintes atividades:

investigar e corrigir qualquer problema operacional no terminal, microcomputador ou outro dispositivo de entrada de dados;

assegurar que os procedimentos de reinicialização são executados de maneira apropriada;

monitorar as atividades de entrada de dados no terminal, microcomputador ou outro dispositivo similar;

investigar qualquer desvio dos procedimentos de entrada de dados pré-estabelecidos.

Os recursos computacionais e humanos disponíveis para a entrada de dados garantem que estes sejam inseridos tempestivamente.

2.2. Controles do Processamento de Dados

Os controles de processamento devem assegurar que todos os dados de entrada sejam processados e que o aplicativo seja executado com sucesso, usando os arquivos de dados, as rotinas de operação e a lógica de processamento corretos.

2.2.1. Integridade do processamento

Existem procedimentos documentados que explicam a forma com que os dados são processados pelo programa aplicativo.

Os sistemas on-line estão protegidos contra a atualização simultânea de arquivos por diferentes usuários.

Existem registros históricos (logs) que armazenam eventos ocasionados pelo computador e seus operadores durante o processamento da aplicação, fornecendo uma trilha de auditoria das transações processadas.

Os códigos de identificação do usuário, do terminal ou do microcomputador, juntamente com os dados de data, hora e informação anterior à alteração (esta última quando a relevância justificar) são mantidos em registros históricos.

72


2.2.2. Validação do processamento

Dados incorretos são rejeitados pelo aplicativo.

Procedimentos de validação são executados em todos os campos relevantes ou de preenchimento obrigatório, antes da gravação dos dados.

Em rotinas de arredondamento matemático há um controle do efeito provocado por esse arredondamento.

2.2.3. Tratamento de erros do processamento

As rotinas de tratamento de erro devem ser capazes de identificar transações com erros e suspender seu processamento sem afetar a execução de outras transações válidas. Existem procedimentos documentados para identificação, correção e reinserção de dados rejeitados.

As mensagens geradas pelas rotinas de tratamento de erro de processamento são claras e objetivas.

Os arquivos temporários de dados rejeitados pelo sistema são controlados adequadamente e geram mensagens de alerta para que estes dados sejam devidamente revisados e corrigidos.

Existe controle sobre os erros ocorridos durante o processamento de dados, sendo possível identificá-los, juntamente com as medidas que foram tomadas para corrigi-los e o tempo transcorrido entre a sua ocorrência e sua correção.

2.3. Controles da Saída de Dados

Controles da saída de dados são utilizados para garantir a integridade e a correta e tempestiva distribuição dos dados de saídas.

2.3.1. Revisão dos dados de saída

Os relatórios de dados de saída são revisados com relação à sua integridade e exatidão antes da sua liberação para os usuários.

Existem procedimentos documentados para relatar, corrigir e refazer relatórios de saída com erros.

A revisão dos relatórios de saída inclui o confronto das contagens de registros com totais de controle para garantir que dados não foram inseridos ou omitidos indevidamente.

2.3.2. Distribuição dos dados de saída

Cada relatório impresso é etiquetado para identificar o nome do produto, nome do destinatário e data e hora de produção.

73


Existem procedimentos escritos que descrevem o processo de distribuição dos dados de saída (relatórios impressos ou on-line).

Existem listas de distribuição pré-definidas para todos os dados criados pela aplicação. As listas de distribuição de dados são alteradas de acordo com as necessidades da organização.

Os usuários são questionados periodicamente para determinar se os dados produzidos continuam sendo necessários ou úteis.

Os relatórios impressos são entregues ao seu destino dentro dos prazos estipulados.

Existe controle sobre os dados de saída apresentados na tela para os usuários, impedindo adulterações.

Existe um registro histórico das informações sobre os dados de saída.

Existem procedimentos documentados para reportar e controlar os erros ocorridos no processamento dos dados de saída.

Os usuários são comunicados sobre os erros dos relatórios recebidos.

São mantidos registros dos relatórios com erros.

Existe controle sobre os erros ocorridos em relatórios (batch ou on-line), sendo possível identificar os erros, as medidas que foram tomadas para corrigi-los e o tempo transcorrido entre a ocorrência do erro e sua correção.

2.3.3. Segurança dos dados de saída

A organização deve manter procedimentos para restringir o acesso aos relatórios apenas ao pessoal autorizado.

Existem procedimentos documentados para classificar os relatórios como confidenciais, críticos ou de acesso geral.

Existem procedimentos adequados que asseguram a segurança dos relatórios considerados confidenciais pela organização.

Há procedimentos para restringir o acesso de dados confidenciais somente às pessoas autorizadas.

Os usuários com acesso a relatórios confidenciais (impressos ou on-line) têm conhecimento da necessidade de sigilo e tomam medidas adequadas para protegê-los.

Os relatórios confidenciais são claramente identificados ou marcados. Estes, quando não são mais úteis à organização, são destruídos de forma adequada.

74

3. DESENVOLVIMENTO DE SISTEMAS

A auditoria do desenvolvimento de sistemas objetiva avaliar a adequação das metodologias e procedimentos de projeto, desenvolvimento, implantação e revisão pós-implantação dos sistemas produzidos dentro da organização auditada. Essa avaliação pode abranger apenas o ambiente de desenvolvimento da organização ou prever também a análise do processo de desenvolvimento de um sistema específico, ainda na fase de planejamento, já em andamento ou após sua conclusão.

O desenvolvimento de um sistema de informação representa um investimento que não pode ser assumido sem dados confiáveis e precisos sobre o custo do projeto, seus benefícios e os riscos envolvidos. Todos os projetos de desenvolvimento de sistemas precisam ter sido avaliados em profundidade, devendo ser precedidos de análises de custo/benefício, capacidade de satisfação dos usuários e de atendimento aos objetivos da organização, custos de desenvolvimento, medidas de desempenho, planos de implementação, previsão de recursos humanos etc. São necessários, também, mecanismos gerenciais que auxiliem a definição da prioridade dos projetos e permitam sua avaliação e controle durante todo o processo de desenvolvimento.

O desenvolvimento de sistemas possui diversas fases de evolução que podem ser separadas da seguinte forma: Planejamento; Elaboração do plano de desenvolvimento e início do projeto; Organização do projeto; Elaboração do projeto de sistema; Revisão e aprovação pelos dirigentes; Desenvolvimento e Implantação; e Revisão de pós-implementação.

A seguir é apresentado um roteiro para auditoria em sistemas em desenvolvimento, que irá permitir a avaliação do ambiente e do processo de desenvolvimento de sistemas na organização auditada.

3.1. Fase 1: Planejamento

A organização: identifica as necessidades de informação ainda não atendidas e estabelece um

plano de ação para o desenvolvimento dos sistemas de maior prioridade; estabelece e documenta as metodologias de desenvolvimento a serem

adotadas; define e documenta as responsabilidades de todas as pessoas envolvidas no

desenvolvimento de sistemas.

75


A organização possui uma estratégia de desenvolvimento de sistemas de informação e elaborou um plano operacional consistente com essa estratégia, estabelecendo a prioridade dos sistemas a serem desenvolvidos de acordo com sua importância para o cumprimento da missão institucional.

Foi estabelecida uma metodologia de desenvolvimento de sistemas que: fornece uma abordagem estruturada de desenvolvimento, compatível com os

conceitos e práticas geralmente aceitos; prevê o envolvimento ativo dos usuários no processo de desenvolvimento de

sistemas; prevê o uso de técnicas atuais, tais como tecnologia de banco de dados, redes

de comunicação de dados, ferramentas CASE, linguagens de quarta geração, prototipação etc.;

é suficientemente documentada, sendo capaz de oferecer orientação a funcionários com diversos níveis de conhecimento e experiência;

oferece meios de controlar mudanças nos requisitos de projeto que ocorram durante a vida do sistema;

inclui requisitos de programação, documentação, padrões para usuários, programadores, desenvolvedores de sistemas e operadores do centro de processamento de dados;

estabelece mecanismos de reavaliação, acompanhamento e controle em todas as fases do processo, pela equipe e as gerências envolvidas, permitindo redirecionar os trabalhos ou abandonar o projeto, quando se concluir que o novo sistema não irá atender às necessidades da organização.

A organização definiu e documentou as responsabilidades de todas as pessoas envolvidas no desenvolvimento de sistemas.

Foram estabelecidos padrões para os testes dos sistemas produzidos, com indicação das responsabilidades de cada parte envolvida (usuários, analistas de sistema, programadores, auditores, controle de qualidade etc).

O pessoal envolvido no desenvolvimento e teste de software foi treinado para utilizar a metodologia adotada pela entidade e possui habilidades e conhecimentos suficientes.

3.2. Fase 2: Elaboração do plano de desenvolvimento e início do projeto

O projeto é avaliado mais minuciosamente quanto a análises de viabilidade técnica, custo/benefício etc. Sendo confirmada a conveniência do desenvolvimento do projeto, a organização estabelece e aprova um plano de desenvolvimento ou modernização do sistema específico, com elementos suficientes para permitir o seu projeto físico e lógico na próxima fase (natureza e abrangência do sistema, requisitos de usuário que deverão ser atendidos e outras informações relevantes).

É selecionada a equipe de projeto, que deve ter, no conjunto, habilidades e conhecimentos suficientes para conduzir com sucesso as atividades de elaboração do projeto físico e lógico, desenvolvimento e implantação do sistema.

76


O sistema a ser desenvolvido foi avaliado mais minuciosamente, tendo sido realizadas análises abrangendo custo/benefício, estudo de viabilidade técnica, importância da informação para os usuários e sua relação com os objetivos gerais e funcionais da organização, custos de desenvolvimento, planos de implementação, previsão de recursos humanos e demais elementos relevantes para a tomada de decisão.

A organização estabeleceu e aprovou um plano de desenvolvimento ou modernização de sistema, com elementos suficientes para permitir o seu projeto físico e lógico (identificando a natureza do sistema, requisitos de usuário que deverão ser atendidos e outras informações relevantes).

O projeto objetiva atacar deficiências reconhecidas ou problemas sistêmicos da organização.

As estimativas e análises feitas em relação a cronograma e custos são razoáveis, e os benefícios esperados são atingíveis.

Foram reservados recursos suficientes para a completa realização do projeto.

Foi designada uma equipe de projeto, formada por representantes do grupo de usuários e do DTI, e que possui, em conjunto, os requisitos de habilidade e conhecimento necessários para desempenhar a tarefa.

3.3. Fase 3: Organização do projeto

A equipe de projeto, com base no plano de desenvolvimento aprovado, cria e submete à gerência um plano de trabalho, informando a abrangência e conteúdo do projeto, bem como os mecanismos de acompanhamento e controle (cronograma, datas-limite, processo de supervisão e acompanhamento das etapas, medidas de desempenho etc.), de acordo com o estabelecido na metodologia de desenvolvimento de sistemas.

A equipe de projeto definiu claramente a abrangência do projeto e o conteúdo do sistema de forma coerente com os objetivos previstos no plano de desenvolvimento.

Os usuários concordaram com a abrangência e o conteúdo do sistema.

Foi elaborado o plano de trabalho, contendo os mecanismos de acompanhamento e controle do processo (cronograma, datas-limite, processo de supervisão e acompanhamento das etapas, medidas de desempenho), de acordo com a metodologia de desenvolvimento de sistemas.

O plano de trabalho foi devidamente analisado e aprovado pela gerência de planejamento (ou similar) e pelo DTI.

3.4. Fase 4: Elaboração do projeto do sistema

A fase de elaboração do projeto de sistema consiste na produção dos seus projetos físico e lógico utilizando a metodologia de desenvolvimento de sistemas padrão de organização .

77


A equipe de projeto define detalhadamente as especificações técnicas e funcionais do sistema, da forma mais completa possível, e elabora o projeto de sistema de acordo com essas especificações, levando em conta o ambiente de operação existente.

A equipe de projeto elaborou os projetos físico e lógico do sistema e produziu um documento que apresenta:

características do sistema - físicas (plataforma, recursos exigidos) e funcionais (atividades a serem executadas);

restrições ou impedimentos que possam limitar sua implementação; tecnologias envolvidas (arquitetura do sistema, sistemas de segurança,

questões de integração, tais como interconectividade e interoperabilidade); abordagem adotada para o projeto, seus componentes mais importantes e

como eles deverão operar em conjunto para atingir os objetivos organizacionais;

relatórios de viabilidade técnica, análise de riscos e custo/benefício do projeto; controles preventivos e corretivos, e trilhas de auditoria para os pontos críticos

do sistema.

Os projetos físico e lógico estão dentro dos padrões adotados pela organização no que diz respeito a hardware, software, sistema operacional e linguagem de programação.

Os relatórios de viabilidade técnica, análise de riscos e custo/benefício são consistentes e confiáveis.

3.5. Fase 5: Revisão e aprovação pelos dirigentes

Os departamentos envolvidos revisam todos os documentos produzidos para determinar se o projeto é adequado para atender às necessidades organizacionais e de usuários; confirmam a exeqüibilidade do projeto dos pontos de vista tecnológico e orçamentário; analisam o risco de atrasos ou extrapolação do orçamento e aprovam o ingresso na fase de desenvolvimento.

A equipe de projeto submeteu aos superiores um relatório (ou documento similar) para revisão e aprovação do projeto.

O gerente de TI analisou os documentos produzidos nas fases anteriores e concordou com o seu conteúdo.

A área usuária aprovou o relatório da equipe do projeto, autorizando-a a seguir para a fase de desenvolvimento e implantação do sistema

3.6. Fase 6: Desenvolvimento e Implantação

A equipe desenvolve (isto é, codifica, integra e testa) o sistema e avalia sua qualidade.

Os usuários testam o sistema e aprovam ou não sua implantação (etapa também conhecida como homologação).

O sistema aprovado é implantado, de acordo com planos detalhados de testes, transição, implantação e operação.

78


O sistema foi produzido de acordo com a metodologia de desenvolvimento adotada pela organização e atende às especificações de projeto.

A documentação do sistema desenvolvido é apropriada, estando dentro dos padrões adotados pela organização no que diz respeito a hardware, software, sistema operacional e linguagem de programação, e contém descrição lógica, diagrama de fluxo de dados, descrição de arquivos, modelo de relatórios e outros itens considerados relevantes para o seu bom entendimento e controle.

Foram preparados manuais de operação, de usuário e de manutenção do sistema, bem como um plano de treinamento dos futuros usuários.

3.6.1. Teste do sistema

Foi criado um plano detalhado para o teste do sistema, compatível com os padrões de teste estabelecidos pela organização e respeitando as responsabilidades definidas para cada parte envolvida (usuários, analistas de sistema, programadores, auditores, controle de qualidade etc.).

Testes do sistema e de integração com outros sistemas foram executados e aprovados de acordo com o plano de teste, utilizando um número suficiente de condições válidas e inválidas.

Amostras suficientes de transações e dados foram utilizadas para representar as várias atividades e condições que serão encontradas no processamento real.

O ambiente de teste é diverso do ambiente real e dados reais não são usados no teste de programas, exceto para construir arquivos de dados de teste.

Os testes foram revistos, documentados, seus resultados analisados e aprovados pelo DTI e pela área usuária do sistema.

Foi efetuado um teste de aceitação final junto a usuários selecionados.

As deficiências de desempenho foram devidamente corrigidas antes do sistema ser considerado em condições de entrar em operação.

3.6.2. Implementação

O sistema desenvolvido é colocado em uso somente após a aprovação formal dos usuários e da gerência de desenvolvimento de sistemas.

Quando o sistema novo é posto em operação, a documentação é atualizada em relação ao software, hardware, pessoal de operação e usuários.

Existem procedimentos padrão para distribuição de software novo a ser implementado.

3.6.3. Bibliotecas de controle

79


As bibliotecas dos sistemas em desenvolvimento são independentes das de sistemas em manutenção, testes e programas em uso.

Os códigos-fonte são mantidos em biblioteca própria.

3.7. Fase 7: Revisão de pós-implementação

A gerência de desenvolvimento de sistemas verifica o grau de satisfação dos usuários com os sistemas implementados e checa se os requisitos iniciais do usuário foram ou não satisfeitos.

Foram feitas avaliações de resultado do sistema desenvolvido, do atendimento das necessidades e requisitos dos usuários e do seu grau de satisfação.

O sistema foi testado para verificar sua conformidade aos padrões de desenvolvimento e implantação estabelecidos pela organização.

80

4. BANCO DE DADOS

Tradicionalmente, o termo banco de dados foi usado para descrever um arquivo contendo dados acessíveis por um ou mais programas ou usuários. Os arquivos de dados eram designados para aplicações específicas e o programa era projetado para acessá-los de uma forma predeterminada. Essa abordagem, no entanto, oferecia muitas dificuldades, caso os dados ou o programa tivessem que ser modificados.

Uma alternativa mais moderna é o acesso do banco dados por meio de um sistema gerenciador de banco de dados (SGBD ou DBMS, do inglês Database Management System).

Os SGBD surgiram para resolver problemas relativos a dados duplicados e deficiências na integridade e segurança dos dados. Antes deles, à medida que um aplicativo era desenvolvido, os dados necessários eram produzidos quase sempre em um formato específico para aquele programa. Se, por exemplo, um sistema de pessoal era criado, seguido por um sistema de folha de pagamento, era normal que os dois sistemas tivessem cópias separadas de elementos de dados comuns. Dessa forma, os dados eram duplicados e sua integridade ameaçada, já que as cópias de dados rapidamente perdiam o sincronismo.

O papel do SGBD é manter e organizar os dados e torná-los disponíveis para programas aplicativos, quando requisitados. O gerenciador de banco de dados é um software complexo, que se responsabiliza também pela segurança e integridade dos dados, eliminando diversas tarefas de administração que antes precisavam ser executadas pelos aplicativos.

Os sistemas gerenciadores de banco de dados tornaram-se um requisito essencial na maioria dos ambientes de tecnologia da informação. Apesar do alto custo de sua instalação, suas vantagens costumam compensá-lo.

As principais funções desempenhadas pelo SGBD são: manter os arquivos que constituem o banco de dados; oferecer uma interface uniforme para usuários e aplicativos que utilizam os

dados; fornecer elementos de dados para aplicativos que os solicitem; diminuir a necessidade de que o aplicativo saiba como os dados são

armazenados (estruturas de arquivos e registros); manter a integridade dos dados, quanto ao seu conteúdo (validação) e

referência (dependência de um elemento na existência de outro); controlar o acesso aos dados por meio de mecanismos de segurança.

4.1. Dicionários de dados

Quando os dados são compartilhados por duas ou mais aplicações, como acontece com os bancos de dados, é preciso manter um registro de todos os elementos de dados disponíveis no sistema, suas características e como eles são usados pelos programas aplicativos. Dicionários de dados foram desenvolvidos com esse objetivo.

Normalmente, os Dicionários de Dados armazenam as seguintes informações para cada elemento:

81

BANCO DE DADOS

descrição (nome dos elementos de dados, descrição do seu conteúdo); formato e estrutura dos elementos de dados; relação com outros elementos de dados; programas ou transações com acesso aos dados, e razão para esse acesso; relatórios de saída que contêm os elementos de dados.

4.2. Armazenamento de dados

O método usado para armazenar os dados fica a cargo do próprio SGBD e depende do tipo de sistema adotado, que pode ser hierárquico, em rede ou relacional.

Os SGBD hierárquicos e em rede normalmente armazenam dados como uma estrutura de registros vinculados por ponteiros. Eles oferecem acesso rápido, mas sua manutenção é complexa.

Sistemas relacionais, os quais se baseiam em uma teoria matemática definida pelo Professor Ted Codd, nos anos 70, armazenam registros de dados em tabelas. Cada tabela é representada por um arquivo indexado. O relacionamento que existe entre registros é mantido mediante o uso de campos de referências cruzadas das tabelas, as quais são avaliadas durante o tempo de acesso aos dados. Isso significa que o sistema relacional é de fácil manutenção, porém mais lento quanto ao acesso quando comparado aos sistemas hierárquicos ou em rede.

4.3. Acesso ao banco de dados

O acesso a banco de dados é uma necessidade não só para programadores mas também para usuários do sistema e gestores. A maioria dos gerenciadores de banco de dados (SGBD) modernos oferecem diversos meios de acesso aos dados nele armazenados, operando dentro de um esquema de controle de acesso bastante rigoroso.

Geralmente as consultas aos dados são feitas por um mecanismo interativo, por meio do qual o usuário é instado a fornecer instruções sobre que dados estão sendo requisitados. Esse mecanismo de solicitação de dados é freqüentemente específico para um sistema, mas hoje há uma linguagem padrão ANSI chamada SQL, que foi projetada para atender ao modelo de banco de dados relacional mencionado anteriormente.

A SQL (Structured Query Language, ou Linguagem de Consulta Estruturada), interpretada pelo SGBD, exige apenas que o usuário defina quais os dados desejados, dispensando-o de informar como encontrá-los. Isso, mais uma vez, facilita o trabalho de desenvolvimento de aplicativos e representa uma das maiores vantagens do uso dos SGBD, que é a independência dos dados.

4.4. Bancos de dados distribuídos

Normalmente o banco de dados é armazenado em um sistema computacional único, estando disponível para usuários diretamente conectados a esse sistema, ou com acesso via rede. Esse tipo de banco de dados, dito centralizado, muitas vezes satisfaz completamente as necessidades da organização.

Em algumas organizações, entretanto, existe a necessidade de acesso aos mesmos dados em diferentes localidades. Uma solução alternativa seria instalar banco de

82

BANCO DE DADOS

dados duplicados em cada localidade, com uma cópia de todos os dados ou apenas dos dados locais. Isso oferece independência a cada localidade com relação à disponibilidade dos dados, caso seja interrompido o acesso ao sistema central, mas acarreta problemas de manutenção, integridade e duplicação dos dados.

A melhor solução, nesses casos, é o uso de um SGBD que permita um banco de dados distribuído. Cada localidade participante executa uma cópia do SGBD, que coopera com as demais por meio da rede e, para todos os efeitos, forma um sistema único.

Os dados que são compartilhados por meio da rede pelas diversas localidades também são tratados pelo SGBD como um banco de dados único e completo. Os dados são distribuídos pela a rede de acordo com as solicitações de cada localidade, aumentando a velocidade do acesso.

Por exemplo, um vendedor poderia solicitar informações sobre todos os pedidos dos clientes da companhia em que trabalha. O SGBD responderia juntando todos os pedaços da informação espalhados pela rede e formando o conjunto de dados solicitado.

Os dados podem ser distribuídos de forma horizontal (por registros) ou vertical, (por campos dentro de uma tabela), de acordo com a necessidade específica. A distribuição do banco de dados evita a dependência de uma só máquina e a necessidade da duplicação de dados.

Os banco de dados distribuídos são projetados para manter todas as vantagens oferecidas pelos SGBD e funcionam, do ponto de vista do usuário, da mesma forma que um banco de dados centralizado.

4.5. Administração de banco de dados

O tamanho e a complexidade das bases de dados exigem que as organizações possuam um pessoal especificamente designado para cuidar de todos os aspectos da administração do banco de dados (coletivamente chamados de administrador de banco de dados). As tarefas do administrador de banco de dados incluem a manutenção de estruturas e sub-estruturas de dados, do software de SGBD e programas relacionados, documentação do banco de dados, verificação da compatibilidade de novos sistemas com o banco de dados, procedimentos de cópias de segurança, registros históricos e recuperação de falhas do banco de dados etc. O administrador de banco de dados é responsável, também, pela manutenção de controles sobre os dados, podendo combinar responsabilidades que abranjam procedimentos e controles, que em sistemas convencionais seriam normalmente efetuados por pessoas diferentes. Quando esses procedimentos e controles estiverem muito concentrados no administrador de banco de dados, é importante, para preservar a adequada segregação de funções, que esse administrador seja impedido de obter acesso não supervisionado às instalações computacionais e aos sistemas em operação, bem como de iniciar transações.

4.6. Administração de dados

Outro técnico que merece destaque no DTI é a figura do administrador de dados. Este é responsável pelo controle de todos os tipos de dados que são manipulados pelo

83

BANCO DE DADOS

banco de dados, do ponto de vista do seu significado, seu formato e relacionamento com outros tipos de dados. Difere do administrador de banco de dados porque preocupa-se, não com os elementos operacionais e de segurança do funcionamento do banco de dados, mas com os dados propriamente ditos, garantindo, por exemplo, que o mesmo dado (com mesmo conteúdo) não seja armazenado como elementos de dados diferentes. Ele conhece, sobretudo, o negócio da empresa, enquanto que o administrador de banco de dados deve ser especialista no software gerenciador do banco de dados. Assim, o administrador de dados garante, em primeira instância, a uniformidade e coerência do banco de dados, possibilitando que os dados sejam inseridos de forma lógica e ordenada, pois nada adiantaria possuir um software de última geração se os elementos de dados fossem definidos aleatoriamente.

A seguir, apresentam-se as técnicas de controle e os procedimentos de auditoria que podem ser usados em atividades de fiscalização que tenham como objetivo avaliar os bancos de dados da organização auditada, em complemento às verificações indicadas no capítulo 1 - Controles Gerais.

4.7. Avaliação de Banco de Dados

A seguir é apresentado um roteiro para a avaliação de bancos de dados

4.7.1. Controles da administração de dados

Foram claramente definidas e documentadas as responsabilidades relacionadas à administração de dados, tais como:

coordenação da manutenção dos dados (definição, criação, exclusão e propriedade dos dados);

estabelecimento de políticas de acesso, confidencialidade e integridade de dados;

manutenção da documentação; coordenação entre administração de dados, usuários e programação de

sistemas; desenvolvimento e manutenção de padrões.

O pessoal responsável pelas atividades de administração de dados possui as habilidades e conhecimentos técnicos necessários para executá-las.

A organização estabeleceu padrões e métodos para o desenvolvimento de aplicações que utilizam bancos de dados.

As atividades de administração de dados são armazenadas em registros históricos e periodicamente analisadas por um supervisor.

84

BANCO DE DADOS

4.7.2. Controles da administração de banco de dados

Foram claramente definidas e documentadas as responsabilidades relacionadas à administração de banco de dados, tais como:

projeto e manutenção da estrutura da base de dados; revisão e avaliação da confiabilidade do sistema gerenciador de banco de

dados; avaliação do pessoal encarregado das funções de banco de dados; treinamento do pessoal responsável pela administração de banco de dados; segurança de dados.

O pessoal responsável pelas atividades de administração de banco de dados possui as habilidades e conhecimentos técnicos necessários para executá-las.

As atividades de administração de banco de dados são armazenadas em registros históricos e periodicamente analisadas por um supervisor.

O plano de treinamento em linguagens de acesso a banco de dados é adequado.

4.7.3. Controles de acesso ao banco de dados e dicionário de dados

O uso das facilidades do gerenciador de banco de dados é limitado ao pessoal com atribuições compatíveis com esse acesso.

Existem mecanismos para restringir o acesso a arquivos de dados e ao dicionário de dados (senhas, tabelas e perfis de segurança), impedindo o acesso a pessoas não autorizadas.

O acesso ao software e às tabelas de segurança do SGBD e aos perfis de segurança do dicionário de dados é limitado.

Foram estabelecidos procedimentos de autorização de acesso ao banco de dados, que são cumpridos.

São produzidos registros históricos de acesso e atualização, bem como trilhas de auditoria que possibilitem investigar o acesso e atualização a elementos da base de dados.

O gerenciador de banco de dados controla o acesso simultâneo aos elementos de dados e possui mecanismos para prevenir processamento incorreto nessas situações.

4.7.4. Controles sobre o conteúdo e alterações no dicionário de dados

Há consistência entre as estruturas de dados do banco de dados e do dicionário de dados.

O dicionário de dados contém os elementos necessários, tais como: data de criação e última atualização; descrição de cada elemento de dados; chaves utilizadas; estrutura de cada elemento de dados (qual registro lógico contém o elemento);

85

BANCO DE DADOS

programas e sistemas que utilizam cada elemento de dados e de que forma.

Foram estabelecidos procedimentos para produção de cópias de segurança (backup) e recuperação do dicionário de dados.

São mantidas trilhas de auditoria que permitam supervisionar mudanças nos dicionários de dados.

A alteração e a criação de novos nomes de arquivos e descrição de dados são controladas e seguem padrões e políticas predefinidos.

4.7.5. Disponibilidade e recuperação do banco de dados

A organização deve estabelecer políticas e procedimentos que garantam a disponibilidade do banco de dados e sua pronta recuperação após a ocorrência de falhas operacionais ou desastres. As técnicas e procedimentos indicados devem ser usados em conjunto com as apresentadas no item 3 - Continuidade do Serviço, do módulo A2 - Controles Gerais.

Os procedimentos de backup de hardware e software asseguram a disponibilidade da base de dados para as aplicações consideradas prioritárias, em caso de redução da capacidade de operação.

Existem nós ou caminhos alternativos de acesso para bancos de dados acessados via rede.

Foram estabelecidos procedimentos para recuperação lógica e física do ambiente de banco de dados, e são obedecidos.

Os procedimentos de recuperação são periodicamente testados e atualizados.

4.7.6. Integridade do banco de dados

Existem procedimentos para avaliar o desempenho do banco de dados.

O gerenciador de banco de dados apresenta elementos de controle sobre a organização, o acesso e o compartilhamento de dados.

Existem mecanismos de controle sobre a integridade dos dados, das rotinas e do dicionário de dados do sistema gerenciador de banco de dados.

O sistema gerenciador de banco de dados mantém um controle das mudanças realizadas na base.

O gerenciador de banco de dados estabelece controles sobre atividades de pesquisa, atualização de aplicativos, funções de SGBD e dicionário de dados.

86

5. REDES DE COMPUTADORES

Atualmente, é bastante comum que os usuários de um sistema estejam em um local diferente de onde se encontram os recursos computacionais da organização. Isso torna necessário o uso de mecanismos de transporte de informações entre diferentes computadores e entre computadores e seus periféricos.

As redes de comunicação de computadores permitem às pessoas o acesso instantâneo a dados e a usuários em diferentes escritórios ou localidades da organização.

Em resumo, as redes oferecem as seguintes facilidades: acesso compartilhado a dados, aplicações, impressoras e outros dispositivos; correio eletrônico; acesso a usuários e dispositivos remotos; redução do custo de software, por meio de licenças de multi-usuário; acesso e execução de processamentos em sistemas remotos.

Para o bom funcionamento da comunicação de dados são usados: arquivo log de comunicações, onde ficam registrados todos os blocos

transmitidos correta e incorretamente para efeito estatístico e para tentativas de recuperação de dados transmitidos;

software de comunicação de dados para verificações de protocolo de transmissão, gravação do arquivo log de transações e para codificação e decodificação de sinais de comunicação;

protocolo de transmissão, que garante a recepção correta do bloco de informações transmitido;

software ou hardware para a realização de codificação e decodificação das informações transmitidas.

O principal risco oferecido pelas redes é o de acesso não autorizado a dados e programas da organização, que pode resultar em danos ou prejuízos intencionais ou acidentais.

Existe uma grande variedade de software e hardware especializados em limitar o acesso de indivíduos ou sistemas externos a uma rede de comunicação. Exemplos de componentes de rede que podem ser usados para limitar o acesso incluem gateways ou firewalls (dispositivos que restringem acesso entre redes, importantes para reduzir o risco associado ao uso da Internet), monitores de teleprocessamento (programas incorporados ao sistema operacional dos computadores para limitar o acesso) e dispositivos de proteção dos canais de comunicação.

Em alguns casos envolvendo telecomunicação, não é possível ou prático restringir o acesso à rede mediante controles físicos ou lógicos. Nesses casos, ferramentas de criptografia podem ser usadas para identificar e autenticar usuários, bem como para auxiliar na proteção da integridade e sigilo de dados e programas, quando estes se encontram no sistema computacional; estão sendo transmitidos para outro sistema; ou foram armazenados em meios removíveis (disquetes e outros).

A criptografia envolve o uso de algoritmos (fórmulas matemáticas) e combinações de chaves (seqüências de bits) que servem para transformar uma mensagem em códigos

87

REDES DE COMPUTADORES

ininteligíveis para aqueles que não possuem a chave secreta necessária para decifrá-los, mantendo assim o conteúdo do arquivo ou mensagem confidencial. Servem também para fornecer uma assinatura eletrônica, a qual pode indicar se alguma alteração foi feita no arquivo, garantindo sua integridade e identificando o autor da mensagem.

Além dos riscos associados à facilidade de acesso a dados e programas, a auditoria das redes de comunicação de computadores deve contemplar os riscos relativos à operação incorreta do sistema, perda de informações não protegidas por cópias de segurança e outras situações que podem causar dano ou prejuízo à organização em função do ambiente de rede.

A auditoria de redes de comunicação deve abranger os seguintes elementos críticos:

Gerência de rede: devem existir procedimentos e políticas para auxiliar a gerência do ambiente de rede e padrões definidos para controle do hardware e do software envolvidos;

Segurança dos dados e da rede: devem existir mecanismos de controle de hardware e software que garantam a segurança e integridade dos dados mantidos no ambiente de rede e dos recursos físicos que a compõem; bem como limitem e controlem o acesso a programas e dados;

Operação da rede: a organização deve oferecer condições para uma operação eficiente da rede, incluindo normas e procedimentos de treinamento de pessoal, execução de cópias de segurança, avaliação da eficiência do serviço e rotinas de recuperação da rede após interrupções inesperadas;

Software de rede: a gerência de rede deve monitorar e controlar o software de comunicação e o sistema operacional instalado.

A seguir, apresenta-se um roteiro que pode ser usado em atividades de fiscalização que possuam como objetivo a avaliação de redes de computadores da organização auditada, em complemento às verificações indicadas no módulo A2 - Controles Gerais.

5.1. AVALIAÇÃO DAS REDES DE COMUNICAÇÃO DE COMPUTADORES

5.1.1. Gerência de rede

Foram estabelecidos objetivos de curto e médio prazos para o processamento de dados distribuído da organização, definindo precisamente as configurações de hardware, banco de dados, topologia de rede e interfaces de rede de comunicações.

A escolha da plataforma de rede para a organização foi precedida de uma análise de custo/benefício fundamentada em elementos suficientes para justificar a alternativa adotada.

88


O plano de implantação de processamento em rede contempla: participação dos usuários; riscos da conversão dos sistemas; as diferentes necessidades de processamento dos usuários das diversas

localidades; testes de aceitação a serem executados pelo DTI (Departamento de

Tecnologia da Informação), pelo controle de qualidade e por usuários selecionados.

Os procedimentos de controle do processamento em rede são testados e avaliados periodicamente.

Existem procedimentos documentados que definem as atividades permitidas no ambiente de rede.

Os procedimentos de operação da rede foram distribuídos aos usuários de cada departamento.

Foi estabelecido um mecanismo para garantir a compatibilidade de arquivos entre as aplicações, à medida que a rede cresce em tamanho e complexidade.

Foi estabelecida uma política de auditoria e de backup para a rede.

Existem procedimentos documentados e responsabilidades atribuídas para as atividades de inicialização (start-up), supervisão e uso da rede, e recuperação de defeitos de funcionamento do hardware.

O Departamento de Tecnologia da Informação possui políticas, procedimentos e padrões documentados, atualizados e divulgados para o pessoal responsável, cobrindo as seguintes áreas:

descrição resumida de cada aplicativo rodando na rede; procedimentos de operação (tais como startup e shutdown); gerência de fitas e discos; cópias de segurança (backup); procedimentos de emergência; planejamento de contingência.

5.1.2. Segurança dos dados

Foram instituídos mecanismos para padronizar definições de dados compartilhados e manter os dicionários de dados de uso comum.

Existem mecanismos eficazes de controle sobre mudanças feitas nos dados compartilhados.

5.1.2.1. Integridade dos dados

89


Existem controles para garantir que a integridade dos dados seja mantida durante a transferência de dados na rede, tais como:

procedimentos de autenticação de mensagens; mecanismos de garantia da exatidão e integridade da transmissão.

5.1.3. Segurança da rede

Os departamentos de usuários mantêm um inventário atualizado dos equipamentos de rede que se encontram em seu local de trabalho e revisam periodicamente a eficácia das práticas de segurança adotadas.

Os procedimentos de segurança são adequados para proteger os recursos físicos da rede e a integridade do software do aplicativo e dos dados armazenados, e são periodicamente revisados (v. itens 1.2. Programa Geral de Segurança e 1.4. Controle de Acesso, do capítulo 1 - Controles Gerais).

O grupo responsável pela segurança da rede confere periodicamente se a documentação de segurança está devidamente atualizada e reavalia, com a freqüência suficiente, a adequação dos controles de segurança:

do hardware de comunicação e estações de trabalho; do sistema operacional; dos aplicativos relevantes; dos dados considerados confidenciais.

Existe segregação de funções adequada entre gerência de rede e gerência de segurança.

5.1.3.1. Controle do acesso

São mantidas trilhas de auditoria por períodos razoáveis, informando atividades tais como:

login/out (local, hora e data, identificação do usuário); tipo de acesso (discado, por estação de trabalho etc.); tentativas de acesso inválidas (local, hora e data, ID).

Os usuários somente conseguem acesso aos discos, volumes, diretórios e arquivos para os quais possuem autorização.

Foram implantados controles de acesso aos terminais ou estações de trabalho e todos os usuários são identificados por senhas individuais.

Os terminais e estações de trabalho são inabilitados após um determinado número de tentativas de acesso não autorizado.

Foram estabelecidos perfis de acesso para os usuários, que definem os recursos, dados, aplicações, transações e comandos autorizados, de acordo com as responsabilidades dos respectivos cargos.

5.1.3.2. Segurança de comunicação na rede

90


Os controles são adequados para prevenir: transmissão incompleta; roteamento incorreto; alteração não autorizada de mensagens; divulgação não autorizada de informações. Os dispositivos de conexão da rede possuem controles de segurança, incluindo

pacotes de software e dispositivos de criptografia.

Existem controles de acesso e de implementação sobre as seguintes funções de comunicação:

mudança do ambiente de rede; acesso discado; registro histórico de atividade da rede; criptografia de dados.

5.1.4. Segurança física A segurança física oferecida para servidores e equipamentos de comunicação e

conexão em rede é adequada.

Os servidores estão localizados em uma área com acesso restrito apenas ao pessoal autorizado.

Os terminais e estações de trabalho possuem mecanismos de segurança física que previnem a sua remoção não autorizada.

5.1.5. Plano de contingência A organização desenvolveu um plano de contingência para a recuperação da

rede, que inclui: proteção de arquivos de dados; procedimentos para vários níveis de interrupções e emergências; procedimentos de recuperação de aplicações do sistema; lista de documentos e arquivos com cópias a serem mantidas em outro local.

O plano de contingência é testado em simulações periódicas.

91


5.1.6. Operação da rede

Os procedimentos de administração e operação da rede estão documentados e atualizados.

As responsabilidades de operação estão claramente definidas para todas as posições e preservam o princípio da segregação de funções.

O DTI estabeleceu um acordo de nível de serviço com os usuários que define: disponibilidade da rede; tempo de resposta; requerimentos de backup; requerimentos de controle e segurança.

Existem procedimentos para a avaliação periódica da rede, quanto ao seu desempenho, tempo de resposta e tempo de recuperação após falhas.

Existem procedimentos documentados para a administração de problemas e sua solução, e estes indicam as responsabilidades dos fornecedores. Examinar os registros de resolução de problemas e determinar se os problemas estão ocorrendo com freqüência excessiva, se o tempo de resolução é razoável e se algum problema reportado é conseqüência de falhas nos controles do sistema.

5.1.6.1. Falhas e interrupções de serviço

A configuração de rede impede que a ocorrência de uma falha em um de seus pontos provoque a queda de toda a rede.

A rede contém mecanismos que minimizam o impacto provocado por uma falha do sistema e existem procedimentos documentados para o retorno à operação, caso ocorra uma interrupção inesperada do serviço.

Os procedimentos de recuperação da rede após interrupções inesperadas do serviço são periodicamente testados e atualizados (se for o caso), e o pessoal responsável está devidamente capacitado para executar as atividades necessárias de forma eficiente e rápida.

5.1.7. Software de rede

O software de comunicação de rede contém mecanismos para armazenar temporariamente mensagens destinadas a usuários provisoriamente desconectados e retransmiti-las automaticamente quando a conexão for restabelecida.

92


Existem procedimentos documentados tratando da manutenção de rotas de comunicação normais e alternativas.

O software de rede apresenta rotinas de tratamento de erros e de supervisão do desempenho.

Foram especificadas em contrato as manutenções preventivas e reparadoras da rede.

5.1.7.1. Controle de alterações

Existem mecanismos de controle e registro das mudanças efetuadas no software de rede.

Os procedimentos de alteração do software de rede são adequados e prevêem mecanismos de supervisão e autorização.

De modo geral, os procedimentos de controle de alterações do sistema levam em consideração o impacto para a organização, incluindo a disponibilidade do sistema, impacto para usuários, eficiência do sistema e atualização da documentação e manuais.

Existem procedimentos adequados para informar, treinar e auxiliar o pessoal de operações na implementação e suporte de mudanças no software de rede.

93

6. MICROCOMPUTADORES

Normalmente são chamados de microcomputadores os computadores de mesa que compreendem um processador, discos rígido e flexível, monitor e teclado. Os microcomputadores podem ser utilizados isoladamente ou estar conectados a uma rede, com o propósito de compartilhar dados ou periféricos.

Os microcomputadores oferecem às organizações diversas vantagens quanto ao aumento de eficiência e flexibilidade. Entretanto, em razão da necessidade de mecanismos de segurança próprios, que diferem daqueles tipicamente instalados num centro de processamento de dados, a organização também pode ficar exposta a riscos substanciais.

Exemplos dos riscos específicos associados aos microcomputadores: familiaridade - por causa da aparente simplicidade e facilidade de uso, existe o

risco de que o uso inadequado seja subestimado por usuários e pela gerência; custo - ainda que os microcomputadores em si possam ser considerados de

baixo custo, é importante levar em conta o custo dos softwares, periféricos e manutenção, que pode elevar significativamente o custo de uma máquina;

localização - microcomputadores normalmente estão localizados em escritórios comuns, com pouca proteção contra furto, acesso não autorizado ou dano acidental;

softwares proprietários - apesar de ser mais barato adquirir programas do que desenvolvê-los internamente, os softwares oferecidos pelo mercado muitas vezes não apresentam mecanismos de segurança adequados;

conexão com outros computadores - quando os microcomputadores são usados como terminais de mainframes ou inseridos em uma rede de comunicação de computadores, o seu uso não autorizado pode levar ao acesso indevido a dados e programas de toda a organização.

Para que possa proteger-se contra esses riscos, a organização precisa adotar políticas e procedimentos específicos quanto ao uso de microcomputadores pelos seus funcionários, compreendendo padrões de hardware, software, aquisição, treinamento e suporte, além dos controles gerais e de aplicativos.

Os microcomputadores precisam de controles específicos destinados a protegê-los da perda de dados e programas por furto ou acidente (a ser evitada por restrições físicas de acesso às máquinas, controles de software, tais como senhas de acesso e realização periódica de cópias de segurança), e do furto de equipamentos (por meio de mecanismos adequados de segurança no local de trabalho).

Os elementos críticos para a auditoria dos microcomputadores são:

Controles do software em uso: destinados a garantir a consistência da operação do software instalados nos microcomputadores, impedindo a instalação de programas não autorizados, a alteração indevida do software instalado etc.

94

MICROCOMPUTADORES

Segurança: controlam o acesso a recursos computacionais, dados e programas, protegendo-os contra alterações indevidas, furtos, divulgação de documentos sigilosos etc.

Controles sobre a operação: protegem os recursos de microinformática contra prejuízos e danos causados por falta de treinamento de pessoal e de manutenção adequada.

A seguir, é apresentado um roteiro indicado para a auditoria na área de microcomputadores, que deve ser complementado pelas investigações sobre controles gerais e de aplicativos apresentados nos capítulos 1e 2 deste manual.

6.1. Controles do software em uso

A organização estabeleceu políticas, padrões e procedimentos documentados para aquisição e uso de microcomputadores e do software associado, abrangendo também dados sobre:

desenvolvimento e teste de aplicativos; documentação; controles de entrada, saída e processamento; backup e recuperação de dados e programas; autorização para o uso de software, hardware e dados.

A organização mantém um inventário atualizado dos recursos de microinformática (hardware e software), sua localização física, seus usuários, softwares em uso etc.

A aquisição de recursos de microinformática é precedida de análise de custo/benefício e da compatibilidade dos mesmos com o ambiente já instalado.

O uso dos microcomputadores é supervisionado pelos gerentes de cada unidade.

Existem normas que proíbem a instalação de programas pessoais dos funcionários nos microcomputadores da organização e mecanismos para prevenir e detectar o uso ou instalação de programas não licenciados (software pirata).

A documentação do software de micro é mantida atualizada e em local seguro.

Os departamentos de usuários de micros possuem procedimentos documentados para catalogar, armazenar e fazer cópias de segurança de arquivos de dados e programas, e estes estão sendo seguidos.

6.2. Controles de Segurança

Os recursos de microinformática foram classificados de acordo com sua importância e vulnerabilidade, de forma a permitir que os mecanismos de controle sejam direcionados para a proteção dos recursos que ofereçam maiores riscos para a organização.

Existem mecanismos de identificação de usuários e verificação do nível de acesso aos microcomputadores (códigos de identificação ou IDs, senhas individuais).

95

MICROCOMPUTADORES

Os microcomputadores conectados à rede pública de comunicação têm mecanismos de proteção contra acesso externo indevido.

Códigos de identificação e senhas de uso compartilhado pelos funcionários não são permitidos.

Os procedimentos para documentação e backup de programas, arquivos de dados e aplicativos são adequados e estão sendo seguidos.

Os backups de dados críticos ou confidenciais são mantidos em local seguro.

O plano de contingência contempla o ambiente de microinformática (v. capítulo 1 - Controles Gerais, Continuidade do Serviço – Desenvolvimento e documentação de um plano geral de contingência).

Os programas aplicativos são protegidos contra atualizações indevidas.

Os recursos físicos de microinformática contêm identificação única e são inventariados.

São utilizados estabilizadores de energia ou outros dispositivos similares para proteção dos microcomputadores.

A organização mantém em todos os seus micros programas anti-vírus em versões atualizadas.

Os usuários de micro costumam submeter ao programa anti-vírus os disquetes recebidos de ambientes externos à organização.

São oferecidos seminários, palestras ou cursos aos funcionários da organização com intuito de conscientizá-los sobre a importância da segurança em ambiente de microinformática.

Os funcionários da organização são conscientes dos riscos que envolvem os microcomputadores e agem de forma a minimizá-los.

6.3. Controles sobre a operação

Os usuários de micro recebem treinamento adequado.

São programadas manutenções periódicas preventivas em todos os microcomputadores da organização.

O conteúdo dos discos rígidos dos microcomputadores é supervisionado e controlado.

Existe um centro de suporte ao usuário capaz de dar informações, tirar dúvidas de utilização e registrar problemas com o processamento.

96

GLOSSÁRIO

Aplicativo ou aplicação: programa ou conjunto de programas de computador que efetua uma ou mais tarefas aplicadas a um campo específico. Dependendo do tipo de tarefa para o qual foi projetado, o aplicativo pode manipular texto, números, gráficos ou a combinação de todos estes elementos.

Arquivo: coleção organizada de informações, preparada para ser usada com finalidade específica e identificada por um nome.

Banco ou base de dados: (1) coleção de dados organizados. (2) conjunto de todas as informações armazenadas em um sistema de computação.

Códigos-fonte: (1) arquivo (texto) ou instruções originais a partir das quais um programa é criado; (2) representação textual de um programa ou procedimento.

Controle de acesso: recurso que permite bloquear acesso a dados, de pessoas não autorizadas.

Controles de aplicativo: métodos e procedimentos contidos no software do aplicativo cuja função é garantir autoridade para originar dados, exatidão dos dados de entrada, integridade do processamento e distribuição dos dados de saída.

Controles gerais: controles aplicáveis a todos os processamentos executados em um ambiente informatizado, visando garantir que o ambiente computacional como um todo seja eficiente, eficaz, seguro e confiável. Estão relacionados à organização, projeto, desenvolvimento, modificação e segurança dos sistemas.

Dados: (1) representação formalizada de fatos, conceitos ou instruções, adequada para comunicação, interpretação ou processamento; (2) qualquer representação, tais como caracteres, símbolos etc., a qual pode ser associado um significado.

Dados de teste: conjunto de dados escolhidos especificamente para testar um sistema.

DBMS: v. Sistema gerenciador de banco de dados.

Departamento de Tecnologia da Informação (DTI): termo utilizado para substituir o antigo CPD (Centro de Processamento de Dados), representando o departamento responsável por todos os serviços ligados à área de informática, tais como de redes de computadores, centrais de telecomunicação, etc. Normalmente composto pelas seguintes categorias de pessoal:

Gerência de TI: divisão corporativa, chefiada por um Diretor Executivo.

Divisão de desenvolvimento e suporte de aplicações: dedicada ao projeto, desenvolvimento e manutenção de softwares aplicativos. Pode consistir em diversas equipes de desenvolvimento, incluindo analistas de sistema, projetistas e programadores.

Divisão de operações: setor chefiado pelo Gerente de Operações e responsável pela organização e operação diária do hardware e dos sistemas em uso. Presta serviço para as equipes de desenvolvimento de aplicativos e usuários de sistemas.

97

Divisão de suporte de produção: intermediário entre usuários e pessoal de operação e redes de comunicação, oferecendo suporte para a identificação e solução de problemas e falhas do sistema. Essa divisão pode também ser responsável pela administração de base de dados para aplicações.

Divisão de software de sistema: o grupo de programação de sistema que será responsável pela instalação e manutenção de software de sistema e dar suporte ao resto do pessoal de TI e usuários em matérias técnicas. Eles garantem que os sistemas de hardware e software operam com desempenho ótimo.

Divisão de comunicação de dados: o grupo de comunicação de dados ou rede oferece assistência e auxílio aos usuários do sistema que experimentem problemas de teleprocessamento ou precisam comunicar com dispositivos ou usuários remotos. São responsáveis pelo desenvolvimento e manutenção de toda a rede de comunicação da entidade.

Dicionário de dados: repositório centralizado de informações sobre dados, como por exemplo, seu significado, relacionamento com outros dados, origem, utilização e formato. Auxilia os administradores de base de dados, analistas de sistemas e programadores no planejamento efetivo, controle e avaliação do sistema, armazenamento e utilização dos dados.

Documento-fonte: registro original que deverá ser convertido para linguagem computacional.

Elemento de dado: item específico de informação que tem parâmetros definidos (exemplo: número de CGC).

Elementos-chave de controle: pontos de controle que, num sistema, desempenham uma função essencial para evitar ou detectar erros em fases decisivas dos procedimentos ou operações.

Entrada de dados: método de introduzir dados em um computador para processamento, normalmente via terminais ou micros.

Firewall: conjunto de componentes de hardware e software instalado entre redes com o propósito de segurança. A implementação deste dispositivo pode prevenir ou reduzir ataques ou invasões às bases de dados corporativas. Pode-se instalar firewalls entre as sub-redes de uma rede interna ou firewalls externos para proteger a rede corporativa de ataques vindos do exterior. O firewall é composto por duas partes: choke e gate. Ambas podem estar no mesmo computador ou em computadores diferentes. Na configuração do firewall é aconselhável desabilitar os serviços de rede não necessários para a organização.

Gateway: máquina ou conjunto de máquinas que fornecem serviços entre duas redes. São dispositivos usados na tradução entre protocolos de aplicação.

Gerenciador de banco de dados: v. Sistema gerenciador de banco de dados.

Hardware: - (1) componentes físicos (equipamentos) de um sistema de processamento de dados; (2) equipamento mecânico e eletrônico, combinado com software (programas, instruções etc.) na implementação de um sistema de processamento de informações eletrônicas.

98

Integridade de dados: (1) qualidade de resistência do dado a perdas ou a tentativas de destruição ou alteração, acidental ou intencional; (2) qualidade dos dados mantidos em computador de, em conjunto, representarem o universo completo dos dados originais em que se baseiam.

Interconectividade: habilidade de conectar eletronicamente um equipamento. Por exemplo, conectar-se a uma rede, enviar e receber dados.

Interoperabilidade: habilidade de sistemas trabalharem juntos, enviar e interpretar mensagens, compartilhar dados etc.

Log: arquivo em disco ou fita no qual são registrados todos os fatos relevantes relativos ao processamento de uma transação. Muito útil para a recuperação de informações para fins de auditoria ou recuperação após falhas.

Nível de acesso: conjunto de características que define o tipo de atividade permitida pelo usuário em um sistema computacional (ex.: somente consulta, entrada de dados, alteração de configurações, etc.).

Plataforma: tecnologia base de um sistema de computação.

Projeto: aplicação de recursos materiais e humanos a um objetivo específico, mediante a execução de uma seqüência pré-estabelecida de eventos, com princípio, meio e fim.

Projeto de sistema: fase de produção dos sistemas em que se elaboram os projetos físico e lógico do sistema, com especificações detalhadas para o seu desenvolvimento.

Proprietário ou Gestor de dados ou sistema: setor responsável pela manutenção e utilização de determinado sistema. Os proprietários devem ser os primeiros responsáveis pela segurança dos seus dados

Recursos computacionais: elementos que fazem parte de um sistema computacional, incluindo dados, programas, equipamentos e instalações.

Registro: grupo de fatos ou campos de informação relacionados entre si, tratados como unidade.

Risco: efeito latente resultante da exposição de um sistema a uma situação à qual este é vulnerável.

Risco de confiabilidade: (1) risco de que os dados utilizados não sejam suficientemente confiáveis para o fim a que se destinam; (2) risco de que os dados não sejam exatos e completos o suficiente para servir de fundamento para achados de auditoria.

Saída de dados: informação transferida a partir de um computador para o mundo externo.

99

Segurança computacional: conceitos e técnicas (medidas físicas, administrativas e técnicas) usadas para proteger hardware, software e dados de um sistema contra dano, destruição, acesso, manipulação, modificação, uso ou perda, decorrente de ação deliberada ou acidental. O objetivo da segurança computacional é assegurar integridade e disponibilidade do sistema e o sigilo das informações nele contidas.

Segurança de dados: prevenção contra acesso ou uso de dados por pessoal não autorizado.

Segurança física: medidas de segurança para proteger os sistemas de informação, prédios e equipamentos contra incêndio e outras intempéries naturais, ataques, invasão e acidentes. Geralmente é feita através de controles administrativos, alarmes, trancas, crachás de identificação etc.

Segurança física e lógica de um sistema: conjunto de salvaguardas tecnológicas e administrativas estabelecidas e aplicadas para proteção de hardware, software e dados contra alterações acidentais ou propositais ou, ainda, destruição.

Sistema: conjunto de processos ou elementos inter-relacionados, que funcionam juntos para atingir um determinado resultado.

Sistema de processamento de dados: conjunto de equipamentos e programas de processamento de dados capaz de aceitar informações, processá-las de acordo com um plano e produzir os resultados desejados.

Sistema gerenciador de banco de dados (SGBD ou DBMS): programa projetado para permitir a criação de arquivos especialmente organizados, bem como entrada, manipulação, remoção e elaboração de um relatório dos dados existentes nesses arquivos.

Sistema on-line: sistema em que os dados são introduzidos no computador diretamente pelo ponto de origem (o qual pode ser remoto ou local) e a saída é retornada imediatamente a este mesmo ponto.

Software: conjunto de programas e instruções que operam o computador. São dois os tipos de software de computador: software de sistema, o qual engloba operações básicas necessárias para operar o hardware (por exemplo, sistema operacional, utilitários de comunicação, monitores de performance, editores, compiladores etc.) e software aplicativo, o qual executa tarefas específicas para auxiliar os usuários em suas atividades.

Teste: execução de um programa, processo ou rotina com intuito de identificar suas falhas.

Transação: conjunto de atividades.

Trilha de auditoria: (1) rotinas específicas programadas nos sistemas para fornecerem informações de interesse da auditoria. (2) conjunto cronológico de registros que proporcionam evidências do funcionamento do sistema. Estes registros podem ser utilizados para reconstruir, revisar e examinar transações desde a entrada de dados até a saída dos resultados finais, bem como para rastrear o uso do sistema, detectando e identificando usuários não autorizados.

Usuário: qualquer pessoa que utiliza computadores e aplicativos.

100

Usuários de dados: funcionários ou terceiros que possuem direitos de acesso concedidos pelos proprietários do sistema.

Utilitário: programa projetado para otimizar ou facilitar o trabalho com computadores, reparar danos em software/hardware, ajudar a prática da programação, realizar configurações, cópias de segurança, varreduras anti-vírus, etc.

Validação: (1) processo de avaliação de um sistema ou componente durante ou ao final do processo de desenvolvimento, para determinar se este satisfaz os requerimentos especificados; (2) processo de verificação dos dados de entrada de uma aplicação.

Vulnerabilidade da informação: qualidade ou condição da informação ser vulnerável, determinada a partir da avaliação dos seguintes aspectos:

disponibilidade: as informações, os serviços, os sistemas ou os programas podem causar prejuízos se não estiverem disponíveis no momento oportuno?

confidencialidade: a informação pode causar prejuízos se for divulgada? integridade: a informação pode causar prejuízos se for modificada, estiver

incorreta ou incompleta?

101

BIBLIOGRAFIA

PARTE 1 – Tecnologia da Informação e Atividade de Fiscalização

CIPFA (1997). Computer Audit. Londres, Reino Unido.

------ (1997). A Guide to Certification Audit. Londres, Reino Unido.

GAO (1991). Preparing, Documenting and Referencing Microcomputer Data Base Applications. Washington-DC, EUA.

------ (1996). Assessing the Reliability of Computer Processed Data. Washington-DC, EUA.

TCU (1996). Manual de Auditoria do Tribunal de Contas da União. Brasília-DF.

102

BIBLIOGRAFIA

PARTE 2 – Auditoria de Sistemas de Informação

AUDINET (1997). LAN Audit Program in ASAP – Auditor Sharing Audit Programs. Internet.

------ (1997). LAN Basic Audit in ASAP – Auditor Sharing Audit Programs. Internet.

CIPFA (1997). A Guide to Certification Audit. Londres, Reino Unido.

------ (1997). Computer Audit. Londres, Reino Unido.

GAO (1997). Assessing Risks and Returns: A Guide for Evaluating Federal Agencies' IT Investment Decision-making. Washington-DC, EUA.

------ (1996). Assessing the Reliability of Computer Processed Data. Washington-DC, EUA.

------ (1996). Federal Information System Control Audit Manual, Vol I - Financial Statement Audits. Washington-DC, EUA.

------ (1996). The System Assessment Framework. Washington-DC, EUA.

GIL, Antônio de Loureiro (1993). Auditoria de Computadores. São Paulo: Atlas.

ICAS (1992). Auditing Small Computer Systems. Edinburgh, Escócia.

INTOSAI (1995). Information System Security Review Methodology.

------ (1996). IT Audit Training for INTOSAI. Barbados.

JENKINS, Brian (1992). An Audit Approach to Computers. London: Coopers & Lybrand.

TCU (1997). Procedimentos de Auditoria - Auditoria de Sistemas (PA-02). Brasília-DF.

103

RELAÇÃO DOS DOCUMENTOS ELABORADOS NA ÁREA DE FISCALIZAÇÃO E CONTROLE EXTERNO

ESTRATÉGIAS ÚLTIMA ATUALIZAÇÃO

Estratégia de Atuação para o Controle da Gestão Ambiental 1998

MANUAIS DE AUDITORIA ÚLTIMA ATUALIZAÇÃO

Manual de Auditoria 1996

Manual de Auditoria de Desempenho 1998

Manual de Auditoria de Sistemas 1998

Manual de Instrução de Tomada de Contas Especiais 1997

Manual de Instrução de Tomada e Prestação de Contas 1997

PROCEDIMENTOS DE AUDITORIA ÚLTIMA ATUALIZAÇÃO

PA-01 – Convênios 1998

PA-02 – Sistemas 1998

PA-03 – Licitações 1995

PA-04 - Contratos Administrativos 1995

PA-05 – Pessoal 1997

PA-06 - Obras Públicas 1998

PA-07 - Imóveis 1998

PA-08 - Publicidade e Propaganda 1998

PA-09 - Unidades Sediadas no Exterior 1998

ROTEIROS DE AUDITORIA ÚLTIMA ATUALIZAÇÃO

Roteiro de Acompanhamento via SIAFI 1997

Roteiro de Extração de Dados do SIAFI 1998

Roteiro de Extração de Dados do SIAPE 1998

TÉCNICAS DE AUDITORIA ÚLTIMA ATUALIZAÇÃO

Técnicas de Entrevistas para Auditorias 1998

OUTRAS PUBLICAÇÕES ÚLTIMA ATUALIZAÇÃO

Convênios – Principais Informações para Estados e Municípios 1997

Auditorias do TCU nas Repartições do MRE no Exterior 1997

104

FOLHA DE SUGESTÕES

O TCU preocupa-se com o constante aperfeiçoamento da qualidade de seus manuais e orientações, buscando, para isso, ouvir a valiosa opinião do público-alvo dos referidos trabalhos.

O questionário a seguir refere-se especificamente ao Manual de Auditoria de Sistemas, distribuído a partir de setembro de 1998. Será muito útil para o TCU se o leitor deste manual puder dispor de alguns minutos para responder às perguntas elencadas no referido questionário e enviá-lo aos Correios (não é preciso selar, o porte será pago pelo TCU).

Sugestões sobre este manual também podem ser enviadas como se segue:

E-mail: [email protected]: (061) 316-7538Fone: (061) 316-7388Endereço: Tribunal de Contas da União - TCU

SAUDI/DIPEASetor de Administração Federal Sul - Lote 01CEP: 70042-900 – Brasília - DF

105

Tribunal de Contas da União QUESTIONÁRIO DE AVALIAÇÃOMANUAL DE AUDITORIA DE SISTEMAS

FINALIDADE

Este questionário tem por objetivo obter a opinião dos leitores sobre o Manual de Auditoria de Sistemas, com vistas ao seu aperfeiçoamento.

Por favor, responda às questões abaixo assinalando com um “X” a alternativa mais adequada. Desde já agradecemos a sua colaboração.

1. Em que esfera do governo você trabalha?

� Federal � Estadual ou DF � Municipal

2. Em que órgão você trabalha?

� Poder Legislativo

� Poder Executivo

� Poder Judiciário

� Controle Interno

� Outro [especificar] ________________

3. Que partes do Manual de Auditoria de Sistemas você leu?

� Todo � Itens 1,2 e 4 [todos ou parte] � Itens 3 e 5 [todos ou parte]

4. Leia com atenção cada indicador e escolha o ponto da escala que melhor descreve a sua opinião sobre o Manual de Auditoria de Sistemas. Marque com um “X” a opção que melhor representa o seu julgamento.

Concorda integralmente Concorda Indiferente Discorda Discorda integralmente5 4 3 2 1

O manual é : 5 4 3 2 1Fácil de ser lido � � � � �Fácil de ser entendido � � � � �Lógico � � � � �Sucinto � � � � �Completo � � � � �Útil � � � � �

5. Como você tomou conhecimento do Manual de Auditoria de Sistemas?

� Quando recebeu

� Divulgação interna do TCU� Por mensagem do SIAFI

� Pela Internet

� Pela imprensa� Outros [especificar]_______________________

6. Como você obteve o Manual de Auditoria de Sistemas?

� Solicitou diretamente ao TCU � Download pela Internet � Outros [especificar] _________________

7. Apresente, a seguir, comentários e sugestões para o aprimoramento da qualidade do Manual de Auditoria de Sistemas. No caso de sugestões para alteração/supressão/aditamento de itens de verificação, favor preencher o quadro anexo.

106

Tribunal de Contas da União QUADRO DE SUGESTÕESMANUAL DE AUDITORIA DE SISTEMAS

FINALIDADE

Nº do item Proposta de alteração, supressão ou aditamento Fundamentação

107

PTR/BSB

880/92

UP-AC/TCU

DR/BSB

CARTA - RESPOSTANÃO É NECESSÁRIO SELAR

O SELO SERÁ PAGO PORTRIBUNAL DE CONTAS DA UNIÃO

70099-999 BRASÍLIA-DF

UNIDADES DA SECRETARIA DO TRIBUNAL DE CONTAS DA UNIÃOSecretaria da Presidência Olga Emília Monte BarrosoAssessoria de Cerimonial e de Relações Institucionais Márcia Paula SartoriAssessoria de Imprensa Erivan Carlos de CarvalhoAssessoria de Relações Internacionais Sérgio Freitas de AlmeidaAssessoria para Assuntos Legislativos Severino Lucena da NóbregaConsultoria-Geral Terezinha de Jesus CarvalhoInstituto Serzedello Corrêa Ricardo de Mello AraújoSecretaria de Controle Interno Antônio Miranda de Castro

Secretaria-Geral das Sessões Eugênio Lisboa Vilar de MeloSecretaria do Plenário Elenir Teodoro Gonçalves dos SantosSecretaria da 1ª Câmara Francisco Costa de AlmeidaSecretaria da 2ª Câmara Miguel Vinicius da Silva

Secretaria-Geral de Administração Antônio José Ferreira da TrindadeSecretaria de Engenharia e Serviços Gerais Mário Fabbris RiccóSecretaria de Material, Patrimônio e Comunicação Administrativa Leila Fonseca dos Santos V. FerreiraSecretaria de Orçamento, Finanças e Contabilidade Pedro Martins de SousaSecretaria de Recursos Humanos Cláudia de Faria Castro

Secretaria-Geral de Controle Externo José NagelSecretaria de Auditoria e Inspeções Cláudio Souza Castello BrancoSecretaria de Contas do Governo e Transferências Constitucionais Carlos Nivan MaiaSecretaria de Informática Antônio Quintino RosaSecretaria de Planejamento, Organização e Métodos Mauro Giacobbo1ª Secretaria de Controle Externo José Moacir Cardoso da Costa2ª Secretaria de Controle Externo Gilberto Fernando da Silva3ª Secretaria de Controle Externo Sônia Lúcia Imbuzeiro4ª Secretaria de Controle Externo Marília Zinn Salvucci5ª Secretaria de Controle Externo Francisco Carlos Ribeiro de Almeida6ª Secretaria de Controle Externo Antonio Newton Soares de Matos7ª Secretaria de Controle Externo Cláudio Sarian Altounian8ª Secretaria de Controle Externo Eduardo Duailibe Murici9ª Secretaria de Controle Externo Jorge Pereira de Macedo10ª Secretaria de Controle Externo Rosângela Paniago Curado FleurySecretaria de Controle Externo/AC Dion Carvalho Gomes de SáSecretaria de Controle Externo/AL Edimilson Monteiro BatistaSecretaria de Controle Externo/AP Wilson Maurício Paredes Ferreira LimaSecretaria de Controle Externo/AM Helena Montenegro ValenteSecretaria de Controle Externo/BA Paulo Pereira TelesSecretaria de Controle Externo/CE Paulo Nogueira de MedeirosSecretaria de Controle Externo/ES Hamilton Caputo Delfino SilvaSecretaria de Controle Externo/GO Carlos Martins dos SantosSecretaria de Controle Externo/MA Osmir da Silva FreireSecretaria de Controle Externo/MT Luiz Guilherme da Boamorte SilveiraSecretaria de Controle Externo/MS Raimundo Nonato CoutinhoSecretaria de Controle Externo/MG Élsio Geová dos SantosSecretaria de Controle Externo/PA José Márcio Paulino MurtaSecretaria de Controle Externo/PB Raimundo Nonato Soares AraújoSecretaria de Controle Externo/PR Nazaré do Socorro do Rosário VuardiSecretaria de Controle Externo/PE Ildê Ramos Rodrigues TheodoroSecretaria de Controle Externo/PI José Maria Araújo LimaSecretaria de Controle Externo/RJ José Augusto Pôrto NetoSecretaria de Controle Externo/RN Marcos Valério de AraújoSecretaria de Controle Externo/RS Antônio José Martins de AlmeidaSecretaria de Controle Externo/RO Fábio Arruda de LimaSecretaria de Controle Externo/RR Rainério Rodrigues LeiteSecretaria de Controle Externo/SC Rafael Blanco MunizSecretaria de Controle Externo/SP Eloi CarnovaliSecretaria de Controle Externo/SE Clímaco Romualdo de CarvalhoSecretaria de Controle Externo/TO Jacques Silva de Souza

Documents

[Apostila] Auditoria de Sistemas - TCU