LEITURA DIGITAL

Prévia do material em texto

SEGURANÇA E AUDITORIA EM 
BANCO DE DADOS
W
B
A
04
73
_v
1.
0
2
Washington Henrique Carvalho Almeida
Londrina 
Editora e Distribuidora Educacional S.A. 
2020
SEGURANÇA E AUDITORIA EM BANCO DE 
DADOS
1ª edição
3
2020
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: editora.educacional@kroton.com.br
Homepage: http://www.kroton.com.br/
Presidente
Rodrigo Galindo
Vice-Presidente de Pós-Graduação e Educação Continuada
Paulo de Tarso Pires de Moraes
Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Braga de Oliveira Higa
Carolina Yaly
Giani Vendramel de Oliveira
Henrique Salustiano Silva
Mariana Gerardi Mello
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo
Coordenador
Henrique Salustiano Silva
Revisor
Marcelo Ramillo
Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Gilvânia Honório dos Santos
Mariana de Campos Barroso
Paola Andressa Machado Leal 
Dados Internacionais de Catalogação na Publicação (CIP)
__________________________________________________________________________________________ 
Almeida, Washington Henrique Carvalho.
A447s Segurança e auditoria em Banco de Dados/ Washington 
 Henrique Carvalho Almeida, – Londrina: Editora e 
 Distribuidora Educacional S.A., 2020.
 44 p.
 ISBN 978-65-5903-049-1
1. Segurança 2. Auditoria 3. Dados I. Título.
 
CDD 004
____________________________________________________________________________________________
Raquel Torres – CRB 6/2786
© 2020 por Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser 
reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, 
eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de 
sistema de armazenamento e transmissão de informação, sem prévia autorização, 
por escrito, da Editora e Distribuidora Educacional S.A.
4
SUMÁRIO
Gerenciamento de usuários e seus privilégios ______________________ 05
Controle de Bloqueio em Transações: Locks ________________________ 21
Políticas de backup e recovery de banco de dados _________________ 35
Aplicação de Auditoria em banco de dados _________________________ 49
SEGURANÇA E AUDITORIA EM BANCO DE DADOS
5
Gerenciamento de usuários e seus 
privilégios
Autoria: Washington Henrique Carvalho Almeida
Leitura crítica: Marcelo Ramillo
Objetivos
• Abordar conceitos da segurança de dados.
• Demonstrar a importância da segurança de dados 
no âmbito do Banco de Dados.
• Conceituar os tipos de privilégios de acesso dos 
usuários ao banco de dados.
• Tratar as medidas de controle usadas para fornecer 
segurança ao Banco de Dados.
• Expor a importância do DBA na Segurança e 
Auditoria em Banco de Dados.
6
1. Introdução
O número de ataques externos e internos a organizações públicas e 
privadas para obter informações privilegiadas passa por um crescimento 
substancial. No caso dos ataques externos, a principal forma de 
impedir é mantendo uma arquitetura de segurança bem estruturada. 
Contudo, também é necessário garantirmos as melhores práticas para 
as ações internas, e, nesse caso, é preciso ter uma política de segurança 
consistente com critérios para fornecer privilégios de acesso ao banco 
de dados.
Neste tema, estudaremos questões de segurança de bancos de dados 
e sua importância; tipos de segurança de dados; medidas de controle; 
importância do Administrador de Banco de Dados ou Database 
Administrator (DBA); controle de acesso discricionário; controle de 
acesso mandatário; e concessão e revogação de privilégios. Assim, ao 
final da aula, será possível responder a algumas perguntas relativas ao 
assunto em questão: gerenciamento de usuários e seus privilégios. 
São elas:
1. O que é Segurança de Dados?
2. O que é integridade?
3. Quais os tipos de perdas causadas por ameaças aos Bancos de 
Dados?
4. Qual é o papel do DBA?
5. Quais os tipos de ações que ele executa?
7
2. Segurança de dados
A segurança do banco de dados tem como referência o uso de uma 
ampla variedade de controles que visam proteger as informações. 
Coerentemente, deve discernir quais controles usar de acordo com os 
tipos de negócios para os quais o banco de dados é utilizado.
Em muitos casos de acidentes de segurança, emprega-se mais tempo 
em descobrir as causas em vez de investir na criação de boas medidas 
preventivas. Pensando na situação de um banco de dados local, como 
é o caso da maioria das organizações, nas quais existe uma segurança 
de rede centralizada de rede e firewall, a segurança precisa de uma 
estratégia específica para os dados, devendo estabelecer critérios para 
cada situação em que o usuário acessa o banco.
Os assuntos de segurança de dados apresentam-se intimamente 
relacionados à integridade de dados; todavia, devemos lembrar que 
segurança não é sinônimo de integridade. Nesse escopo, serão vistas 
várias formas de proteção dos dados.
Date (2003, p. 819) conceitua integridade e segurança como: “Segurança 
significa proteger os dados contra usuários não autorizados. 
Integridade significa proteger os dados contra usuários autorizados (!)”. 
Percebe-se que a diferença é sutil: a segurança protege os dados contra 
usuários NÃO AUTORIZADOS, enquanto a integridade possui a mesma 
definição, mas para usuários AUTORIZADOS.
Vamos ver agora a importância da integridade e da segurança de dados 
por meio de um exemplo. Imaginemos acessar os dados do seu imposto 
de renda por meio do E-CAC e verificar que aqueles dados expostos 
na tela do computador não são seus de fato. Em outras palavras, é 
possível acessar as informações, mas os dados não são íntegros, isto é, 
apresentam-se “adulterados” e não há integridade.
8
Já sobre a segurança de dados, podemos exemplificar com uma situação 
muito simples. Uma pessoa recebe um SMS do banco dizendo que 
acessou a conta-corrente em tal hora, mas percebe que não foi ela que 
acessou. Isso é a segurança de dados.
A integridade do banco de dados tem a ver com o requisito de que 
a informação não seja alterada indevidamente, incluindo todas as 
etapas e operações de comandos DML de um SGBD (INSERT, UPDATE 
e DELETE). Ressalta-se que, quando se fala em consistência e precisão, 
devemos nos lembrar dos princípios da segurança de informação: 
confidencialidade, integridade e disponibilidade. Esses conceitos são 
determinantes, pois no final o gerenciamento de permissões de usuários 
busca garantir a inviolabilidade desses três princípios, a famosa trinca 
CID da Segurança da Informação:
• Confidencialidade: garantir que a informação se apresente 
acessível somente às pessoas que possuem autorização para 
acessá-las.
• Integridade: somente pessoas autorizadas podem alterar a 
informação.
• Disponibilidade: garantir que as pessoas autorizadas tenham 
acesso àquela informação quando quiserem, isto é, quando 
acharem necessário, a qualquer tempo.
9
Figura 1 – Princípios da Segurança da Informação
Fonte: elaborada pelo autor.
Garantir a segurança da informação é apresentar confidencialidade, 
integridade e disponibilidade. Em outras palavras, é fazer com que as 
informações estejam acessíveis somente para as pessoas autorizadas, 
de modo que elas possam alterá-las e que essas informações possam 
estar disponíveis a qualquer tempo.
3. Tipos de Segurança de Banco de Dados
Para uma definição clara do tipo de segurança a ser aplicada, é 
necessário conhecer e compreender quais bancos de dados contêm 
dados confidenciais, por exemplo. Assim, definir requisitos, como 
10
autenticação, autorização e controle de acesso, será importante para a 
estratégia e a arquitetura de segurança.
A área de segurança de banco de dados é muito vasta, tentando assim 
solucionar muitos problemas. Elmasri e Navathe (2011) incluem os 
seguintes problemas:
• Diversas questões éticas e legais:por exemplo, algumas 
informações podem ser acessadas por organizações ou pessoas 
não autorizadas. Nos Estados Unidos, existem várias leis que 
controlam a privacidade da informação.
• Questões políticas institucionais quanto aos tipos de informações 
que não devem se tornar públicas: por exemplo, classificações de 
crédito e registros médicos pessoais.
• Questões relacionadas ao sistema, como os níveis de sistema 
em que várias funções de segurança devem ser impostas: por 
exemplo, se uma função de segurança deve ser tratada no nível 
de hardware físico, no nível do sistema operacional ou no nível do 
SGBD.
• A necessidade, em algumas organizações, de identificar vários 
níveis de segurança e categorizar os dados e os usuários com 
base nessas classificações: por exemplo, altamente secreta, 
secreta, confidencial e não classificada. A política de segurança da 
organização com relação a permitir o acesso a várias classificações 
dos dados deve ser imposta.
Date (2003) elenca os tipos de problemas a serem solucionados:
• Aspectos legais, sociais e éticos: por exemplo, a pessoa que faz 
a requisição quanto ao crédito de um cliente tem direito legal à 
informação solicitada?
11
• Controles físicos: por exemplo, a sala do computador ou do 
terminal é trancada ou protegida de algum modo?
• Questões de política: por exemplo, como a empresa proprietária 
do sistema decide quem deve ter acesso a quê?
• Problemas operacionais: por exemplo, se é usado um esquema de 
senha, como é conservado o segredo das próprias senhas e com 
que frequência elas são trocadas?
• Controles de hardware: por exemplo, o servidor fornece recursos 
de segurança, tais como chaves de proteção de armazenamento 
ou um modo de operação protegido?
• Suporte do sistema operacional: por exemplo, o sistema 
operacional sendo utilizado apaga o conteúdo da memória 
principal e dos arquivos de disco quando termina de trabalhar com 
eles? E o que dizer do log de recuperação?
Percebe-se que há muitas semelhanças concernentes às questões entre 
os dois autores. Isso nos mostra que as questões éticas, políticas e 
sociais devem ser regulamentadas e solucionadas quando falamos em 
segurança de dados.
Os Sistema de Gerenciamento de Banco de Dados (SGBD) oferecem 
mecanismos de segurança com base no controle de acesso dos dados 
e até mesmo a ocultação de dados por meio de visões (VIEW), que são 
projeções de parte dos dados de tabelas, podendo ser construídas com 
consultas SQL avançadas. Além disso, são implementadas diversas 
medidas de controle, detalhadas no próximo tópico.
12
4. Medidas de Controle
As medidas de controle possuem o objetivo de fornecer segurança 
nos bancos de dados, concedem aos usuários apenas os privilégios 
necessários para realizar o trabalho que lhes foi atribuído e permitem 
que apenas alguns usuários acessem, processem ou alterem dados.
São divididas por categorias:
• Privilégio do sistema.
• Funções do usuário.
• Privilégios do objeto.
Por exemplo, criar espaços de tabela e excluir as linhas de qualquer 
tabela em um banco de dados são privilégios do sistema. Os privilégios 
de um sistema de banco de dados são tão importantes que, por padrão, 
são configurados para impedir usuários típicos.
Elmasri e Navathe (2011, p. 563) dividem as medidas de controle em 
quatro tipos:
• Controle de acesso.
• Controle de fluxo.
• Criptografia de dados.
• Controle de inferência.
O controle de acesso sobre contas e privilégios de usuários ou grupos 
de usuários é determinado pelas necessidades negociais e pelos 
gerentes de negócio, cabendo ao DBA gerenciar essa permissão.
13
O controle de fluxo inibe que as informações transitem por canais 
secretos e burlem a política de segurança ao alcançarem usuários não 
autorizados. A criptografia, por sua vez, tem a ver com o ocultamento 
dos dados por meio dos meios de transmissão, sendo permitido apenas 
ao emissor e receptor ler as mensagens em texto claro, ou seja, sem 
estarem criptografadas.
Por fim, o controle de inferência tem a ver com o banco de dados 
estatísticos, em que os usuários podem acessar os dados agregados, 
mas não podem, por exemplo, chegar à informação de menor 
granularidade. Assim, um sistema de compras em que se teria acesso às 
compras de uma região, mas não se poderia acessar os dados de cada 
um dos compradores especificamente.
Aqui, veremos o mais importante dentro da temática abordada: o 
controle de acesso.
4.1 Controle de Acesso
O SGBD deve fornecer técnicas com o intuito de permitir que uma gama 
de usuários possua acesso somente a um conjunto selecionado dos 
dados, mas sem acesso ao banco de dados restante. Conforme Elmasri e 
Navathe (2011, p. 563), existem dois tipos de mecanismos de segurança:
• Mecanismos de segurança discricionários: são os relativos à 
concessão de privilégios de usuários nos objetos do banco de 
dados, usando as operações padrão SQL (SELECT, UPDATE, INSERT 
e DELETE).
• Mecanismos de segurança obrigatórios: estão relacionados a 
impor segurança baseada em camadas ou multiníveis. Em resumo, 
alguns grupos de usuários têm papéis, em que uns podem ler 
alguns dados, outros atualizar esses dados e outros simplesmente 
14
não acessar esses dados por terem privilégios de classificação 
baixos.
5. Segurança de Dados e o DBA
Nesse cenário, existe um profissional que é responsável por administrar 
a gestão dos acessos e privilégios, o chamado Database Administrator 
ou, em português, Administrador de Bando de Dados (DBA). Entre suas 
tarefas diárias, está a gestão de desempenho do banco de dados por 
meio de monitoramento, políticas de backups, recuperação de dados, 
auditorias de acessos, atendimento a solicitações de usuários, entre 
outras correlatas. Aqui iremos dar maior foco às questões de criação de 
contas, concessão de privilégios, revogação de privilégios e atribuição de 
nível de segurança.
Como já vimos, o DBA concede aos usuários apenas os privilégios 
necessários para realizar o trabalho que lhes foi atribuído. Em outras 
palavras, permite que apenas alguns usuários acessem, processem ou 
alterem dados. São divididos por categorias:
• Privilégio do sistema.
• Funções do usuário.
• Privilégios do objeto.
Por exemplo, como já falamos, criar espaços em tabela e excluir dados 
de qualquer tabela em um banco de dados são privilégios do sistema. 
Esses privilégios são tão importantes que, por padrão, são configurados 
para impedir que usuários executem operações importantes.
15
5.1 Tipos de ações tomadas pelo DBA
Cada banco de dados requer pelo menos um DBA, o qual tem várias 
funções, como monitoramento e otimização. Em se tratando da 
segurança do SGDB, é imprescindível sua atuação, pois é por meio dele 
que serão aplicados os melhores controles de segurança.
Os DBA normalmente possuem contas com altos privilégios, mas é 
importante ressaltar que, em alguns bancos de dados comerciais, essa 
conta varia de nome. Por exemplo, no MySQL, chama-se root; e no SQL 
Server ou MS SQL, banco de dados da Microsoft, chama-se SA.
No geral, são quatro tipos de ações basicamente tomadas por esses 
profissionais:
• Criação de contas: criar uma conta para um grupo de usuários 
ou um usuário específico com a finalidade de acessar o SGBD; 
comando SQL – CREATE USER.
• Concessão de privilégios: essa ação atribui ao usuário específico 
ou a um grupo de usuários privilégios a determinadas contas; 
comando SQL – GRANT.
• Revogação de privilégios: essa ação retira os privilégios 
concedidos pelo comando GRANT; comando SQL – REVOKE.
• Atribuição de nível de segurança: o objetivo dessa ação é 
conceder, conforme cada conta de usuário, o nível apropriado 
de segurança, incluindo, em resumo, em um grupo ou papel 
específico.
O DBA é responsável pela segurança do sistema de banco de dados, 
e a criação de conta é utilizada para controlar o acesso ao SGDB, 
nominando um serviço ou responsável. A concessão e a revogação de 
privilégios são usadas no controle da autorização dos usuários do SGDB.16
A atribuição de nível de segurança é importante e servirá para o controle 
e os direitos de acesso ao banco de dados de forma obrigatória.
6. Principais privilégios
A concessão de privilégios acontece no dia a dia das corporações, 
quando são necessários acesso aos dados armazenados nos mais 
diversos SGBDs. No Quadro 1, demonstramos quando utilizar e em 
quais cenários.
Quadro 1 – Cenários de concessão de privilégios nas corporações
TIPO DE PRIVILÉGIO CENÁRIO DE UTILIZAÇÃO
SELECT
Podem ser concedidas permissões de SELECT 
para usuários que precisam apenas visualizar 
os dados, garantindo dessa forma que, mesmo 
em caso de tentativa de alteração ou exclusão 
dos dados, não seja possível a efetivação dessas 
operações.
UPDATE
Usuários de aplicações que precisam atualizar 
dados em determinadas tabelas, mas sem 
ter visão do banco de dados como um todo, 
garantindo, assim, a confidencialidade dos 
dados. O usuário apenas tem permissão para 
UPDATE no BD, sendo muito utilizado em 
instituições financeiras para evitar acesso a 
saldos de contas de clientes de outras agências.
INSERT e DELETE
Normalmente são concedidos privilégios de 
INSERT e DELETE para usuários que precisam 
persistir dados; para garantir a auditoria, são 
criados gatilhos no banco.
Fonte: elaborado pelo autor.
17
Nesses cenários, podem ser mesclados e concedidos privilégios 
utilizando diversos recursos de um SGBD de mercado, mas na prática 
do dia a dia é muito comum a concessão de privilégios dos três tipos 
apresentados no Quadro 1.
Segundo Date (2003, p. 853), existe uma forma simples para separar 
o acesso aos dados pelos usuários, que é o mecanismo de visões, 
comando SQL CREATE VIEW. Essa instrução pode criar uma estrutura 
que condessa informação de várias tabelas do banco por meio de 
consultas SQL elaboradas, ocultando colunas ou linhas de dados que 
não devem ser acessíveis a certos grupos de usuários. Após sua criação, 
podem ser concedidas permissões com o comando GRANT. A utilização 
de comandos GRANT e REVOKE tem como objetivo o controle de quais 
usuários têm privilégios tanto para a definição de dados com comandos 
Data Definition Language (DDL) como comandos Data Manipulation 
Language (DML).
As concessões são dadas em todos os objetos de um banco de dados, 
como TABLES, PROCEDURES, VIEWS e TRIGGERS. Uma opção interessante 
para o usuário é conceder permissões para outro usuário e este 
ter privilégios para concessão de permissões. O comando GRANT é 
completado pela opção WITH GRANT OPTION.
Para exemplificar, vamos utilizar o banco de dados MySQL, que é um 
software de mercado e possui licença para uso gratuito. Os comandos 
GRANT e REVOKE dão possibilidade aos DBA para conceder e revogar 
direitos aos usuários do MySQL em seis níveis de privilégios:
• Nível global: privilégios globais aplicam-se para todos os bancos 
de dados em um determinado servidor, o comando GRANT dá 
permissões amplas no servidor localhost para o usuário userdb 
e o comando REVOKE retira esses privilégios logo em seguida. 
Se for usada a sintaxe ON * (em vez de ON *. *), privilégios serão 
18
atribuídos no nível do banco de dados para o banco de dados 
padrão.
Exemplo:
1. grant all on *.* to userdb@localhost;
2. revoke all on *.* from userdb;
• Nível das colunas: privilégios de colunas aplicam-se a uma coluna 
específica em uma determinada tabela. Podem ser utilizados para 
os comandos SELECT, INSERT e UPDATE de determinadas colunas 
que desejar.
Exemplo:
1. grant select(nomecoluna1),
2. insert(nomecoluna1),
3. update(nomecoluna1)
4. on posgraduacao.nome_tabela
5. to userdb@localhost
6. identified by senha;
• Nível do banco de dados: privilégios de bancos de dados aplicam-
se a todas as tabelas em um determinado banco de dados. Os 
comandos para conceder e revogar apenas privilégios de banco de 
dados serão:
Exemplo:
1. grant all to posgraduacao.* to userdb @localhost
2. revoke all on posgraduacao.*;
• Nível de tabelas: privilégios de tabelas aplicam-se a todas as 
colunas em uma determinada tabela. Os comandos para conceder 
e revogar apenas privilégios de tabelas serão:
19
Exemplo:
1. grant all on posgraduacao.nome_tabela;
2. revoke all on posgraduacao.nome_tabela;
• Nível de proxy user e rotinas armazenadas: o privilégio de proxy 
permite que um usuário seja proxy de outro. O usuário externo de 
um outro host assume os privilégios de um usuário e o de rotinas 
armazenadas; as famosas procedures e functions também podem 
ser concedidas. Vejamos um exemplo de cada caso.
Exemplo 1 – Proxy User:
1. mysql> grant PROXY on userdb@localhost to 
‘usuarioexterno’@’hostexterno’;
Exemplo 2 – Rotinas Armazenadas:
1. ## para rotinas
2. mysql> grant routine on posgraduacao.* to userdb@localhost;
3. ## para procedures
4. mysql> grant execute on procedure posgraduacao.
nomeprocedure to userdb@localhost;
Assim, finalizamos este bloco sobre o gerenciamento de usuários e o 
controle de acesso, dando base teórica e prática para que o aluno possa 
entender como funciona um SGDB de mercado.
Referências Bibliográficas
DATE, Christopher J. Introdução a sistemas de banco de dados. 8. ed. Rio de 
Janeiro: Elsevier, 2003.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed. São 
Paulo: Pearson, 2011.
20
HEUSER, Carlos A. Banco de dados relacional: conceitos, SQL e administração. 
Porto Alegre: Clube de Autores, 2019.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de 
dados. 6. ed. Rio de Janeiro: Elsevier, 2012.
21
Controle de Bloqueio em 
Transações: Locks
Autoria: Washington Henrique Carvalho Almeida
Leitura crítica: Marcelo Ramillo
Objetivos
• Conceituar transação.
• Apresentar o conceito das propriedades da 
transação.
• Definir resumidamente cada um dos “princípios” da 
transação.
• Demonstrar a importância do COMMIT e ROLLBACK.
• Expor os tipos de bloqueio.
22
1. Introdução
Neste tema, estudaremos o assunto controle de bloqueio em transações 
e trataremos, somente, acerca dos temas principais:
• Transações.
• Propriedades das transações.
• Tipos de bloqueios.
• Operação atinente a cada bloqueio.
As transações podem consistir em uma ou mais instruções de 
manipulação de dados, gravando informações no Sistema de 
Gerenciamento de Banco de Dados (SGDB). A consistência e a 
integridade dos dados são gerenciadas nativamente e garantem que as 
transações sejam executadas de forma segura. Uma transação simples 
geralmente usa um padrão:
1. Início da transação.
2. Execução de um conjunto de manipulações de dados e/ou 
consultas.
3. Se nenhum erro ocorrer, a transação é confirmada.
4. Se ocorrer um erro, a transação é revertida.
Portanto, uma transação requer que todos os resultados de 
manipulações de dados dentro do escopo das instruções sejam íntegros. 
É importante salientar uma característica primordial nas situações 
com as quais nos deparamos: para garantir a integridade apresentada, 
as regras de negócios deverão estar no SGDB. Porém, em muitos 
casos, estão escritas na aplicação, não se beneficiando desse recurso 
importantíssimo.
23
Vamos a um exemplo. Consideremos um aplicativo bancário em que 
a pessoa irá transferir determinado valor da conta-poupança para a 
conta-corrente. Se o aplicativo subtrair o valor da conta-poupança, mas 
for interrompido por um problema no sistema antes de adicionar o 
valor à conta-corrente, a transação não será realizada. Nesse caso, não 
houve integridade na transação, tampouco todos os comandos foram 
executados.
Ao final deste tema, será possível responder a algumas perguntas 
atinentes ao assunto em questão: Controle de Bloqueio em 
Transações. São elas:
1. O que é transação?
2. Qual a diferença entre COMMIT e ROLLBACK?
3. Quais as propriedades da transação?
4. Definir resumidamente cada uma delas.
5. Quais os tipos de bloqueios?
6. Quais são as operações de cada bloqueio citado anteriormente?
1.1 Transações
Uma transação é uma execução de código escrito em SQL. É formada 
por uma sequência deoperações, insert, update ou delete, que precisam 
ser executadas integralmente e são obrigatoriamente delimitadas por 
declarações de início e fim. A principal função é garantir ao banco de 
dados a consistência e a precisão dos dados. Só é considerada válida 
e gravada na fonte de dados se todos os seus comandos forem bem-
sucedidos. Se houver falha durante qualquer comando, a transação será 
invalidada.
Também pode ser definida como uma unidade de trabalho que começa 
sempre com uma operação chamada de BEGIN TRANSACTION e termina 
com uma operação COMMIT ou ROLLBACK. Veremos a seguir a definição 
de cada uma.
24
Como o próprio nome já diz, BEGIN TRANSACITON é o início da transação, 
isto é, é um comando SQL que indica onde a transação deve começar; 
assim, tudo que estiver antes desse comando não entra no comando da 
transação. Já o COMMIT TRANSACTION é o fim do código da transação, e 
vale ressaltar que ele indica quando a ação ocorre como o esperado. Por 
fim, o ROLLBACK TRANSACTION diz respeito a voltar para a “versão” em 
que o banco se encontrava sem erro, isto é, em seu estado original.
Exemplo:
CREATE TABLE TabelaAula (id int);
BEGIN TRANSACTION; — IníciodaTransação
INSERT INTO TabelaAula VALUES(1);
INSERT INTO TabelaAula VALUES(2);
COMMIT; — Conclusão da transação e gravação de todos os comandos.
Se utilizássemos o ROLLBACK, os valores inseridos na TabelaAula seriam 
“excluídos”, isto é, o estado do banco de dados anterior à transação 
citada teria “voltado”. Ele significa uma conclusão com insucesso de uma 
transação.
Nos casos de ROLLBACK e COMMIT, em ambas as situações a execução 
ocorre automaticamente dentro da aplicação.
Já em relação ao COMMIT, na operação citada, quando ocorre a inserção 
dos valores na tabela TabelaAula, esta não é gravada antes que ocorra 
o COMMIT. Acontece que a operação (inserção dos dados na tabela) 
é armazenada em buffer de memória, ou seja, não há uma efetiva 
atualização dos dados antes do COMMIT.
25
1.2 Propriedades da Transação
Vamos falar um pouco acerca das propriedades da transação 
(Atomicidade, Consistência, Isolamento e Durabilidade). Todavia, antes, 
abordaremos um assunto chamado de controle de concorrência entre 
transações em banco de dados, pois ele é inerente a essas propriedades.
Quando um banco de dados é acessado por mais de um usuário, 
isto é, quando vários usuários diferentes tentam buscar as mesmas 
informações no banco de dados, é efetuado o controle de concorrência 
entre os dados acessados. Podemos conceituar esse controle como 
um método utilizado para que as transações sejam executadas 
com segurança e sigam os princípios de Atomicidade, Consistência, 
Isolamento e Durabilidade (ACID).
Figura 1 – ACID
Fonte: elaborada pelo autor.
Vamos falar agora sobre cada uma das propriedades citadas na figura.
26
Atomicidade
• A transação deve ser realizada por completo. Assim, se acontecer 
algum erro durante sua execução, ela não será realizada. Ou seja, 
ou a transação é efetuada na sua totalidade ou não é realizada.
• Ex.: Um usuário quer debitar R$ 100 da conta A e creditar R$ 100 
na conta B. Se essa transação acontecer com sucesso, o BD é 
alterado de forma permanente, denominado COMMIT.
Consistência
• Quando ocorrer a execução de uma transação, esta deve partir de 
um estado válido a outro estado válido, isto é, a transação deve 
respeitar sempre as regras relacionadas à integridade dos dados 
do banco (ex. chave primária, chave secundária, tipo de dados, 
entre outros).
• Ex.: Se alguém tentar inserir na TabelaDeVendas a venda de um 
produto que não se encontra na TabelaProdutos, a transação irá 
falhar.
Isolamento
• Conforme Date (2003),
As transações são isoladas umas das outras. Isto é, embora em geral haja 
muitas transações sendo executadas ao mesmo tempo, as atualizações 
de qualquer transação dada são ocultas de todas as outras até o COMMIT 
dessa transação. (DATE, 2003, p. 737)
Outro modo de apresentar esse conceito é afirmar que, no caso de duas 
transações distintas A e B, A poderia ver as atualizações de B (após B 
fazer o COMMIT) ou B poderia ver as atualizações de A (após A fazer o 
COMMIT), mas certamente não ambas.
27
• Ex.: Imaginemos que dois alunos da Universidade XYZ entrem 
no site de uma livraria para comprar um livro sobre segurança 
e auditoria de banco de dados solicitado pelo professor. Os dois 
encontram o livro, mas há somente uma unidade em estoque. 
Como não sabem dessa informação, fazem o pedido na loja. 
No entanto, como há somente um livro no estoque, o primeiro 
que “terminar” a compra fará com que a transação do outro seja 
desfeita, acontecendo o chamado ROLLBACK.
Durabilidade
• Também chamada por alguns autores como permanência, garante 
que as alterações realizadas no banco de dados em razão da 
transação sejam efetivadas com sucesso, mesmo que ocorra 
alguma falha no banco de dados. Ou seja, se acontecer alguma 
“queda” do banco de dados, ela garante que as atualizações serão 
realizadas com sucesso. Todavia, devemos lembrar que tudo isso 
acontece após a conclusão com o COMMIT.
• Ex.: Se uma pessoa faz uma transação bancária (retira dinheiro) 
e no mesmo momento acontece alguma falha no BD, o valor 
retirado não é debitado da conta; assim, somente após o BD 
“voltar ao normal” é que a transação será atualizada.
Como uma digital, a transação deve ser isolada, como se cada uma 
fosse única. A Figura 2 aborda essa característica de suma importância 
no contexto da era da informação e do advento da internet, em que 
a quantidade de processamento de informação cresce em escala 
exponencial.
28
Figura 2 – Transações e sua característica de isolamento
iStock – Monsitj/iStock.com. 
1.3 Técnicas de bloqueio em duas fases para controle de 
concorrência
Vamos estudar sobre as técnicas de bloqueio em duas fases para 
controle de concorrência. Primeiramente, vamos definir o que seria 
bloqueio quando se fala em transação de banco de dados.
No entendimento de Elmasri e Navathe (2011, p. 523), um bloqueio é 
uma variável associada a um item de dados que descreve o status do 
item em relação a possíveis operações que podem ser aplicadas a ele. 
Em geral, existe um bloqueio para cada item de dados no banco de 
dados, o qual é utilizado como um meio de sincronizar o acesso por 
transações concorrentes aos itens do banco de dados.
29
Há diversos tipos de bloqueio utilizados no controle de concorrência, 
entre eles estão o bloqueio binário e o compartilhado, como veremos a 
seguir.
Bloqueio binário
• Esse tipo de bloqueio pode ter somente dois valores, isto é, dois 
estados: 0 ou 1. O estado 0 (zero) significa estado desbloqueado 
e o estado 1 (um) significa estado bloqueado. Quando se fala 
em estado bloqueado, quer dizer que não pode ser acessado. 
Por exemplo, se o valor em A for 1, dizemos que A não pode ser 
acessado por nenhuma operação do banco de dados que solicite 
esse item. Agora se o valor em A for 0, dizemos que A pode ser 
acessado por qualquer operação do banco de dados que solicitar 
esse item.
• Ressalta-se que duas operações são utilizadas no bloqueio binário, 
o lock_item e o unlock_item. Se utilizamos LOCK (A) = 1, sendo A 
nosso item, essa transação é forçada a parar; mas, se utilizarmos 
LOCK (A) = 0, a transação pode acessar o item A. No caso do 
UNLOCK, quando a transação termina de usar o item, emite 
uma operação UNLOCK, ou seja, o LOCK (A) volta para o valor 0 
(zero) e desbloqueia o item, o qual pode ser acessado por outras 
transações.
• Exemplo de código:
lock_item(A):
B: se LOCK(A) = 0 (*aqui, o item apresenta-se desbloqueado*)
então LOCK(A) 1 (*aqui, o item apresenta-se bloqueado*)
se não
início
30
wait (until LOCK(A) = 0
go to B
fim;
unlock_item(A):
LOCK(A) 0; (*aqui o item apresenta-se desbloqueado*)
Se alguma transação estiver esperando, então desperta uma das 
transações que está esperando.
Bloqueios compartilhados/ exclusivos
• Outros autores também definem esse tipo de bloqueio com 
leitura/ gravação.Diferentemente do bloqueio binário, que 
somente uma transação mantém o bloqueio a um determinado 
item, no bloqueio compartilhado o item A pode ser acessado por 
várias transações ao mesmo tempo no caso de leitura; agora, se 
for no caso de gravação, no item A a transação precisa ter acesso 
exclusivo ao respectivo item.
• Há três tipos de operações que ocorrem nesse tipo de bloqueio: 
Read_lock(A), Write_lock(A) e Unlock(A). O bloqueio do item A 
possui três estados: bloqueio para leitura, bloqueio para gravação 
e desbloqueio para transação. Outras transações podem ter 
acesso ao item bloqueado para leitura, e, por isso, ele pode ser 
chamado de item bloqueado para compartilhamento. No item 
bloqueio para gravação, somente uma transação mantém com 
exclusividade e o bloqueio no item pode ser chamado de item 
bloqueio exclusivo.
• Exemplo de código:
read_lock(A):
31
B: se LOCK(A) = “unlocked”
então início LOCK(A) “read-locked”;
num_de_leituras(A) 1
fim
se não se LOCK(A) = “read-locked”
então numero_de_leituras(A) numero_de_leituras(A) + 1
se não início
wait (até que LOCK(A) = “unlocked”
e o gerenciador de bloqueio desperta a transação);
go to B
fim;
write_lock(A):
B: se LOCK(X) = “unlocked”
então LOCK(X) “write-locked”
então início
wait (até que LOCK(X) = “unlocked”
e o gerenciador de bloqueio desperta a transação);
go to B
fim;
32
unlock (A):
se LOCK(A) = “write-locked”
então início LOCK(A) “unlocked”;
desperta uma das transações aguardando, se houver
fim
se não se LOCK(A) = “read-locked”
então início
numero_de_leituras(A) numero_de_leituras(X) −1;
se numero_de_leituras(A) = 0
então início LOCK(A) = “unlocked”;
desperta uma das transações aguardando, se houver
fim
fim;
1.4 Visão Geral de Controle
Neste tema, apresentamos a introdução e a conceituação da transação 
e sua importância dentro da Segurança em Banco de Dados. Também 
explicitamos acerca das propriedades da transação ACID: atomicidade, 
consistência (alguns autores chamam essa propriedade de correção), 
isolamento e durabilidade. Percebe-se que cada uma tem uma função 
muito importante nas transações.
33
A atomicidade pode ser descrita como tudo ou nada, isto é, ou as 
atualizações são realizadas como um todo ou não. Aqui podemos 
afirmar que não há atualização atinente à transação de modo parcial, 
pois, como dito, é tudo ou nada.
O isolamento garante que uma transação seja isolada de todas as 
demais. Em resumo, a transação apresenta-se invisível em relação a 
todas as outras transações, tendo cada uma sua própria digital, de 
forma que nunca se confundem com outras, até realizar o COMMIT 
(sucesso).
No caso da consistência, é a propriedade que assegura que uma 
transação deve conduzir o BD de um estado válido a outro estado 
válido. Por fim, temos a durabilidade, propriedade que afirma que, 
após realizada a transação com sucesso, esta permanecerá no banco de 
dados mesmo que ocorra um eventual erro no banco.
Vale lembrar que as propriedades da transação são um dos 
conceitos mais importantes quando se fala em segurança de banco 
de dados, definindo os princípios que o SGBD deve possuir. Esse 
modelo (Atomicidade, Consistência, Durabilidade e Isolamento) está 
intimamente ligado aos princípios de Segurança de Dados, que são 
confidencialidade, integridade e disponibilidade.
A confidencialidade está relacionada à garantia de que as informações 
estão acessíveis somente para aqueles clientes devidamente 
autorizados. Já a disponibilidade garante que as informações estejam 
sempre disponíveis para os usuários devidamente autorizados. Por 
fim, a integridade está relacionada à precisão, à consistência e à 
confiabilidade das informações recebidas pelos usuários
Falamos também sobre as técnicas de bloqueio em duas fases para 
o controle de concorrência: bloqueio binário e bloqueio exclusivo/ 
compartilhado. Assim, temos como definição das operações do bloqueio 
34
binário LOCK(item) e UNLOCK(item) e como definição das operações do 
bloqueio exclusivo/ compartilhado Read_lock(item), Write_lock(item) e 
Unlock(item).
Referências Bibliográficas
CHU, Shao Yong. Banco de dados: organização, sistemas e administração. São 
Paulo: Atlas, 1983.
DATE, Christopher J. Introdução a sistemas de banco de dados. 8. ed. Rio de 
Janeiro: Elsevier, 2003.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed. São 
Paulo: Pearson, 2011.
HERNADEZ, Michel J. Aprenda a Projetar seu Próprio Banco de Dados. São Paulo: 
Makron Books, 2000.
HEUSER, Carlos A. Banco de dados relacional: conceitos, SQL e administração. 
Porto Alegre: Clube de Autores, 2019.
ITO, Giani Carla. Banco de dados móveis: uma análise de soluções propostas para 
gerenciamento de dados. Florianópolis: UFSC, 2001.
KROENKE, David M. Banco de Dados: Fundamentos, Projeto e Implementação. Rio 
de janeiro: LTC, 1999.
ORACLE. Manual do Banco de Dados Oracle versão 8.1.7. EUA: Oracle 
Corporation, 2002.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de 
dados. 6. ed. Rio de Janeiro: Elsevier, 2012.
35
Políticas de backup e recovery de 
banco de dados
Autoria: Washington Henrique Carvalho Almeida
Leitura crítica: Marcelo Ramillo
Objetivos
• Conceituar e exemplificar a importância dos 
backups.
• Tratar da definição da política de backup.
• Demonstrar a importância da recuperação de falhas 
do SGBD.
36
1. Introdução
Neste tema, será abordado um assunto de grande importância, que é o 
tema Políticas de backup e recovery de banco de dados. A seguir são 
resumidos os principais tópicos a serem abordados.
Figura 1–Backup
iStock – NicoElNino/iStock.com.
O assunto backup é um tema comum nas atividades de várias áreas, 
mas na temática de banco de dados se torna um ponto crítico para 
a garantia da continuidade dos negócios. Imaginemos, por exemplo, 
a ocorrência de uma falha no equipamento em que está instalado o 
software do Sistema de Gerenciamento de Banco de Dados (SGBD) e 
que não seja possível restabelecer esse servidor. Sem backup, todos 
37
os dados seriam perdidos, o que pode acarretar até mesmo a falência 
de uma instituição. Nesse contexto, serão tratados os assuntos 
relacionados a seguir:
• Backup.
• Política de Backup.
• Tipos de Backup.
• Testes de Backup.
• Recuperação de falhas no SGBD.
• Tipos de Falhas.
Ao final, será possível responder a algumas perguntas relacionadas ao 
assunto. São elas:
1. O que é backup?
2. Qual a importância do backup?
3. Qual o objetivo de uma política de segurança?
4. Quais os tipos de backup?
5. Qual a definição de backup completo?
6. Quais são os tipos de recuperação de falhas?
1.1 Backup
Backup é o termo usado para a cópia de dados cujo objetivo é a 
recuperação em caso de falha e/ou perda. Para entender melhor 
e situarmos sua importância, vejamos um exemplo bem simples e 
corriqueiro na vida de todos nós:
• Imaginemos que um aluno finalize o projeto final do curso e, como 
uma pessoa precavida, salva o trabalho em algum serviço na 
38
nuvem, em um pen drive ou até mesmo no próprio computador. 
Depois, ele encaminha um e-mail com um anexo (o projeto 
final) para ele mesmo e, para garantir, ainda imprime e guarda 
na gaveta. O exemplo é simples, mas tudo que ele “guardou” é 
considerado um backup. Nesse procedimento, foram armazenados 
cinco arquivos com backups dos mesmos dados.
• Na nuvem.
• No pen drive.
• No computador.
• No e-mail.
• A impressão.
Nesse primeiro momento, podemos achar o procedimento apresentado 
correto, mas, na gestão de um Banco de Dados, os backups precisam ser 
realizados de forma sistemática e verificados periodicamente. Por esse 
motivo, será necessário entender a importância das políticas de backup.
Para finalizar, conceituando de forma simples o que seria backup, é só 
traduzir a palavra, que significa cópia de segurança. Percebe-se que cada 
“item” citado anteriormente é uma cópia de segurança, e todos esses 
dados devem estar disponíveis e ser íntegros e de fácil acesso.
1.2 Políticade Backup
Para que as ações de proteção sejam efetivas, devemos elaborar uma 
política de backup, que é um “manual” com todas as regras acerca do 
armazenamento de dados. Para termos uma ideia, ele nos responde 
algumas questões importantes
• Quais os dados/informações para realizar o backup?
39
Na política de backup, devem ser definidos os dados dos quais iremos 
fazer backup, pois, se realizarmos backup de todos os dados, ficará 
muito caro para a empresa, uma vez que o armazenamento de dados 
custa muito caro, seja ele storage “físico” ou nuvem. Essa pergunta é 
crucial para a organização definir quais dados são importantes e devem 
constar no backup.
• Qual o tipo de backup a ser realizado?
É muito importante a organização definir o tipo de backup. Como 
exemplo, podemos citar o backup Full, que é muito mais caro para a 
organização do que um backup incremental, porque ele faz uma cópia 
de todos os dados, diferentemente do incremental, como veremos mais 
adiante.
• Qual o local de armazenamento?
Devemos definir aqui o local de armazenamento, isto é, se a cópia 
dos nossos dados irá para um storage “físico” ou para a nuvem. É 
necessário fazer um estudo técnico preliminar para definir uma solução, 
conforme a necessidade da empresa, como tamanho da empresa, ramo, 
quantidade de dados para backup, entre outros. Além disso planos 
de continuidade de negócios pregam a segregação de ambientes para 
não ficarem no mesmo local físico os dados e os backups, pois, no caso 
de uma falha catastrófica ocasionada por um incêndio, por exemplo, 
a recuperação dos dados seria impossível, pois os backups também 
seriam perdidos.
• Qual a frequência da realização desse backup?
O backup pode ser realizado diariamente, semanalmente, 
quinzenalmente ou mensalmente. É importante lembrar que o 
armazenamento de dados custa dinheiro; assim, quanto maior a 
frequência, possivelmente o custo aumenta.
40
• Quais os responsáveis por essa tarefa?
É possível definir responsáveis ou automatizar o processo para a 
realização dos procedimentos do backup.
A importância da política de backup é mitigar os riscos de perda de 
informações. Sua função é garantir que os backups estejam disponíveis 
quando essas cópias forem solicitadas.
No âmbito da segurança em banco de dados, os backups podem ser 
melhor entendidos como cópias de segurança que são realizadas com 
periodicidade e constituem um ponto de partida para recuperar o banco 
de dados depois da ocorrência de uma falha, dependendo do grau de 
gravidade dessa falha.
1.3 Tipos de Backup
Existem basicamente quatro tipos de política de backup tratados 
pelos principais autores. Imaginemos uma situação hipotética 
para podermos entender os tipos utilizando um exemplo simples. 
Todos os dados de um aluno estão armazenados na pasta chamada 
“TrabalhoDeConclusãoDeCurso”, e as subpastas apresentam-se 
conforme a figura a seguir:
41
Figura 2 – Subpastas da pasta “TrabalhoDeConclusãoDeCurso” do 
exemplo
Fonte: elaborada pelo autor.
Imaginemos agora que serão definidos tipos de backups que podem ser 
realizados em cima desse conjunto de informações.
42
Backup Completo (Full)
• Realiza uma cópia de segurança total de toda a pasta para 
outro local de armazenamento, independentemente se houve 
atualização somente nas subpastas. No nosso exemplo, então, 
a cada execução de um backup desse tipo, todos os dados são 
novamente copiados para o local definido.
Backup Incremental
• Esse tipo de backup realiza a cópia de segurança somente das 
subpastas em que houve atualização desde o último backup 
incremental. Por exemplo, caso existisse a inserção de tabelas na 
subpasta “Tabelas” e a exclusão de figuras na pasta “Figuras”, 
a cópia de segurança somente seria realizada nessas pastas. 
Diferentemente do backup completo, o incremental não 
faria o backup em todas as pastas. Assim, em resumo, só são 
incrementadas na cópia as informações novas ou alteradas.
Backup Diferencial
• Esse tipo de backup é semelhante ao incremental. No entanto, no 
incremental, a cópia de segurança é realizada em relação à última 
cópia de segurança do backup incremental, enquanto no backup 
diferencial a cópia de segurança é realizada em relação à última 
cópia do backup completo.
• Backup Diferencial: última cópia do backup completo.
• Backup Incremental: última cópia do backup incremental.
Backup Incremental Contínuo
43
• É semelhante ao backup incremental, mas a diferença está na 
automatização do processo; assim, não há necessidade de saber 
quais bancos de dados serão copiados, e, no nosso caso, quais 
subpastas necessitam de backup.
1.4 Outras classificações
O backup pode ser classificado também em:
• Backup lógico: realiza uma cópia dos scripts de criação de banco 
de dados, das tabelas e dos registros. Esse tipo de backup é o mais 
utilizado.
• Backup físico: realiza uma cópia da pasta de instalação do 
banco de dados, salvando a estrutura do arquivo de instalação e 
incluindo os dados.
Outra classificação de tipos de backup utilizada por alguns autores:
• Backup on-line: ocorre enquanto o servidor apresenta-se em 
execução para que as informações contidas no banco de dados 
possam ser adquiridas a partir do servidor de banco de dados. 
Podemos citar uma característica desse tipo de backup:
• De acordo Carvalho (2017, p. 136), devem ser tomados cuidados 
para impor bloqueio apropriado a fim de que as modificações de 
dados não ocorram de forma a comprometer a sua integridade.
• Backup off-line: diferentemente do backup on-line, que ocorre 
enquanto o servidor de banco de dados apresenta-se em 
execução, o off-line ocorre quando o banco de dados está parado. 
Podemos citar duas características importantes desse tipo:
• O servidor não fica disponível durante o backup, afetando de 
forma negativa os clientes.
44
• Não existe possibilidade de interferência do cliente, tornando o 
processo simples.
1.5 Recuperação de Falhas
Sabendo os tipos de backups e as políticas básicas que podem ser 
utilizadas nas mais diversas bases de dados, pode-se pensar no cenário 
de recuperação de falhas. O conceito de recuperação de falhas é 
simples, trata-se do processo em que é realizado o retorno do banco 
de dados ao seu estado “sem falhas”, ou seja, antes de um problema ou 
desastre ocorrer, retornando assim a um estado consistente e válido 
com dados confiáveis.
Esse assunto apresenta-se intimamente ligado às propriedades da 
transação chamadas de Propriedades ACID. A recuperação de falhas 
implementa um nível a mais de segurança em um ambiente de SGBD, 
pois nem sempre é possível que o SGBD garanta a consistência dos 
dados em caso de falhas.
1.6 Testes de Backup
Uma atividade fundamental na garantia da consistência dos dados 
que são copiados de maneira segura são os testes de backup. 
Todas as políticas definidas de cópia e retenção devem ser testadas 
periodicamente, mesmo que seja comum nas organizações essas 
atividades serem relegadas. Assim, quando é necessária a recuperação 
de algum dado, verifica-se que o backup não funciona, ou seja, por 
problemas nas mídias ou por falha nos softwares o backup não está 
funcional.
Na definição de políticas de backup, devem constar cláusulas que 
indiquem a periodicidade dos testes em ambientes específicos, 
45
separados de produção, para validar se os dados das cópias de 
segurança realmente poderão ser utilizados quando necessário.
1.7 Tipos de Falhas
Falhas ocorrem corriqueiramente nas instituições e podem ser 
ocasionadas por desastres naturais, incidentes elétricos e até por ações 
criminosas. O estudo da segurança da informação pressupõe a análise 
de riscos e a classificação da informação, mas, de forma simples no 
escopo do objeto de estudo desta disciplina, podemos classificar as 
falhas em dois tipos:
Falha catastrófica
• Essa falha ocasiona a perda permanente dos dados. Assim, para 
recuperá-los, é necessário a restauração da última cópia do 
banco de dados, anterior ao colapso. Dessa forma, o SGBDrealiza 
a restauração do banco de dados conforme o último backup 
armazenado.
Falha não catastrófica
• Nesse caso, é necessário saber a abrangência do problema 
ocasionado e verificar qual política de backup utilizada pode 
atender à demanda para recuperar os dados com o menor 
impacto possível, em alguns casos sem perda de dados e em 
outros com pequenos períodos de perda.
De acordo com Elmasri e Navathe (2011, p. 557), o gerenciador de 
recuperação de um SGBD também precisa ser equipado para lidar com 
falhas como as de disco. A principal técnica utilizada para lidar com 
essas falhas é um backup do banco de dados em que a base inteira e 
os logs são periodicamente copiados para um meio de armazenamento 
de menor custo, como fitas magnéticas ou outros dispositivos de 
46
armazenamento off-line de grande capacidade. No caso de uma falha 
catastrófica do sistema, a cópia de backup mais recente pode ser 
recarregada da fita para o disco, e o sistema é reiniciado.
Os dados de aplicações críticas, como bancos, seguros, mercado de 
ações e outros negócios críticos, são copiados de tempos em tempos 
em sua totalidade e movidos para locais seguros e fisicamente 
separados. Câmaras de armazenamento subterrâneas têm sido usadas 
para proteção contra danos ocasionados por inundação, tempestade, 
terremoto ou incêndio.
Eventos como o ataque terrorista de 11 de setembro em Nova York 
(em 2001) e o desastre do furacão Katrina em Nova Orleans (em 
2005) criaram uma maior conscientização sobre a recuperação, após 
desastres, dos bancos de dados críticos aos negócios. Para evitar perder 
todos os efeitos das transações que foram executadas desde o último 
backup, é comum fazer o backup do log do sistema em intervalos 
mais frequentes do que o do banco de dados inteiro, copiando-o 
periodicamente para fitas magnéticas.
O log do sistema costuma ser muito menor do que o próprio banco de 
dados e, portanto, pode ser copiado com mais frequência, fazendo com 
que os usuários não percam todas as transações que realizaram desde o 
último backup. Todas as transações confirmadas e registradas na parte 
do log do sistema que foi copiada para a fita podem ter efeito sobre o 
banco de dados refeito. Um novo log é iniciado após cada backup do 
banco de dados.
Assim, para recuperar-se da falha do disco, o banco de dados é 
primeiramente recriado no disco com base em sua cópia de backup 
mais recente em fita. Depois disso, os efeitos de todas as transações 
confirmadas, cujas operações foram registradas nas cópias do log do 
sistema, são restaurados.
47
1.8 Visão Geral sobre Backups
O termo backup ou “cópia de segurança” é uma cópia dos 
dados armazenados em uma fonte primária para uma fonte de 
armazenamento secundária. Para a gestão efetiva das cópias de 
segurança, é necessária a definição de políticas e de seu objetivo 
principal, que é a mitigação de riscos de perda da base dados. Nas 
atividades de gestão de um SGBD realizadas por um Administrador de 
Banco de Dados (DBA), são definidas inúmeras políticas de backups de 
acordo com a relevância e os riscos atrelados à perda dos dados que 
serão protegidos.
É necessário entender que em um mesmo ambiente de SGBD existem 
normalmente inúmeras bases de dados e cada uma delas vai ter uma 
política de backup diferente. Por exemplo, dados que têm pouca ou 
nenhuma alteração em longos períodos de tempo não necessitam ser 
copiados em políticas de backup diárias. Imaginemos o caso da Tabela 
que armazena os Estados do Brasil; se a última vez que um estado foi 
criado foi há mais de 30 anos, então não há a necessidade de realizar 
cópia desses dados periodicamente, podendo ser realizada anualmente.
O custo para armazenar backups é algo que sempre é levado em 
consideração na definição de políticas. Por isso, às vezes em cenários 
de restrições orçamentários de uma organização, muitos dados acabam 
por não ser incluídos nas políticas mais abrangentes, o que pode ser um 
risco para a instituição no caso de falhas.
48
Referências Bibliográficas
CARVALHO, Vinícius. MySQL: comece com o principal banco de dados open source 
do mercado. São Paulo: Casa do código, 2017.
DATE, Christopher J. Introdução a sistemas de banco de dados. 8. ed. Rio de 
Janeiro: Elsevier, 2003.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed. São 
Paulo: Pearson, 2011.
HEUSER, Carlos A. Banco de dados relacional: conceitos, SQL e administração. 
Porto Alegre: Clube de Autores, 2019.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de 
dados. 6. ed. Rio de Janeiro: Elsevier, 2012.
49
Aplicação de Auditoria em banco 
de dados
Autoria: Washington Henrique Carvalho Almeida
Leitura crítica: Marcelo Ramillo
Objetivos
• Apresentar o conceito de auditoria.
• Expor a importância da auditoria em banco de dados 
para as organizações.
• Conceituar e exemplificar comandos relacionados a 
cada tipo de linguagem de BD.
50
1. Introdução
A auditoria em banco de dados é um tema relevante na gestão de um 
Sistemas Gerenciador de Banco de Dados (SGBD) e o Administrador 
de Banco de Dados (DBA) tem entre suas atribuições a verificação dos 
controles estabelecidos pelas diversas políticas aplicadas nas bases 
de dados. Muitos estudos apontam que os incidentes de segurança 
da informação que trazem maiores prejuízos às organizações são os 
realizados por funcionários da própria instituição que possuem acessos 
privilegiados.
Neste tema, estudaremos sobre a aplicação de auditoria em banco de 
dados. Seguem os principais tópicos sobre o assunto:
• Auditoria.
• Auditoria em Banco de Dados.
• Formas para auditar Banco de Dados.
• Tipos de Linguagem.
51
Figura 1 – Auditoria em Banco de Dados
iStock – Erikona/iStock.com. 
Como já é de praxe, no final deste tema, será possível responder a 
algumas perguntas atinentes ao assunto em questão. São elas:
1. O que é auditoria?
2. Qual a importância da auditoria de Banco de Dados?
3. O que é log?
4. O que é DML?
5. O que é DDL?
1.1 Auditoria
Para entender a auditoria no contexto de um banco de dados, deve-se 
compreender primeiro o que significa esse tema, pois ela está ligada 
a diversas temáticas, tanto em organizações privadas como públicas. 
52
Além disso, a governança, um tema de bastante relevância, tem como 
premissa a utilização da ferramenta de auditoria para verificação de 
conformidade.
Crepaldi (2010) entende a auditoria como o estudo e a avaliação 
sistemática das transações, dos procedimentos, das operações, das 
rotinas e das demonstrações financeiras de uma entidade. E segundo 
Franco e Marra (2011), a auditoria é um trabalho que deve ser 
minuciosamente planejado e deve ser construído um plano de auditoria 
para isso.
Essas definições de autores renomados vão situar a importância 
do tema de forma mais ampla. Todavia, de uma forma sucinta e 
prática, pode-se definir auditoria por meio da própria tradução do 
verbo em inglês to audit, que significa examinar, certificar e confirmar 
procedimentos, processos e normas.
Alguns autores definem a palavra auditar por meio da sua origem do 
latim audire, que significa audição. Diante disso, os especialistas na 
área a conceituam como o ato de escutar o administrador. No âmbito 
dessa matéria, podemos dizer que esse auditor é o DBA, profissional 
responsável por gerenciar, criar regras, atualizar e monitorar o banco de 
dados.
A auditoria verifica e garante que um usuário não altere as informações 
às quais ele não deve ter acesso. As categorias de auditoria devem ser 
definidas por meio de checklists, que irão facilitar o rastreamento de 
alterações no banco de dados. A imagem a seguir retrata o que foi dito.
53
Figura 1 – Auditoria por Lista de Verificação (Checklist)
iStock – Porcorex/iStock.com. 
Trazemos por meio de um exemplo simples uma realização de auditoria. 
Há uma norma na empresa XYZ que determina que os cinco relatórios 
de vendas devem seguir essa sequência
1. Relatório 1 – Sapatos.
2. Relatório 2 – Camisas.
3. Relatório3 – Cuecas.
4. Relatório 4 – Calças.
5. Relatório 5 – Meias.
Em um certo momento, o chefe de Bob solicita a ele que faça os 
relatórios de vendas dos seguintes produtos: sapatos (1), camisas (2), 
https://www.istockphoto.com/br/portfolio/porcorex?mediatype=photography
54
cuecas (3), calças (4) e meias (5). Bob faz os relatórios de acordo com a 
ordem a seguir:
1. Relatório 1 – Meias.
2. Relatório 2 – Camisas.
3. Relatório 3 – Calças.
4. Relatório 4 – Cuecas.
5. Relatório 5 – Sapatos.
Seguindo a orientação de seu chefe, será que no caso de uma futura 
auditoria será possível dizer que os relatórios realizados estão em 
conformidade com a norma? Vamos ver um quadro comparativo de 
como a norma solicitava a produção dos relatórios e como Bob os 
realizou.
Quadro 1 – Comparativo Norma versus Trabalho Realizado
Número do 
Relatório
Como a norma 
determinou
Como Bob fez
Em conformidade 
com a norma?
1 Sapatos Meias Não
2 Camisas Camisas Sim
3 Cuecas Calças Não
4 Calças Cuecas Não
5 Meias Sapatos Não
Percebe-se que uma auditoria traria recomendações a essa área por 
não seguir a norma, como no caso dos relatórios (1, 3, 4 e 5); somente o 
relatório 2 está compliance (em conformidade) com a norma.
1.2 Auditoria em Banco de Dados
A auditoria é um dos recursos mais eficientes para a segurança do 
banco de dados. Independentemente do SGDB usado, em sua maioria 
possui ferramentas e métodos para a seleção da tecnologia de 
auditoria correta. Essa ação irá determinar o impacto no desempenho 
55
da auditoria, na proteção de dados e na geração de relatórios sobre 
informações que deverão ser ajustadas.
O que realmente fará a diferença no processo de auditoria de um 
banco é ter bem definido o que deverá ser auditado. Em se tratando 
da estrutura complexa de um SGDB, a definição é primordial para que 
os resultados sejam positivos, seja por meio da análise dos direitos dos 
usuários em executar comandos DML em um conjunto de tabelas ou no 
comprometimento que poderá afetar o processamento do servidor ao 
criar uma instrução SQL sem índices.
1.2.1 Controles da Administração do BD
É importante salientar que a auditoria deve se estender por situações 
que o DBA é responsável. Um exemplo, quando se cria uma instância 
de banco de dados, automaticamente o SGDB cria uma configuração 
padrão, incluindo usuários e senhas. Faz-se necessário nesses casos 
alterar e criar senhas fortes, o que é um tipo de auditoria que não tem 
relação com o usuário.
Um outro exemplo de relatório de auditoria é analisar o limite de tempo 
de time out configurado para cada usuário. Ou seja, se a sessão não 
expirar e o usuário se esquecer de fazer logout, o sessão permanecerá 
aberta, permitindo a qualquer pessoa realizar uma alteração de 
informação.
Outra situação recorrente no uso de auditoria são instruções SQL mal 
estruturadas pela aplicação. Esse tipo de problema geralmente absorve 
processamento, gerando lentidão para toda a empresa. Nesse caso, o 
DBA deverá auditar e identificar o processo, o módulo da aplicação, e 
corrigir a instrução que está gerando a lentidão para a correção.
A utilização de banco de dados é uma forma organizada e eficiente 
para manter os dados íntegros, confiáveis e disponíveis; todavia, 
56
somente o armazenamento dos dados em um banco não garante essas 
características. É preciso também se preocupar com a segurança do 
SGBD, que possui como um dos seus principais objetivos mitigar riscos 
para que os dados armazenados não sejam acessados por pessoas 
não autorizadas e que as pessoas autorizadas tenham acesso a esses 
dados sempre preservando os três princípios básicos da segurança da 
informação, o CID (Confidencialidade, Integridade e Disponibilidade).
Para garantir que a segurança seja eficiente de fato, devem ser 
realizadas auditorias para se certificar sobre o que os usuários estão 
fazendo, ou seja, o que estão autorizados a fazer. Dessa forma, não 
basta uma empresa ter uma SGBD em operação apenas, pois a 
informação nele armazenada é constantemente alterada; dependendo 
do tipo de aplicação que opera sobre esses dados, a segurança de 
bancos de dados possui aspectos relevantes no dia a dia da operação 
das bases de dados.
Da mesma forma, não basta ter somente segurança em banco de dados 
sem auditoria. Como já relatado, muitos problemas graves são advindos 
de usuários que possuem acesso válidos; por isso ela se torna tão 
importante.
Então, se existe um banco e este não tem segurança, todas as 
informações poderão ser acessadas por quem quiser. Por outro lado, 
se tem segurança, é preciso haver auditoria nesse banco, pois é a única 
forma de garantir que a política de segurança está cumprindo seu 
objetivo, ou seja, garantindo acesso somente a usuários autorizados 
e que estes estejam de fato realizando operações legais. Esses três 
conceitos apresentam-se inerentemente ligados entre si, conforme 
Figura 2.
57
Figura 2 – Camadas da Auditoria em Banco de Dados
Fonte: elaborada pelo autor.
Como já dito, a auditoria quer saber se aquela pessoa que estava 
autorizada a realizar certas ações no banco de dados está de fato 
realizando somente aquelas ações, bem como se existem pessoas tendo 
acesso a informações que não lhes foram autorizadas. Vejamos um 
exemplo:
O usuário A possui somente a permissão de realizar select na tabela A, 
mas com a auditoria percebe-se que esse usuário realizou update nessa 
mesma tabela; ou que o usuário B não tem permissão a nenhuma tabela 
do banco de dados, mas verifica-se que ele tem acesso não somente a 
uma tabela, e sim a todas as tabelas do banco.
O banco de dados deve prover meios para que o DBA o audite. Ele deve 
ter acesso a todas as ações, isto é, a todos os comandos que foram 
58
executados no banco com o objetivo de verificar se houve alguma ação 
indesejada, como alterações, exclusões ou inclusões indevidas de dados. 
Para isso, há algumas ferramentas que auxiliam na auditoria, tais como: 
Oracle Audit Vault, Firewall do Banco de Dados (AVDF) e db2audit da 
IBM.
1.3 Formas para auditar Banco de Dados
Podemos citar duas formas de auditar banco de dados, por meio de:
• Logs.
• Regras.
Para resolver o problema de ações indesejadas, podemos implementar 
logs no banco de dados, que nada mais são que um arquivo que grava 
todas as ações realizadas no SGBD. Resumidamente, o objetivo do 
arquivo de Log é gravar as atividades que o usuário realiza no banco de 
dados. Em outras palavras, tudo que for realizado será registrado no 
Log e somente o DBA ou a quem ele der permissão tem acesso a esse 
arquivo.
Devemos lembrar que, em um banco de dados médio, um arquivo de 
log poderá ter dezenas de gigabytes de texto corrido. Além dos logs, 
podem ser auditadas as regras estabelecidas aos usuários ou grupos, 
baseadas nos tipos de linguagem SQL, como será demonstrado a seguir. 
Um exemplo de ferramenta de análise de log é o Oracle Trace File 
Analyzer, que busca auxiliar/agilizar a árdua tarefa de coleta e análise 
de logs pelo DBA e/ou Oracle Suporte. 
59
1.3.1 Segregação de Funções
Alguns manuais e até mesmo legislações internacionais, como a 
Lei Sarbannes Oxley (SOX), indicam a boa prática de segregação de 
funções para fins de divisão de responsabilidades e verificação dos atos 
exarados pelos profissionais que executam atividades críticas. O Manual 
de Auditoria de Sistemas do TCU (1998), por exemplo, exemplifica 
que devem ser segregadas as funções de administração de dados. 
Essa segregação pode ser implantada por comitês de governança ou 
por meio de atribuição de responsabilidades segregadas no banco de 
dados por esquemas ao DBA envolvido na gestão, a fim de que as ações 
sempre sejam verificadas por mais de um responsável ou por áreas 
distintas.
Para exemplificar a questão, basta pensarmos que apenas um DBA faz 
a gestão de todo o SGBD de uma organização, de forma que seus atos 
não têm como ser auditados, mas isso não deve ocorrer em um cenário 
com segregação de funções. A segregação de funções é umaprática 
simples para evitar problemas graves, em que todas as operações são 
no mínimo realizadas e verificadas por um par de pessoas distintas. 
Um exemplo simples seria um DBA, que concede privilégios, ter as 
concessões verificadas por seu chefe, ou até mesmo para conceder os 
privilégios precisar previamente obter autorização explícita. Esse tipo de 
controle é facilmente implementado em ferramentas de atendimento 
de chamados, como o Ocomon, software livre, ou o Control Desk da 
empresa IBM.
1.3.2 Tipos de Linguagem
As regras podem ser criadas no banco de dados por meio de tipos de 
linguagens, são elas:
60
Quadro 2 – Linguagens SQL
Tipo de Linguagem Descrição Comandos Associados
DML – Data 
Manipulation 
Language
Manipulação de Dados
INSERT, UPDATE e 
DELETE
DDL – Data Definition 
Language
Definição de Dados CREATE, ALTER e DROP
DQL – Data Query 
Language
Consulta de Dados SELECT
DCL – Data Control 
Language
Controle de Dados GRANT e REVOKE
DTL – Data 
Transaction Language
Transação de Dados
BEGIN TRANSACTION, 
COMMIT e ROLLBACK
Fonte: elaborado pelo autor.
Então, a verificação de regras pode ser realizada pelo DBA ao consultar 
se os privilégios definidos de fato batem com os privilégios concedidos 
no SGBD. No exemplo inicial do caso do Bob, o DBA precisa verificar se 
o que está na norma, no caso a política de concessão de privilégios, está 
de fato batendo com os privilégios concedidos na base.
Alguém pode se perguntar como pode um usuário A ter pela política 
apenas privilégios, por exemplo, de DML e depois ser verificado que 
ele também possui privilégios de DQL, ou seja, consultar dados. Isso 
pode ocorrer por diversos fatores, principalmente pela liberação de 
acessos indevidos. Por exemplo, no caso de o DBA liberar acessos de 
maneira irrestrita, sem levar em consideração as normas estabelecidas; 
ou em casos de invasão ao SGBD, a partir da qual determinado usuário 
consegue acesso com privilégios de DCL e sai concedendo permissões 
para usuários que não deveriam tê-las; ou até mesmo em cenários 
de ataques do tipo de engenharia social, em que um funcionário 
ou colaborador descobre a senha do DBA com o intuito de cometer 
ilegalidades e obtém acesso para implementar acessos indevidos.
61
Por isso, a atividade de DBA deve ser desempenhada por pessoas que 
entendam a importância e as responsabilidades dessas atribuições, pois 
qualquer um dos casos anteriores pode levar a fraudes e problemas 
sérios nas instituições, sendo cabíveis penalidades legais às pessoas 
envolvidas.
1.3.3 Exemplificando com o MySQL
Em bancos de dados relacionais de metadados de banco de dados, 
como informações sobre o servidor, o nome de um banco de dados ou 
de uma tabela, o tipo de dado de uma coluna ou os privilégios de acesso 
são armazenados no dicionário de dados e/ou no catálogo do sistema. O 
MySQL fornece metadados de banco de dados em um esquema especial 
chamado INFORMATION_SCHEMA, havendo um desses em cada instância 
do MySQL. Ele contém várias tabelas somente leitura que podem ser 
consultadas para obter as informações necessárias.
Dependendo do que for preciso consultar, esse banco de dados pode 
apoiar os trabalhos de auditoria e servir de base para a análise de 
desempenho.
62
Figura 3 – Ferramenta HeidiSQL
Fonte: acervo do autor.
Já para a consulta de privilégios, o MySQL armazena informações dos 
seus usuários em outro banco de dados, que é o MySQL, demonstrado 
na Figura 3. As quatro tabelas principais que contêm informações 
valiosas para auditoria são: user, db, tables_priv e columns_priv.
A tabela user armazena as informações de todos os usuários do 
banco, como seu próprio nome já sugere; a tabela db armazena os 
privilégios dos usuários de um banco de dados específico; e as tabelas 
com final _priv armazenam privilégios associados a tabelas e colunas. 
Normalmente, apenas os DBA com privilégios de root (superusuário) 
acessam essas informações.
63
1.4 Considerações Finais
A aplicação da auditoria em banco de dados é uma tarefa importante 
para a garantia de conformidade nas operações executadas sobre os 
dados. Sua função principal é agregar à segurança do banco de dados 
uma nova camada de segurança para a governança dos dados, pois 
uma boa gestão só pode ser realizada com a aplicação de controles e 
a verificação das atividades. Há um senso comum de que a auditoria 
tem como foco verificar apenas operações indevidas, mas seu principal 
objetivo é garantir a mitigação de riscos, os quais podem levar à perda 
de dados e à quebra da segurança da informação.
Muitas instituições precisam, para sobreviver no mercado, garantir 
a integridade dos dados que mantêm, e é a auditoria que fornece 
subsídios para a confirmação, a partir de ações necessárias para evitar 
riscos que possam ser materializados.
Referências Bibliográficas
BRASIL. Tribunal de Contas da União. Manual de Auditoria de Sistemas. Brasília: 
TCU, 1998.
BRITO, Claudenir; FONTENELLE, Rodrigo. Auditoria privada e governamental: 
teoria de forma objetiva e mais de 500 questões comentadas. 3. ed. Niterói: 
Impetus, 2016.
CREPALDI, Sílvio Aparecido. Auditoria contábil: teoria e prática. 6. ed. São Paulo: 
Atlas, 2010.
DATE, Christopher J. Introdução a sistemas de banco de dados. 8. ed. Rio de 
Janeiro: Elsevier, 2003.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed. São 
Paulo: Pearson, 2011.
FRANCO, Hilário; MARRA, Ernesto. Auditoria contábil. 4. ed. São Paulo: Atlas, 2011.
HEUSER, Carlos A. Banco de dados relacional: conceitos, SQL e administração. 
Porto Alegre: Clube de Autores, 2019.
64
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de 
dados. 6. ed. Rio de Janeiro: Elsevier, 2012.
65
Bons estudos!
	Sumário
	Gerenciamento de usuários e seus privilégios
	Objetivos
	1. Introdução
	2. Segurança de dados
	3. Tipos de Segurança de Banco de Dados
	4. Medidas de Controle
	5. Segurança de Dados e o DBA
	6. Principais privilégios
	Referências Bibliográficas
	Controle de Bloqueio em Transações: Locks
	Objetivos
	1. Introdução
	Referências Bibliográficas
	Políticas de backup e recovery de banco de dados
	Objetivos
	1. Introdução
	Referências Bibliográficas
	Aplicação de Auditoria em banco de dados
	Objetivos
	1. Introdução
	Referências Bibliográficas