I have set audit_sys_operations to true, audit_trail is DB,EXTENDED. now I have a account name admin who have DBA privilige. I use AUDIT CREATE ANY TABLE BY ADMIN, But the select * from SYS.AUD$ just show nothing about admin creating a new table even when admin did create several tables;
can I see the audit record of user with DBA privilege ?
Well, I will make a summary here for future come-acrossers.
AUDIT_TRAIL=DB/TRUE enables systemwide auditing where audited records are written to the
database audit trail(the SYS.AUD$ table). The only audit data that will not be written to the table is the audit data pertaining to the activities of SYSDBA.
As I had set AUDI_TRAIL， I can see audited activities in SYS.AUD$。
As stated here:
AUDIT_SYS_OPERATIONS enables or disables the auditing of top-level operations, which are SQL statements directly issued by users when connecting with the SYSASM, SYSBACKUP, SYSDBA, SYSDG, SYSKM, or SYSOPER privileges. (SQL statements run from within PL/SQL procedures or functions are not considered top-level.) The audit records are written to the operating system's audit trail. The audit records will be written in XML format if the AUDIT_TRAIL initialization parameter is set to xml or xml, extended.
Since I had set audit_sys_operations to true, oracle will audit SYSDBA activities, but the records will not show up in SYS.AUD$ , it will be at (in my case /u01/app/oracle/admin/orcl/adump) .
But be careful, do not look up the wrong audit log file. The activities record are contained in file like orcl_ora_6225_20160513082219532252143795.aud
. I share some of it's contents below:
ACTION :[14] 'drop table foo'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/3'
STATUS:[3] '942'
DBID:[10] '1439309578'
Fri May 13 08:00:17 2016 -07:00
LENGTH : '205'
ACTION :[51] 'CREATE TABLE FOO(
FOO1 INTEGER,
BAR VARCHAR(10)
)'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/3'
STATUS:[1] '0'
DBID:[10] '1439309578'
You can see that I used an account with SYSDBA privilige to drop a table named foo and recreate it. The number in the brackets is the length of the value.
That's how auditing SYSDBA works.
If you want to audit what SYS does, you'll need to set the AUDIT_SYS_OPERATIONS parameter to TRUE which you already did. But SYS operations won't be written to SYS.AUD$ for security reasons. Since SYS can delete rows from the AUD$ table, the SYS audit trail has to be written to the file system (where, presumably, you can configure file permissions so that the DBA cannot modify the audit trail).
Related
I'm using Oracle 11g(11.2.0.1.0). I created about 20 tablespaces and users. And the data came by [Tools] - [Database Copy] on Oracle SQL Developer.
Somehow I found that a user is using SELECT query on the table from another schema. I want to prevent it for security. How should I change my grant options?
I read "Oracle Database Security Guide 11g Release 2(11.2)", but couldn't find the solution clearly.
Here are my creating and granting queries.
create user [USER_NAME]
identified by [PASSWORD]
default tablespace [TABLESPACE_NAME]
temporary tablespace TEMP;
grant create session,
create database link,
create materialized view,
create procedure,
create public synonym,
create role,
create sequence,
create synonym,
create table,
drop any table,
create trigger,
create type,
create view to [USER_NAME];
alter user [USER_NAME] quota unlimited on [TABLESPACE_NAME];
And here is the SELECT result of session_privs on a user.
SQL> SELECT * FROM session_privs;
PRIVILEGE
--------------------------------------------------------------------------------
CREATE SESSION
CREATE TABLE
DROP ANY TABLE
CREATE SYNONYM
CREATE PUBLIC SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE ROLE
CREATE PROCEDURE
CREATE TRIGGER
PRIVILEGE
--------------------------------------------------------------------------------
CREATE MATERIALIZED VIEW
CREATE TYPE
13 rows selected.
I want to prevent a user from querying SELECT on other schemas.
For example, the following query
-- connected with USER1
SELECT *
FROM USER2.table1;
should make an error like:
ERROR: USER1 doesn't have SELECT privilege on USER2.
Edited:
Use appropriate terms (changed some words from tablespace to schema)
Add SELECT result of session_privs on a user
Add the method of how the data came by.
It was my fault. I missed that I had added some roles.
To copy data using Oracle SQL Developer, I added predefined roles to users. The roles were exp_full_database and imp_full_database.
According to Oracle Database Security Guide: Configuring Privilege and Role Authorization, exp_full_database contains these privileges:
SELECT ANY TABLE
BACKUP ANY TABLE
EXECUTE ANY PROCEDURE
EXECUTE ANY TYPE
ADMINISTER RESOURCE MANAGER
INSERT, DELETE, UPDATE ON SYS.INCVID, SYS.INCFIL AND SYS.INCEXP
and roles:
EXECUTE_CATALOG_ROLE
SELECT_CATALOG_ROLE
Those roles are not required now. So the answer is removing them from users.
REVOKE exp_full_database, imp_full_databsae FROM USER1;
And I get the result I wanted.
-- connected with USER1
SELECT * FROM USER2.TABLE1;
ERROR at line 1:
ORA-01031: insufficient privileges
I use windows 7 and oracle 11g , so when i created user test and give an him create table privilege:
grant create table to test;
I notice that this user can also do select,insert,delete on the table that he created but i don't give him any object privileges.
is create table privilege mean all object privileges are granted?
Table owner can do everything with that table - all DML and DDL actions (selects, inserts, updates, deletes, alters, drops, ... everything).
If you want to let other users do something with your tables, then you'll have to grant those privileges to them.
I would like to submit a question about creating an audit trail for specific tables on Oracle 11g database. We would like to track user's changes, on some specific tables, that records has been changed from the application (front end) side. Of course the first idea we came up with was to create manually audit tables and set triggers to track:
who is changing the data
what type of operation is it (I, U, D)
time of the operation
But I read that Oracle has in-build mechanism that can handle audit trails, but at this moment I don't know any details how is it working. So the main question is: "What is the best / most elegant, with easy and clear access to the data, way to perform audit tracking?"
First of all your auditing should be on by setting your audit_trail
parameter to a valid value like DB, DB_EXTENDED, XML,
XML_EXTENDED or OS with scope=spfile and restart database.
Next, you need to use audit commands for what you want to track, such
as :
audit drop user by access;
audit drop any procedure by access;
audit drop any table by access;
audit audit system by access;
audit grant any privilege by access;
audit insert, update, delete on myschema.mytable by access;
To track sessions by audit-trail it's advisible to use
Dbms_Session.Set_Identifier( :i_client );
to set client info, during connection phase of your program unit.
Dbms_Session.Set_Identifier sets the session's client id to the
given value. This value can be used to identify sessions in
v$session by means of v$session.client_identifier. It can also be
used to identify sessions by means of
sys_context('USERENV','CLIENT_IDENTIFIER').
This procedure is executable by PUBLIC.
In addition ;
Dbms_Application_Info.Set_Client_Info( :i_client );
Dbms_Application_Info.Set_Module( :i_modul,null );
-- :i_modul is the name of your module or program unit from which
-- you are connecting to db .
methods are also useful to monitor from gv$session view's client_info and module columns.
As stated on the topic , I am looking for a way for us to track on the activities of the specific user. May or may not have the SYSDBA or SYSOPER privilege.
For example , HR.
I would like to know what are the details of his login , what are the objects that are changed by him , what were their original values , SQL statements executed , what procedure/functions that were executed etc.
Could we set up such audit trail log in Oracle 11gR2 Standard/Enterprise?
Thanks
First of all you need to enable auditing in your database by setting audit_trail parameter as shown below-
SQL> alter system set audit_trail='OS|DB|DB,EXTENDED|XML|XML, EXTENDED';
Initialization Parameters Used for Auditing
Then, you can audit user as-
SQL>CONNECT sys/password AS SYSDBA
SQL> AUDIT ALL BY username BY ACCESS;
SQL> AUDIT SELECT TABLE, UPDATE TABLE, INSERT TABLE, DELETE TABLE BY username BY ACCESS;
SQL> AUDIT EXECUTE PROCEDURE BY username BY ACCESS;
AUDIT
Audit records can be found in DBA_AUDIT_TRAIL view.Following query list all audit related views.
SQL>SELECT view_name FROM dba_views WHERE view_name LIKE 'DBA%AUDIT%';
Fine-grained auditing is available in Enterprise Edition only.
Feature Availability by Edition
I created some tables as a normal user, and when I change the privilege to sysdba I didn't fiund my tables!
I get this message: table or view does not exist
This is what I do:
First of all, with a normal user's privilege I create tab1:
create table tab1 …;
and I insert some values, when I
select * from tab1;
all my rows are displayed, but when I connect as sysdba; with this current user, no row is displayed!!
When you login as sysdba, you literally become the the sys user, and as such, you're connected to the sys schema, not your own:
sqlplus kjohnston as sysdba
*connected*
SQL> show user;
USER is "SYS"
Since you are in the sys schema, you have to reference your tables in your schema by prefixing the tablename with the schema name, as in:
select * from kati_ais.tab1; //assuming kati_ais is your schema name
As a side note, you should not get in the habit of logging in as sysdba unless you really need those higher level privileges for that session.
From the oracle documentation https://docs.oracle.com/database/121/ADMIN/dba.htm#ADMIN11048 , here's what sysdba provide to your user:
Perform STARTUP and SHUTDOWN operations
ALTER DATABASE: open, mount, back up, or change character set
CREATE DATABASE
DROP DATABASE
CREATE SPFILE
ALTER DATABASE ARCHIVELOG
ALTER DATABASE RECOVER
Includes the RESTRICTED SESSION privilege
What you need to see your tables with your other user is either:
grant select on *normal_user*.table1 to *your_sysdba_user*
and repeat it for each table
or you can go bar open with
grant select any table to *your_sysdba_user*
but be advised that select any table include everything from everyone including data dictionary view which may be more than you truly wish to allow
I would assume that your sysdba user would be close to database god like sys so that would be ok but the disclaimer is there so you know