O parâmetro de inicialização AUDIT_SYSLOG_LEVEL - Oracle Database 10g
O parâmetro de inicialização AUDIT_SYSLOG_LEVEL é parcialmente documentado. Várias imprecisões na documentação sugerem que o parâmetro é menos útil do que realmente é. Ações de banco de dados pelo SYS e/ou administradores de banco de dados ou os operadores podem ser auditados para registrar nos arquivos de log (pelo deamon do syslog) do sistema operacional UNIX pertencentes ao root. Isso impede que usuários de banco de dados privilegiados removam os registros de auditoria que contêm um registo das suas atividades. A configuração padrão é a auditoria CONNECT, STARTUP e SHUTDOWN com privilégios SYSDBA ou SYSOPER com escrita nos arquivos pertencentes ao proprietário do software Oracle, embora não havendo auditoria do SQL, PL/SQL e outras ações com esses privilégios ou outros privilégios, tais como a role DBA. Em outras palavras, com exceção das operações descritas acima, a auditoria padrão (veja o parâmetro AUDIT_TRAIL), assim como auditoria fina (veja o pacote DBMS_FGA), estão desligadas por padrão. Como conseqüência, não haverá nenhum vestígio de muitas atividades realizadas por usuários privilegiados. Auditoria de arquivos do sistema operacional pertencente ao proprietário do software Oracle (AUDIT_TRAIL = OS) ou para a tabela de banco de dados SYS.AUD$ (AUDIT_TRAIL = DB) pode ser contornada, uma vez que os DBAs têm normalmente acesso à conta do proprietário do software Oracle UNIX, bem como a SYS.AUD$, o que lhes permite facilmente remover registros de auditoria gerados por suas ações. Auditoria pelo syslog UNIX também é útil para a detecção de invasões por hackers.
- Syslog
Um novo recurso do Oracle 10g é a capacidade de gravar trilhas de auditoria usando o syslog em sistemas UNIX. Este mecanismo consiste em um processo daemon chamado syslogd (veja "man syslogd") que aceita mensagens de registro dos pedidos através da função syslog na biblioteca C (veja "man syslog"). O arquivo de configuração para o syslogd é normalmente /etc/syslog.conf e as mensagens de log vão para arquivos em /var/log e /var/adm dependendo da variante do UNIX. O nome do arquivo de log é determinada por uma seqüência que consiste em um nome de unidade e uma prioridade ou nível. A maioria destes pode ser utilizado na definição do AUDIT_SYSLOG_LEVEL. Cada entrada no /etc/syslog.conf atribui um nome de arquivo de log para uma determinada combinação de facilidade e prioridade. Ao colocar a entrada "user.notice /var/log/oracle_dbms" no arquivo syslog.conf e fazendo com que o syslogd releia o arquivo de configuração enviando um sinal de hang-up com o comando kill, qualquer entrada posterior no log de uma instância ORACLE com o parâmetro configurado AUDIT_SYSLOG_LEVEL = user.notice será gravado no arquivo /var/log/oracle_dbms.
No Windows, quando o parâmetro AUDIT_SYS_OPERATIONS é definido para TRUE, operações com SYSDBA ou SYSOPER são escritas também para o Event Log.
O manual "Oracle Database Reference 10g Release 2" fala sobre o AUDIT_SYSLOG_LEVEL assim:
AUDIT_SYSLOG_LEVEL permite que os logs de auditoria SO sejam escritos para o sistema via utilitário syslog, isso se o parâmetro AUDIT_TRAIL for definido para "OS". O valor da facilidade pode ser qualquer dos seguintes: USER, LOCAL0, LOCAL7, SYSLOG, DAEMON, KERN, MAIL, AUTH, LPR, NEWS, UUCP ou CRON. O Valor do nível pode ser quaisquer dos seguintes: NOTICE, INFO, DEBUG, WARNING, ERR, CRIT, ALERT, EMERG.
Testes do novo recurso em ambientes Solaris 10 e Red Hat Linux mostram que a documentação é imprecisa em 3 pontos:
1. AUDIT_SYSLOG_LEVEL é independente do AUDIT_TRAIL. Quando o AUDIT_SYSLOG_LEVEL é definido e o AUDIT_TRAIL tem seu valor padrão para NONE, ações CONNECT, STARTUP e SHUTDOWN são logados via syslog.
2. Definindo os parâmetros AUDIT_SYSLOG_LEVEL e AUDIT_SYS_OPERATIONS=TRUE causa qualquer ação como comandos SQL e PL/SQL executados com privilégios SYSDBA ou SYSOPER serem logados via syslog, mesmo se AUDIT_TRAIL=NONE.
3. Somente certas combinações de facilidades e níveis são aceitáveis. Combinações não aceitáveis causam o erro "ORA-32028: Syslog facility or level not recognized" e assim impedindo que a instância DBMS se inicie.
Se a documentação fosse precisa, não seria possível auditar ações executadas com privilégios SYSDBA ou SYSOPER ao log do systema, enquanto ações de auditoria por outros usuarios para a tabela SYS.AUD$ do dicionário de dados. Entretanto, esta limitação não existe.
- Usando AUDIT_SYSLOG_LEVEL
Como citado anteriormente, a string definida ao parâmetro AUDIT_SYSLOG_LEVEL deve consistir de um nome de uma facilidade e uma prioridade ou nível. Curiosamente, quando executa-se um SHOW PARAMETER ou um SELECT FROM V$PARAMETER, meramente a facilidade é visível, o ponto e o nível são suprimidos (teste na versão 10.2.0.3). Por exemplo, com a entrada *.audit_syslog_level='USER.NOTICE' no SPFILE usado para iniciar a instância, SHOW PARAMETER mostra:
SQL> SHOW PARAMETER audit_syslog_level
NAME TYPE VALUE
------------------------------------ ----------- -----
audit_syslog_level string USER
SQL> SELECT value FROM v$parameter WHERE name='audit_syslog_level';
VALUE
-----
USER
Ainda assim, quando executa-se CONNECT / AS SYSDBA, a facilidade e o nível logado em /var/adm/messages (no Solaris) é "user.notice":
Feb 21 11:45:52 dbserver Oracle Audit[27742]: [ID 441842 user.notice]
ACTION : 'CONNECT'
Feb 21 11:45:52 dbserver DATABASE USER: '/'
Feb 21 11:45:52 dbserver PRIVILEGE : SYSDBA
Feb 21 11:45:52 dbserver CLIENT USER: oracle
Feb 21 11:45:52 dbserver CLIENT TERMINAL: pts/3
Feb 21 11:45:52 dbserver STATUS: 0
Se um SPFILE for utilizado, a definição completa do parâmetro é visualizada consultando a V$SPPARAMETER:
SQL> SELECT value FROM v$spparameter WHERE name='audit_syslog_level';
VALUE
-----------
user.notice
- Auditando usuários não-privilegiados
Claro, você pode também direcionar os registros de auditoria relativos aos usuários não-privilegiados no log de sistema, definindo AUDIT_TRAIL = OS além de AUDIT_SYSLOG_LEVEL. Os usuários não-privilegiados não podem apagar as trilhas de auditoria. A busca por autores com consultas em views de auditoria, como DBA_AUDIT_STATEMENT ou DBA_AUDIT_OBJECT, é mais fácil do que procurar no log de sistema. Por estas razões, mantendo as trilhas de auditoria de usuários não-privilegiados dentro do banco de dados com AUDIT_TRAIL = DB é o preferido. Com o último ajuste, trilhas de auditoria são gravados na tabela SYS.AUD$ e pode ser consultado através das views de dicionário acima mencionadas. Definindo AUDIT_TRAIL=NONE, desliga auditoria de ações por usuários não-privilegiados.
Abaixo um exemplo depois de habilitar auditoria para conexões no banco de dados estabilizadas por usuários não-privilegiados:
SQL> AUDIT CONNECT BY appuser /* audit_trail=os set */;
Feb 21 11:41:14 dbserver Oracle Audit[27684]: [ID 930208 user.notice]
SESSIONID: "15" ENTRYID: "1" STATEMENT: "1" USERID: "APPUSER"
USERHOST: "dbserver" TERMINAL: "pts/3" ACTION: "100" RETURNCODE: "0"
COMMENT$TEXT: "Authenticated by: DATABASE" OS$USERID: "oracle"
PRIV$USED: 5
Outra entrada é adicionada ao /var/adm/messages (no Solaris) quando uma sessão do banco de dados encerrou:
Feb 21 11:44:41 dbserver Oracle Audit[27684]: [ID 162490 user.notice]
SESSIONID: "15" ENTRYID: "1" ACTION: "101" RETURNCODE: "0"
LOGOFF$PREAD: "1" LOGOFF$LREAD: "17" LOGOFF$LWRITE: "0" LOGOFF$DEAD:
"0" SESSIONCPU: "2"
Perceba que dados adicionais são fornecidos nas ações LOGON (100) e LOGOFF (101) conforme as colunas na visão DBA_AUDIT_SESSION:
SQL> SELECT action, name FROM audit_actions WHERE action IN (100,101)
ACTION NAME
------ ------
100 LOGON
101 LOGOFF
Quando o parâmetro é definido para AUDIT_SYSLOG_LEVEL=AUTH.INFO, AUDIT_SYS_OPERATIONS=FALSE e AUDIT_TRAIL=NONE, ações CONNECT,STARTUP e SHUTDOWN são logados via syslog. Com estas configurações um shutdown de uma instância escreve entradas similares as seguintes para o /var/adm/messages:
Feb 21 14:40:01 dbserver Oracle Audit[29036]:[ID 63719 auth.info] ACTION:'SHUTDOWN'
Feb 21 14:40:01 dbserver DATABASE USER: '/'
Feb 21 14:40:01 dbserver PRIVILEGE : SYSDBA
Feb 21 14:40:01 dbserver CLIENT USER: oracle
Feb 21 14:40:01 dbserver CLIENT TERMINAL: pts/3
Feb 21 14:40:01 dbserver STATUS: 0
Quando o parâmetro é definido para AUDIT_SYSLOG_LEVEL=AUTH.INFO, AUDIT_SYS_OPERATIONS=TRUE, e AUDIT_TRAIL=NONE, comandos SQL and PL/SQL executados com privilégios SYSDBA ou SYSOPER são também logados via syslog. Excluindo um usuário depois de se conectar com / AS SYSDBA resulta numa entrada similar no syslog:
Feb 21 14:46:53 dbserver Oracle Audit[29170]: [ID 853627 auth.info]
ACTION : 'drop user appuser'
Feb 21 14:46:53 dbserver DATABASE USER: '/'
Feb 21 14:46:53 dbserver PRIVILEGE : SYSDBA
Feb 21 14:46:53 dbserver CLIENT USER: oracle
Feb 21 14:46:53 dbserver CLIENT TERMINAL: pts/3
Feb 21 14:46:53 dbserver STATUS: 0
Até mais!!
Trecho retirado do livro (traduzido e com adaptações):
LONG, Norbert. Secrets of the Oracle Database. Apress, New York, p.03-08, 2009
- Syslog
Um novo recurso do Oracle 10g é a capacidade de gravar trilhas de auditoria usando o syslog em sistemas UNIX. Este mecanismo consiste em um processo daemon chamado syslogd (veja "man syslogd") que aceita mensagens de registro dos pedidos através da função syslog na biblioteca C (veja "man syslog"). O arquivo de configuração para o syslogd é normalmente /etc/syslog.conf e as mensagens de log vão para arquivos em /var/log e /var/adm dependendo da variante do UNIX. O nome do arquivo de log é determinada por uma seqüência que consiste em um nome de unidade e uma prioridade ou nível. A maioria destes pode ser utilizado na definição do AUDIT_SYSLOG_LEVEL. Cada entrada no /etc/syslog.conf atribui um nome de arquivo de log para uma determinada combinação de facilidade e prioridade. Ao colocar a entrada "user.notice /var/log/oracle_dbms" no arquivo syslog.conf e fazendo com que o syslogd releia o arquivo de configuração enviando um sinal de hang-up com o comando kill, qualquer entrada posterior no log de uma instância ORACLE com o parâmetro configurado AUDIT_SYSLOG_LEVEL = user.notice será gravado no arquivo /var/log/oracle_dbms.
No Windows, quando o parâmetro AUDIT_SYS_OPERATIONS é definido para TRUE, operações com SYSDBA ou SYSOPER são escritas também para o Event Log.
O manual "Oracle Database Reference 10g Release 2" fala sobre o AUDIT_SYSLOG_LEVEL assim:
AUDIT_SYSLOG_LEVEL permite que os logs de auditoria SO sejam escritos para o sistema via utilitário syslog, isso se o parâmetro AUDIT_TRAIL for definido para "OS". O valor da facilidade pode ser qualquer dos seguintes: USER, LOCAL0, LOCAL7, SYSLOG, DAEMON, KERN, MAIL, AUTH, LPR, NEWS, UUCP ou CRON. O Valor do nível pode ser quaisquer dos seguintes: NOTICE, INFO, DEBUG, WARNING, ERR, CRIT, ALERT, EMERG.
Testes do novo recurso em ambientes Solaris 10 e Red Hat Linux mostram que a documentação é imprecisa em 3 pontos:
1. AUDIT_SYSLOG_LEVEL é independente do AUDIT_TRAIL. Quando o AUDIT_SYSLOG_LEVEL é definido e o AUDIT_TRAIL tem seu valor padrão para NONE, ações CONNECT, STARTUP e SHUTDOWN são logados via syslog.
2. Definindo os parâmetros AUDIT_SYSLOG_LEVEL e AUDIT_SYS_OPERATIONS=TRUE causa qualquer ação como comandos SQL e PL/SQL executados com privilégios SYSDBA ou SYSOPER serem logados via syslog, mesmo se AUDIT_TRAIL=NONE.
3. Somente certas combinações de facilidades e níveis são aceitáveis. Combinações não aceitáveis causam o erro "ORA-32028: Syslog facility or level not recognized" e assim impedindo que a instância DBMS se inicie.
Se a documentação fosse precisa, não seria possível auditar ações executadas com privilégios SYSDBA ou SYSOPER ao log do systema, enquanto ações de auditoria por outros usuarios para a tabela SYS.AUD$ do dicionário de dados. Entretanto, esta limitação não existe.
- Usando AUDIT_SYSLOG_LEVEL
Como citado anteriormente, a string definida ao parâmetro AUDIT_SYSLOG_LEVEL deve consistir de um nome de uma facilidade e uma prioridade ou nível. Curiosamente, quando executa-se um SHOW PARAMETER ou um SELECT FROM V$PARAMETER, meramente a facilidade é visível, o ponto e o nível são suprimidos (teste na versão 10.2.0.3). Por exemplo, com a entrada *.audit_syslog_level='USER.NOTICE' no SPFILE usado para iniciar a instância, SHOW PARAMETER mostra:
SQL> SHOW PARAMETER audit_syslog_level
NAME TYPE VALUE
------------------------------------ ----------- -----
audit_syslog_level string USER
SQL> SELECT value FROM v$parameter WHERE name='audit_syslog_level';
VALUE
-----
USER
Ainda assim, quando executa-se CONNECT / AS SYSDBA, a facilidade e o nível logado em /var/adm/messages (no Solaris) é "user.notice":
Feb 21 11:45:52 dbserver Oracle Audit[27742]: [ID 441842 user.notice]
ACTION : 'CONNECT'
Feb 21 11:45:52 dbserver DATABASE USER: '/'
Feb 21 11:45:52 dbserver PRIVILEGE : SYSDBA
Feb 21 11:45:52 dbserver CLIENT USER: oracle
Feb 21 11:45:52 dbserver CLIENT TERMINAL: pts/3
Feb 21 11:45:52 dbserver STATUS: 0
Se um SPFILE for utilizado, a definição completa do parâmetro é visualizada consultando a V$SPPARAMETER:
SQL> SELECT value FROM v$spparameter WHERE name='audit_syslog_level';
VALUE
-----------
user.notice
- Auditando usuários não-privilegiados
Claro, você pode também direcionar os registros de auditoria relativos aos usuários não-privilegiados no log de sistema, definindo AUDIT_TRAIL = OS além de AUDIT_SYSLOG_LEVEL. Os usuários não-privilegiados não podem apagar as trilhas de auditoria. A busca por autores com consultas em views de auditoria, como DBA_AUDIT_STATEMENT ou DBA_AUDIT_OBJECT, é mais fácil do que procurar no log de sistema. Por estas razões, mantendo as trilhas de auditoria de usuários não-privilegiados dentro do banco de dados com AUDIT_TRAIL = DB é o preferido. Com o último ajuste, trilhas de auditoria são gravados na tabela SYS.AUD$ e pode ser consultado através das views de dicionário acima mencionadas. Definindo AUDIT_TRAIL=NONE, desliga auditoria de ações por usuários não-privilegiados.
Abaixo um exemplo depois de habilitar auditoria para conexões no banco de dados estabilizadas por usuários não-privilegiados:
SQL> AUDIT CONNECT BY appuser /* audit_trail=os set */;
Feb 21 11:41:14 dbserver Oracle Audit[27684]: [ID 930208 user.notice]
SESSIONID: "15" ENTRYID: "1" STATEMENT: "1" USERID: "APPUSER"
USERHOST: "dbserver" TERMINAL: "pts/3" ACTION: "100" RETURNCODE: "0"
COMMENT$TEXT: "Authenticated by: DATABASE" OS$USERID: "oracle"
PRIV$USED: 5
Outra entrada é adicionada ao /var/adm/messages (no Solaris) quando uma sessão do banco de dados encerrou:
Feb 21 11:44:41 dbserver Oracle Audit[27684]: [ID 162490 user.notice]
SESSIONID: "15" ENTRYID: "1" ACTION: "101" RETURNCODE: "0"
LOGOFF$PREAD: "1" LOGOFF$LREAD: "17" LOGOFF$LWRITE: "0" LOGOFF$DEAD:
"0" SESSIONCPU: "2"
Perceba que dados adicionais são fornecidos nas ações LOGON (100) e LOGOFF (101) conforme as colunas na visão DBA_AUDIT_SESSION:
SQL> SELECT action, name FROM audit_actions WHERE action IN (100,101)
ACTION NAME
------ ------
100 LOGON
101 LOGOFF
Quando o parâmetro é definido para AUDIT_SYSLOG_LEVEL=AUTH.INFO, AUDIT_SYS_OPERATIONS=FALSE e AUDIT_TRAIL=NONE, ações CONNECT,STARTUP e SHUTDOWN são logados via syslog. Com estas configurações um shutdown de uma instância escreve entradas similares as seguintes para o /var/adm/messages:
Feb 21 14:40:01 dbserver Oracle Audit[29036]:[ID 63719 auth.info] ACTION:'SHUTDOWN'
Feb 21 14:40:01 dbserver DATABASE USER: '/'
Feb 21 14:40:01 dbserver PRIVILEGE : SYSDBA
Feb 21 14:40:01 dbserver CLIENT USER: oracle
Feb 21 14:40:01 dbserver CLIENT TERMINAL: pts/3
Feb 21 14:40:01 dbserver STATUS: 0
Quando o parâmetro é definido para AUDIT_SYSLOG_LEVEL=AUTH.INFO, AUDIT_SYS_OPERATIONS=TRUE, e AUDIT_TRAIL=NONE, comandos SQL and PL/SQL executados com privilégios SYSDBA ou SYSOPER são também logados via syslog. Excluindo um usuário depois de se conectar com / AS SYSDBA resulta numa entrada similar no syslog:
Feb 21 14:46:53 dbserver Oracle Audit[29170]: [ID 853627 auth.info]
ACTION : 'drop user appuser'
Feb 21 14:46:53 dbserver DATABASE USER: '/'
Feb 21 14:46:53 dbserver PRIVILEGE : SYSDBA
Feb 21 14:46:53 dbserver CLIENT USER: oracle
Feb 21 14:46:53 dbserver CLIENT TERMINAL: pts/3
Feb 21 14:46:53 dbserver STATUS: 0
Até mais!!
Trecho retirado do livro (traduzido e com adaptações):
LONG, Norbert. Secrets of the Oracle Database. Apress, New York, p.03-08, 2009
Comentários
Postar um comentário