Dear Readers,
My name is Franz Devantier, creator of this blog. I am an Oracle Certified
Professional (OCP DBA 11g) Security DBA.
I will be sharing with you the basic duties of an Oracle DBA, and also
some of the undocumented, and not so well known tasks.
I will make a deal with you: If you refer me to a company that needs
database support, from a few hours per week to full time, and I am able to sign
a contract with them.
Then I will give you 10% of the monthly
contract or deal price every month. When
the contract ends, and we re-sign the contract, I will again give you 10% of
the monthly contract price. This will go
on until the company no longer employs or contracts me or my agents to look
after their databases.
I can do this, because that 10% is my
marketing budget. When we re-sign the
contract, in the future, it may depend on you giving the thumbs up again, and
that is worth 10% of the monthly contract price, to be given to you as
commission.
Contact:
Franz
Security
Policies - Part 1
Security Policies
Security considerations range from protecting
sensitive table data on the row or column level to; regular database backups
that are stored offsite.
We can divide security policies into the
following broad headings:
-> System Security Policy
-> Data Security Policy
-> User Security Policy
-> Password Management Policy
-> Auditing Policy
-> Security Checklist
System Security Policy
System Security consists of the following
broad areas:
-> Database User Management
-> User Authentication
-> Operating System Security
In a small installation the database
administrator will double up as the security administrator. Otherwise you may have one or more database
security administrators. A security policy
should be developed for every database.
Database User Management
Database users represent the access paths to
all of the data in an Oracle database. The
security administrator should exclusively have the privileges required to
CREATE, ALTER, or DROP database users.
User Authentication
You can authenticate users through Oracle or through the
host operating system. If you have
advanced security installed, then you can also authenticate users through
network services, or by Secure Sockets Layer (SSL).
Operating System Security
Firstly database administrators must have the operating
system privileges to create and delete files.
Secondly, other database users should not have the operating system
privileges to create or delete files, related to the database. Lastly, if the operating system identified
database roles for users; then the Security database administrator/s must have
the privileges to modify the security domain of operating system accounts.
Data Security Policy
This policy determines which
users have access to which schema objects, as well as the list of specific
actions that the user is allowed to execute on those objects.
The level of security that you
want to establish overall for your database, determines how you security policy
will look at the detail level.
Generally the data security
policy is based on the sensitivity of the data stored in the table
objects. If the data is not sensitive,
then little or no security may be necessary to implement. If the data is sensitive, then a tight
security policy should be developed and maintained.
You can implement data security by managing system
privileges, object privileges, and roles.
Roles are named sets of privileges that are grouped together. Views also implement data security, because a
view can restrict the columns and rows of the base tables that are displayed,
thereby filtering out the sensitive data, from the viewer.
You can implement data security with fine-grained access
control. Fine-grained access control
enables you to implement security policies with functions, which can be
associated with tables or views. The
security function policy generates a WHERE condition that is appended to the
SQL statement given, and restricts user access to certain rows in the table or
view. An application context consists of a secure data cache, in which
attributes on the application level and user level are stored, which are used
in making data access decisions, and
also for other functions in the application
User Security Policy
There are a few broad areas to cover with reference to User
Security Policy:
-> General User Security
-> End-User Security
-> Administrator Security
-> Application Developer Security
-> Application Administrator Security
General User Security
For all types of database users, there are two security
issues that always emerge:
-> Password Security
-> Privilege management
Password Security
Database Security Administrators should develop a password
security policy to maintain database access security, for users who are
authenticated y the database. You can
reduce unauthorized database access, by forcing a user to modify their password
on a regular basis, and in cases where the password has been compromised, to
change it as well.
If you use the AES (Advanced Encryption Standard) algorithm on passwords, before sending them
across the network, then the passwords will be automatically and transparently
encrypted for Client/Server and server/server connections.
Privilege Management
There are a few issues to consider with privilege
management. For example if there are
only a few users, it may be easy enough to directly grant the needed privileges
explicitly to the users. In this way you
would have avoided using roles. If a
database has many users or schemas, then it becomes more beneficial to use
roles. Roles are named groups of
privileges that you can grant to users or to other roles. Using roles simplifies the task of granting a
whole lot of people a set of privileges, because you just grant these
privileges to the role once, and thereafter, you just grant the role, to each
user with a similar requirement. In
complicated environments, the use of roles is essential in order to simplify
the administration.
End-User Security
There must be a policy that is designed for end-user
security. If there are many users, then
the security administrator can put different users in their own user groups,
and then create roles that match the requirements for these groups. You will grant all the needed privileges to a
role, and then grant the role to everyone in the group. Of course there will always be
exceptions. To handle these exceptions,
the required privileges can be granted to the users in addition, or a special
role with the special privileges in it, can be created, and granted to the
users, with the exception.
Using Roles for End-User Privilege Management
To simplify the management and improve the level of control
over the granting of privileges, roles are the simplest means of ease of
management and control. Let’s say that
an employee needs the access rights to access accounts receivable, and the
general Ledger, then roles for each of these applications will have been
created, containing all of the necessary privileges. The roles are then granted to the employee.
For example if you have a requirement for a group of
accountants to work together. Each
accountant may need access to the accounts receivable and the accounts payable
objects.
To facilitate this you create an accounts receivable role,
and grant all the privileges to the accounts receivable role, that you
need. Then you create an accounts
payable role, and grant all the privileges to the accounts payable role, that
is needed to perform their duties. Now
you create an accountant role, and grant the accounts receivable role, and the
accounts payable role to the accountant role.
Now when a new accountant joints the company, you simply grant them the
accountant role. With this role they
will be able to perform all of their duties.
-> With this arrangement, if a new database application
was developed or assigned to accountants, then a new role can be created for
the new application, all the privileges assigned to this role, and this role
then granted to the accountant role. In
this way the users will automatically be able to access all of the objects for
the new application. None of the users,
will need the privileges granted to them individually.
-> In the same way if the accounting department were
to discontinue the use of a certain
application, then the role associated with the application can be revoked from
the accountant role.
-> If there are changes to the accounts receivable
application and or the accounts payable application, then the new privileges
required can be granted to the two application roles. The security domain of the accountant role,
and all the users who are granted the accountant role, will automatically
reflect the privilege modification.
As a rule of thumb, use roles in all the situations that
you can, in order to simplify end-user privilege management, and make the
process more efficient and simple.
Using a Directory Service for End-User Privilege Management
If you have installed the Oracle Advanced Security options,
then you can set up a directory service through the enterprise user, and
enterprise role features of oracle Advanced Security. This is an alternative way to manage users,
and their authorizations centrally.
Administrator Security
There should be a policy in place to address database
administrator security. Especially if
there are several different types of
database administrators in a large database installation. You can group related administrative
privileges into several administrative roles.
You can then grant different roles to different administrators. In this way you can create a separation of
duties, and improve the security of the database installation. However on a small installation, you may just
create one custom administrative role, and grant this role to all the
administrators.
Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com
