IF DV GmbH. Oracle Security. Seminarunterlage

Transkript

1 Oracle Security Seminarunterlage

2 2 ORACLE SECURITY Impressum Version: 1.01 DID: ORA_SEC Autoren: Jörg Fritze Gabriel Sommer Herausgeber: Alte Straße 65 D Dortmund Telefon: Telefax: Internet: Wichtiger Hinweis Diese Seminarunterlage wurde mit größter Sorgfalt erstellt. Trotzdem können wir Fehler nicht völlig ausschließen und können deshalb für fehlerhafte Angaben und deren Folgen keine Haftung übernehmen. Bitte geben Sie uns Hinweise zu Fehlern unter der oben angegebenen Telefonnummer oder -Adresse. Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung auf Datenverarbeitungsanlagen bleiben auch bei nur auszugsweiser Verwendung vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen der Bundesrepublik Deutschland mit Genehmigung des Urhebers zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtgesetzes. Jörg Fritze, Dortmund 2010 Copyright 2010 by ID DV GmbH

3 Identifizierung und Authentisierung Zutrittskontrolle 2-17 Betriebssystem-authentifizierte Benutzer Alte Oracle-Hasen oder ehemalige VMS-Nutzer kennen diese Technik evtl. noch unter dem Begriff "OPS$-User", weil Oracle aus historischen Gründen einen Präfix namens "OPS$" für Betriebssystembenutzer festlegt. Dies hat zwar einen nostalgischen Reiz, ist jedoch sicherheitstechnisch unelegant. Durch folgenden Befehl kann dann nämlich sehr einfach erkannt werden, welche Benutzer nicht in Oracle sondern nur über das Betriebssystem überprüft werden: SELECT username, account_status FROM dba_users WHERE username LIKE 'OPS$%' ; Aber zunächst zur Syntax; man legt einen entsprechenden Benutzer wie folgt an: CREATE USER name IDENTIFIED EXTERNALLY; Copyright 2010 by Existiert ein BS-Benutzer name, so kann dieser sich ohne Angabe von Benutzer oder Passwort an Oracle anmelden. Voreingestellt ist hier (zum Glück) nur eine lokale Login-Erlaubnis. Sollen auch entfernte Zugriffe erlaubt werden, muss der Oracle-Systemparameter REMOTE_OS_AUTHENT auf TRUE gesetzt werden.

4 2-18 Identifizierung und Authentisierung Zutrittskontrolle Vorteile BS-Benutzer Authentisierung: Benutzer haben einen bequemeren Zugang zur DB und brauchen sich keine weiteren Passworte zu merken lokale Batch-Programme benötigen keine Login-Anweisungen mit fest kodierten Passwörtern Nachteile: Die DB-Schutzschicht geht verloren, insbesondere bei Fernzugriffen (Remote Login's) ist dies sehr gefährlich! Jeder BS-Benutzer kann immer nur mit genau einem DB- Benutzer verbunden werden. Copyright 2010 by ID DV GmbH

5 Identifizierung und Authentisierung Zutrittskontrolle 2-21 Jetzt kann ein Wallet im obigen Verzeichnis angelegt werden: C:/>mkstore -wrl "C:/oracle/product/10.2.0/db_1/NETWORK/ADMIN" -create Wallet-Kennwort eingeben Wallet-Kewnnwort erneut eingeben Nun legen wir einen Eintrag im Wallet an: C:/>mkstore -wrl "C:/oracle/product/10.2.0/db_1/NETWORK/ADMIN" -createcredential jf10 pwstore tresor Wallet-Kennwort eingeben Create credential oracle.security.client.connect_string1 Den Eintrag prüfen: C:/>mkstore -wrl "C:/oracle/product/10.2.0/db_1/NETWORK/ADMIN" -listcredential Wallet-Kennwort eingeben List credential (index: connect_string username) 1: jf10 pwstore Jetzt ist ein Login ohne Eingabe von Benutzernamen/Passwort möglich: Copyright 2010 by C:/>sqlplus SQL*Plus: Release Production on Fr Jan 23 14:07: Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

6 2-22 Identifizierung und Authentisierung Zutrittskontrolle Verbunden mit: Oracle Database 10g Production SQL> select user from dual; USER PWSTORE Um das PW eines Benutzereintrags zu wechseln, schreibt man: mkstore -wrl <wallet_location> -modifycredential <db_alias> <username> <password> So wird ein Eintrag gelöscht: mkstore -wrl <wallet_location> -deletecredential <db_alias> Auf DB-Ebene kann man (leider?) nicht erkennen, ob ein Login per "Client-Wallet" = "externem PW-Speicher" erfolgt ist: SQL> SELECT sys_context('userenv', 'authentication_method') 2 "Login-Methode" FROM dual; Login-Methode PASSWORD Copyright 2010 by ID DV GmbH

7 Identifizierung und Authentisierung Zutrittskontrolle 2-23 Nicht jedes Werkzeug unterstützt diese "Login-Automatik", problemlos geht es z.b. bei: SQL*PLUS RMAN TOAD PL/SQL Developer Ein Passwort-Wallet ist selbstverständlich nicht mit der für DBA- Sonderfunktionen notwendigen Passwort-Datei zu verwechseln. Diese wird mittels "orapwd" erstellt und z.b. mit Hilfe des SQL-Befehls GRANT SYSDBA TO benutzer; Copyright 2010 by mit entsprechend privilegierten Benutzern gefüllt. Eine Liste dieser Benutzer (also quasi den Inhalt der Passwort-Datei) erhält man mit SELECT * FROM v$pwfile_users;

8 2-24 Identifizierung und Authentisierung Zutrittskontrolle Web User authentifizieren (Proxy) Die Kommunikation eines Clients mit einer Datenbank gestaltet sich in den ja heute üblichen Mehrschichtarchitekturen durchaus etwas komplizierter als bei einer reinen Client-/(DB)-Server Lösung. Grundsätzlich lässt sich der Begriff "Proxy" in diesem Zusammenhang mit "Stellvertreter" übersetzen. Zwischen Mittelschicht/Applikationsserver und Datenbankserver wird eine Verbindung aufgebaut, auf die der eigentliche Client dann zugreifen kann. Bei der für die Verbindungsnutzung können zwei Varianten unterschieden werden: a) ohne Client-Kontext/Authentifizierung b) mit Client-Kontext/Authentifizierung Im Fall A wird vom Client nur ein Benutzername verlangt; da der Proxy-Benutzer ja bereits mit der Datenbank verbunden ist, kann der applikatorische Client diese Variante nutzen ohne ein Passwort angeben oder sich auf andere Art authentisieren zu müssen. Dies Variante hat sicher diverse Nachteile; z.b. stehen jedem Benutzer ja prinzipiell alle Privilegien des zentralen DB-Benutzers zur Verfügung. Etwaige Einschränkungen müssen im Applikationscode verwaltet werden. Im Fall B wird der Client von der Mittelschicht über eine beliebige Methode authentifiziert. Die Mittelschicht authentifiziert sich nun gegenüber der Datenbank (mit fest verdrahtetem Passwort oder kennwortlosem Verfahren) über den Proxy-Benutzer, liefert aber (jetzt kommt der entscheidende Unterschied!) den Client-Kontext mit in die Datenbank. Dieser Kontext (Client Identifier) kann nun dazu dienen unterschiedliche Zugriffsrechte mit Hilfe entsprechender "Applikations-Rollen" (s. Kap. 3 Benutzer und Rollen) zu setzen. Diese Methode besitzt also gegenüber dem obigen Fall A zwei grundsätzliche Vorteile: Copyright 2010 by ID DV GmbH

9 Identifizierung und Authentisierung Zutrittskontrolle 2-27 Kurzdefinition PKI Mit Public-Key-Infrastruktur (PKI, engl. public key infrastructure) bezeichnet man in der Kryptologie ein System, welches es ermöglicht, digitale Zertifikate auszustellen, zu verteilen und zu prüfen. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Absicherung rechnergestützter Kommunikation verwendet. Mit Hilfe eines asymmetrischen Kryptosystems können Nachrichten in einem Netzwerk digital signiert und verschlüsselt werden. Sichere Kryptosysteme können bei geeigneter Wahl der Parameter (z. B. der Schlüssellänge) auch bei Kenntnis des Verfahrens nicht in überschaubarer Zeit gebrochen werden. Für jede verschlüsselte Übermittlung benötigt der Sender allerdings den öffentlichen Schlüssel (Public-Key) des Empfängers. Dieser könnte z. B. per versendet oder von einer Web- Seite heruntergeladen werden. Es muss jedoch sichergestellt werden, dass es sich tatsächlich um den Schlüssel des Empfängers handelt und nicht um die Fälschung eines Betrügers. Hierzu dienen nun digitale Zertifikate, welche die Authentizität eines öffentlichen Schlüssels und seinen zulässigen Anwendungs- und Geltungsbereich bestätigen. Das digitale Zertifikat ist selbst durch eine digitale Signatur geschützt, deren Echtheit mit dem öffentlichen Schlüssel des Ausstellers des Zertifikates geprüft werden kann. Um die Authentizität des Ausstellerschlüssels zu prüfen, wird wiederum ein digitales Zertifikat benötigt. Auf diese Weise lässt sich eine Kette von digitalen Zertifikaten aufbauen, die jeweils die Authentizität des öffentlichen Schlüssels bestätigen, mit dem das vorhergehende Zertifikat geprüft werden kann. Eine solche Kette von Zertifikaten wird Validierungspfad oder Zertifizierungspfad genannt. Auf die Echtheit des letzten Zertifikates (und des durch diesen zertifizierten Schlüssels) müssen sich die Kommunikationspartner aber ohne ein weiteres Zertifikat verlassen können. Quelle: Wikipedia Kurzdefinition LDAP (Lightweight Directory Access Protocol) Copyright 2010 by Ein LDAP-Server stellt Informationen über Benutzer und deren Gruppenzugehörigkeit bereit. Aber auch andere Objekte wie zum Beispiel die Zertifikate eines Computers können in einem solchen Verzeichnis gespeichert werden. Beispiele für LDAP-Server sind: IBM Lotus Notes Microsoft Active Directory Oracle Internet Directory

10 2-28 Identifizierung und Authentisierung Zutrittskontrolle DB-Links Datenbank-Links sind aus Datenschutzsicht ebenfalls erwähnenswert. Man unterscheidet ja private und öffentlich zugängige ('public') Datenbank-Links. Die Eigenschaft "privat" erlaubt nur dem Link-Ersteller den Zugriff, ein öffentlicher DB-Link (per "create public database link " erstellt) darf von jedem DB-Nutzer verwendet werden. DB-Links können neben dem Verweis auf die anzusprechende Datenbank auch Benutzernamen und Passwort und damit explizite Authentikationseigenschaften enthalten. Fehlen diese, so gilt ein impliziter Login-Wunsch mit dem aktuellen Benutzernamen und passwort. Die folgende Tabelle zeigt den Benutzerzugriff per Datenbank-Link: Link-Typ Expl. authentisiert Zugriff private nein Benutzername und passwort der aktuellen Sitzung => die beiden zu verbindenden Datenbanken benötigen synchronisierte Benutzer und Passwörter private ja Benutzername und passwort für den Zugriff auf die Ziel-DB werden der Link-Definition entnommen und ist daher fix. public nein Wie beim privaten Link, jedoch kann dieser Link von jedem DB-Benutzer eingesetzt werden die Verbindung ist benutzerspezifisch public ja Wie beim privaten Link, jedoch kann dieser Link von jedem DB-Benutzer eingesetzt werden die Verbindung ist statisch Link-Informationen (insbesondere Benutzernamen und passwörter werden in der Datenbank abgelegt; achten Sie also bitte darauf, dass folgende Tabellen nicht allgemein zugreifbar sind: DBA_DB_LINKS V$DB_LINK SYS.LINK$ (! enthält Passworte - bis 10.1 unverschlüsselt) Copyright 2010 by ID DV GmbH

11 Autorisierung Datenzugriffskontrolle ad 3. (evtl. Fehler in UDUMP) conn -- Arbeitszeit SQL> select to_char(sysdate, 'HH24:MI') zeit from dual; ZEIT :08 SQL> select * from dummy; I und nach Feierabend... => SQL> select to_char(sysdate, 'HH24:MI') zeit from dual; ZEIT :08 SQL> select * from dummy; Es wurden keine Zeilen ausgewählt Copyright 2010 by -- aber als SYS!!! conn sys/hochgeheim_a644@testdb as sysdba SQL> select to_char(sysdate, 'HH24:MI') zeit from dual; ZEIT :09 SQL> select * from dummy;

12 3-18 Autorisierung Datenzugriffskontrolle I EINSATZBEREICHE Bei Anwendungen mit besonders hohen Geheimhaltungs- oder Datenschutzanforderungen, wie etwa im medizinischen Bereich Für Hosting-Anwendungen, wo eine strikte Trennung der Daten verschiedener Kunden gewährleistet sein muss, also zur transparenten Bildung einer Mandantenfähigkeit Ein Hacker kann mit folgendem Befehl die komplette VPD- Sicherheits-schicht umgehen (selbst in Oracle 11.2): grant exempt access policy to public; ZUGRIFFSPROBLEME BEI VPD Falls eine Policy-Funktion fehlschlägt, kann ein Benutzer nicht auf die geschützten Objekte zugreifen (ungewollter Datenschutz ;-) ). Die Auftrittswahrscheinlichkeit dieser Problematik steigt mit der Komplexität der Funktion. Es gibt zwei Hauptgründe für einen Policy-Fehler: Die Policy-Funktion ist ungültig (Status: INVALID) und wird nicht rekompiliert/ausgeführt. Das kann z.b. passieren, falls eine Zieltabelle Copyright 2010 by ID DV GmbH

13 Zugriffsüberwachung 4-9 Hierzu zählen Aktionen, die unter Nutzung der folgenden Privilegien durchgeführt werden: ALTER ANY PROCEDURE CREATE ANY JOB DROP ANY TABLE ALTER ANY TABLE CREATE ANY LIBRARY DROP PROFILEE ALTER DATABASE CREATE ANY PROCEDURE DROP USER ALTER PROFILE CREATE ANY TABLE EXEMPT ACCESS POLICY AUDIT ROLE BY ACCESS CREATE EXTERNAL JOB GRANT ANY OBJECT PRIVILEGE ALTER SYSTEM CREATE PUBLIC DATABASE LINK GRANT ANY PRIVILEGE ALTER USER CREATE SESSION GRANT ANY ROLE ALTER SYSTEM CREATE USER AUDIT SYSTEM BY ACCESS DROP ANY PROCEDURE Was aus Gründen der Sicherheit eine gute Maßnahme darstellt, kann sich allerdings schnell zum Problem entwickeln, da es keinen Automatismus für das Löschen der Audit-Daten in der Audit-Tabelle (AUD$) gibt. Die Tabelle wird schnell zunehmend größer, was je nach Konfiguration bis zum Stillstand der Instanz führen kann. Die Tabelle sollte also in einen dedizierten Tablespace gelegt und die entstandenen Audit-Daten regelmäßig verarbeitet werden. In älteren Oracle-Versionen gab es keinen Standardweg, um AUDIT- Ergebnisse (AUD$, FGA_LOG$) in einem anderen Tablespace als SYS- TEM (evtl. sogar in getrennten Zielen) abzulegen. Oracle kennt ein Paket namens DBMS_AUDIT_MGMT, welches die AUDIT-Verwaltung vereinfacht. Nun können Audit-Tabellen in andere Tablespaces verschoben werden. Ab Oracle 11.2 erlaubt das Paket zusätzlich die automatisierte Löschung alter AUDIT-Einträge durch die Prozedur CLEAN_AUDIT_TRAIL. Copyright 2010 by Fragen Sie Ihren Referenten bei Bedarf nach weiteren Details oder Beispielen (audit_verwaltung.txt) Es empfiehlt sich außerdem, die obigen Audit-Einstellungen zu überprüfen und ggf. an die eigenen Bedürfnisse anzupassen; einige sind gewiss zu viel des Guten (z. B. CREATE SESSION...WHENEVER SUCCESSFUL), andere könnten sicherlich noch hinzugefügt werden.

14 4-10 Zugriffsüberwachung Trigger basiertes Auditing Neben dem AUDIT-Kommando gibt es noch weitere Möglichkeiten, Zugriffe auf Objekte oder auch bereits Login-Vorgänge zu protokollieren. Je nach Audit-Wunsch können verschiedene Triggerarten eingesetzt werden: INSERT, UPDATE, DELETE (DML-Objekttrigger) SELECT (FINE GRAINED AUDITING, s. nä. Kapitel) DDL-Kommandos (Schema-Trigger) Sitzung starten (ebenfalls Schema-Trigger) DB-Start /-Stop (System-Trigger) ORA-Fehlermeldung (ebenfalls System-Trigger) Einige Beispiele: -- DML-Objektzugriff CREATE TRIGGER Auftrag_aud_tr AFTER INSERT OR UPDATE OR DELETE ON auftrag FOR EACH ROW DECLARE operation VARCHAR2(20); BEGIN IF INSERTING THEN operation := Eingefügt ; ELSIF UPDATING THEN operation := Geändert ; ELSE operation := Gelöscht ; END IF; INSERT INTO protokoll( aktion, benutzer, zeitpunkt,nummer_alt, nummer_neu ) VALUES (operation, USER, SYSDATE, :OLD.auftrnr, :NEW.auftrnr ); END; / Copyright 2010 by ID DV GmbH

15 Zugriffsüberwachung 4-11 Copyright 2010 by -- Systemtrigger zur Fehlerprotokollierung CREATE OR REPLACE TRIGGER se_irf_tr AFTER SERVERERROR ON DATABASE BEGIN IF Ora_Server_Error(1) IN (1536,1562,1631) OR Ora_Server_Error(1) BETWEEN 1650 AND 1659 THEN irf_mail.sendmail( NULL, Server-Fehler aufgetreten!, Achtung: Der Fehler ora_server_error(1) ist bei der Datenbank ora_database_name für den Benutzer ora_login_user entdeckt worden! Offensichtlich liegt ein Plattenplatzproblem vor. ); END IF; END; /

16 4-12 Zugriffsüberwachung Fine Grained Auditing Bisher beschränkte sich der Audit-Zugriff auf minimal ein Objekt (z.b. eine Tabelle). Evtl. sollen aber nur bei bestimmten Selektionen oder Projektionen Audit-Sätze angelegt werden. Hier hilft "feines Auditieren" (FGA) weiter. Ergebnisse werden in DBA_FGA_AUDIT_TRAIL (oder ab V10 auch in DBA_COMMON_AUDIT_TRAIL) geschrieben. Neben dem Namen des zu beobachtenden Objekts können eine Prüffunktion, eine Selektionsbedingung, eine Projektionsbedingung und (ab V10) auch DML-Typen angegeben werden. -- Zugriffe auf DUMMY-Tabelle außerhalb der Arbeitszeit werden protokolliert Aufräumen benötigte Rechte Funktion anlegen Policy anlegen ("nur" Prüffunktion übergeben) Zugriffstest -- ad 0. drop table fritze.dummy; exec DBMS_fga.drop_policy(object_schema => 'FRITZE', object_name => 'DUMMY', policy_name => 'BSP_POL') create table fritze.dummy(i number); insert into fritze.dummy values(10); insert into fritze.dummy values(42); commit; -- ad 1. GRANT EXECUTE ON DBMS_fga TO fritze; -- ad 2. create or replace function tagsueber return NUMBER is begin if to_number(to_char(sysdate, 'HH24')) between 8 and 17 then return 1; else return 0; end if; Copyright 2010 by ID DV GmbH

17 Datenübertragung Netzwerksicherheit 5-1 Copyright 2010 by 5 Datenübertragung Netzwerksicherheit

18 5-2 Datenübertragung Netzwerksicherheit Listener Der Listener ist das Ohr der Datenbank zur Außenwelt. Wenn ein Client eine Anfrage an die Datenbank stellen möchte, nimmt er Kontakt mit dem Listener auf, der nun seinerseits einen Serverprozess startet und dessen Adresse (bzw. die Dispatcher-Adresse bei MTS- Konfiguration) an den Client zurück gibt. Hierüber läuft dann die Kommunikation. Naturgemäß sind Listener beliebte Angriffsziele. Um den Angriff deutlich zu erschweren, gilt es zunächst einmal einige Basisschutzmaßnahmen zu treffen: Alle Verzeichnisse mit Listener-Konfigurationsdateien (auf Serverund auf Clientseite) sind gegen unberechtigten Zugriff zu schützen. Setzen bzw. entziehen Sie also entsprechende Dateizugriffsrechte auf BS-Ebene. Entsprechendes gilt für den Zugriff auf die Listerspezifischen Programme TNSLSNR und LSNRCTL im Oracle/Bin Verzeichnis! Änderung der allseits bekannten Standardportadressen 1521/1526 etc. Eine komplette Liste dieser Ports sowie die notwendigen Änderungsmaßnahmen finden Sie hier Anmerkung: Zur Änderung von Default Ports s. auch Metalink Note ID Spielen Sie aktuelle Listener-Security Patches ein! Begrenzen Sie SQL*NET Zugriffe von "jenseits der Firewall" auf das unbedingt nötige Maß, d.h. auf bekannte Absender (z.b. Web-Server), Applikationen an spezifizierte DB-Server als Adressaten. Listener-Konfigurationsänderungen dürfen nicht unberechtigt durchgeführt werden, da sonst z.b. ein Trace aktiviert werden oder der Listener einfach heruntergefahren werden kann (DoS-Attacke). Vergeben Sie hierzu ein Passwort mittels LSNRCTL (Kommando change_password) oder behalten Sie die Voreinstellung (ab Oracle 10.1) "lokale Listener-Administration" (LOAL_OS_AUTHENTICATION_<listener> = ON in LISTENER.ORA). Vor Oracle 10 wird z.b. nicht geprüft, ob der Copyright 2010 by ID DV GmbH

19 Datenübertragung Netzwerksicherheit 5-3 LSNRCTL-Aufrufer zur lokalen DBA-Gruppe gehört. Falls organisatorisch annehmbar sollten Sie falls Sie Remote- Administration benötigen diese im laufenden Betrieb verbieten. Der Eintrag in listener.ora: ADMIN_RESTRICTIONS_LISTENER=ON erledigt dies. Falls fachlich möglich, sollten Sie die Möglichkeit nutzen, SQL*NET Zugriffe (per TCP/IP) auf spezielle Clients zu beschränken. Sie können wahlweise angeben, welche Maschinen Sie zulassen oder ausschließen wollen. Tragen Sie in SQLNET.ORA folgendes ein: TCP.VALIDNODE_CHECKINH=YES TCP.INCLUDED_NOTES=( ) bzw. TCP.EXCLUDED_NOTES=( ) Um überwachen zu können, ob evtl. jemand versucht das Listener Passwort zu erraten (z.b. per Brute Force Attacke) sollte "Listener Logging" aktiviert werden (mit LSNRCTL: Kommandos set log_directory, set log_file, set log_status). Nun können Sie Rateversuche durch die Meldung TNS entdecken. KONTROLLE DER NETZWERKZUGRIFFE AUS DER DATENBANK MIT ACL'S In der Oracle Datenbank existieren bereits seit längerer Zeit eine Reihe von PL/SQL Paketen, mit deren Hilfe Informationen aus der Datenbank heraus an beliebige, im Netzwerk erreichbare Server geschickt werden können. Zu diesen Netzwerk -Paketen zählen: Copyright 2010 by UTL_TCP UTL_SMTP UTL_MAIL UTL_HTTP UTL_INADDR Diese Pakete sind bis Oracle 10g durch das EXECUTE-Privileg, das standardmäßig an PUBLIC(!) vergeben ist, zur Ausführung freigegeben. Diese uneingeschränkte und allgemeingültige Zugriffsmöglichkeit auf

20 5-4 Datenübertragung Netzwerksicherheit das gesamte Netzwerk mag praktisch erscheinen, stellt aber ein erhebliches Sicherheitsrisiko dar. Hier liefert Oracle ab Version 11.1 ein neues Sicherheitskonzept: Netzwerkzugriffe, die durch PL/SQL-Pakete erfolgen, müssen vom DBA sowohl für die einzelnen Ziele als auch für die einzelnen Benutzer bzw. Rollen separat freigegeben werden. Diese Freigabe erfolgt über so genannte Access Control Listen (ACL's). Programmtechnisch werden die ACLs als XML-Dokumente mit dem neuen Paket DBMS_NETWORK_ACL_ADMIN erzeugt und verwaltet. ACL-Bsp. -- ACL anlegen BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'test_acl.xml', description => 'Netzwerkzugriff für UTL-Pakete bzgl. Benutzer TEST_ACL', principal => 'TEST_ACL' -- 'PUBLIC' für alle Benutzer is_grant => TRUE, privilege => 'resolve'); -- 'connect' oder 'resolve' möglich END; / -- ACL zuweisen BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'test_acl.xml', host => 'AS2.if-dv.de'); -- '*' für alle Hosts END; / commit; Folgende Systemtabellen liefern einen Überblick über ACL's und die dazugehörende Rechte: DBA_NETWORK_ACLS DBA_NETWORK_ACL_PRIVILEGES Copyright 2010 by ID DV GmbH Anmerkung zu ACL's: XDB muss in der Datenbank installiert sein!

21 Datenübertragung Netzwerksicherheit 5-7 "alter user tcra identified by tcra;" sieht jetzt z.b. so aus: [06-APR :22:20:187] nspsend: 6E 3C E8 AC A9 47 8F C0 n<...g.. [06-APR :22:20:187] nspsend: C1 98 7E DD F5 13..~.B... [06-APR :22:20:187] nspsend: D5 05 DD 36 7F C...6..f. [06-APR :22:20:187] nspsend: C2 1E E2 DF #...e. [06-APR :22:20:187] nspsend: B7 F0 24 CB DF C5 0E 3F..$...? [06-APR :22:20:187] nspsend: 3A D2 DA 79 3D D3 FD B3 :..y=... [06-APR :22:20:187] nspsend: 45 D6 0B 42 0D C7 74 F0 E..B..t. Beim Verschlüsselungsalgorithmus hat man die Qual der Wahl. Es folgt eine Übersicht über die möglichen Algorithmen und Schlüssellängen (Stand Oracle 11.1): Algorithmus Schlüssellängen Ab Oracle Version DES 40,56 8i AES 128, 192, RC4 40, 56, 128, 256 8i 3DES 112, Anmerkung: Verwenden Sie immer die stärkste Verschlüsselung, d. h. vor Oracle 10g 3DES168, danach AES256! Neben dem Algorithmus ist jetzt für Server und Client noch der Verschlüsselungstyp einzugeben. Folgende Einstellungen sind möglich: Copyright 2010 by Verschlüsselungstyp ACCEPTED REJECTED REQUESTED REQUIRED Bedeutung Default für Client&Server: Verschlüsselung wird angenommen, i aber nicht erzwungen Verweigert die Verschlüsselung Verschlüsselt falls möglich Erzwingt Verschlüsselung, kein unverschlüsselter Datenverkehr möglich Anmerkung: Der Server bestimmt sinnvollerweise die Verschlüsselung; hier ist mindestens REQUESTED, falls möglich REQUIRED zu setzen! Folgende Tabelle zeigt, bei welchen Kombinationen eine unverschlüsselte, verschlüsselte oder gar keine Kommunikation durchgeführt wird:

22 5-8 Datenübertragung Netzwerksicherheit Client (SERVER) REJECTED ACCEPTED REQUESTED REQUESTED REJECTED Klartext Klartext Klartext Keine Verbindung ACCEPTED Klartext Klartext (*) verschlüsselt verschlüsselt REQUESTED Klartext verschlüsselt verschlüsselt verschlüsselt REQUESTED Keine Verbindung verschlüsselt verschlüsselt verschlüsselt * Dies ist die Voreinstellung! Verschlüsselungsparameter setzen Wie vorhin im Beispiel gesehen, sind Algorithmus und Typ (sowie eine Zufallszeichenkette als Start) explizit in der Datei SQLNET.ORA einzutragen (es ginge auch grafisch mit dem Oracle Net Manager). sqlnet.crypto_seed="zufallszeichenfolge_mit_10_bis_70_zeichen" sqlnet.encryption_types_server=(algor., algor., ) sqlnet.encryption_server=verschlüsselungstyp sqlnet.encryption_types_client=(algor., algor., ) sqlnet.encryption_client=verschlüsselungstyp Nach diesen Einstellungen ist der Datenverkehr auch über folgende Protokolle/Schnittstellen verschlüsselt ODBC JDBCI (OCI="thick" Treiber) Copyright 2010 by ID DV GmbH

23 Datenübertragung Netzwerksicherheit 5-9 Leider gilt dies nicht für den JDBC "thin" Treiber; da er als reiner Java- Treiber SQL*NET nur emuliert, müssen Client-Verschlüsselungseinstellungen direkt im Programmcode (classes12.jar) angegeben werden. Der sicherste Algorithmus ist vor Oracle 11g: 3DES168, ab Oracle 11g: AES256 Parametername Typ und Klasse Erlaubte Werte oracle.net.encryption_client string static REJECTED ACCEPTED REQUESTED REQUIRED oracle.net.encryption_types_client string static RC4_40 RC4_56 DES40C DES56C 3DES112 3DES168 Ab V11 zusätzlich: AES128, AES192, AES256 oracle.net.crypto_checksum_client string static REJECTED ACCEPTED REQUESTED REQUIRED oracle.net.crypto_checksum_types_client string static MD5 Anmerkung: Zitiert aus Oracle Database JDBC Developer's Guide and Reference sowie Oracle Database Advanced Security Administrator's Guide 11g Ein Programmabschnitt kann also so aussehen (CHECKSUM-Erklärung s.u.): Properties props = new Properties(); Copyright 2010 by try { props.put("oracle.net.encryption_client", "REQUIRED"); props.put("oracle.net.encryption_types_client", "AES256"); props.put("oracle.net.crypto_checksum_client","requested"); props.put("oracle.net.crypto_checksum_types_client", " MD5 "); props.put("user", "gast"); props.put("password","tiger43"); } catch (Exception e) { e.printstacktrace(); } Connection conn = DriverManager.getConnection ("jdbc:oracle:thin:@testserver:1521:testdb",props);

24 5-10 Datenübertragung Netzwerksicherheit Integritätsprüfung Erinnern Sie sich an das "Liebesbrief-Bild" im Kapitel 1? Die Angreiferin (vermutlich eine verschmähte Kollegin) hat hier die versandte Nachricht abgefangen, verändert und dadurch den Sinn entstellt. Diese Situation kann zu Herzschmerz führen, eine verfälschte Bankanweisung (mit z.b. neuem Zielkonto) zu herben finanziellen Verlusten! Um sich davor schützen zu können, baut man Integritätsprüfungen ein, die garantieren, dass genau der Inhalt einer Nachricht beim Empfänger ankommt, der auch vom Absender losgeschickt wurde. Selbstverständlich könnte diese Änderung auch technische Hintergründe haben (z.b. Übertragungsfehler aufgrund defekter Hardware). Integritätsprüfungen unterstützen also sowohl den Schutz vor Verlust (Datensicherheit) als auch den Schutz vor vorsätzlicher Veränderung (Fälschungssicherheit). Die ASO erlaubt die Bildung kryptographischer Prüfsummen vor und nach der Datenübertragung. Werden beim Prüfsummenvergleich keine Unterschiede festgestellt, handelt es sich höchstwahrscheinlich um den Originaldateninhalt. Eingestellt wird diese Prüfsummentechnik durch die Eigenschaften Algorithmus (s.u.) und Typ (s.o. "Netz-Verschlüsselung") explizit in der Datei SQLNET.ORA (oder grafisch mit dem Oracle Net Manager). sqlnet. CRYPTO_CHECKSUM _TYPES_SERVER=(algor., algor., ) sqlnet. CRYPTO_CHECKSUM _SERVER=verschlüsselungstyp sqlnet. CRYPTO_CHECKSUM _TYPES_CLIENT=(algor., algor., ) sqlnet. CRYPTO_CHECKSUM _CLIENT=verschlüsselungstyp Erlaubte Algorithmen sind hier: MD5 und SHA1; beide bereits ab Oracle 8i. Copyright 2010 by ID DV GmbH

25 Datenspeicherung und sicherung 6-1 Copyright 2010 by 6 Datenspeicherung und sicherung

26 6-2 Datenspeicherung und sicherung Sicherheit der Data-, Control- und Logfiles Datendateien sind das Herzstück Ihrer Datenbank. Jeder DBA hütet sie wie seinen Augapfel, denn er weiß, dass bei z.b. zu großzügig vergebenen Zugriffsrechten (auf BS- oder DB-Ebene) sensible Informationen leicht zugänglich sind. Diese Dateien können gelesen, verändert oder gelöscht werden! Der Zugriff kann auf BS-Ebene durch Editoren oder innerhalb der Datenbank z.b. per PL/SQL (utl_file-package) erfolgen. Folgendes Beispiel zeigt, wie leicht Informationen in Tablespacedateien lesbar sind: -- Benutzer TCRA legt Daten ab create table test_tab(i number, t varchar2(50)); insert into test_tab values(42, 'zweiundvierzig'); insert into test_tab values(17, 'siebzehn'); commit; SQL> SELECT * from TEST_TAB; I T zweiundvierzig 17 siebzehn -- jetzt suchen wir den Speicherort der Tabelle TEST_TAB -- (als privilegierter Benutzer z.b. Administrator, Tuning-Experte ) select file_id, block_id, d.blocks, value, substr(f.name,1,45) file_name from dba_extents d, v$datafile f, sys.ts$ t, v$parameter p where owner = 'TCRA' and segment_name = 'TEST_TAB' and segment_type = 'TABLE' and d.file_id = f.file# and d.tablespace_name = t.name and p.name = db_block_size' order by file_id, block_id; FILE_ID BLOCK_ID BLOCKS VALUE FILE_NAME D:/oracle/oradata/JF10/USERS02.DBF Copyright 2010 by ID DV GmbH

27 Datenspeicherung und sicherung 6-5 SQL> select count(*) from v$logmnr_contents where operation = 'DDL'; COUNT(*) SQL> select username, operation, sql_redo from v$logmnr_contents 2 where operation = 'DDL'; USERNAME OPERATION SQL_REDO ABC DDL drop table autos; ABC DDL create sequence au; APPL_X DDL create table mit(pnr number,name varchar2(30), gehalt number(6,2)); -- und jetzt schauen wir mal, wer wieviel verdient SQL> SELECT SQL_REDO FROM V$LOGMNR_CONTENTS WHERE username = 'APPL_X' 2 where operation in ('INSERT', 'UPDATE', 'DELETE'); SQL_REDO insert into "APPL_X"."MIT("PNR","NAME","GEHALT") values (4711, 'Max Muster', ); Wer ein "ALTER SYSTEM"-Recht besitzt, kann auch einen Dump veranlassen; dieser liefert ebenfalls Nutzdateninhalte. Ein Beispiel hierzu findet sich in REDOLOG_DUMP.PDF Copyright 2010 by Bis Oracle 9 wurden selbst Kommandos wie ALTER USER A IDENTIFIED BY XYZ; komplett im Klartext in Redo-Logfiles abgelegt. Heute muss der interessierte Hacker dafür etwas tiefer in die Trickkiste greifen, z.b. durch direkte nicht/schlecht nachweisbare - Hauptspeicherzugriffe wie in Kapitel 4 Stichwort "Auditing".