A SIMPLE SECURITY APPROACH

------------------------------------------------
PART I
Author JP Vijaykumar Oracle DBA
A detailed discussion on the setup and administration of database access and security is beyond the scope
of this document.

This document aims at simplifying the setup and administration of database security in an ever changing /
volatile environment.

Majority of tasks an Oracle DBA does in maintaining the Security and Database Access are:

0100 User account management - like

0101 Creating users, roles, profiles.
Granting table level / system level privileges to users / roles.
Drop / Lock users. Password management.

0200 Special requirements - like.

0201 Protecting sensitive / confidential data using column level / row level security
by implementing Virtual Private Database / or custom built views.
0202 Granting Truncate privileges on tables in others’ schemas.

Creation and maintenance of database access and security is becoming a complex and demanding task day
in and day out. Lack of proper planning and approach, will put the DBA life in fire fighting mode.

0100 User account management

Creation and re-creation of tables in Development/ Integration environments is an ongoing process.

Creation of new schemas and tables in Production environment is continuous, with new code / modules
migration from Development / Integration environments.

In either case, all the users in the database can not access newly created / re-created objects.

Users granted only the DBA role or SELECT_ANY_TABLE system level privilege only can access the
newly created / re-created tables in a database, without any re-granting of privileges.

For security reasons, if we can not grant SELECT_ANY TABLE system level privilege, nor the DBA role
to the users in the database, imagine the trouble of granting the necessary privileges on the newly created /
re-created tables to users /roles quite frequently.
Tracking all the newly created/ re-created tables and granting permissions on these tables to different
users / roles is a full time DBA job.

To address this issue and simplify the process of granting privileges:

Create three roles for each schema, to manage the different table level permissions required by the users
(Currently existing schemas in our database are - TOM, DICK and HARRY). Alternatively, we can reduce
or increase the number of roles in the database, depending on the operational requirements and ease.

The details of roles and their granted table level privileges are as follows:

Role Name Privilege

--------- --------- -----------
TOM_SELECT SELECT PERMISSION ON ALL TABLES IN TOM'S SCHEMA
TOM_SINSERT SELECT/INSERT PERMISSIONS ON ALL TABLES IN TOM'S SCHEMA
TOM_SIUD SELECT/INSERT/UPDATE/DELET PERMISSIONS ON ALL TABLES IN
TOM'S SCHEMA

DICK_SELECT SELECT PERMISSION ON ALL TABLES IN DICK'S SCHEMA

DICK_SINSERT SELECT/INSERT PERMISSIONS ON ALL TABLES IN DICK'S SCHEMA
DICK_SIUD SELECT/INSERT/UPDATE/DELET PERMISSIONS ON ALL TABLES IN
DICK'S SCHEMA

HARRY_SELECT SELECT PERMISSION ON ALL TABLES IN HARRY'S SCHEMA

HARRY_SINSERT SELECT/INSERT PERMISSIONS ON ALL TABLES IN HARRY'S SCHEMA
HARRY_SIUD SELECT/INSERT/UPDATE/DELET PERMISSIONS ON ALL TABLES IN
HARRY'S SCHEMA

Create the roles for each schema.

Create role tom_select;
Create role tom_sinsert;
Create role tom_siud;

Create role dick_select;

Create role dick_sinsert;
Create role dick_siud;

Create role harry_select;

Create role harry_sinsert;
Create role harry_siud;

Grant create session to these roles:

Grant create session to tom_select;
Grant create session to tom_sinsert;
Grant create session to tom_siud;

Grant create session to dick_select;

Grant create session to dick_sinsert;
Grant create session to dick_siud;

Grant create session to harry_select;

Grant create session to harry_sinsert;
Grant create session to harry_siud;

This approach is good and maintainable with few schemas in the database.

With more schemas in the database, the number of roles to be created will become a huge list

To further simplify the approach, you can have three roles for the entire database, like db_select, db_sinsert
and db_siud. Grant necessary permissions on all the schema tables in the database to these three roles.
Another approach is to have multiple schemas grouped into different groups, depending on their
application, sensitivity, criticality. Create roles for each group like group1_select, group1_sinsert and
group1_siud.
Whenever a new user is created, grant the necessary roles to the user.

Create a procedure to grant different levels of permission to different roles on the newly created /
re-created tables. Schedule the procedure to run everyday at 18:00 hrs. By scheduling the procedure to run
everyday at 18:00 hrs, the users can access all the tables, created / re-created the day before.

declare
begin
for t1 in (select owner, table_name from all_tables
where owner in ('TOM','DICK','HARRY')) loop
execute immediate 'grant select on '||t1.owner||'.'||t1.table_name||' to '||t1.owner||'_SELECT';
execute immediate 'grant select, insert on '||t1.owner||'.'||t1.table_name|| ' to '||t1.owner||'_SINSERT';
execute immediate 'grant select, insert, update, delete on ‘||t1.owner||'.'||t1.table_name|| ‘ to '||
t1.owner||'_SIUD';
end loop;
end;

This procedure grants the required permissions on the existing tables in the database to different roles as
per the security setup.

This procedure works fine if each schema in the database has three roles, however, the procedure needs to
be modified if the roles setup is different, ie. three roles for the entire database or all the schemas are put
into different groups and three roles per group are created.

Any time the table level permissions on all the schema objects can be granted/ re-granted to different roles
by executing the procedure.

Grant the roles to users at the time of users’ creation.

Imagine the number of scripts I have to execute in the database, if I do not have a setup like this and I have
to grant various table level permissions on all created/ re-created schema tables to all the users

If required create a procedure to grant various roles to users.

declare
begin
for u1 in (select username from all_users
where username in upper('')) loop /* Here supply the username */
for p1 in (select username from all_users
where username in ('TOM','DICK','HARRY')) loop
/* uncomment necessary grant of roles and comment unnecessary grant of roles in this script */
--execute immediate 'grant '||p1.username||'_select to '||u1.username;
--execute immediate 'grant '||p1.username||'_sinsert to '||u1.username;
execute immediate 'grant '||p1.username||'_siud to '||u1.username;
end loop;
end loop;
end;

Wherever specific privileges are needed, grant the privileges to specified users separately.

For password management, create a default profile with required limits on password management and
assign it to the users in the database.
A sample profile:
Create profile apps_developer limit
Failed_login_attempts 3
Password_lock_time 3
Password_life_time 30
Password_grace_time 3
Password_reuse_time 150
Password_reuse_max 5 ;

If only one user was created in the database. This single user owns all the schema objects. And if all
the end users are connecting to the database as the single database user / schema owner. Then where
is the need for further simplification of Security?