Saturday, July 23, 2011

Auditing in Oracle

Auditing is the monitoring and recording of selected user database actions. Auditing is normally used to:

1.) Investigate suspicious activity. For example, if an unauthorized user is deleting data from tables,the security administrator might decide to audit all connections to the database and all successful and unsuccessful deletions of rows from all tables in the database.

2.) Monitor and gather data about specific database activities. For example, the database administrator can gather statistics about which tables are being updated, how many logical I/Os are performed, or how many concurrent users connect at peak times.

There are two distinct types of auditing
1.) Standard        ->>  auditing based on statement, privilege and object-level
2.) Fine-grained  ->>  auditing on a finer granule which is based on content i.e. value > 10,000


Standard Auditing is further classified into 3 levels of standards auditing.The following are 
 i.)    Statement    ->>  audit all actions on any type of object.
ii.)   Privilege       ->>  audit actions that stem from system privileges.
iii.)  Object-level ->>  specific audit actions like select, update, insert or delete.


For all 3 levels of auditing we can choose to audit by access (audit every time we access) or by session (audit only once per access during the session), we can also auditing on if the access was successful (whenever successful) or not (whenever not successful).

How to eanable auditing : 
Below are some basic methods for auditing : 


1.) AUDIT_SYS_OPERATION : This parameter audits the SYS and SYSDBA connections. when we enable the parameter audit_sys_operations the database will write a trace file of the session action to the udump directory. This parameter should be enables on ALL production databases. Here is the method of enabling auditing .


SQL> alter system set audit_sys_operations=true scope=spfile;
SQL> shut immediate
SQL> startup
SQL> sho parameter audit
NAME                                TYPE                       VALUE
------------------                -----------            --------------------------------------------------------------
audit_file_dest                string               D:\ORACLE\PRODUCT\10.2.0\ADMIN\NOIDA\ADUMP
audit_sys_operations     boolean           TRUE
audit_trail                       string               DB
We can audit sys and sysdba connections from event logfile .(eventvwr.msc)


2.) AUDIT_TRAIL  Parameter : This parameter audit SESSION, DCL, DDL, DML, Select statements to table AUD$ or OS files.This is the easiest and most common method of auditing an oracle database, and this parameter should be set on ALL production databases. The audit_trail parameter can take the following values :

none  = disables auditing
os      = records the information to a o/s file (uses parameter audit_file_dest for the file location)
db      = records the information in the database, use the view dba_audit_trail ( view accesses table sys.aud$ )   to display audit information.
db, extended   = as per the db value but also populates the sqlbind and sqltext clob columns
xml     = audits to the o/s file but in xml format (uses parameter audit_file_dest for the file location)
xml,extended  =  as per xml option but also populates the sqlbind and sqltext clob columns


A basic list of audit option are as : 


==>Turn off auditing : 
SQL> alter system set audit_trail=none scope=spfile;


==> Auditing written to o/s :
SQL> alter system set audit_file_dest='c:\oracle\auditing';
SQL> alter system set audit_trail=os scope=spfile;


Note: if the audit_file_dest is not set then the default location is $oracle_home/rdbms/audit/


To start auditing we can use the below (there are many more options than stated below)
==> On Session    
SQL> audit session by neer;


==> On Table 
SQL> audit table;


==>Table and Specific user   
SQL>audit table by neer;


==>Table, Specific User and Access
SQL> audit table by neer by access;

==>Privilege auditing
SQL>audit create any table;

SQL>audit create any table by neer;


==>Object auditing
SQL> audit select on neer.employees by access whenever successful;

SQL> audit select on neer.employees by access whenever not successful;


==>Disabling audit
SQL>noaudit table;
SQL>noaudit all privileges;
SQL>noaudit create any table by neer;


==>Turn off all auditing
SQL> noaudit all;                              (turn off all statement auditing)

SQL> noaudit all privileges;               (turn off all privilege auditing)
SQL> noaudit all on default;               (turn off all object auditing)


==>Purge audit table
SQL>delete from sys.aud$;
SQL>truncate from sys.aud$;


Here is demo of the Standard auditting  :


C:\>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Sat Jul 23 13:58:26 2011
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options


SQL> alter system set audit_trail=db scope=spfile;   
System altered.


SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.


Total System Global Area      167772160  bytes
Fixed Size                             1247876      bytes
Variable Size                         75498876    bytes
Database Buffers                   83886080    bytes
Redo Buffers                         7139328      bytes
Database mounted.
Database opened.
SQL> create user test identified by test
  2  default tablespace users
  3  quota unlimited on users;
User created.


SQL> grant connect to test;
Grant succeeded.


SQL> grant create table,create procedure to test;
Grant succeeded.


SQL> audit select table,update table,insert table,delete table by test by access;
Audit succeeded.


SQL> audit all by test by access;
Audit succeeded.


SQL> conn test/test@noida
Connected.


SQL> create table aud_table(id number);
Table created.


SQL> insert into aud_table values (&A);
Enter value for a: 1
old   1: insert into aud_table values (&A)
new   1: insert into aud_table values (1)
1 row created.


SQL> insert into aud_table values (&A);
Enter value for a: 2
old   1: insert into aud_table values (&A)
new   1: insert into aud_table values (2)
1 row created.


SQL> /
Enter value for a: 3
old   1: insert into aud_table values (&A)
new   1: insert into aud_table values (3)
1 row created.


SQL> update aud_table set id=123 where id=2;
1 row updated.


SQL> select  *  from aud_table;
        ID
----------
         1
       123
         3


SQL> delete from aud_table;
3 rows deleted.


SQL> drop table aud_table;
Table dropped.


SQL> conn / as sysdba
Connected.


SQL> select username,obj_name,action_name from dba_audit_trail
  2       where owner='TEST' order by timestamp;


USERNAME              OBJ_NAME             ACTION_NAME
---------                   ---------------           -------------------
TEST                      AUD_TABLE              CREATE TABLE
TEST                      AUD_TABLE              INSERT
TEST                      AUD_TABLE              INSERT
TEST                      AUD_TABLE              INSERT
TEST                      AUD_TABLE              UPDATE
TEST                      AUD_TABLE              SELECT
TEST                      AUD_TABLE              DELETE
TEST                      AUD_TABLE              DROP TABLE
8 rows selected.


FGA (fine-grained auditing)  :  Fine-grain auditing (FGA) allows us to audit users accessing data of a certain criteria. As per standard auditing we can audit select, insert, update and delete operations. We use the package dbms_fga to add, remove, enable and disable FGA auditing policies, it is virtually impossible to bypass these policies, one nice feature is that we can attach handlers (like a trigger) to the policies which can execute procedures.


There are many options that can be applied to the dbms_fga package, here are some simple examples : 
==> Creating  :  


SQL> begin
dbms_fga.add_policy (
object_schema=>'neer',
object_name=>'employees',
policy_name=>'aud_test',
audit_column=>'salary,commission_pct',
enable=>false,
statement_types=>'select'); 
end;
/


==> Removing  :  


SQL> begin
dbms_fga.drop_policy (
object_schema=>'neer',
object_name=>'employees',
policy_name=>'aud_test');
end;
/


==>Enabling  :  


SQL>begin
dbms_fga.enable_policy (
object_schema=>'neer',
object_name=>'employees',
policy_name=>'aud_test');
end;
/


==> Disabling  :


SQL> begin
dbms_fga.edisable_policy (
object_schema=>'neer',
object_name=>'employees',
policy_name=>'aud_test');
end;
/

Here is Demo of the FGA Auditing  :  

First,we will create the FGA policy say "FGA_AUD"

SQL>  begin
  2  dbms_fga.add_policy (
  3  object_schema=>'test',
  4  object_name=>'hot',
  5  policy_name=>'FGA_AUD',
  6  audit_column=>'id',
  7  enable=>true,
  8  statement_types=>'select,update');
  9  end;
 10  /
PL/SQL procedure successfully completed.

Now we will perform some "select" and "update" statements to audit  :

SQL> update hot set id=2222 where id=123;
0 rows updated.

SQL> update hot set id=2222 where id=2;
1 row updated.

SQL> select * from hot;
        ID
   ----------
       22
      2222
      2342

SQL> update hot set id=8888 where id=2342;
1 row updated.

SQL> commit;
Commit complete.

To audit the table and the statements fired by db_user, fire the below query :

SQL> select   db_user  ,scn,  sql_text   from  dba_fga_audit_trail   where   db_user='TEST';
db_user         SCN                        SQL_TEXT
--------        ----------              ------------------------------------
TEST          1186412              update hot set id=2222 where id=123
TEST          1186421              update hot set id=2222 where id=2
TEST          1186431              select * from hot
TEST          1186440              update hot set id=8888 where id=2342

SYS.AUD$ table :  Make sure that the sys.aud$ table gets purged from time to time as connections and DML activity in the database might come to a stand still if it becomes full.


 Purge Audit Table : 
SQL> delete from sys.aud$;
SQL> truncate from sys.aud$;   

Friday, July 22, 2011

Create Read-only user for a Schema


Sometimes the DBA requires  to create the read-only user for a particular schemas.While creating the user,one should always keep in mind that the user should have minimum privileges.  There is no any direct command to create the read-only user in oracle.Sometimes I find people grants  “read any table ”  privileges to create the read-only  user ,which is not correct . Here is demo for creating read-only users. 
In this demo, I have created a user name “neer” and given  access to select only  “hr”  schemas tables.

Step  1  :  Create User  “NEER”

SQL> create user neer identified by neer;
User created.

Step  2  :  Grant session and create synonym privileges

SQL> grant create session ,create synonym to  neer ;
Grant succeeded.

Step  3  :  Make script to grant  select privileges to neer 

Here I have created the script with the help of spool  by selecting the tables of the HR schemas .

SQL> SPOOL  C:\select_privs.sql
SQL> select 'grant select on hr.'||table_name|| '  to neer;' from dba_tables where owner='HR';
SQL> select 'grant select on hr.'||view_name||  '  to neer;' from dba_views where owner='HR';
SQL> spool off

Now , we will check the spool  “select _privs.sql”  and prepare this as script for grant permission.

Step  4  :  Run the script to grant the permission

SQL> @C:\select_privs.sql

The  script  “select_privs.sql”  script  after modification  is .

grant select on hr.REGIONS to neer;                                             
grant select on hr.LOCATIONS to neer;                                           
grant select on hr.DEPARTMENTS to neer;                                         
grant select on hr.JOBS to neer;                                                
grant select on hr.EMPLOYEES to neer;                                           
grant select on hr.JOB_HISTORY to neer;                                         
grant select on hr.COUNTRIES to neer;                                                                
grant select on hr.EMP_DETAILS_VIEW to neer;                                    
  
Step  5  :  Create the synonym    
Connect to “NEER” schemas and create the synonym so that the “NEER” user can access the “HR”  schemas without any  dot(.)  like  “select * from employees”   instead of   “select * from HR.employees” .Here again we use the above method.

SQL> conn neer/neer@noida
SQL> SPOOL  C:\synonym_privs.sql
SQL> select 'create synonym '||view_name|| '  for HR.'||view_name||';' from all_views where owner='HR';
SQL> select 'create synonym '||table_name|| '  for HR.'||table_name||';' from all_tables where owner='HR';
SQL> spool off

Now we have the script to create the synonym

SQL>@ C:\synonym_privs.sql

Now we have successfully created a read-only user for a particular schemas.

Step  6  :   Check the tables

SQL> select Count(*) from employees ;
  COUNT(*)
----------
       107

SQL> select Count(*) from hr.employees;
  COUNT(*)
----------
       107

SQL> sho user
USER is "NEER"


Enjoy   :-) 



Thursday, July 21, 2011

Five DBA best practices

I have read a very good post of Arup Nanda and wish to share with you all. The post was regarding the best practices of DBA in day to day life. The practices are :


1. ) Multiple Oracle Homes : 
My   favorite  best  practice   is  the  one  about  multiple  Oracle  Homes. Here  it  how  it g oes. When applying  a patch  or  a  patchset, I  recommend  against  applying  to  the  existing  Oracle  Home. Instead, I suggest  creating  a  new  Oracle  Home, and  apply  the  patches  there. I create the first Oracle  Home  at /app/oracle/db_1, for instance.  When a  patch comes  out, I i nstall the  whole  Oracle  software  in a different home -- /app/oracle/db_2 -- and   then apply the patch there. During the process of installation and patch application, the  database is up and running, as it runs off the home /db_1. When the outage window comes, all I have to   do is to shut down Oracle; change Oracle Home to db_2 and bring the database up. If there is a  problem, I can reset the Oracle Home back to the old one.
So, here is the conventional approach:
1.                 Shut down the database
2.                 Apply patch to the Oracle Home
3.                 Start the database
4.                 In case of problems:
5.                 Shut down the database
6.                 Roll back the patch
7.                 Start the database
Steps 2 and 6 could take as much as three hours depending on the amount of patching.


The database is down during these times. 
In the new approach:
1.                 Install new Oracle Home
2.                 Apply the patch to the new Home
3.                 Shut down the database
4.                 Change Oracle Home to the new location
5.                 Start the database
6.                 In case of problems:
7.                 Shut down the database
8.                 Change Oracle Home to the old one
9.                 Start the database


The database is down only during steps 4 and 8, which takes a couple of minutes at the most, not hours.
So, here are the advantages:
1.) The downtime is significantly reduced, to one 60th of the original time.
2. ) The risk is reduced significantly, as there is no rolling back a patch; you just go to the older version.
3.) You can perform a "diff" on these two homes to see what changed. You can see the differences across   multiple homes as well.
4.)You can take several databases running on the same server to the new Oracle Home one by one.
5.) You can see the various Oracle Homes and what patch level they are on using the inventory.


The only negative part is the space consumption -- you need space for two Oracle Homes. But considering a typical Oracle Home takes about 4 GB or less, this aspect of the suggestion is trivial.


2.) Set audit trail to DB : 
Set the audit trail to DB by placing the parameter AUDIT_TRAIL = DB in   the initialization parameter file during  the  database creation. Setting this parameter  does  not  start  the auditing, because an explicit AUDIT  command  must  be  given on the object. But the parameter must be set to a value other than FALSE (the default)  for the command to take  effect. Being a non-dynamic parameter, the database  must                      be bounced to change the value of AUDIT_TRAIL. To save the trouble and avoid an outage,                           always  set  the  value  to  DB, even  if  you  never intend  to audit a nything. It  does  not break anything  and you  will always be ready to audit when the time comes.

3.) Don't use.log : 
Don't use.log as the extension of redo logs. Someone   may run a script to remove all the log files assuming they are redundant and you will end up losing the online redo logs as well, forcing a database recovery. Instead, name them with extension "redo" or "rdo."

4.) Preview RMAN Restore : 
Preview  RMAN  Restore  to  identify  all the  various backup pieces that will be used in the recovery process without doing an actual recovery. This eliminates any surprises from missing pieces during an actual recovery process.

5.) Create a new Oracle user for clients running on the same server as the DB : 
The  Oracle  Database server  software  also contains  the  client  piece, which  allows the  clients  to  connect to the database on the same server. But  as  a best  practice  do  not  use  the  same  user or  the software; use  a new one. For instance, if "oracle"  is  the  user  to  install  Oracle  software,  create  a  new  user  called, say, "oraapp" and  install  the  client-only software using that user. The user "oraapp" should not be part  of  the  dba  or  the oinstall group; so this  user  can't  log  on  to  the  database  as sysdba. Create a new  group  called "appgrp" and assign  the user o raaap  to  this group. All the  application users on the box should also be part of the appgrp group. This way they can use the sqlplus, sqlldr and other executables on the server,  but  be  able  to  connect  a s sysdba.
The  common  practice  is  to  use  the  client  oftware  in  the  same  user  as  the database  software  owner; but s tarting  with 10.2, Oracle has changed  the  security  policy that takes  away the  global  execution permissions  from  the  Oracle Home. So the only option is  to  let  app  users  be  part  of  the  dba  group  or change the permissions on Oracle Home -- both make the database extremely vulnerable.

For more click here 


Enjoy   :-)