Aula 5 - Segurança e Aditoria no Oracle

Prévia do material em texto

/
Administração de Banco de Dados III
Aula 5: Segurança e Auditoria no Oracle
Apresentação
Esta quinta aula da disciplina Administração de Bancos de Dados III trata da administração dos usuários que acessam os
bancos de dados Oracle, incluindo as melhores práticas para concessão de acessos e gerenciamento dos per�s de acesso
associados aos principais recursos do banco de dados.
Ao �nal desta aula você será capaz de utilizar as ferramentas do Oracle para con�guração do acesso dos usuários, criar
mecanismos seguros para esse acesso, utilizar as ferramentas de auditoria do Oracle e responder aos questionamentos
mais frequentes realizados por auditorias em bancos de dados Oracle.
Objetivo
Discutir aspectos de concessão de privilégios e construção de per�s para garantir segurança no acesso aos bancos
de dados Oracle;
Aplicar ferramentas e técnicas para implementação de acesso seguro aos dados e objetos dos bancos de dados no
Oracle;
Aplicar as ferramentas de auditoria do Oracle e responder a questionamentos de auditorias sobre acesso aos bancos
de dados Oracle.
Introdução
Os requisitos de segurança em bancos de dados Oracle não são diferentes dos requisitos para qualquer Sistema Gerenciador
de Banco de Dados (SGBD).
É preciso garantir a proteção aos dados armazenados, seja em relação ao acesso
a esses dados ou em relação à perda dos dados.
/
 Fonte: madartzgraphics / Pixabay.
Quanto ao acesso aos dados, o Oracle oferece ferramentas para que o administrador implemente políticas de acesso. Usuários
criados no banco de dados podem ser associados a pro�les e a roles. A partir de pro�les é possível de�nir regras e limites para
usuários. Por meio de roles é possível construir uma cadeia de privilégios de acesso concedidos em objetos do banco de
dados. Vamos trabalhar com esses dois conceitos para tratar a questão do acesso dos usuários aos dados, um dos pilares da
segurança dos bancos de dados.
Com relação à perda dos dados, vimos parte da solução na aula anterior. A partir de uma política de backup e do uso do RMAN,
construímos uma alternativa para restauração dos bancos de dados. Naturalmente, essa alternativa precisa estar
adequadamente monitorada e, com testes automatizados, é possível mitigar o risco associado às falhas no ambiente
computacional e à consequente perda de dados. Nesta aula vamos conhecer outro utilitário de cópia de dados importante para
o administrador, o Data Pump.
Pro�les
Os per�s de acesso no Oracle são conjuntos de regras e limites que podem
ser associados a usuários para determinar comportamentos de segurança.
Exemplo
Por exemplo, podemos criar um pro�le e de�nir que o tempo de vida (life time) de uma password é 90 dias. Após esse tempo, a
senha deve ser alterada e ela somente poderá ser reutilizada após três mudanças de senha (reuse max) e somente após 30 dias
(reuse time).
Adicionalmente, caso o usuário erre a senha em cinco tentativas consecutivas (failed_login_attempts), a conta é bloqueada. Ao
associar usuários a esse per�l, todos eles seguirão a mesma regra (deverão trocar a senha de 90 em 90 dias, no máximo) e
terão os mesmos limites (não reutilizar uma senha usada nas últimas três mudanças e dentro do período de 30 dias). Veja a
/
seguir a criação desse per�l, chamado de prf_troca_senha_padrao.
 
CREATE PROFILE prf_troca_senha_padrao
LIMIT failed_login_attempts 5
password_life_time 90
password_reuse_max 3
password_reuse_time 30;
Administradores também podem de�nir limites de uso para recursos como o número máximo de sessões por usuário, o tempo
de conexão de uma sessão e o tempo idle (sem atividade) de uma sessão. Veja o exemplo diante.
 
CREATE PROFILE prf_sessao_usuario_padrao
LIMIT sessions_per_user UNLIMITED
connect_time 45
idle_time 5;
No exemplo anterior estamos de�nindo um per�l denominado prf_sessao_usuario_padrao pelo qual não há limite para o
número de sessões por usuário, isto é, um usuário pode iniciar quantas sessões quiser, entretanto cada sessão não pode
ultrapassar o tempo total de 45 minutos e não pode �car sem atividade por mais de cinco minutos. Caso uma das condições
ocorra, a sessão é automaticamente desconectada pelo PMON.
Para veri�car as con�gurações de um determinado per�l, podemos utilizar a visão dba_pro�les. Veja a seguir uma consulta aos
parâmetros de senha con�gurados para o pro�le prf_troca_senha_padrao.
 
SELECT * FROM dba_profiles
WHERE profile = 'prf_troca_senha_padrao'
AND resource_name like 'password%';
A Oracle fornece um pro�le denominado default, con�gurado com os valores padrão, conforme a seguir:
 
SELECT * FROM dba_profiles
WHERE profile = 'default';
Comentário
/
A Note que a maioria dos valores é con�gurada como unlimited, o que pode não ser o ideal para você. Normalmente, o time de
Segurança fornece essas de�nições e você provê o melhor arranjo para implementá-las.
É frequente encontrar pro�les diversos, construídos para grupos de usuários que possuem requisitos comuns, sendo o per�l
default con�gurado para aqueles que não pertencem a um grupo especí�co e podem trabalhar com a con�guração padrão.
Nesse caso, você deve alterar os parâmetros necessários na con�guração default como no exemplo adiante:
 
ALTER PROFILE default LIMIT failed_login_attempts 3;
Para o tipo de con�guração que impõe limites de uso de recursos, como CPU e memória, a Oracle vem recomendando mais
recentemente o uso do Resource Manager, em substituição ao uso de pro�les. Vamos ver como ele funciona na próxima aula,
sobre Monitoração e Gerenciamento de Processos.
Roles
O conceito de roles em banco de dados relacionais foi criado pela Oracle e foi adotado como padrão pela SQL, razão pela qual
está atualmente implementado em outros SGBDs. Elas são utilizadas para compor um conjunto de concessões de acesso,
frequentemente necessárias a um grupo de usuários. Os grants são efetivados para a role e a role é concedida a cada usuário
do grupo. Vamos ver como funciona.
 
CREATE ROLE CRM_Leitura;
GRANT SELECT ON Usuarios TO CRM_Leitura;
GRANT SELECT ON Usuarios_Historico TO CRM_Leitura;
No exemplo anterior estamos criando a role CRM_Leitura e concedendo o acesso de leitura nas tabelas Usuarios e
Usuarios_Historico à função. Para criar uma role equivalente para acesso de escrita podemos utilizar a construção adiante.
 
CREATE ROLE CRM_Escrita;
GRANT INSERT, UPDATE, DELETE ON Usuarios TO CRM_Escrita;
GRANT INSERT, UPDATE, DELETE ON Usuarios_Historico TO CRM_Escrita;
É uma estratégia clássica criar funções de leitura e escrita para acesso às tabelas de um mesmo esquema ou de um mesmo
sistema. A imagem a seguir representa bem essa estratégia.
/
 Fonte: Oracle (2020).
Figura 1 - Usuários e roles
Nesse cenário, existe o gerente (manager), os funcionários que realizam pagamentos (pay clerk) e os funcionários que realizam
recebimentos (rec clerk). Eles são agrupados em suas respectivas roles, chamadas de user roles. Já os privilégios de execução
das aplicações de Pagamentos e Recebimentos são governados pelas application roles; os grants de acesso aos dados e de
execução de procedimentos estão con�gurados nessas roles.
A associação das user roles com as application roles é que vai determinar quem pode fazer o quê. No exemplo, o grupo de
usuários pay_clerk possui somente os privilégios concedidos à função accts_pay, assim como o grupo de usuários rec_clerk
possui somente os privilégios concedidos à função accts_rec. Já o grupo de usuários manager possui tanto os privilégios
concedidos à role accts_pay quanto os privilégios concedidos à role accts_rec.
Saiba mais
Existem roles que são prede�nidas em bancos de dados Oracle, como CONNECT e RESOURCE. CONNECT, por exemplo, inclui
uma série de privilégios para criação de clusters, database links e sessões. Veja no endereço
https://docs.oracle.com/cd/B12037_01/network.101/b10773/admusers.htm uma descrição completa dessas roles.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Criação de usuários e esquemas
Agora que temos pro�les eroles, podemos criar os usuários e associá-los ao per�l e às funções adequadas às suas
necessidades. Conforme comentamos na aula anterior, existe uma relação de 1:1 entre usuário e esquema. Quando você cria
um usuário, um esquema com o mesmo nome é automaticamente criado pelo Oracle.
 
CREATE USER U001 IDENTIFIED BY passw0rd;
GRANT CREATE SESSION TO U001;
javascript:void(0);
/
Com esses comandos criamos o usuário U001 e concedemos a ele o
direito de fazer login na instância. Ao criar o usuário, o esquema U001
também é criado e todos os objetos criados pelo usuário, quando
criados sem uma de�nição explícita do esquema, serão associados ao
esquema de mesmo nome.
Vamos ao próximo exemplo:
 
CREATE USER U001 IDENTIFIED BY passw0rd
DEFAULT TABLESPACE tsp_u001
PROFILE prf_troca_senha_padrao;
O usuário U001 é associado a um pro�le e a um tablespace padrão, em que serão persistidos os objetos que forem criados sem
a de�nição explícita de um tablespace.
Associação de usuários
Uma vez que o usuário está criado você pode associá-lo às roles. Para isso, você concede a role ao usuário. Veja a construção
a seguir.
 
GRANT CRM_Leitura TO U001;
O que ocorre de fato é que os privilégios concedidos à role CRM_Leitura são concedidos ao usuário U001. É possível conceder
roles a outras roles, criando assim uma cadeia de concessões que vai ao encontro das estratégias clássicas de concessão de
acesso. É possível conceder ao usuário U001 a opção de grant (objetos) ou admin (roles), a partir das quais ele mesmo pode
conceder a permissão para outros usuários.
 
GRANT CRM_Leitura TO U001 WITH ADMIN OPTION;
Voltando ao cenário apresentado com as funções manager, pay_clerk e rec_clerk, podemos fazer:
/
 
GRANT ACCTS_PAY TO pay_clerk;
GRANT ACCTS_PAY TO manager;
GRANT ACCTS_REC TO manager;
GRANT ACCTS_REC TO rec_clerk;
Esse conjunto de grants implementa a estratégia apresentada na imagem, baseada na concessão de privilégios para as roles
de aplicação (ACCTS_PAY e ACCTS_REC) e a concessão dessas roles às roles dos usuários.
Usuários e roles em ambiente Multitenancy
Quando estamos trabalhando na versão 12c ou posterior, devemos atentar para o container no qual estamos trabalhando, que
pode ser o próprio container root ou um dos pluggable databases. A criação dos usuários e das roles pode ser realizada em um
container especí�co ou para todos os containers da instância. Veja os exemplos adiante.
 
ALTER SESSION SET CONTAINER = CDB$ROOT;
CREATE USER C##U002 IDENTIFIED BY passw0rd CONTAINER=ALL;
No exemplo, estamos criando um usuário common, ou seja, existente no root e em todos os pluggable databases. Observe que
você deve estar conectado ao container root para especi�car CONTAINER = ALL e nomear o usuário com o pre�xo padrão C##.
No exemplo a seguir estamos conectados ao pluggable database e especi�camos CONTAINER = CURRENT, para que o usuário
U003 seja criado somente no PDB. Esse é um usuário local.
 
ALTER SESSION SET CONTAINER = XEPDB1;
CREATE USER U003 IDENTIFIED BY passw0rd CONTAINER=CURRENT;
As roles também podem ser common ou local. Conectado ao root, você pode criar uma role common e associá-la a usuários
common ou local. No exemplo a seguir estamos concedendo a role C##SALES_LEITURA, criada no root, ao usuário common
C##U002 e, conectado ao PDB XEPPDB1, concedendo a mesma role ao usuário local U003.
 
ALTER SESSION SET CONTAINER = CDB$ROOT;
CREATE ROLE C##SALES_Leitura;
GRANT C##SALES_Leitura TO C##U002 CONTAINER=ALL;
ALTER SESSION SET CONTAINER = XEPDB1;
GRANT C##SALES_Leitura TO U003;
/
Quando a role é criada no PDB, então ela é local e só pode ser associada a usuários locais. Veja o exemplo a seguir.
 
ALTER SESSION SET CONTAINER = XEPDB1;
CREATE ROLE CRM_Leitura;
GRANT CRM_Leitura TO U003;
É importante para o administrador contar com as alternativas de escopo de roles e usuários. Não são raras as necessidades de
acesso de usuários a vários bancos de dados (PDBs). Nesse caso, uma alternativa é criá-lo como um common user e conceder
os acessos por roles locais.
A Figura 2 ilustra essa distribuição de usuários common e usuários locais aos PDBs.
 Fonte: Oracle (2020).
Figura 2 - Usuários common e local
Agora, execute a atividade a seguir:
Atividade
Na aula anterior nós criamos objetos no tablespace CRM, mas ainda sem os usuários e as roles. Nesta atividade, vamos
recriar os objetos sob o esquema CRM. Para isso, execute as seguintes tarefas.
Remova todos os objetos criados;
Crie um pro�le de�nindo tempo de vida de senha em seis meses e somente três tentativas para bloqueio de senha;
Crie o usuário CRM associado ao tablespace CRM;
/
Conceda a permissão de abertura de sessão para esse usuário;
Faça login com esse usuário;
Crie as tabelas e a visão;
Veri�que que os objetos foram criados no esquema CRM e no tablespace CRM;
Crie as roles CRM_Leitura e CRM_Escrita e conceda os acessos de leitura dos objetos para a role CRM_Leitura e os
acessos de escrita nas tabelas para a role CRM_Escrita;
Conceda esses acessos ao usuário U001;
Faça um backup do tablespace CRM com RMAN.
Gestão de usuários e roles
O trabalho do administrador Oracle no escopo da segurança dos bancos de dados vai além do estabelecimento da estratégia
de acesso, da criação dos pro�les e das roles e da sua associação aos usuários. É preciso monitorar as necessidades dos
usuários e gerir grupos e privilégios.
Uma das tarefas frequentes nessa gestão das roles é a construção automática dos grants para um determinado esquema. Veja
a seguir como gerar os grants de leitura para todos os objetos do esquema CRM.
 
SELECT 'GRANT SELECT on CRM. ' || object_name || ' to CRM_Leitura;'
FROM dba_objects
WHERE owner = 'CRM' AND object_type in ('TABLE', 'VIEW')
ORDER BY object_type, object_name;
Note que o SELECT passeia pela tabela dba_objects e retorna todos os objetos do tipo table ou view do esquema CRM. Para
cada um desses objetos constrói a string correspondente ao grant. O resultado é uma lista com os comandos de concessão,
um para cada objeto.
Na construção a seguir temos os GRANTs para a role CRM_Escrita.
 
SELECT 'GRANT INSERT, UPDATE, DELETE on CRM. ' || object_name || ' to CRM_Escrita;'
FROM dba_objects
WHERE owner = 'CRM' AND object_type in ('TABLE', 'VIEW')
ORDER BY object_type, object_name;
Outra tarefa importante para o administrador é checar quais são as roles existentes e quais as concessões realizadas para
essas roles. Para checar as funções existentes você pode fazer uma consulta na visão dba_roles, conforme abaixo.
/
 
SELECT * FROM dba_roles WHERE role LIKE 'CRM_%';
Para conferir quais os privilégios concedidos a determinadas roles, podemos utilizar a construção abaixo:
 
SELECT role, privilege, count(*)
FROM role_tab_privs
WHERE role IN 'CRM_Leitura, CRM_Escrita'
GROUP BY role, privilege
ORDER BY role, privilege ASC
Comentário
Os privilégios associados às funções no Oracle estão disponíveis em três visões. Além da que utilizamos anteriormente, que
mostra os privilégios concedidos diretamente, temos também os privilégios por concessão de roles a roles e os privilégios de
sistema.
 
SELECT * FROM role_role_privs WHERE role IN role_names;
SELECT * FROM role_sys_privs WHERE role IN role_names;
No escopo da gestão dos usuários frequentemente precisamos checar os privilégios de um determinado usuário. Para essa
tarefa, vamos usar as três visões correspondentes às concessões por roles, diretamente em objetos e concessões de sistema,
com grantee sendo o usuário que recebe as concessões.
 
SELECT * FROM dba_role_privs WHERE grantee = 'U001';
SELECT * FROM dba_tab_privs WHERE grantee = 'U001’';
SELECT * FROM dba_sys_privs WHERE grantee = 'U001';
Você pode ver diretamente as concessões das roles que são concedidas a um determinado usuário. Veja adiante como fazer
isso.
/
 
SELECT * FROM dba_tab_privs
WHERE grantee IN (SELECT granted_role
FROM dba_role_privs
WHERE grantee = 'U001');
A construção recupera granted_role de dba_role_privs,que é a role concedida ao usuário U001 e, para cada uma dessas roles,
recupera as concessões correspondentes da role na dba_tab_privs.
Exportação e importação de esquemas
Uma ferramenta muito utilizada no dia a dia do administrador Oracle é o Data Pump. Por intermédio dela é possível exportar e
importar diretamente os esquemas dos bancos de dados, sendo uma alternativa para backups e restaurações eventuais. Trata-
se também da recomendação da Oracle para migração de esquemas entre bancos de dados on-premises e entre um banco de
dados on-premises e outro na nuvem. Veja o diagrama a seguir.
 Fonte: Oracle (2020).
Figura 3 - Uso do Data Pump
Comentário
No diagrama você pode observar a infraestrutura on-premises e na nuvem da Oracle. A interconexão entre os datacenters é
realizada por meio de um gateway DRG (Dynamic Routing Gateway) e, em cada um deles, você pode visualizar os bancos de
dados, um Oracle Database Enterprise Edition na infraestrutura on-premises e um Autonomous Transaction Processing (ATP) na
nuvem.
Como migrar os dados do banco de dados on-premises para o banco de dados
/
ATP?
Data Pump oferece grande �exibilidade para os DBAs, sendo a exportação de esquemas realizada por meio do expdp (Data
pump Export) e a importação a partir do impdp (Data pump Import). Em uma das alternativas mostradas no diagrama, o expdp
é utilizado na infraestrutura on-premises, o arquivo gerado pelo expdp é armazenado no Object Storage da nuvem e, na
sequência, importado para o banco ATP por meio do impdp. Vamos começar pela exportação.
 
expdp schemas=CRM directory=data_pump_dir dumpfile=CRM.dmp
No exemplo anterior estamos exportando todo o esquema CRM para o arquivo CRM.dmp, localizado na pasta correspondente
ao diretório data_pump_dir. Os diretórios do Oracle são de�nidos na tabela dba_directiories. Para importar este dump, basta
conectar-se ao banco de dados destino, seja on-premises ou na nuvem e executar o impdp, conforme a seguir.
 
impdp directory=data_pump_dir dumpfile=CRM.dmp
O esquema é importado para o banco de dados corrente, incluindo o usuário, sua senha, os tablespaces associados ao
esquema. Como �zemos uma exportação completa, metadados e dados são importados. Quando fazemos a exportação
podemos restringir o que de fato será exportado pelo expdp.
No exemplo adiante estamos exportando somente os metadados do esquema, além de incluir um arquivo de log que será
gerado durante a geração do dump.
 
expdp schemas=CRM directory=data_pump_dir dumpfile=CRM.dmp
logfile=CRM.log content=metadata_only
Na importação do esquema, você pode mapeá-lo de novo para outro esquema, inclusive renomeando os tablespaces
associados ao esquema. Veja no exemplo adiante.
 
impdp directory=data_pump_dir dumpfile=CRM.dmp
remap_schema=CRM:CRM_novo
remap_tablespace=TS_CRM:TS_CRM_novo
Dica
/
Data Pump é uma ferramenta completa para exportação e importação de metadados e dados, e possui uma série de opções de
controle. Vale estudar sua documentação e dominar as técnicas, pois elas certamente farão parte do seu dia a dia como
administrador Oracle.
Acesse https://docs.oracle.com/cd/B19306_01/server.102/b14215/dp_overview.htm para ver uma documentação completa do
Data Pump.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Auditoria
Nesta última parte da aula vamos falar sobre auditoria. É muito comum que você, como um DBA Oracle, receba
questionamentos acerca dos usuários que têm permissão de acesso aos bancos de dados e que tipo de privilégios eles
possuem. A despeito das solicitações, que são frequentes, auditar é uma boa prática de administração de bancos de dados.
As principais auditorias solicitam informações sobre os usuários que estão
habilitados a acessar o banco de dados. Essas informações são encontradas
na dba_users. Há também a tabela dba_users_with_defpwd que contém os
usuários que ainda estão usando sua password default. Essa tabela deve
estar sempre vazia.
 
SELECT * FROM dba_users;
SELECT * FROM dba_users_with_defpwd;
Solicitam também as informações sobre os privilégios dos usuários, dos objetos do banco de dados e dos per�s de usuários.
javascript:void(0);
/
1
Privilégio dos usuários
Para os pro�les, as auditorias checam, por exemplo, se
todos os usuários estão alterando regularmente suas
senhas. Isso pode ser feito pela dba_pro�les. Todos os
usuários devem estar associados a um pro�le que contenha
as de�nições esperadas.
2
Objetos do banco de dados
Para os objetos do banco é importante veri�car suas
últimas datas de alteração na dba_objects e confrontá-las
com os processos internos de passagem para produção.
3
Per�s do usuário
Para os privilégios dos usuários é fundamental que os
acessos concedidos estejam devidamente autorizados.
A checagem é realizada pela consulta às visões %_privs, conforme a seguir.
 
SELECT * FROM dba_tab_privs;
SELECT * FROM dba_role_privs;
SELECT * FROM dba_sys_privs;
Além das visões disponíveis o Oracle também fornece ferramentas de auditoria. Entre elas, podemos destacar Database
Auditing e Uni�ed Auditing.
Database Auditing
Com Database Auditing, implementado pelo comando AUDIT, é possível auditar as operações realizadas sobre um esquema,
sejam elas DDL ou DML, e gerar registros de auditoria. Esses registros podem �car armazenados no banco de dados, tabela
SYS.AUD$, ou em arquivos do sistema operacional. Há também a visão dba_common_audit_trail que recupera os registros
gerados pelo AUDIT.
Para habilitar Database Auditing em seu banco de dados Oracle, você deve con�gurar o parâmetro de inicialização
AUDIT_TRAIL no SPFILE (ou PFILE).
Registros no banco de dados
Se quiser gerar os registros de auditoria no
próprio banco de dados (tabela SYS.AUD$)
esse parâmetro deve ser con�gurado com
“DB”. 
Registros no sistema
operacional
Se quiser gerar os registros em arquivos no
sistema operacional esse parâmetro deve
ser con�gurado com “OS” e o parâmetro
AUDIT_FILE_DEST deve ser con�gurado
com o caminho do arquivo de auditoria.
/
Saiba mais
Existem outras opções de con�guração. Veja no link
https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm.
Com a auditoria con�gurada podemos usar os comandos AUDIT e NOAUDIT para iniciar a geração dos registros de auditoria. É
preciso ter cautela no uso desses comandos porque, como eles atuam diretamente no banco de dados, há algum impacto em
seu desempenho. Portanto, deve-se auditar somente aquilo que é realmente necessário. Veja o exemplo a seguir.
 
AUDIT SELECT TABLE BY U001;
O comando anterior habilita a auditoria para quaisquer comandos SELECT em tabelas disparados pelo usuário U001. A
depender do volume de SELECTs realizados pelo usuário, um grande número de registros de auditoria pode ser gerado. Um
critério mais restritivo é desejável, como especi�car as tabelas para as quais deseja-se a auditoria.
 
AUDIT SELECT ON CRM.Usuarios BY U001;
Para gerar a auditoria para todos os usuários, nessa mesma tabela, podemos fazer:
 
AUDIT SELECT ON CRM.Usuarios BY ACCESS;
No exemplo seguinte, todas as deleções de tabela são auditadas, independente do usuário.
 
AUDIT DELETE ON CRM.Usuarios BY ACCESS;
Para auditar somente as deleções que não executam com sucesso, podemos fazer:
 
AUDIT DELETE ON CRM.Usuarios BY ACCESS WHENEVER NOT SUCCESSFUL;
javascript:void(0);
/
Uni�ed Auditing
A partir da versão 12c, a Oracle implantou uma nova arquitetura para auditoria, chamada Uni�ed Auditing. Nela, há áreas
especí�cas de memória para geração das trilhas de auditoria, o que melhorou sensivelmente o desempenho da geração das
trilhas, quando comparada ao AUDIT. Portanto, nas versões mais recentes, recomenda-se o uso de Uni�ed Auditing.
 Fonte: Oracle (2020).
Figura 4 - Uni�ed Auditing
Observe que, conforme os comandos SQL vão sendo executados no banco de dados (1), os registros de auditoria são gerados
em memória, em uma área especi�ca na SGA (2). Esses registros aguardam em uma �la, até que um processo que roda em
background (3) despejaos registros dessa �la em uma tabela do banco de dados, a AUDSYS. Para visualizar os registros dessa
tabela utilizamos a visão uni�ed_audit_trail (4). O despejo também pode ser realizado manualmente por meio da procedure
�ush_uni�ed_audit_trail.
Conclusão
Nesta aula vimos como combinar as técnicas existentes no Oracle para garantir acesso seguro aos dados.
Para o administrador do banco de dados, utilizar essas técnicas e construir
um arcabouço de segurança é imprescindível, na medida em que ele deve
evitar exposição ao risco operacional provocado por acessos indevidos e
roubo ou perda de dados.
/
Por que o Oracle faz essa diferença entre um small�le e um big�le?
1
Através do uso de pro�les e roles, e da sua associação a usuários, começamos a construir a base da segurança no
acesso aos dados. Durante a aula veri�camos como podem ser implementadas as funções, em uma abordagem
clássica de distribuição de privilégios e agrupamento de usuários segundo suas necessidades de acesso. Em seguida,
veri�camos as diferenças existentes nessas implementações quando estamos trabalhando em um ambiente
multitenancy.
2
A exportação e a importação de esquemas a partir do Data Pump, utilitário recomendado pela Oracle para transporte de
esquemas entre bancos de dados, também foi objeto do estudo, na medida em que backups eventuais de tablespaces
também fazem parte das ferramentas de segurança do DBA.
3
Na última parte da aula vimos como utilizar os recursos do banco de dados Oracle para auditoria. As visões disponíveis
nos permitem veri�car usuários, pro�les, roles e privilégios, itens sempre constantes quanto a questionamentos sobre
acesso e uso dos bancos de dados. Vimos também que o próprio Oracle oferece ferramentas de auditoria, como o
Database Auditing e o Uni�ed Auditing.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Atividade
1. Discutir aspectos de concessão de privilégios e construção de per�s para garantir segurança no acesso aos bancos de dados
Oracle;
É fundamental construir uma estratégia de concessão de acesso aos dados armazenados no Oracle. Os blocos de construção
disponíveis incluem _______, por onde de�nimos limites para o comportamento da atividade dos usuários, _______ e _______, que
mantêm uma relação 1:1 nos bancos de dados, e _______, por onde realizamos as concessões de acesso aos objetos do banco de
dados.
a) profiles, roles, users, schemas.
b) roles, profiles, grants, schemas.
c) profiles, schemas, grants, roles.
d) roles, users, schemas, grants.
e) profiles, schemas, users, roles.
2. Aplicar ferramentas e técnicas para implementação de acesso seguro aos dados e objetos dos bancos de dados no Oracle.
Assinale a seguir a construção incorreta na manutenção de roles e usuários no Oracle.
a) ALTER SESSION SET CONTAINER=CRM_PDB; CREATE ROLE CRM_Leitura.
b) CREATE USER CRM_user IDENTIFIED BY passw0rd CONTAINER=CURRENT.
c) GRANT CRM_Leitura TO CRM_user.
d) DELETE FROM dba_roles WHERE role=’CRM_Leitura’.
e) SELECT * FROM dba_roles WHERE role=’CRM_Leitura’.
/
3. Aplicar as ferramentas de auditoria do Oracle e responder questionamentos de auditorias sobre acesso aos dados Oracle.
Assinale a alternativa que não representa uma solicitação frequente de auditoria no Oracle.
a) Parâmetros de configuração de senha, como número de tentativas para bloqueio de senha e tempo de vida por meio da dba_profiles.
b) Lista de usuários com acesso de escrita em um determinado esquema do banco de dados através das visões dba_%_privs.
c) Lista de usuários com privilégio de administrador no banco de dados da dba_objects.
d) Lista de usuários que devem trocar a senha padrão fornecida por meio da dba_users_with_defpwd.
e) Cadeia de concessão de acessos e privilégios por meio de funções por meio da dba_roles.
Notas
Referências
AUDIT. Oracle Help Center. Disponível em: https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4007.htm.
Acesso em: 18 set. 2020.
AUTHORIZATION: Privileges, Roles, Pro�les, and Resource Limitations. Oracle® Database Security Guide. Disponível em:
https://docs.oracle.com/cd/B12037_01/network.101/b10773/authoriz.htm. Acesso em: 18 set. 2020.
CREATE pro�le. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_6010.htm. Acesso em: 15 set. 2020.
CREATE role. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_6012.htm. Acesso em: 20 set. 2020.
CREATE user. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_8003.htm. Acesso em: 18 set. 2020.
KUMAR, R.; KUPATADZE, M.; MUFALANI, R. Benefícios e Implementação do Oracle Virtual Private Database (VPD). Recursos
Técnicos da Oracle. Disponível em: https://www.oracle.com/br/technical-resources/articles/database-performance/uni�ed-
auditing-database-12c.html. Acesso em: 20 set. 2020.
RAMAKHRISHNAN, R.; GEHRKE, J. Database Management Systems. 3rd. edition. New York: McGraw-Hill, 2002. 1098 p.
PUGA, S.; FRANÇA, E.; GOYA, M., 2013. Banco de Dados: implementação em SQL, PL/SQL e Oracle 11g. São Paulo: Pearson.
332 p.
SECURITY Requirements, Threats, and Concepts. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B19306_01/network.102/b14266/reqthret.htm. Acesso em: 15 set. 2020.
Próxima aula
Monitoração de processos;
Identi�cação das sessões dos usuários;
Ajuste de con�gurações.
Explore mais
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
/
As ferramentas de segurança e auditoria do Oracle são bastante completas em termos de recursos e funcionalidades para o
administrador de banco de dados. O Enterprise Manager, por sua vez, oferece uma visão integrada dos bancos de dados,
inclusive no que diz respeito à segurança e auditoria.
Conheça mais sobre o uso do Enterprise Manager para o estabelecimento das melhores práticas de segurança em bancos de
dados Oracle e na infraestrutura que suporta o SGBD. O paper Enterprise Manager Cloud Control 12c Infrastructure and
Operational Security Best Practices, discorre sobre os aspectos abordados nesta aula e traz outras recomendações para
implementação de melhores práticas de segurança e auditoria de bancos de dados Oracle. Explore o paper, implementando as
recomendações com o Enterprise Manager Cloud Control.
javascript:void(0);