WBA0473_v1.

SEGURANÇA E AUDITORIA EM
BANCO DE DADOS
 Washington Henrique Carvalho Almeida

SEGURANÇA E AUDITORIA EM BANCO DE

DADOS
1ª edição

Londrina
Editora e Distribuidora Educacional S.A.
2020

2
 © 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.

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
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: [Link]@[Link]
Homepage: [Link]

3
SEGURANÇA E AUDITORIA EM BANCO DE DADOS

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

4
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.

5
 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?

6
 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.

7
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.

8
 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

9
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?

10
 • 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.

11
 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.

12
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

13
 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.

14
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.

15
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

Podem ser concedidas permissões de SELECT

para usuários que precisam apenas visualizar
os dados, garantindo dessa forma que, mesmo
SELECT
em caso de tentativa de alteração ou exclusão
dos dados, não seja possível a efetivação dessas
operações.
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
UPDATE
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.
Normalmente são concedidos privilégios de
INSERT e DELETE para usuários que precisam
INSERT e DELETE
persistir dados; para garantir a auditoria, são
criados gatilhos no banco.
Fonte: elaborado pelo autor.

16
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

17
 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:

18
 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.

19
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.

20
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.

21
 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.

22
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 de operaçõ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.

23
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.

24
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.

25
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.

26
 • 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.

27
 Figura 2 – Transações e sua característica de isolamento

iStock – Monsitj/[Link].

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.

28
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

29
 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):

30
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;

31
 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.

32
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

33
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.

34
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.

35
 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/[Link].

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

36
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

37
 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ítica de 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?

38
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.

39
 • 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:

40
 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.

41
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

42
 • É 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.

43
 • 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,

44
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 SGBD realiza
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

45
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.

46
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.

47
 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.

48
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.

49
 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.

50
 Figura 1 – Auditoria em Banco de Dados

iStock – Erikona/[Link].

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.

51
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.

52
 Figura 1 – Auditoria por Lista de Verificação (Checklist)

iStock – Porcorex/[Link].

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ório 3 – 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),

53
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 Como a norma Em conformidade
Como Bob fez
Relatório determinou 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

54
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,

55
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.

56
 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

57
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.

58
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 é uma prá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:

59
 Quadro 2 – Linguagens SQL
Tipo de Linguagem Descrição Comandos Associados
DML – Data
INSERT, UPDATE e
Manipulation Manipulação de Dados
DELETE
Language
DDL – Data Definition
Definição de Dados CREATE, ALTER e DROP
Language
DQL – Data Query
Consulta de Dados SELECT
Language
DCL – Data Control
Controle de Dados GRANT e REVOKE
Language
DTL – Data BEGIN TRANSACTION,
Transação de Dados
Transaction Language 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.

60
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.

61
 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.

62
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.

63
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de
dados. 6. ed. Rio de Janeiro: Elsevier, 2012.

64
Bons estudos!

65