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
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'm creating a USER on Oracle 12 c database, using TOAD.
After creating the TABLESPACE, I'm creating the USER. I'm a little confusing about the many ROLES and PRIVILEGES that can be given to a USER.
What are the minimum/standard roles and privileges a user must be given in order to perform CRUD operation and being able to 'edit' the database (create or delete table, DROP the schema ecc) from TOAD?
Thank you
It depends on what operations are you going to perform. If you want to work only with tables in your own db schema, then the following privileges are usually enough to start:
grant create session to <your_user>;
grant create table to <your_user>;
You have the default rights to insert/update/delete/select tables which you own.
Tablespace quota:
alter user <your_user> quota unlimited on <your_tablespace_name>;
It's better to set the default tablespace for the user. In this case you can omit the tablespace name in a create table statement.
alter user <your_user> default tablespace <your_tablespace_name>;
A link to the documentation - Privileges
Grant the user the following privileges:
CREATE SESSION (in order to allow the user to connect to the database)
INSERT
UPDATE
DELETE
SELECT
Use the below command to grant privileges to the user (you need to login as SYS or SYSTEM or another user that has GRANT privilege):
GRANT CREATE SESSION, SELECT, UPDATE, DETETE, INSERT TO user_name
Here's a suggestion you might (or might not) want to follow.
As a privileged user (such as SYS), check tablespaces available in your database. I'm using 11g XE (Express Edition) which shows the following:
SQL> show user
USER is "SYS"
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP --> temporary
USERS --> my data
Now, create a user:
SQL> create user mdp identified by pdm
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
Quite a long time ago, there were two popular predefined roles named CONNECT and RESOURCE which were granted some of the most frequent privileges so people just loved to grant those roles to newly created users.
Nowadays, you shouldn't be doing that: grant only minimal set of privileges your user might need. The first one is CREATE SESSION; without it, your user won't even be able to establish a connection.
SQL> grant create session to mdp;
Grant succeeded.
Then, you'll want to create some tables so - grant it:
SQL> grant create table to mdp;
Grant succeeded.
OK, let's connect as newly created user and do something:
SQL> connect mdp/pdm#xe
Connected.
SQL> create table test (id number);
Table created.
SQL> insert into test id values (1);
1 row created.
SQL> drop table test;
Table dropped.
SQL>
Nice; I can create tables, insert/update/delete/select from them. For beginning, that's quite enough. However, when it turns out that you'd want to, for example, create a view, it won't work until you grant it that privilege:
SQL> create view v_dual as select * From dual;
create view v_dual as select * From dual
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> connect sys#xe as sysdba
Enter password:
Connected.
SQL> grant create view to mdp;
Grant succeeded.
SQL> connect mdp/pdm#xe
Connected.
SQL> create view v_dual as select * From dual;
View created.
SQL>
And so forth; don't grant anything just because you might need it - grant it if & when you need it. Especially pay attention to system privileges which can potentially be dangerous if you don't know what you're doing.
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
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).
We have set audit_trail to DB, extended.I m trying to restrict the audit for specific users. But all users(objects) DML operations are auditing by default.
I tried to stop the auditing using all these statements:
SQL> NOAUDIT ALL;
Noaudit succeeded.
SQL> NOAUDIT ALL ON DEFAULT;
Noaudit succeeded.
SQL> NOAUDIT SESSION;
Noaudit succeeded.
SQL> noaudit select any table by X;
SQL> noaudit all by X;
But its still auditing all dml operations(for x schema also)
There are no audit policies and i see below output from below statement
SELECT * FROM DBA_PRIV_AUDIT_OPTS UNION SELECT * FROM DBA_STMT_AUDIT_OPTS;
null EXEMPT ACCESS POLICY By Access By Access
So i disabled it too
noaudit EXEMPT ACCESS POLICY;
Oracle 11g Release 2 Database is running on 64 bit CentOS.
Please let me know,is this default behavior of 11g database.If yes,Is there any way i can restrict it.
Your help is really appreciated.
Thank You!
By default database will record when it is stopped or started as well as record when a user logs on with either SYSDBA or SYSOPER privileges.
Oracle Database 11g audits the following privileges by default:
ALTER ANY PROCEDURE DROP ANY TABLE CREATE ANY PROCEDURE
ALTER ANY TABLE DROP PROFILE CREATE ANY LIBRARY
ALTER DATABASE DROP USER CREATE ANY TABLE
ALTER PROFILE DROP ANY PROCEDURE CREATE EXTERNAL JOB
ALTER SYSTEM EXEMPT ACCESS POLICY CREATE PUBLIC DATABASE LINK
ALTER USER AUDIT SYSTEM CREATE SESSION
GRANT ANY PRIVILEGE GRANT ANY ROLE CREATE USER
GRANT ANY OBJECT PRIVILEGE CREATE ANY JOB
Reference : https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000
In your case you could check if fine grained auditing is turned on. You could check with the following SQLs.
SQL> SET lines 150
SQL> SELECT object_schema,object_name,policy_name,policy_column,enabled,sel,ins,upd,del FROM dba_audit_policies;
SQL> SELECT * FROM dba_audit_policy_columns;