Artigos
Identidade e Segurança
Oracle Database 12c Security: "Auditoria no 12c: Unified Auditing" ( Part III )
Por Joel Perez , Aman Sharma
, Karan Dodwal (OCM) & Carlos H. Y. Furushima
Postado em Abril 2015
Revisado por Marcelo Pirovar - Solution Architect
Neste artigo, oferecemos-lhe a continuidade do artigo correspondente na parte III. Recomendamos que leia primeiro a PARTE I & PARTE II do presente. Continuamos..
Demonstração – Auditando o DBA Smith
Neste cenário, faremos uma auditoria sobre o usuário Smith, que é um administrador de banco de dados (DBA). O objetivos é saber se Smith manipula a tabela EMP de Scott. Para tanto, é necessário criar uma política simples, que capture uma possível tentativa de manipulação (update) na tabela EMP por Smith.
SQL> grant dba to Smith identified by smith; Grant succeeded.
SQL> grant select on scott.emp to smith; Grant succeeded.
Criação da política (auditpolicy) utilizando o nome SCOTTEMP_POL1.
SQL> create audit policy scottemp_pol1 actions update on scott.emp; Audit policy created. SQL> audit policy scottemp_pol1 by smith; Audit succeeded.
Para verificar os atributos da política (auditpolicy), consultaremos a view AUDIT_UNIFIED_ENABLED_POLICIES.
SQL> COL user_name FORMAT A8 SQL> COL policy_name FORMAT A18 SQL> SELECT * FROM AUDIT_UNIFIED_ENABLED_POLICIES WHERE POLICY_NAME like '%SCOTT%'; USER_NAM POLICY_NAME ENABLED_ SUC FAI -------- ------------------ -------- --- --- SMITH SCOTTEMP_POL1 BY YES YES
Após confirmado a criação da política/diretiva e habilitada, faremos um update utilizando o usuário Smith.
[oracle@host04 ~]$ sqlplus smith/smith
... << Saída omitida por questão de brevidade >> ...
SQL> update scott.emp set sal=0; 14 rows updated.
SQL> roll; Rollback complete. SQL>
Após isso, consultaremos na view UNIFIED_AUDIT_TRAIL para descobrir detalhes da atividade maliciosa feita pelo DBA Smith nesta tabela.
SQL> col dbusername format A10 SQL> col action_name format A12 SQL> col system_privilege_used FORMAT A30 SQL> col object_name format A10 SQL> SELECT dbusername, action_name, object_name, 2 system_privilege_used, unified_audit_policies 3 FROM unified_audit_trail 4 WHERE UNIFIED_AUDIT_POLICIES like'%SCOTT%' 5 /
DBUSERNAME ACTION_NAME OBJECT_NAM SYSTEM_PRIVILEGE_USED ---------- ------------ ---------- ------------------------------ UNIFIED_AUDIT_POLICIES -------------------------------------------------------------------------------- SMITH UPDATE EMP UPDATE ANY TABLE SCOTTEMP_POL1
- Usuário SMITH, executou um UPDATE na tabela EMP.
Para retirar a politica (auditpolicy) é necessário utilizar a instrução NOAUDIT.
SQL>noaudit policy scottemp_pol1 by smith; Noaudit succeeded.
Para confirmar, basta consultar view UNIFIED_AUDIT_ENABLED_POLICIES.
SQL> SELECT * FROM AUDIT_UNIFIED_ENABLED_POLICIES WHERE POLICY_NAME like '%SCOTT%'; no rows selected
Na demonstração anterior, foi criada uma política para um objeto de um usuário. Existe uma grande abrangência de auditoria, como monitoração de Data Pump, RMAN, etc. Além de outros monitoramento sobre concessão de privilégios. A lista completa dos componentes Oracle que podem ser auditados é encontrada na view SYS.AUDITABLE_SYSTEM_ACTIONS.
SQL> select count(component) from SYS.AUDITABLE_SYSTEM_ACTIONS 2 / COUNT(COMPONENT) ---------------- 250
Na demonstração anterior, criamos uma política/diretiva a nível de objeto (Tabela EMP do SCOTT), todavia, é possível também, criar política/diretiva a nível de sistema e também para roles.
SQL> CREATE AUDIT POLICY audit_sysprivs_role PRIVILEGES select ANY table ROLES manager_role;
Audit policy created.
Habilitando a política/diretiva que foi criada.
SQL> audit policy audit_sysprivs_role; Audit succeeded.
Ao ser habilitado, essa política envolve todos os usuários existente no banco de dados, para confirmar isso, basta consultar a view AUDIT_UNIFIED_ENABLED_POLICIES.
SQL> SELECT POLICY_NAME, ENABLED_OPT, USER_NAME, SUCCESS, FAILURE 2 FROM AUDIT_UNIFIED_ENABLED_POLICIES 3 where POLICY_NAME='AUDIT_SYSPRIVS_ROLE';
POLICY_NAME ENABLED_ USER_NAME SUC FAI ------------------------------ -------- ------------------------------ --- --- AUDIT_SYSPRIVS_ROLE BY ALL USERS YES YES
Vamos tentar acessar a tabela DEPT do usuário SCOTT com a conta de Smith (DBA). É importante ressaltar que Smith não tem privilegio explicito para acessar a tabela DEPT do usuário SCOTT, contudo, ele é DBA e possui privilegio de sistema, onde concede um SELECT ANY TABLE (Executar select em qualquer tabela).
SQL> conn smith/smith Connected.
SQL> select count(*) from scott.dept;
COUNT(*) ---------- 4
Verificaremos a trilha de auditoria.
SQL> SELECT dbusername, action_name, object_name, 2 system_privilege_used, unified_audit_policies 3 FROM unified_audit_trail 4 WHERE UNIFIED_AUDIT_POLICIES='AUDIT_SYSPRIVS_ROLE';
DBUSERNAME ACTION_NAME OBJECT_NAM SYSTEM_PRIVILEGE_USED ---------- ------------ ---------- ------------------------------ UNIFIED_AUDIT_POLICIES -------------------------------------------------------------------------------- SMITH SELECT DEPT SELECT ANY TABLE AUDIT_SYSPRIVS_ROLE
Veja que foi constado que Smith, executou um select no objeto de SCOTT. Para desativar ou excluir esta política/diretiva, é possível utilizarmos NOAUDIT ou DROP.
SQL>noaudit policy AUDIT_SYSPRIVS_ROLE;
Noaudit succeeded.
SQL> drop audit policy AUDIT_SYSPRIVS_ROLE;
Audit Policy dropped.
Gerenciando o UnifiedAuditing
Como descrito anteriormente, a auditoria unificada (UnifiedAudit) é gerenciada por um usuário dedicado chamado AUDSYS, seus objetos são somente leitura (read-only), com isso, nem mesmo o super usuário SYS, é capaz de executar modificações. Para endurecer a segurança, evitando modificação acidental de objetos, nem mesmo o owner, o usuário AUDSYS, é capaz de fazer alterações, ou seja, caso haja qualquer tentativa, um erro ORA-55941 é retornado.
Veja:
SQL> select table_name from dba_tables where owner='AUDSYS';
TABLE_NAME -------------------------------------------------------------------- CLI_SWP$a6cdfd21$1$1
SQL> delete audsys."CLI_SWP$a6cdfd21$1$1"; delete audsys."CLI_SWP$a6cdfd21$1$1" * ERROR at line 1: ORA-55941: DML and DDL operations are not allowed on table"AUDSYS"."CLI_SWP$a6cdfd21$1$1"
Com isso, qualquer expurgo da tabela deve ser feito via pacote DBMS_AUDIT_MGMT.Veja um exemplo de expurgo utilizando o pacote DBMS_AUDIT_MGMT.
SQL> exec DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED);
PL/SQL procedure successfully completed.
É possível automatizar essa atividade, criando um JOB utilizando a procedure CREATE_PURGE_JOB. O procedimento recebe alguns argumentos e deve ser invocado por um usuário quem tenha consigo a role AUDIT_ADMIN, é importante frisar que o beneficiário da role, também pode configurar e gerenciar todos os aspectos da auditoria unificada (UnifiedAuditing). É notável que o role SYSDBA não servirá como role obrigatória para configuração e gerencia da auditoria, ou seja, há uma separação de funções do DBA e do administrador de segurança, que tem a responsabilidade de gerir exclusivamente a auditoria. Além da role AUDIT_ADMIN, existe também a AUDIT_VIEWER, que só permite a visualização dos dados de auditoria.
SQL> grant audit_viewer to auditviewer identified by oracle; Grant succeeded.
SQL> grant connect to auditviewer; Grant succeeded.
SQL> conn auditviewer/oracle Connected. SQL> select count(*) from audit_unified_enabled_policies;
COUNT(*) ---------- 2 SQL> select count(*) from unified_audit_trail;
COUNT(*) ---------- 93
Portanto, não há nenhum problema, um usuário ter o privilégio de visualização de dados de auditoria. Mas o que acontece quando o usuário tenta criar uma política/diretiva de auditoria? Como esperado, ele falha com erro "insuficientes privilégios".
SQL> CREATE AUDIT POLICY audit_sysprivs_role PRIVILEGES select ANY table ROLES manager_role; CREATE AUDIT POLICY audit_sysprivs_role PRIVILEGES select ANY table ROLES manager_role * ERROR at line 1: ORA-01031: insufficient privileges
O novo mecanismo de auditoria, denominada auditoria unificada (UnifiedAuditing) é um grande arsenal para o DBA implementar e endurecer a segurança de seu banco de dados. Além de tornar a configuração e o gerenciamento mais fácil em comparação as versões anteriores.
Esperamos que ele tenha sido útil para seguir com o crescimento do seu conhecimento sobre as tecnologias Oracle.
Nos vemos no próximo artigo. Abraços!
Joel Pérez é um DBA Especialista (Oracle ACE Director, OCM Cloud Admin. & OCM11g ). Com mais de 14 anos de experiência do mundo Oracle Technology, especializado em arquitetura e implementação de soluções como: Cloud, Alta disponibilidade, Disaster/Recovery, Upgrades, replicação e todos as áreas relacionadas com bancos de dados Oracle. Consultor internacional com deveres, conferências e atividades em mais de 50 países e inúmeros clientes em todo o mundo. Palestrante regular nos eventos Oracle em todo o mundo como: OTN LAD, OTN MENA, OTN APAC e muito mais. Joel sempre foi conhecido por ser pioneiro em tecnologia Oracle desde os primeiros dias de sua carreira sendo o primeiro latino-americano premiado como "OTN Expert" no ano de 2003 pela Oracle Corporation, um dos primeiros "ACE Oracle" no Oracle ACE Program no ano de 2004, um dos primeiros OCP Database Cloud Administrator em todo o mundo no ano de 2013 e como um das maiores realizações profissionais em sua carreira, recentemente ele foi homenageado como o primeiro "OCM Database Cloud Administrator" do mundo.
Aman Sharma é um especialista em banco de dados Oracle, um Oracle Certified Professional (9i, 10g, 11g), um Oracle Certified Expert para Linux e SQL e Sun Certified System Admin com mais de 6 anos de experiência. Aman trabalha como instrutor de formação de profissionais ao redor da Ásia-Pacífico em tecnologias da Oracle relacionadas. Antes disso, ele trabalhou como DBA para uma empresa de desenvolvimento de software de grande porte. Em seu tempo livre, quando Aman não está ensinando ou viajando, ele gosta de passar o tempo em vários fóruns da Oracle através da web.
Karan Dodwal (OCM) é um Oracle arquiteto com especialização em Oracle High Availability. Ele é um DBA Oracle Certified Master (OCM) com vários anos de experiência em banco de dados Oracle e no desenvolvimento Oracle. Ele trabalha como consultor Oracle e já realizou diversos serviços e treinamentos sobre os produtos da Oracle na Ásia Pacífico, Ásia do Sul e na Grande China. Ele é um speaker do All India Oracle Users Group (North India Chapter) e apresenta sessões no Oracle Technology. Ele tem várias configuração feitas do Oracle High Availability em todas as plataformas para missões críticas do Oracle Database. Ele é um expert em todas as soluções de High Availability da Oracle como RAC, Exadata, Data Guard e outros. Ele freqüentemente publica artigos em diversos sites e no seu bloghttp://karandba.blogspot.in e participa ativamente de eventos do grupo de usuários Oracle AIOUG AllIndia Oracle UsersGroup (North IndiaChapter) e ajuda diversos usuário no OTN Fórum da Oracle.
Carlos H. Y. Furushima é um especialista em banco de dados relacional, trabalhando como consultor de TI, atuando principalmente como o Oracle Database Administrator (DBA Oracle). Tem uma vasta experiência e conhecimento em "Performance, diagnosticand tuning", "High Availability", "Backup & Recovery" e "Exadata". Ele também está entusiasmado com sistema operacional Linux/Unix, onde contribui com o desenvolvimento do código do kernel Linux em parceria com a comunidade "GNU Linux", com criação e revisão de novas funcionalidades, melhorias e correções de bugs. Recentemente, Furushima divide seu tempo com consultoria especializada em banco de dados Oracle e estudos sobre "Oracle Internals", com o objetivo de descobrir e entender os benefícios do bancos de dados Oracle em plataforma Linux/Unix.
Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.
Printer ViewEntre em Contato Conosco
- Vendas: 0800-891-4433
- Contatos Globais
- Diretório de Suporte