A SIMPLE SECURITY APPROACH III Author JP Vijaykumar Oracle DBA Date 11-11-11 Some complex security requirements in Oracle

databases are: 01 Dropping adhoc/temporary users from the db after some time limit. ---------------------------------------------------------------------In our application, we create temporary users to access the db for one month. After one month, the users' account is locked & dropped from the db. For normal users in a database, the following password limits can be enforced through profiles: Create profile apps_developer limit failed_login_attempts 3 --account will be locked after 3 failed login attempts password_lock_time 3 --number of days the account will be locked password_life_time 30 --number of days a password can be used password_grace_time 3 --number of days of grace period to change password password_reuse_time 150 --number of days until a password can be reused password_reuse_max 5 --number of changes required before a password reuse. / Here, when I try to drop a temporary user after the time limit, and if the user is currently logged into the db, then I get an error "ORA-01940: cannot drop a user that is currently connected". To avoid this problem, first I lock the user, after the stipulated time limit. In the next step I drop the locked user. create user month_jp idenfied by month_jp account unlock; grant create session to month_jp; create user week_jp identified by week_jp account unlock; grant create session to week_jp; SQL> select account_status from dba_users where username='VEEKSHA'; ACCOUNT_STATUS -------------------------------LOCKED(TIMED) The account of JP is locked here because the user exceeded the number of failed login attempts to the db. The default profile's failed login attempts limit is 1 0. -----------------------------------------------------------------------This procedure checks for all the existing users in the db with 'TEMP_' prefix --If the userid was 30 days old, the account will be locked --If any account is older than 30 days and locked, then the account is dropped --------------------------------------------------------------------set serverout on size 1000000 timing on declare --create or replace procedure temp_user_maintenance as begin

for c1 in (select username,account_status,trunc(sysdate) - trunc(created) day_co unt from dba_users where (username like 'WEEK%' or username like 'MONTH%')) loop begin dbms_output.put_line(c1.username ' ' c1.account_status ' ' c1.day_count); if ((c1.account_status NOT LIKE '%LOCKED%') and ( ((c1.day_count >= 30) and (c1.username like 'MONTH%')) or ((c1.day_count >= 7) and (c1.username like 'WEEK%')))) then --or ((c1.day_count >= 1) and (c1.username like 'WEEK%')))) then execute immediate 'alter user ' c1.username ' account lock'; dbms_output.put_line (c1.username ' ' c1.account_status ' ' c1.day_count ' Locked '); elsif ((c1.account_status LIKE '%LOCKED%') and ( ((c1.day_count >= 30) and (c1.username like 'MONTH%')) or ((c1.day_count >= 7) and (c1.username like 'WEEK%')))) then --or ((c1.day_count >= 1) and (c1.username like 'WEEK%')))) then execute immediate 'drop user ' c1.username ' cascade'; dbms_output.put_line (c1.username ' ' c1.account_status ' ' c1.day_count ' Dropped '); end if; exception when others then dbms_output.put_line (c1.username ' ' c1.account_status ' ' c1.day_count ' ' sqlerrm); end; end loop; end; / 02 Restricting users' db access after office hours/weekends. ---------------------------------------------------------------------For some reason, the application does not permit some adhoc users to login to the database between 8:00 PM - 8:00 AM and on weekends (national holidays not included). To enforce this requirement, there is no option available in profiles. For this purpose I created the following trigger that raises an error, when user JP tries to login to the database. CREATE OR REPLACE TRIGGER user_control_trig_jp AFTER LOGON ON DATABASE DECLARE /******************************* This trigger does not allow user jp to login to the database before 08:00 hrs or after 20:00 hrs and on weekends. create user VEEKSHA identified by VEEKSHA account unlock; grant create session to VEEKSHA; create table temp_users_jp(username varchar2(30), status varchar2(100)); insert into temp_users_jp values ('VEEKSHA','GRANTED ACCESS BETWEEN 8AM TO 8PM FROM M-F ONLY');

select to_char(sysdate,'mm-dd-yyyy hh24:mi:ss') from dual; *******************************/ v_user varchar2(50); v_day varchar2(10); v_num number; v_hrs number; BEGIN execute immediate 'alter session set nls_date_format=''' 'mm-dd-yyyy hh24:mi:ss' ''''; select sys_context('USERENV','SESSION_USER'), substr(to_date(sysdate,'mm-dd-yyyy hh24:mi:ss'),12,2), to_char(sysdate,'DAY') into v_user, v_hrs, v_day from dual; execute immediate 'select count(1) from temp_users_jp where username = ''' v_user ''' ' into v_n um; if ( ((v_day = 'SATURDAY' OR v_day = 'SUNDAY') AND (v_num = 1)) OR ( v_day <> 'SATURDAY' AND v_day <> 'SUNDAY' AND v_num = 1 AND ( v_hrs < 8 OR v_hrs > 17)) ) then --dbms_output.put_line(v_user ' ' v_time); --dbms_output.put_line('After 20 hrs you can not connect to the db'); RAISE_APPLICATION_ERROR(-20001,'Your are not authorized to connect at this time' ); end if; END; / alter trigger user_control_trig_jp disable; alter trigger user_control_trig_jp enable; Pls note - enabling the above trigger fires at every user's every login and creates overhead on the db's performance. If the trigger is a security requirement of the db, then enable the trigger at 7:59 PM and disable the trigger at 8:00 AM M-F through a scheduled job. That way, you can reduce the overhead of trigger firing for each login during business hours. 03 Trigger to fire before alter/drop/truncate of a table. ---------------------------------------------------------------------Also I want to enable a trigger in the database that raises an error, if an object is dropped or truncated.This save the dba from lot of trouble, if anybody accidentally drops an object from the database. If at all any object is to be dropped or truncated, first disable the trigger and then drop/truncate the object and re-enable the trigger. create or replace trigger no_drop_trigger_jp before alter or drop or truncate on database begin --if user='JP' then raise_application_error(-20999,'Alter/Drop/Truncate on objects not allowed'); --end if; end;

/ drop table temp; drop table temp * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-20999: Alter/Drop/Truncate on objects not allowed ORA-06512: at line 3 As a dba, if you need to drop/truncate a table, first disable the trigger and then alter/drop/truncate the object and re-enable the trigger. alter trigger no_drop_jp disable; drop table temp_jp; alter trigger no_drop_jp enable; Even, if you are working in Oracle 10g or higher and using flashback option, it a good to enable a ddl trigger that fires before a drop/truncate/alter command. If you are working in Oracle 9i or below, then having a ddl trigger that fires before a drop/ truncate/alter command is of great help. This trigger will reliev e you from lot of trouble of performing incomplete recoveries to recover dropped t ables. This will check on any user inadvertantly dropping/truncating/altering tables/ob jects in the database. ------------------------------------------------------select last_day(add_months(sysdate,-1)) + 1 first_day, last_day(sysdate) from dual; FIRST_DAY LAST_DAY( --------- --------01-OCT-11 31-OCT-11 ------------------------------------------------------To enforce case sensitivity in passwords alter system set sec_case_sensitive_logon=true; ------------------------------------------------------REFERENCES http://www.dbasupport.com/oracle/ora10g/SecurityApproach01.shtml http://www.dbasupport.com/oracle/ora10g/SecurityApproach02.shtml http://docstore.mik.ua/orelly/oracle/guide8i/ch06_03.htm http://dbataj.blogspot.com/2007/04/accountstatus-of-oracle-user.html http://www.oracle-base.com/articles/misc/BasicSecurityMeasuresForOracle.php Oracle Database Security Guide 10g Release 2(10.2) 7 Security Policies Oracle Database Security Checklist an Oracle While Paper January 2006 http://www.adp-gmbh.ch/ora/concepts/profile.html http://www.dbapool.com/articles/0916200801.html http://www.dbasupport.com/oracle/ora11g/11gSecurityGuide01.shtml http://www.dbasupport.com/oracle/ora11g/11gSecurityGuide02.shtml Metalink Note 114930.1 Oracle Password Management Policy http://www.orafaq.com/forum/t/153921/0/

http://www.submityourarticle.com/articles/Paul-Fleming-2057/oracle-database-2825 2.php http://waltsilva.wordpress.com/2007/10/12/using-regular-expression-functions-inplsql-to-check-for-complex-password-values/