12cR2 Auditing All Users With A Role Granted

12cR2 auditing all users with a role granted
12.1 introduced Unified Auditing where you define policies and then enable them. As with
the traditional audit, you enable them for all users or for specific users. The unified auditing
adds a syntax to audit all users except some listed ones. 12.2 adds a syntax to audit a group of
users, defined by the role granted. This is the best way to enable a policy for a group of users,
including those created later.
I create a simple policy, to audit logon and DBA role usage:

SQL> create audit policy DEMO_POLICY actions logon, roles DBA; Audit POLICY
created.
I create a new DBA user, USER1
SQL> create user USER1 identified by covfefe quota unlimited on USERS; User
USER1 created. SQL> grant DBA to USER1; Grant succeeded.
I want to enable the policy for this user because I want to audit all DBAs
SQL> audit policy DEMO_POLICY by USER1; Audit succeeded.
I remove Audit records for this demo
SQL> exec
dbms_audit_mgmt.clean_audit_trail(audit_trail_type=>dbms_audit_mgmt.audit_t
rail_unified,use_last_arch_timestamp=>false); PL/SQL procedure successfully
completed.
Let’s connect with this user and see what is audited:
SQL> connect USER1/covfefe@//localhost/PDB1 Connected. SQL> select
audit_type,os_username,userhost,terminal,dbusername,action_name,unified_aud
it_policies,system_privilege_used,event_timestamp 2 from
unified_audit_trail where unified_audit_policies='DEMO_POLICY' order by
event_timestamp; AUDIT_TYPE OS_USERNAME USERHOST TERMINAL DBUSERNAME
ACTION_NAME UNIFIED_AUDIT_POLICIES SYSTEM_PRIVILEGE_USED EVENT_TIMESTAMP --
-------- ----------- -------- -------- ---------- ----------- -------------
--------- --------------------- --------------- Standard oracle VM104 pts/0
USER1 LOGON DEMO_POLICY CREATE SESSION 04-JUN-17 04.22.51.865094000 PM
Standard oracle VM104 pts/0 USER1 SELECT DEMO_POLICY SELECT ANY DICTIONARY
04-JUN-17 04.22.51.948187000 PM
The logon and the select on dictionary table (possible here thanks to the DBA role) has been
audited because the policy is enabled for this user.
We have a new DBA and we create a new user for him:

USER2 created. SQL> grant DBA to USER2; Grant succeeded.
He connects and check what is audited:
SQL> connect USER2/covfefe@//localhost/PDB1 Connected.
SQL> select
-------- ----------- -------- -------- ---------- ----------- -------------
04-JUN-17 04.22.51.948187000 PM Standard oracle VM104 pts/0 USER1 SELECT
DEMO_POLICY SELECT ANY DICTIONARY 04-JUN-17 04.22.52.132814000 PM
Nothing is audited for this user. The DBA role usage is audited, but only for USER1.
Of course, we can add an audit statement for each user created for a DBA:
SQL> audit policy DEMO_POLICY by USER2; Audit succeeded.
Then his new activity is audited:
SQL> connect USER2/covfefe@//localhost/PDB1 Connected. SQL> select
-------- ----------- -------- -------- ---------- ----------- -------------
DEMO_POLICY SELECT ANY DICTIONARY 04-JUN-17 04.22.52.132814000 PM Standard
oracle VM104 pts/0 USER2 LOGON DEMO_POLICY CREATE SESSION 04-JUN-17
04.22.52.338928000 PM
But for security reason, we would like to be sure that any new user having the DBA role
granted is audited.
Let’s try something else
SQL> noaudit policy DEMO_POLICY by USER1,USER2; Noaudit succeeded.
We can simply audit all users:
SQL> audit policy DEMO_POLICY; Audit succeeded.
But this is too much. Some applications constantly logon and logoff and we don’t want to
have that in the audit trail.
SQL> noaudit policy DEMO_POLICY; Noaudit succeeded.
We can still enable the policy for all users, and exempt those users we don’t want:
SQL> audit policy DEMO_POLICY except DEMO; Audit succeeded.
Here is what is enabled, and this will audot all new users:
SQL> select * from audit_unified_enabled_policies; USER_NAME POLICY_NAME
ENABLED_OPT ENABLED_OPTION ENTITY_NAME ENTITY_TYPE SUCCESS FAILURE --------
- ----------- ----------- -------------- ----------- ----------- ------- --
----- DEMO DEMO_POLICY EXCEPT EXCEPT USER DEMO USER YES YES ALL USERS
ORA_SECURECONFIG BY BY USER ALL USERS USER YES YES ALL USERS
ORA_LOGON_FAILURES BY BY USER ALL USERS USER NO YES
But once again, this is not what we want.
SQL> noaudit policy DEMO_POLICY by DEMO; Noaudit succeeded. SQL> select *
from audit_unified_enabled_policies; USER_NAME POLICY_NAME ENABLED_OPT
ENABLED_OPTION ENTITY_NAME ENTITY_TYPE SUCCESS FAILURE --------- ----------
- ----------- -------------- ----------- ----------- ------- ------- ALL
USERS ORA_SECURECONFIG BY BY USER ALL USERS USER YES YES ALL USERS
Audit all users to whom roles are granted directly
In 12cR2 we have the possibility to do exactly what we want: audit all users having the DBA
role granted:
SQL> audit policy DEMO_POLICY by users with granted roles DBA; Audit
succeeded.
This enables the audit for all users for whom the DBA role has been directly granted:
SQL> select * from audit_unified_enabled_policies; USER_NAME POLICY_NAME
ENABLED_OPT ENABLED_OPTION ENTITY_NAME ENTITY_TYPE SUCCESS FAILURE --------
- ----------- ----------- -------------- ----------- ----------- ------- --
----- DEMO_POLICY INVALID BY GRANTED ROLE DBA ROLE YES YES ALL USERS
ORA_SECURECONFIG BY BY USER ALL USERS USER YES YES ALL USERS
The important thing is that a newly created user will be audited as long as he has the DBA
role directly granted:
USER3 created. SQL> grant DBA to USER3; Grant succeeded. SQL> connect
USER3/covfefe@//localhost/PDB1 Connected. SQL> select
-------- ----------- -------- -------- ---------- ----------- -------------
DEMO_POLICY SELECT ANY DICTIONARY 04-JUN-17 04.29.18.117258000 PM Standard
oracle VM104 pts/0 USER2 LOGON DEMO_POLICY CREATE SESSION 04-JUN-17
04.29.18.322716000 PM Standard oracle VM104 pts/0 USER2 SELECT DEMO_POLICY
SELECT ANY DICTIONARY 04-JUN-17 04.29.18.345351000 PM Standard oracle VM104
pts/0 USER2 SELECT DEMO_POLICY SELECT ANY DICTIONARY 04-JUN-17
04.29.18.415117000 PM Standard oracle VM104 pts/0 USER2 SELECT DEMO_POLICY
SELECT ANY DICTIONARY 04-JUN-17 04.29.18.439656000 PM Standard oracle VM104
pts/0 USER2 SELECT DEMO_POLICY SELECT ANY DICTIONARY 04-JUN-17
04.29.18.455274000 PM Standard oracle VM104 pts/0 USER3 LOGON DEMO_POLICY
CREATE SESSION 04-JUN-17 04.29.18.507496000 PM
This policy applies to all users having the DBA role, and gives the possibility to audit more
than their DBA role usage: here I audit all login from users having the DBA role.
So what?
We don’t use roles only to group privileges to grant. A role is usually granted to define groups
of users: DBAs, Application user, Read-only application users, etc. The Unified Auditing can
define complex policies, combining the audit of actions, privileges, and roles. The 12.2 syntax
allows enabling the policy to a specific group of users.
Unified Auditing was introduced with Oracle 12c 12.1.0.1 and one idea is to combine
standard auditing (AUD$) with fine grained auditing (FGA_LOG$). AUD$ and FGA_LOG$
still exists and if you like you can use your existing and well accepted auditing procedures.
Some documents stated that the same auditing which was introduced with Oracle 11g is still
running but that’s not one hundred percent true. If you don’t change the standard database
setup the “old” AUD$ table exist but will stay empty in contrast to 11g. A new partitioned
table with a somewhat cryptic name (CLI_SWP$2dc5e8db$1$1) is populated in the
schema AUDSYS and with the view unified_audit_trail you can query the audit information.
Many blogs are available talking about how to enable unified auditing by relinking the kernel.
But actually that’s not necessary and even more some features like single column auding are
not yet available with unified auditing but with fine grained auditing. So my approach is not
to change the kernel but leave it as it is so I can use both methods simultaneously.
Fine grained auditing relies on “auditing policies” and you can have a look at the existing
ones using Toad (guess since 12.0).
On the left hand you can see the pre created auditing policies as the come with 12c. On the
right hand the first 6 lines are some descriptions and starting with line 7 you see actions to be
audited. The first action type is an “object action” which says: execute on the procedure
sys.dbms_rls will be audited. The next 16 actions are “Standard Actions”. So for example
every usage of the command “ALTER DATABASE LINK” will be audited. At the bottom
you see “System Privilege” actions. Those actions are audited if a database user executes a
command due to one of these privileges.
The “Object Actions” and “Standard Actions” are easy to understand. But what is the
difference between a “Standard Action” and “System Privilege”?
With this screenshot I used a filter (“Value LIKE %USER%) on the value of the policy info.
As you can see there are three actions:
 – Standard Action ALTER USER: whenever a user executes „ALTER“ user one audit
record will be created.
 – System Privilege CREATE USER: whenever a user how has granted the privilege
CREATE USER is executing the command one audit record will be created.
 – System Privilege DROP USER: same as the above.
For an ordinary user there is no difference in these three actions. Every time he’s executing
CREATE, ALTER, or DROP USER a new audit record will be created. But if SYS is
executing CREATE, ALTER, or DROP only the ALTER USER will be recorded as SYS does
not have the privilege CREATE USER granted but is the owner of that privilege.
This is not a theoretical example but reality as the ORA_SECURECONFIG policy is enabled
per default. It took me some time to find out why a CREATE USER hasn’t been recorded
while an ALTER user was. Now I know!
So how can you find out which audit policies are being used. The tab “Policy Enablement”
gives you some more information. One or more audit policies can be enabled though being
active.
With the enablement you can add some values and the above example shows that the policy
“ORA_LOGON_FAILURES” which by the way is a default as well is enabled
“WHENEVER NOT SUCCESSFUL”. So in contrast to Oracle 11g where every logon and
logoff was recorded with Oracle 12c only a failed logon will be recorded per default. If there
is no “WHENEVER” clause (like with ORA_SECURECONFIG) a record will be created
regardless if the command was successful or not.
Oracle 12c will create audit trails for several actions per default. But I must admit that I have
no idea why they took these actions (e.g. record every execution of ALTER USER but record
CREATE USER and DROP USER only if it isn’t SYS). So my approach is the following (I
won’t call it best practice as I’ve only used it for one customer yet):
1. Create a policy for logons. So like the ORA_LOGON_FAILURES but record fail and
successful logins.
2. Create a policy for critical DBA commands like CREATE, ALTER, DROP
TABLESPACE, etc.
3. Create a policy for all DDL commands not in the two above.
These three policies can be enabled or disabled as needed. For example policy 1 will be
enabled for all databases. Policy two only databases where the DBA is responsible – dear
DBA: don’t see this as a limitation or missing trust. It’s a safe guard for you because normally
YOU are blamed if something goes wrong. And the third policy will be enabled for all
preproduction, UAT (User Acceptance Testing) and production databases.

12cR2 Auditing All Users With A Role Granted

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

12cR2 Auditing All Users With A Role Granted

Uploaded by

Copyright:

Available Formats

12cR2 auditing all users with a role granted

I create a simple policy, to audit logon and DBA role usage:

We have a new DBA and we create a new user for him:

Audit all users to whom roles are granted directly

You might also like