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.
Oracle
Database Preinstallation – Part 7
Creating Required
Operating System Groups and Users
If the Oracle software was
previously installed on your system, then you may not have to do this. However it is always best to verify the
configuration that has been defined, if it is already in place.
Otherwise you will need to
create several operating system groups and users.
If you prefer to allocate
operating system user privileges, so that you can use one administrative user
and one group for your operating system authentication for all of the administrative
privileges, then you can use the oracle user as the installation owner, and use
one group as the primary group for any user requiring administrative privileges
for Oracle ASM, and Oracle database Administration. This group must then also be the Oracle
Inventory group. To simplify using the
defaults for the Oracle tools, the group name should then be oinstall. From a security point of view this is a big
problem.
A better approach is to
create custom configuration groups and users, based on job role separation. A custom configuration would for example have
groups and users, that divide access privileges granted by membership in separate
or different operating system groups and users.
You could still in this scenario create a single user, which would own
both the Oracle Database, and the Oracle Grid Infrastructure installation. Of course this brings with it a security
consideration. It would still be far
better to create a user to own the Oracle database, and a separate user to own
the Oracle Grid infrastructure installation.
For a standalone server
installation, the owners and or users of the Oracle database and grid
infrastructure, must both belong to the Oracle Inventory group for example “oinstall”. A user that has been created to own wither
the Oracle database installation, or all the Oracle installations is referred
to as the oracle user, although the username, may not be “oracle”. A user that is created to own the Oracle Grid
Infrastructure software is called the grid user.
Creating Custom
Configuration Groups and Users for Job Roles
To start with you will need
to log in as “root” to create these groups or users. If your company does not give you access to
the root user, even after motivation, then you should look for another job. Alternatively you can multiply the time
required for the operation by at least 10 times. Then you will need to sit with the System
administrator who does have root access, and patiently talk them through the
process, step by step. You should set up
a server or a laptop at home with the installation on it, so that you can
practice the full installation for yourself, in order to minimize your
disability with not having “root” access.
Understanding
Restrictions for Oracle Installations with Job Role Separation
Always best in the long run
to go with the Oracle recommendations, because they are there for good reasons. Oracle recommends that you should have one
software owner for each Oracle Software installation. This makes a lot of sense, because it
separates the different installations logically from each other, ie, you don’t
end up writing in each other’s configurations files etc. Actually the worst that I have seen at some
large well known telecom companies in Southern Africa, is different databases,
that have their data-files mingled together in the same directory structures. Of course this becomes a nightmare when
management decides to move databases around and clean-up “obsolete” data-files. In this specific case, I pointed out the
situation, before any actions were taken.
So you need to create
separate Oracle software owners, create separate users, create separate operating
system privilege groups for different Oracle software installations. Each of these separate users must have the
Oracle central inventory group or the OraInventory group, as their primary
group. Members of this group have write
privileges to the Oracle central inventory or oraInventory directory, as well
as being granted permissions for various Oracle Restart resources and directories
in the Oracle Restart Home. Oracle DBA’s
need write access amongst other privileges to these directory structures. The Oracle documentation tends to refer to
this group as the “oinstall” group, although it could be called something else.
The database software owner
which is usually “oracle”, must also have the OSDBA group of the Oracle Grid
infrastructure home, so that database instances can log on to Oracle ASM. “oracle”, should also have the OSOPER group
assigned as a secondary group. The
OSOPER group is optional to a certain extent, but not creating it, does raise
additional security issues. Usually the
Oracle software owner users are referred to as the oracle users, regardless of
what the username is.
For a standalone server
installation, the owners of the Oracle Database software, and the Oracle Grid
Infrastructure software, must both belong to the Oracle inventory group “oinstall”.
Each Oracle software owner
must be a member of the central inventory group. You can have only one central inventory group
for Oracle installations on a server. If
you do create a separate central inventory group, then you stand a chance of
corrupting the central inventory. On a
standalone server, the grid user or the owner of the Grid infrastructure
software, must be in the OSDBA group of every database home on that server.
So you can see that even with
separate software owners, and users, and groups, things can still get very much
intertwined with each other. So you have
to be careful, and you have to have a properly designed infrastructure to
protect your database investment. By the
way, using the services of an Oracle database architect up front, will probably
save you multiple nightmares down the line.
Database Groups
for Job Role Installations
If you are installing the
Oracle Database, then you need to create the following operating system groups.
=> OSDBA group, which may
be “dba”.
The first time that you install the Oracle Database
software on the system, you will need to create this group. The members of the OSDBA group contains
operating system user accounts that have database administrative privileges,
such as SYSDBA privilege.
=> OSOPER group for the Oracle Database installation,
typically “oper”.
Although this is an optional group, there are strong
motivations from a database security perspective to create this group. Having access to this group will allow you to
have a separate group of operating system users, that have a limited set of
database administrative privileges, that are given by the SYSOPER
privilege. This group can’t directly
connect to the database as SYSOPER, unless this privilege is explicitly granted
to them. Members of the OSDBA group by
default have all the privileges that are granted to the SYSOPER privilege. Oracle Universal Installer will prompt you
for the name of this group, which is typically “oper”.
The OSOPER group is ideal to grant to junior DBA’s, so
that the mistakes that they potentially make on the database installations
while they are learning there trade is limited.
Later on, when they start becoming more proficient, and are giving more
responsibilities, they can receive the appropriate privileges.
Oracle Grid Infrastructure Groups for Job
Role Installations
If you are preparing to install Oracle Grid
Infrastructure, then you will need additional groups to the Oracle Database
installation. You can take the decision
here to use the same group as the OSASM and OSDBA groups, to be able to grant
system privileges to administer both Oracle ASM instances and Oracle database
instances. However it is always more
secure to separate the duties, and create or designate a unique group, separate
from the database administrators groups.
=> OSDBA group for Oracle ASM, which is usually called
“asmdba”.
It is better practice to have separate OSDBA groups for
the Oracle database installation and the Oracle Grid infrastructure
installation.
The Oracle Grid infrastructure software owner “grid”,
must be a member of the OSDBA group.
Membership of the OSDBA group enables access to the files managed by
Oracle ASM.
If you do have a separate OSDBA group for Oracle ASM,
then the Oracle restart software owner must also be a member of the OSDBA (dba)
group for each database, and also must be a member of the OSDBA (asmdba) group
for ASM.
=> OSASM group for Oracle ASM “asmadmin”
SYSASM privileges for Oracle ASM files provide
administrator privileges for storage files.
Typically you would think of the operating system group whose members
are granted the SYSASM privileges as the OSASM group, which typically
translates to “asmadmin” from the Linux perspective. Oracle ASM can support multiple databases.
If you are a member of the OSASM group, then you can use
SQL to connect to an Oracle ASM instance as SYSASM, using the operating system
authentication mechanism. With the
SYSASM privilege you can mount and dismount disk groups, and carry out other
storage administration tasks. The SYSASM
privilege will not provide any access to the RDBMS instance.
■The OSASM group for Oracle ASM
(typically, asmadmin)
SYSASM privileges for Oracle ASM files provide
administrator privileges for storage file. In Oracle documentation, the
operating system group whose members are granted SYSASM privileges is called the OSASM group, and in command
lines, is referred to as asmadmin. Oracle ASM can support multiple databases.
Members of the OSASM group can use SQL to connect to an
Oracle ASM instance as SYSASM using
operating system authentication. The SYSASM privileges permit mounting and dismounting of disk
groups, and other storage administration tasks. SYSASM privileges provide no access privileges on an RDBMS
instance.
This is why you need to create the OSASM group. If you don’t designate a separate group as
the OSASM group, then the OSDBA group that you define is also by default the
OSASM group. This means that you can
access the database with SQL queries as well as manage the ASM disks. It is far better to keep the duties separated
by creating the OSASM group.
OSOPER from for Oracle ASM, “asmoper”.
This is an optional group. Again it comes down to Oracle database security
considerations. Creating this group will
give you a separate group of operating system users, who have a limited set of
Oracle instance administrative privileges.
Now that is exactly what you want.
This is the SYSOPER for the ASM privileges. These privileges includes starting up and
stopping the Oracle ASM instance. By
default the members of the OSASM group will also have all the privileges
granted by the SYSOPER group for ASM privileges. So the OSOPER group is a limited privilege
version of the SYSOPER group.
If you define a OSOPER group for Oracle
ASM, then the Oracle Grid Infrastructure owner must be a member of this group.
Franz
Devantier,
Need
a database health check?
devantierf@gmail.com
Classifieds
No comments:
Post a Comment