Access Control Lists: Schutz vor Missbrauch mächtiger Datenbank-Packages
von Carsten Czarski / Heinz-Wilhelm Fabry, ORACLE Deutschland GmbH

UTL_SMTP, UTL_TCP, DBMS_LDAP und andere Packages, die auch schon länger im Lieferumfang der Datenbank enthalten sind, erlauben den einfachen Zugriff auf andere Server direkt aus der Datenbank. Die Packages sind überwiegend für den Benutzer PUBLIC zur Ausführung freigegeben.

Natürlich ist das bei Bedarf ausgesprochen hilfreich, aber andererseits stellt sowohl die allgemeine als auch die uneingeschränkte Verfügbarkeit ein erhebliches Sicherheitsrisiko dar: Jede Person, die mit den Packages umgehen kann, hat die Möglichkeit, Daten, auf die sie Zugriff hat, z.B. problemlos an einen Server ausserhalb des eigenen Unternehmens zu schicken. Um dieses Sicherheitsrisiko zu eliminieren, ist die Funktionalität der betroffenen Packages in Oracle11g so modifiziert worden, dass der Zugriff auf andere Server erst nach einer ausdrücklichen Freigabe erfolgen kann.

An dieser Stelle ein wichtiger Hinweis für alle, die z.B. in Oracle10g die Packages bereits verwenden: Anwendungen, die auf Oracle11g migriert werden und die auf die o.g. Packages zugreifen, funktionieren erst dann wieder einwandfrei, wenn die dafür nötigen und im folgenden Tipp beschriebenen Einstellungen vorgenommen sind.

Die Freigabe erfolgt über sogenannte Access Control Lists (ACLs). Diese Listen sind wiederum nur dann verfügbar, wenn Oracle XML DB installiert ist. Auch aus diesem Grund ist XML DB Bestandteil jeder Standardinstallation und sollte natürlich auch bei angepassten Installationen in der Regel installiert werden.

Die Access Control Lists werden über den Aufruf von Packages erstellt und bearbeitet. In diesem Tipp erfahren Sie, wie Sie die Listen nutzen und überwachen. Die Beispiele werden anhand des Oracle-Werkzeugs Application Express dargestellt. Dazu werden die SQL-Kommandos in einem normal erzeugten Workspace im SQL Workshop abgesetzt. Bis auf das in Abbildung 2 dargestellte Beispiel können jedoch alle Kommandos mit dem gleichen Ergebnis z.B. auch aus SQL*Plus oder aus dem kostenlosen SQL*Developer abgesetzt werden.

Wie bereits festgestellt sind nach der Installation in Oracle11g noch keine Access Control Lists vorhanden. Trotz vorhandener EXECUTE-Privilegien für die betroffenen Packages sind deshalb keine Netzwerkaktivitäten möglich. Dies erkennt man am Ergebnis der folgenden Abfrage

select httpuritype('http://localhost:8080/i/').getclob() from dual

Das Kommando ruft das Image-Verzeichnis von Application Express ab (es wird davon ausgegangen, dass das PL/SQL Embedded Gateway mit dem Port 8080 verwendet wird; andere URLs sind analog möglich). Abbildung 1 zeigt das Ergebnis in einer Oracle11g-Datenbank.

Versuch eines Netzwerkzugriffs (HTTP) in Oracle11g

Abbildung 1: Versuch eines Netzwerkzugriffs (HTTP) in Oracle11g

Die Fehlermeldung besagt, dass der Zugriffsversuch durch die Access Control List abgelehnt wurde. Nun geht es also zunächst darum, diesen Zugriff zu ermöglichen. Gesteuert werden die Listen mit dem PL/SQL-Paket DBMS_NETWORK_ACL_ADMIN. Das folgende PL/SQL-Skript gibt im letzten Schritt den Zugriff ausschließlich für die oben angesprochene URL 'LOCALHOST:8080' frei

begin
  if dbms_db_version.ver_le_10_2 then
    null;
  else 
    begin
      dbms_network_acl_admin.drop_acl(
        acl =>         'apex-TEST-network.xml'
      );
    exception 
      when others then null-- ACL existiert noch nicht
    end;
    dbms_network_acl_admin.create_acl(
      acl =>         'apex-TEST-network.xml',
      description => 'Netzwerk-Connects von Workspace TEST',
      principal =>   'TESTIT'-- PARSING SCHEMA der Anwendung
      is_grant =>    true,
      privilege =>   'connect'
    );
    DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
      acl =>         'apex-TEST-network.xml',
      principal =>   'TESTIT'-- PARSING SCHEMA der Anwendung
      is_grant  =>   true,
      privilege =>   'resolve'
    );
    dbms_network_acl_admin.assign_acl(
      acl =>         'apex-TEST-network.xml',
      host =>        'localhost',
      lower_port =>  8080,
      upper_port =>  8080
    );
  end if;
end;
/
show error
    
commit
/

Starten Sie das Skript als Datenbanknutzer mit DBA-Privilegien z.B. als Benutzer SYSTEM. Anschließend versuchen Sie das erste SQL-Kommando nochmals (Abbildung 2).

Durch ACL erlaubter Netzwerkzugriff

Abbildung 2: Durch ACL erlaubter Netzwerkzugriff

ACHTUNG: Diese Netwerk-ACL's gelten auch für die Application Express-Umgebung, also für das Schema FLOWS_030000. Um bspw. den Mailversand auch in Oracle11g bereitzustellen, müssen Sie eine entsprechende ACL für den User FLOWS_030000 einrichten.

Man sieht, dass der Netzwerkzugriff funktioniert. Wenn Sie nun einen anderen URL eingeben oder den Port von 8080 auf einen anderen ändern, erhalten Sie sofort wieder die Fehlermeldung, dass der Zugriff durch die ACL abgelehnt wurde. Man sieht daran, dass der DBA die Netzwerkprivilegien nun sehr fein granular und passend zu den Anforderungen einer Applikation setzen kann.

Normalerweise werden stets die Privilegien connect und resolve benötigt. resolve dient zur Auflösung von Rechnernamen in IP-Adressen, verwendet man also keine Rechnernamen, sondern nur IP-Adressen, ist resolve nicht unbedingt nötig.

Es ist allerdings kein Muss, die Privilegien feingranular zu vergeben. Lässt man im Aufruf von DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL die Parameter lower_port und upper_port weg, so sind für diesen Host alle Ports erlaubt. Beim Hostnamen können Wildcards verwendet werden. So steht der Hostname *.oracle.com für alle Rechner der Domain oracle.com. Der Stern alleine steht für das gesamte Netzwerk. Somit stellt die folgende ACL das Verhalten der Oracle10g-Datenbank wieder her, indem es allen Nutzern (PUBLIC) Privilegien für das gesamte Netzwerk einräumt - für produktive Systeme ist dies selbstverständlich absolut NICHT zu empfehlen.

begin
  if dbms_db_version.ver_le_10_2 then
    null;
  else 
    begin
      dbms_network_acl_admin.drop_acl(
        acl =>         'all-network-PUBLIC.xml'
      );
    exception 
      when others then null; 
    end;
    dbms_network_acl_admin.create_acl(
      acl =>         'all-network-PUBLIC.xml',
      description => 'Netzwerk-Connects fuer ALLE',
      principal =>   'PUBLIC',
      is_grant =>    true,
      privilege =>   'connect'
    );
    DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
      acl =>         'all-network-PUBLIC.xml',
      principal =>   'PUBLIC', 
      is_grant  =>   true,
      privilege =>   'resolve'
    );
    dbms_network_acl_admin.assign_acl(
      acl =>         'all-network-PUBLIC.xml',
      host =>        '*'
    );
  end if;
end;
/
show error
    
commit
/

Die View USER_NETWORK_ACL_PRIVILEGES gibt dem aktuellen Benutzer Auskünft über die vorhandenen Privilegien.

Vorhandene Netzwerkprivilegien abfragen

Abbildung 3: Vorhandene Netzwerkprivilegien abfragen

Natürlich gibt es auch die View DBA_NETWORK_ACL_PRIVILEGES, die dem DBA eine umfassende Auskunft über die eingerichteten ACLs und ihre Nutzer gibt.

Nun kann es in der Praxis vorkommen, dass mehrere ACLs zusammenkommen - eine ACL könnte der Rolle NETWORK Zugriffe auf alle Rechner der Domain oracle.com zuweisen. Eine zweite könnte dem User SCOTT den Zugriff auf geheim.oracle.com einräumen. Mit dem folgenden Kommando kann man feststellen, ob der Zugriff auf einen Server (bspw. www.oracle.com) möglich ist

SELECT 
  column_value, 
  lower_port, 
  upper_port, 
  privilege,
  status
FROM 
  user_network_acl_privileges, 
  TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.oracle.com'))
ORDER BY 
  DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(column_value) desc, 
  lower_port,                                              
  upper_port
Netzwerkprivilegien feststellen

Abbildung 4: Netzwerkprivilegien feststellen

Die Abfrage in Abbildung 4 gibt die Netzwerkprivilegien ausgehend von einem bestimmten Rechnernamen für die gesamte Domain und alle Unterdomains wieder - sie eignet sich so recht gut zum Untersuchen von Zugriffsproblemen. Übrigens: Die Funktion DBMS_NETWORK_ACL_UTILITY.DOMAINS löst einen Rechnernamen in seine Namens-Bestandteile (Rechnername, Domain, Top-Level-Domain) auf - das ist vielleicht auch an anderer Stelle recht nützlich.

Nach Einrichten der entsprechenden ACL steht die Netzwerkfunktionalität in Oracle11g wieder wie gewohnt zur Verfügung. Da die Privilegien nun wesentlich feingranularer vergeben werden können, fällt es dem DBA vielleicht sogar leichter, Netzwerkzugriffe zu erlauben.



Zurück zur Community-Seite