9. Juli 2012

DBA zu Weihnachten - mit Secure Application Roles

Become DBA at christmas - with Secure Application Roles
Wenn es um das Zuweisen von Rollen zu Datenbank-Nutzerkonten geht, können Secure Application Roles ganz interessant sein. Eine Secure Application Role ist zunächst eine ganz normale Rolle, das Besondere ist aber, dass sie nur durch eine PL/SQL-Programmeinheit, bspw. ein Package, aktiviert werden kann. So ist die Anforderung, dass eine Rolle nur unter bestimmten Umständen aktiviert werden soll, mit Secure Application Roles ganz einfach umsetzbar. Allerdings erfordern Secure Application Roles eine Enterprise Edition, in der Standard-Edition oder gar in OracleXE sind sie nicht verfügbar.
Das Einrichten einer Secure Application Role ist sehr einfach. Die in IDENTIFIED USING genannte Prozedur muss zum Zeitpunkt des CREATE ROLE-Kommandos noch nicht existieren.
create role dba_an_weihnachten identified using sys.dba_weihnachten_proc
/
Das Zuweisen von Privilegien oder anderen Rollen zur Secure Application Role ist ebenfalls ganz einfach:
grant dba to dba_an_weihnachten
/
Wenn sich der Nutzer SCOTT nun anmeldet und in der View SESSION_ROLES nachsieht, dann ist die Rolle nicht aktiv ...
SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
RESOURCE

2 Zeilen ausgewählt.
Ein einfaches SET ROLE hilft nicht.
SQL> set role dba_an_weihnachten;
set role  dba_an_weihnachten
*
FEHLER in Zeile 1:
ORA-28201: Keine ausreichenden Berechtigungen zur Aktivierung von
Anwendungsrolle 'DBA_AN_WEIHNACHTEN'
Das liegt daran, dass die Rolle eben nur über die im CREATE ROLE genannte Prozedur SYS.DBA_WEIHNACHTEN_PROC aktiviert werden kann. Wir brauchen also, im Schema SYS, diese Prozedur.
create or replace procedure sys.dba_weihnachten_proc authid current_user is
begin
  if extract(DAY from sysdate) in (24,25,26) and extract(MONTH from sysdate) = 12 then
    dbms_session.set_role(
      role_cmd => 'DBA_AN_WEIHNACHTEN'
    );
  else
    raise_application_error(-20000, 'ES IST NICHT WEIHNACHTEN!');
  end if;
end;
/
sho err
Wichtig ist, dass die Prozedur mit der Klausel AUTHID CURRENT_USER angelegt wird, denn im Rahmen einer AUTHID DEFINER-Prozedur sind alle Rollen abgeschaltet. Wie Ihr seht, macht die Prozedur hier nicht viel: Sie prüft das Datum - und an Weihnachten kann der User SCOTT zum DBA werden. Vergesst nicht, das EXECUTE-Privileg zu vergeben.
grant execute on sys.dba_weihnachten_proc to scott
/
Nun als SCOTT anmelden und versuchen, die Rolle zu aktivieren ...
SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
RESOURCE

2 Zeilen ausgewählt.

SQL> exec sys.dba_an_weihnachten;
BEGIN sys.dba_an_weihnachten; END;

*
FEHLER in Zeile 1:
ORA-20000: ES IST NICHT WEIHNACHTEN!
ORA-06512: in "SYS.DBA_AN_WEIHNACHTEN", Zeile 8
ORA-06512: in Zeile 1
An Weihnachten sieht die Sache aber anders aus ... wieder als SCOTT anmelden ...
SQL> select sysdate from dual;

SYSDATE
-------------------
24.12.2012 00:00:00

1 Zeile wurde ausgewählt.

SQL> exec sys.dba_weihnachten_proc;

PL/SQL-Prozedur erfolgreich abgeschlossen.

SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
RESOURCE
DBA
SELECT_CATALOG_ROLE
:

SQL> select count(*) from dba_tables;

  COUNT(*)
----------
      5276
Das ist einfach, aber doch sehr mächtig - es ist natürlich wesentlich mehr möglich, als ein einfacher Check auf "Weihnachten". So kann man aus sich mit der Funktion SYS_CONTEXT jede Menge Umgebungsinformationen holen. Mehr zum Thema findet Ihr in der Dokumentation.
When it is about assigning roles to a database user, secure application roles can be very useful. Basically, a secure application role is a normal role - with other roles and privileges assigned to it. The special bit is, that the secure application role is being activated by a procedure only and not by the SET ROLE command. This procedure now can check the environment and activate the role only, when certain requirements are met. Secure Application Roles are only available in the Enterprise Edition of the Oracle Database - you cannot use them in Standard Edition or OracleXE.
Creating a Secure Application Role is very simple. Note that the procedure which will activate the role (IDENTIFIED USING), does not need to exist at this time.
create role dba_an_weihnachten identified using sys.dba_weihnachten_proc
/
Granting privileges or other roles to the new Secure Application Role works similar to "plain" roles.
grant dba to dba_an_weihnachten
/
In SCOTT's session, the SESSION_ROLES view looks this this.
SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
RESOURCE

2 rows selected.
SET ROLE does not work ...
SQL> set role dba_an_weihnachten;
set role dba_an_weihnachten
*
ERROR at line 1:
ORA-28201: Not enough privileges to enable application role
'DBA_AN_WEIHNACHTEN'
The reason is, that this role is a Secure Application Role and can only be activated by the procedure SYS.DBA_WEIHNACHTEN_PROC named in the CREATE ROLE statement. So let's create the procedure in the SYS schema as follows ...
create or replace procedure sys.dba_weihnachten_proc authid current_user is
begin
  if extract(DAY SELECT_CATALOG_ROLEfrom sysdate) in (24,25,26) and extract(MONTH from sysdate) = 12 then
    dbms_session.set_role(
      role_cmd => 'DBA_AN_WEIHNACHTEN'
    );
  else
    raise_application_error(-20000, 'IT'S NOT CHRISTMAS TIME!');
  end if;
end;
/
sho err
It's important to create the procedure with the AUTHID CURRENT_USER clause. In a AUTHID DEFINER procedure, all roles would be disabled. In this example, the procedure does not do much - it checks the current date - and when it's christmas, the Secure Application Role is being activated, otherwise an error message is being thrown. Don't forget to grant the EXECUTE privilege ...
grant execute on sys.dba_weihnachten_proc to scott
/
Now log on as SCOTT , review SESSION_ROLES again and then try to activate the role ...
SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
RESOURCE

2 rows selected.

SQL> exec sys.dba_an_weihnachten;
BEGIN sys.dba_an_weihnachten; END;

*
ERROR at line 1:
ORA-20000: IT'S NOT CHRISTMAS TIME!
ORA-06512: at "SYS.DBA_AN_WEIHNACHTEN", line 8
ORA-06512: at line 1
It works as designed: It's not christmas, so no DBA privilege ;-) But once a year SCOTT can login and do this ...
SQL> select sysdate from dual;

SYSDATE
-------------------
24.12.2012 00:00:00

1 row selected.

SQL> exec sys.dba_weihnachten_proc;

PL/SQL procedure successfully completed.

SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
RESOURCE
DBA
SELECT_CATALOG_ROLE
:

SQL> select count(*) from dba_tables;

  COUNT(*)
----------
      5276
Secure Application Roles are pretty easy - but powerful. Of course, we can do much more intelligent things than checking whether it is christmas time. Using the SYS_CONTEXT function, environment information can be used to do the checking. More about Secure Application Roles can be found in the Dokumentation.

Kommentare:

ruepprich hat gesagt…

Tolle Idee. Schade das es Scott in den USA nicht so gut geht. Da kann er leider nur am 25. zum DBA werden. ;)

Josch hat gesagt…

Mir ist gerade folgendes Problem aufgefallen: ein SET ROLE dba_an_weihnachten; wird zwar verhindert, aber auf meiner DB kann ich jetzt ein SET ROLE DBA; erfolgreich ausführen!

Carsten Czarski hat gesagt…

Hallo Josch,

habe den Setup gerade nochmal getestet. Ich kann (als SCOTT) das SET ROLE DBA nicht ausführen. Es kommt ein

ORA-01924: Rolle 'DBA' wurde nicht gewährt oder ist nicht vorhanden

Insofern funktioniert es bei mir (11.2.0.3) wie es soll.

Beste Grüße

-Carsten

Josch hat gesagt…

Danke für deine Rückmeldung. Ich habe es nochmal überprüft, und mein Fehler war das Grant der "secure role" an den User. In der Oracle Doku (Secure Application Roles 10.2) steht ein Hinweis, der mich auf die falsche Fährte gelockt hat: "Immediately after granting such a role to a user, issue an ALTER USER statement with the clause DEFAULT ROLE ALL EXCEPT role, substituting the application role for role." Aus diesem Grund dachte ich, ein Grant von dba_an_weihnachten den User mit nachfolgender Änderung der Default Rollen sei empfohlen. Ob dies nur ein Verhalten von Version 10.2.0.3. kann ich leider nicht überprüfen.
Grüße Josch

MaikR hat gesagt…

Hallo Carsten,
der Thread ist zwar schon ein bißchen alt, aber ja immer noch aktuell. Bist du dir sicher, dass SecureApplicationRole nur für die EE zugelassen ist? Ich finde in der Doku dazu keine Einschränkung!
Maik

Carsten Czarski hat gesagt…

Hallo Maik,

in der Tat habe ich im Licensing Guide nichts mehr gefunden, dass das Feature die Enterprise Edition erfordert - und wenn ein Feature nicht im Licensing Guide erwähnt wird, bedeutet das, dass es in der Standard Edition enthalten ist.

Es kann durchaus sein, dass das Feature von der Enterprise- in die Standard-Edition "gewandert" ist ... das kommt immer wieder mal vor. Ich habe das hierfür im Detail nicht verfolgt ...

Grüße

-Carsten

Beliebte Postings