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;
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.
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
When I'm querying a table in schema C from schema A, I'm getting ORA-01031: insufficient privileges and when I'm querying the same table from schema B, I'm getting ORA-00942: table or view does not exist. On the table neither of the schemas are having any privileges. Why am I getting different error messages in this case?
You may get ORA-01031: insufficient privileges instead of ORA-00942: table or view does not exist when you have at least one privilege on the table, but not the necessary privilege.
Create schemas
SQL> create user schemaA identified by schemaA;
User created.
SQL> create user schemaB identified by schemaB;
User created.
SQL> create user test_user identified by test_user;
User created.
SQL> grant connect to test_user;
Grant succeeded.
Create objects and privileges
It is unusual, but possible, to grant a schema a privilege like DELETE without granting SELECT.
SQL> create table schemaA.table1(a number);
Table created.
SQL> create table schemaB.table2(a number);
Table created.
SQL> grant delete on schemaB.table2 to test_user;
Grant succeeded.
Connect as TEST_USER and try to query the tables
This shows that having some privilege on the table changes the error message.
SQL> select * from schemaA.table1;
select * from schemaA.table1
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> select * from schemaB.table2;
select * from schemaB.table2
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL>
ORA-01031: insufficient privileges happens when the object exists in the schema but do not have any access to that object.
ORA-00942: table or view does not exist happens when the object does not exist in the current schema. If the object exists in another schema, you need to access it using .. Still you can get insufficient privileges error if the owner has not given access to the calling schema.
for ORA-01031: insufficient privileges. Some of the more common causes are:
You tried to change an Oracle username or password without having the appropriate privileges.
You tried to perform an UPDATE to a table, but you only have SELECT access to the table.
You tried to start up an Oracle database using CONNECT INTERNAL.
You tried to install an Oracle database without having the appropriate privileges to the operating-system.
The option(s) to resolve this Oracle error are:
You can have the Oracle DBA grant you the appropriate privileges that you are missing.
You can have the Oracle DBA execute the operation for you.
If you are having trouble starting up Oracle, you may need to add the Oracle user to the dba group.
For ORA-00942: table or view does not exist. You tried to execute a SQL statement that references a table or view that either does not exist, that you do not have access to, or that belongs to another schema and you didn't reference the table by the schema name.
If this error occurred because the table or view does not exist, you will need to create the table or view.
You can check to see if the table exists in Oracle by executing the following SQL statement:
select *
from all_objects
where object_type in ('TABLE','VIEW')
and object_name = 'OBJECT_NAME';
For example, if you are looking for a suppliers table, you would execute:
select *
from all_objects
where object_type in ('TABLE','VIEW')
and object_name = 'SUPPLIERS';
OPTION #2
If this error occurred because you do not have access to the table or view, you will need to have the owner of the table/view, or a DBA grant you the appropriate privileges to this object.
OPTION #3
If this error occurred because the table/view belongs to another schema and you didn't reference the table by the schema name, you will need to rewrite your SQL to include the schema name.
For example, you may have executed the following SQL statement:
select *
from suppliers;
But the suppliers table is not owned by you, but rather, it is owned by a schema called app, you could fix your SQL as follows:
select *
from app.suppliers;
If you do not know what schema the suppliers table/view belongs to, you can execute the following SQL to find out:
select owner
from all_objects
where object_type in ('TABLE','VIEW')
and object_name = 'SUPPLIERS';
This will return the schema name who owns the suppliers table.
try to execute this on sql command line:
connect/ as sysdba;
create user b identified by "password";
grant all privileges to b;
and go create a new connection in SQL Developer;
do the same for schema 'c';
and grant privileges for schema 'a' too:
connect/ as sysdba;
grant all privileges to a;
this method fixed the problem for me.
In SQL Developer: Everything was working fine and I had all the permissions to login and there was no password change and I could click the table and see the data tab.
But when I run query (simple select statement) it was showing "ORA-01031: insufficient privileges" message.
The solution is simply disconnect the connection and reconnect.
Note: only doing Reconnect did not work for me.
SQL Developer Disconnect Snapshot
ORA-01031: insufficient privileges
Solution: Go to Your System User.
then Write This Code:
SQL> grant dba to UserName; //Put This username which user show this error message.
Grant succeeded.