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.
Security,
Privileges, Roles, Profiles and Resource Limitations - Part
9
Introduction to Roles
Roles are named groups of privileges, that you can grant as
a group to users or other roles. Roles
make managing and controlling privileges easier. With a database, each role names must be
unique, the namespace is database wide.
Also roles must be different to any of the user names. Because roles are not contained within a
schema, the user or schema that created the role, can be dropped, and the role
will still exist.
Roles are engineered to simplify the management of schema
object privileges. Roles would be
employed in an Oracle Internet Directory, and in an identity management system
to good effect.
Roles are designed firstly for application users. When it comes to application developers, they
need the object privileges to be granted directly, in order to properly define
the objects in the application.
Properties of Roles
Property
|
Description
|
Reduced Privilege Administration
|
Instead of working through long lists of privileges that
need to be granted to each user individually,
You can grant all the privileges to a role once, and then just grant
the role to each user who needs it.
|
Dynamic Privilege Management
|
If the privileges of a group of users need to change,
then instead of updating every user in the group, you can just update the
role. The security domains of the
users who are granted the role that you modify will automatically reflect the
changes made to the role.
|
Selective Availability of Privileges
|
You can selectively enable or disable the roles granted
to a user. This allows a high degree
of control over a users suite of privileges at any moment in time.
|
Application awareness
|
The data dictionary documents or holds the records of all
the roles that exist in the database.
An application can query the data dictionary and programmatically enable
or disable selective roles. This functionality
can be activated when a specific user attempts to execute the application.
|
Application-specific security
|
Roles can be password protected, so users can’t enable or
disable the role without the password.
So users can’t make use of the role outside of the context of the application. Applications can enable the role for users,
by means of embedded passwords, and encrypted passwords, stored in tables.
|
Database administrators will create appropriate roles for
the database application. The DBA will
grant all the privileges needed to run the application to a role, a password
protected role, or a secure application role.
Applications can have several different roles, each designed for a different
part of the application. When a user
switch to certain application functionality, the application will determine, if
they should be able to access this functionality, and then grant and revoke the
appropriate roles from the user.
Common Uses of Roles
Generally speaking a role is created to serve one of two
purposes.
·
Application Roles –
manages the privileges for a database application
·
User Roles – manages the
privileges for a user group
Application Roles
Application roles or secure application roles. You grant a secure application role all the
privileges that are needed to run a certain database application. Typically the secure application role will be
granted to the user by the application at run time. Privileges and roles can be granted to other
roles.
Different secure application roles could allow certain
users to access more data, and other s to access less data, depending on their
business role in the organization.
It is not good practice to grant password protected roles
or secure application roles to other roles.
User Roles
A user role consists of a group of privileges that has been
identified as being necessary for a certain user or group of users to carry out
the functions that they are required to perform through the database
application. You grant all the necessary
privileges to such a role, and then grant the role to the users in that group.
Granting and Revoking Roles
Object privileges, system privileges can be granted to a
role. Other roles can be granted to a
role, but best practice says not password protected roles, and not secure
application roles. A role also can’t be
granted to itself. A role cannot be
granted circularly, for example role A can’t be granted role B, if role B is
already granted to role A.
The Oracle Database Server allows applications and users to
enable and disable roles; this creates selective availability of privileges. The roles granted to a user are at any point
in time, either enabled or disabled.
To provide selective availability of privileges, Oracle
Database allows applications and users to enable and disable roles. Each role
granted to a user is, at any given time, either enabled or disabled.
The security domain of a user includes all the privileges
granted directly and available through all the roles that are granted to that
user and are currently enabled. Indirectly
enabled grants are grants that are granted through a role. When you enable a role that contains other
roles, you implicitly enable all the other indirectly granted roles.
There are two ways to grant or revoke roles from users.
·
SQL statements, GRANT
and REVOKE
·
Oracle Enterprise
Manager Database Control
Privileges are granted to and revoked from roles in the
same way that privileges are granted to and revoked from users. Roles can also be granted and revoked through
the operating system, or through network services.
Who Can Grant or Revoke Roles?
Any user that has been granted a role with the ADMIN OPTION
can grant or revoke that role to or from other users. If a user has been granted the GRANT ANY ROLE
system privilege, then they can grant or revoke any role, except a global role
to and from other users in the database.
Security Domains of Roles and Users
The security domain of a user includes all the privileges
that have been directly granted to that user, plus all the roles that are
currently enabled, as well as the indirectly granted roles on enabled roles. Most important is that the security domain of
a user also includes all the privileges and roles that are granted to
PUBLIC. A role can be enabled for one
user and disabled for another user at the same time.
Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com
Classifieds
No comments:
Post a Comment