Oracle 12c New Features - Expert Consolidation in Oracle Database 12c - page 26

Although some problems are addressed with the introduction of the self-contained Pluggable Databases, security
was and is very relevant. Imagine what would happen if someone broke out of this environment and had access to a
much larger number of databases and their data! Thankfully Oracle has done a lot to limit damage that can be done.
A hardened audit administration, the ability to restrict privilege inheritance for procedures with invoker rights, and
many more are aimed at reducing the possibility of an exploit.

Roles and PL/SQL Units
The security model in Oracle 12c knows of two different sets of privileges. Either a procedure was invoked with all the
rights and privileges of the definer or alternatively with the rights of the invoker of the procedure. The documentation
stack refers to the model as “definer” vs. “invoker” rights. There are two significant changes to the invoker rights
model: the first one is explained in this section and deals with the ability to grant roles to a PL/SQL unit. The second
one will be detailed in the next section and allows you to restrict the rights of the invoker.
The Oracle SQL language now allows you to grant roles to PL/SQL units, that is, to a stored procedure, function,
or package. Note the absence of a trigger here! This allows the developer to create an invoker rights procedure in the
schema of the application owner which should be well protected by means of a secure password and a strict
non-interactive use policy. By granting the necessary rights to the role necessary for the execution on the stored
PL/SQL unit it is possible to create low-privileged accounts accessing the application. More importantly, there are
no direct grants to the underlying tables within the application owner's schema.
Figure 2-1 demonstrates how the combined rights of the invoker and the role allow for the execution of the
PL/SQL unit.

Figure 2-1. Access privileges granted to a user and a role allow for the execution of an invoker rights procedure

Consider the following simplified example for a demonstration of the concept.

• An application owner, named APPOWNER owns the tables for the application.

• A user account, named LOWPRIVS accesses the application via a well-defined API.