Histórico da Página
...
Produto:
...
Novo Log de Auditoria
...
Versões:
...
Ocorrência:
...
Manual
...
Ambiente:
...
Com o Log de Auditoria podemos obter um histórico de todas as inclusões, alterações e exclusões que ocorreram na(s) tabela(s) selecionada(s) para serem auditadas.
O Log de auditoria é composto por uma série de Procedures, onde quando é(são) selecionada(s) uma tabela(s) a ser(em) auditada(s), cria-se uma "Tabela Espelho" em um Schema exclusivo do Log de Auditoria(TOTVSAUDIT) e Trigger(s) no banco de dados, dependendo da ação escolhida (Insert, Update, Delete).
Quando houver transações que utilizam a(s) tabela(s) selecionada(s), a Trigger é disparada e grava na tabela de Log (ZAUDITCHANGES) as informações sobre o autor da ação, e os dados que foram criados, alterados ou deletados é salvo na "Tabela Espelho" (Ex.: TOTVSAUDIT.PFUNC, tabela espelho a tabela do sistema RM.PFUNC).
Estas informações podem ser consultadas através de QUERY´s no banco de dados ou através da interface do usuário do Log de Auditoria.
Atenção!!
A partir da versão 12.1.31 foi criado o configurador do TOTVS Audit
Veja mais em: TOTVS Audit
| Aviso | ||
|---|---|---|
| ||
Rotinas Delphi que ainda não foram migradas para o .NET não passam pela estrutura que preenche os parâmetros do Log de Auditoria, onde as informações que serão gravadas são referentes a da conexão do Banco de Dados. Este caso também se aplica para rotinas(MDI ou Delphi) que abrem a conexão com o banco sem passar pela estrutura responsável por enviar os parâmetros corretos para a Trigger de Log de Auditoria. Exemplo: O Login é necessário abrir a conexão manualmente pois ainda não existe a autenticação do usuário no banco de dados, então será enviada as informações da conexão e não do usuário. |
| Aviso | ||
|---|---|---|
| ||
Caso seja necessário se restaurar uma base de dados Oracle em um ambiente de homologação, utilizando-se das ferramentas IMP e IMPDP, deve-se restaurar o Schema RM, após o final da restauração deve-se executar a Stored Procedure p_FixNovoLog.. Comando: EXEC p_FixNovoLog Esta nova Stored Procedure faz uma verificação e cria/recria os objetos necessários para o correto funcionamento do Novo Log de Auditoria, Schema, Tabelas, Grants, Etc. |
Passo a passo:
Para habilitar o Log de Auditoria vá em Serviços Globais, Administração, Log de Auditoria, Configurações:
Após clique no botão Inativo para que o mesmo mude para Ativo:
Clique em Salvar:
A partir do momento que o Log estiver ativo você poderá selecionar as tabelas que serão necessárias para auditoria.
Para habilitar a auditoria na tabela PFUNC, vamos em [P] Totvs Folha de Pagamento e pressione CTRL + F para localizar a tabela, ou se preferir busque a mesma na lista de tabelas.
Assim que a tabela é localizada escolhemos o tipo de Auditoria que necessitamos na tabela, elas são, Update (Quando um registro é alterado na tabela), Delete (Quando um registro é excluído na tabela) e Insert (Quando um registro e inserido na tabela):
Após selecionar é só clicar em salvar que as Triggers de auditoria serão criadas no banco para a tabela em questão e um log será exibido:
E possível manipular quantas Triggers forem necessárias ao mesmo tempo, tanto habilitando quanto desabilitando:
Para remover uma Trigger é só desmarcar todas as opções da tabela:
No novo Log foi implementada a funcionalidade de Exceção.
Existem 2 tipos de exceções, uma por Tabelas/Colunas e outra de DataServer da aplicação.
A primeira (Tabelas/Colunas), não audita a tabela especifica caso somente esta coluna tenha sido alterada:
No campo domínio, digite o nome da tabela que você deseja criar a exceção de coluna:
E selecione as colunas que serão ignoradas, clique em Salvar e depois OK:
Marcação de muitas colunas, pode acarretar em uma queda de performance na execução da Trigger que será montada, desta forma criamos uma validação apenas para informar o cliente:
Caso o cliente marque todas as colunas da tabela, neste caso entendemos que o correto é retirar a coluna da auditoria, nestes casos será mostrado a seguinte mensagem:
Somente poderá ser cadastrado uma exceção por Domínio, caso tentem realizar a adição duplicada será apresentado a seguinte mensagem:
...
Após o cadastro do registro, no momento da edição o campo Dominio ficará desabilitado para edição:
Exceção criada com sucesso, as triggers já refletirão esta nova exceção:
A Segunda (DataServer), ignora processos específicos do sistema, como o Recalculo da Folha.
Para adicionar uma exceção de Dataserver vá até a aba DataServers, e depois botão incluir:
As exceções de DataServer são globais, assim elas se aplicam a todas as tabelas que estão sendo utilizadas pelo processo e que estão sendo auditadas.
Exemplo: Caso seja incluída uma exceção de DataServer no processo RM.Fop.CalcularFolha.FopCalcLogServer (Calculo da Folha) e a tabela PFUNC esteja sendo auditada, nenhum registro modificado pelo processo será auditado, porem caso exista uma alteração manual (realizada pelo usuário) sendo realizada ao mesmo tempo (alteração no cadastro do funcionário) a mesma será auditada normalmente.
Inclua o código do Dataserver no campo Descrição, Salvar e depois OK:
Assim como nas exceções de Colunas quando o registro é salvo a exceção reflete em todas as triggers do sistema, então quanto mais tabelas auditadas, maior poderá ser o tempo para finalizar o processo:
Para excluir uma exceção, tanto de coluna quanto de DataServer é só selecionar a mesma e clicar no X para excluir:
Para desativar o Log de auditoria em todas as tabelas, é só clicar no botão ATIVO e Salvar:
Com isso todas as triggers serão removidas, mas irá manter a configuração que você já realizou, para caso queira reativar o Log:
Visualização do Log de Alterações
Para visualizar selecione o registro desejado, dê um duplo clique no mesmo, nesta tela teremos as informações do Usuário que gerou a auditoria.
Para verificar o que foi alterado vá em Detalhe das alterações do Log de Auditoria, selecione o registro e de um duplo clique.
Neste exemplo vemos que os campos Apelido, Investtreinament e CodNaturalidade foram alterados.
Expurgo parcial
É realizado quando desejamos excluir das tabelas de auditoria registros específicos.
Vá em Processos, e Expurgo Parcial do Log de Auditoria.
Nesta etapa temos que selecionar o filtro de Limpeza/Expurgo, é possível expurgar usando as opções:
- Usuário específico: Nesta opção é possível expurgar dados apenas de um determinado usuário;
- Período: Nesta opção é possível expurgar dados apenas de período superior a um determinado período, exemplo: 30,60,90 dias.
- Operação: Nesta opção é possível expurgar dados apenas de uma das operações que o log executa.
Além das opções acima é possível expurgar log de acessos de tabelas que contém dados protegidos (LGPD), a idade do log é configurável.
Nesta tela é apresentado as tabelas que desejamos que seja feito o expurgo.
Após o expurgo parcial, a tela abaixo indica o sucesso da operação.
Expurgo Total
Nesta opção será realizado o expurgo de todos os dados das tabelas de auditoria, esta é a forma mais rápida e pratica para quando a auditoria não é mais necessária.
Na execução desse processo o usuário é alertado quanto ao procedimento a ser feito.
Na tela abaixo demonstra o status da execução do expurgo total, nesse momento a Triggers são desabilitadas.
Agendamento do Expurgo Parcial/Total
A partir da versão 12.1.32 foi implementado o agendamento de Jobs para o expurgo, tanto parcial como total, com esta nova funcionalidade o usuário poderá agendar o melhor momento
para realizar o expurgo.
Mais informações sobre o agendamento de processos, clique em Agendamento de Processos
Podemos gerar os relatórios a partir dos dados coletados pela auditoria para isso vamos em Processos, Gerar Relatório com Base no Log de Auditoria
Aqui teremos a tela de filtros
Definimos os filtros necessário e onde o arquivo deve ser gerado.
Selecionamos as tabelas que desejamos que o relatório seja gerado
Abaixo modelo de relatório gerado
Observação
...
Importante !!!
Por questões de performance e aumento significativo da base de dados, alguns tipos de dados não são auditados. São eles:
- Em bases Sql Server os tipos não auditáveis são: 'TEXT','NTEXT','IMAGE','TIMESTAMP'
- Em bases Oracle os tipos não auditáveis são: 'LONG','LONG RAW','CLOB','NCLOB','BLOB','BFILE','TIMESTAMP'
- Colunas com estes nomes também são excluídas da auditoria: 'RECCREATEDBY', 'RECCREATEDON', 'RECMODIFIEDBY', 'RECMODIFIEDON'
- Com a configuração da Proteção de Dados o TOTVS Audit está relacionado diretamente à gestão das triggers as quais cuidam do armazenamento dos campos. Desta maneira qualquer modificação feita nos itens deste cadastro o assistente de configuração do TOTVS Audit é acionado para aplicar tais configurações.
Exemplo abaixo com a tabela AABONFUN, onde iremos verificar as triggers existentes devido a configuração aplicada neste cadastro:
- Nesta tela podemos observar que existe a configuração de duas colunas como pessoal:
- Sendo assim, conseguimos evidenciar que no cadastro de tabelas a serem auditadas pelo TOTVS Audit, esta tabela está com o item marcado devido ao cadastro citado acima:
- Podemos observar também no banco de dados que as triggers estão associadas à tabela:
...
Conclusão:
Para adicionar/retirar a configuração desta tabela ou de qualquer outra, basta retirar a configuração pessoal para todas colunas, pois só assim esta tabela passa a não ser mais associada ao item da LGPD e executar o assistente que é acionado após cada alteração salva.
Caso o assistente de configuração do TOTVS Audit não seja executado imediatamente a alteração, tais modificações ficam pendentes até que ele seja executado e efetive as devidas criações ou deleções das triggers na respectiva tabela.
...
Conclusão:
Para adicionar/retirar a configuração desta tabela ou de qualquer outra, basta retirar a configuração pessoal para todas colunas, pois só assim esta tabela passa a não ser mais associada ao item da LGPD e executar o assistente que é acionado após cada alteração salva.
Caso o assistente de configuração do TOTVS Audit não seja executado imediatamente a alteração, tais modificações ficam pendentes até que ele seja executado e efetive as devidas criações ou deleções das triggers na respectiva tabela.
Acesso a rotinas que contém dados protegidos
Através deste anexo é possível verificar quais as rotinas de dados protegidos foram acessadas, conforme imagem abaixo:
Mais detalhes do cadastro de segurança no link abaixo:
Segurança de Dados - Configurar Proteção de Dados
Observações sobre Grants no Oracle para o user RM e user TOTVSAudit
- Na versão 12.1.31 não utilizamos mais sinônimos, contudo o RM precisa ter atribuição de DBA para execução/configuração do TOTVSAudit.
- Na versão 12.1.32 foi retirada a atribuição de DBA para o RM, porém, é necessário atribuir alguns grants para execução/configuração do TOTVSAudit:
Sugestão de comandos para adequação do RM nesta versão:
REVOKE DBA FROM RM;
ALTER USER RM QUOTA UNLIMITED ON RM_DADOS QUOTA UNLIMITED ON RM_INDICES;
GRANT ALTER ANY TABLE, CREATE ANY TABLE, DROP ANY TABLE, DELETE ANY TABLE, SELECT ANY TABLE, INSERT ANY TABLE, CREATE ANY INDEX, DROP ANY INDEX, CREATE ANY SEQUENCE, DROP
...
ANY SEQUENCE, SELECT ANY SEQUENCE TO RM;
...
Observações:
Para mais informações:
COMUNIDADE R@Tecnologia
Canais de Atendimento:
Abertura de Chamados Através do Portal Totvs www.suporte.totvs.com.br
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas