Datenbank-gestützte Authentifizierung und Autorisierung von Web-Applikationen. Dr. Günter Unbescheid Database Consult GmbH - Jachenau

Transkript

1 Datenbank-gestützte Authentifizierung und Autorisierung von Web-Applikationen Dr. Günter Unbescheid Database Consult GmbH - Jachenau

2 Database Consult GmbH Gegründet 1996 Kompetenzen im Umfeld von ORACLE-basierten Systemen Tätigkeitsbereiche Tuning, Installation, Konfiguration Support, Troubleshooting, DBA-Aufgaben Datenmodellierung und design Datenbankdesign, Systemanalysen Programmierung: SQL,PL/SQL,JSP, ADF UIX, BC4J Schulungen Expertise Folie 2 von 31

3 Prolog - Datenbanken steuern immer häufiger die Aufbereitung dynamischer Web-Seiten - Die intensive Eingabe und Modifikation von Daten stellt zusätzliche Anforderungen an Authentifizierung und Autorisierung - Durch multiple Nutzungskontexte sollte AA auch über DB abgesichert werden - Das Datenmodell ist i.d.r. dauerhafter als die Präsentationsschichten Internetprogramme, auch Webanwendungen genannt, sind Anwendungen, die auf einem Webserver ausgeführt werden und dann in einem Browser dargestellt werden. Kategorien von WA u.a.: Transaktionale Webanwendungen (Erweiterung um den Bereich Datenbanken) Wikipedia Folie 3 von 31

4 Agenda Einführung: Application Server und Datenbanken Connection Session Authentifizierung Secure Application Roles und Client Identifier Proxy Authentication Virtual Private Database Auditing Stand der Technik: Oracle 10g Release 2 Folie 4 von 31

5 Einführung Datenbank Einheit von Session und Connection ++ Folie 5 von 31

6 Einführung Application Server Stateless Requests über HTTP(S) + Folie 6 von 31

7 Einführung Application Server Permanente Verbindung Datenbank Stateless Requests + Folie 7 von 31

8 Connection Pool Application Server Datenbank Wiederverwendung physischer Datenbankverbindungen Konfigurierbarer Aufbau Minimale und maximale Anzahl physischer Verbindungen Maximale Idle-Zeiten zum Abbau der Verbindung Ähnelt Multithreaded Server der Datenbank Folie 8 von 31

9 Grundmodell Zentraler, fest codierter Applikationsbenutzer auf Seiten des App-Server Unterschiedliche Endbenutzer mit diversen Privilegienanforderungen Größtmöglicher Querschnitt aus allen erforderlichen Objektprivilegien für App-Benutzer ggf. Filterung der erforderlichen Privilegien durch Mittelschicht Gefahr des Mißbrauchs bei Quereinstieg, z.b. Client- Server Applikation Folie 9 von 31

10 Einflussfaktoren Session Connection Authentication Authorization Auditing + Folie 10 von 31

11 Was Wo? Präsentationsdynamik Pluralität Application Server EndUser Authentication Authorization Auditing ApplicationUser Strukturelle Stabilität Zentralität Datenbank Authentication Authorization Auditing Folie 11 von 31

12 Intermezzo: JDBC Java Database Connectivity Java Standard zur Verbindung zwischen Java- Programmen/Applicationserver und relationalen Datenbanken kompatibel mit SQL92 entry level Implementiert über Standard java.sql Interfaces Komponenten Standard JDBC APIs Oracle Treiber mit spezifischen Erweiterungen zur Unterstützung von Oracle-Datentypen und Performance- Verbesserungen Spezifische Erweiterungen über oracle.jdbc Package Folie 12 von 31

13 Intermezzo: JDBC 3 Ausprägungen Thin driver: reiner Java-Treiber auf Clientseite ohne Oracle- Client-Installation für Applets und Anwendungen. Implementiert SQL*Net über Java Sockets mit TCP/IP OCI-Treiber (thick driver): Treiber auf Clientseite mit Oracle- Client-Installation für Anwendungen Konvertiert in OCI-Calls breitere Funktionalität: OCI Connection Pool, TAF Server-side thin driver: wie thin driver jedoch für Java-Code auf dem Datenbankserver für Zugriffe auf andere Session bzw. Server Server-side internal driver: Java-Code für Zugriffe innerhalb einer Session Folie 13 von 31

14 Connection Modelle (1) Implicit Connection Cache JDBC 3.0 kompatible Implementierung des DataSource Interface Logische Verbindungen (Anforderungen) und physische Verbindungen Verfügbar für thin und thick (OCI) Treiber Ein Cache pro DataSource Instance möglich mit unterschiedlichen Benutzer-Authentifikationen. Cache Properties: MinLimit, MaxLimit, InitialLimit,Timout-Properties + Folie 14 von 31

15 Connection Modelle (2) OCI Connection Pooling Verfügbar nur für JDBC OCI Treiber (thick JDBC) Session Mulitplexing von logischen Verbindungen über (wenige) physische Verbindungen Call-Basis Trennung von Session und Connection Codebeispiel siehe Artikel + Folie 15 von 31

16 Schema-Trennung Rollen / current_schema App-User Owner Internal Ux Uy Folie 16 von 31

17 Proxy-Authentifizierung + Proxy Authentication Connection/Benutzer A agiert als Proxy für Benutzer B, C, D.. Verfügbar für thin und thick JDBC Proxy-Connections nutzen Caching Prinzip Application-Benutzer wird authentifiziert Datenbank-Endbenutzer gibt Privilegiesierung vor Folie 17 von 31

18 Proxy-Authentifizierung Zu beachten: Datenbank kennt Endbenutzer Datenbank privilegiesiert Endbenutzer App-Benutzer benötigt kein Passwort von Endbenutzer Auditing und Logging kennen Proxy proxy_sessionid in Tabelle aud$ Unterschiedliche Möglichkeiten der Authentifizierung (s.u.) Untermenge von Privilegien ist möglich Folie 18 von 31

19 Proxy-Authentifizierung -- App-User anlegen CREATE USER application1 IDENTIFIED BY apppwd; -- andere Authentifizierungen sind machbar -- App-User minimal privilegieren GRANT CREATE SESSION TO application1; -- Enduser anlegen und privilegieren CREATE USER enduser1 IDENTIFIED BY endpwd; GRANT r1, r2, r3 TO enduser1; -- (anonymes) Proxy einrichten und privilegisieren ALTER USER client1 GRANT CONNECT THROUGH applikation1 WITH ROLE r2; -- Eingaben überprüfen über View SELECT * FROM DBA_PROXIES; Folie 19 von 31

20 Proxy-Authentifizierung -- Alternativen der Authentifizierung für Enduser -- (a) anonym (ohne Angabe eines PW für Enduser) ALTER USER <usr> GRANT CONNECT THROUGH <appusr>; -- (b) unter Angabe des PW von Enduser ALTER USER <usr> GRANT CONNECT THROUGH <appusr> AUTHENTICATED USING PASSWORD; -- (c) unter Angabe von Distinguished Name (noch) CREATE USER gu IDENTIFIED GLOBALLY AS 'CN=gu,OU=Europe,O=dbconsult,L=jachenau,ST=by,C=de'; ALTER USER <usr> GRANT CONNECT THROUGH <appusr> AUTHENTICATED USING DISTINGUISHED NAME; -- (d) unter Nutzung eines DN über Zertifikat ALTER USER <usr> GRANT CONNECT THROUGH <appusr> AUTHENTICATED USING CERTIFICATE TYPE 'X.509' VERSION '3'; Folie 20 von 31

21 Proxy-Authentifizierung SELECT schemaname, status, username, type, server FROM v$session WHERE username IS NOT NULL; SCHEMANAME STATUS USERNAME TYPE SERVER CLIENT1 INACTIVE CLIENT1 USER PSEUDO APPLICATION1 INACTIVE APPLICATION1 USER DEDICATED SYSTEM ACTIVE SYSTEM USER DEDICATED Folie 21 von 31

22 Enterprise User LDAP enterprise user enterprise user enterprise roles shared schema global roles Folie 22 von 31

23 Enterprise User Proxy LDAP enterprise user enterprise user proxy permissions schema ALTER USER local_database_user_name GRANT CONNECT THROUGH ENTERPRISE USERS; Folie 23 von 31

24 Client Identifier Beliebige, freibleibende Markierung einer Session Z.B. mit Namen des Endusers Nicht zu verwechseln mit Client Info Zur Sicherheit entsprechende Plausis einbauen Protokolliert in aud$ Enduser müssen nicht in DB eingerichtet sein Authorisierung z.b. über Secure Application Roles + Folie 24 von 31

25 Client Identifier -- Fragment eines Startpakets von Appuser CREATE OR REPLACE PROCEDURE app (user_in IN VARCHAR2) AUTHID CURRENT_USER IS -- diverse Deklarationen BEGIN --.. je mehr kombiniert wird, desto sicherer IF SYS_CONTEXT ('userenv', 'ip_address') = valid_ip AND SYS_CONTEXT ('userenv', 'host') = valid_host AND SYS_CONTEXT ('userenv', 'external_name') = valid_ext THEN -- Client Identifier wie authentifizierter Benutzer DBMS_SESSION.set_identifier (user_in); -- Rolle Aktivieren DBMS_SESSION.set_role ('DEMO_ENDUSER'); -- etc. Folie 25 von 31

26 Client Identifier -- Zugriff auf gesetzten Client Identifier SELECT * FROM my_view WHERE benutzer = SYS_CONTEXT('userenv', 'client_identifier'); -- Löschen BEGIN DBMS_SESSION.clear_identifier; END; / -- Absicherung der Logik des Startpakets durch Wrap -- SQL-Syntax in Datei, dann auf BS-Ebene: wrap iname=pack.sql -- Verbesserungen unter 10g (siehe nächste Folie) -- oder in R2: begin dbms_ddl.create_wrapped ('create or replace procedure p1 as begin null; end;') end; / Folie 26 von 31

27 Client Identifier abcd 7 31d 223 abmdzxjvd7hfjqbws1ew0m8o9rqwg/dxzpyvfi4c/mgpuprlymwksnkghdxxf2fr8rr8qebq ahsrphmnzzq7yu1z31jrqhkpormtxhjmukz6xodwoq73j8mrwg72l8mh4oufdfqnykyeicuc JVS1Lsr1pqY/0LCfl9SsuvfdOOktd0Chx0ZnjL9VRgf7RpD4SJjHErG5M4OQ/y60tQKIlYNx 1APP: 1USER_IN: 1VARCHAR2: 1AUTHID: 1CURRENT_USER: 1LV_VALID_IP: 1CONSTANT: 150: : 1LV_VALID_HOST: 1myserver: 1LV_VALID_EXTERNAL: 1cn=guenter,cn=users,dc=dbconsult,dc=de: 1SYS_CONTEXT: Folie 27 von 31

28 Autorisierung Anforderungen Zentrale App-Accounts mit wechselnden Identitäten/Endbenutzern Individuelle Privilegisierung (need to know- und least privilege-prinzip) Konsequenzen Keine fest gegranteten Objektprivilegien möglich Flexible und sichere Schaltung von Rollen: Secure Application Roles + Folie 28 von 31

29 Secure Application Roles Rollenaktivierung über prädestinierte Programmeinheiten Programme sollten Plausibilitäten prüfen Zuteilung der Rollen an App-Benutzer nicht als Default! -- Die Rollen werden geschaltet über das Schema SECUSER (Locking) CREATE ROLE demo_enduser IDENTIFIED USING secuser.setpriv; -- Aufbau der Programmeinheit -- Kontrolle der angelegten Application Roles SELECT ROLE, SCHEMA, PACKAGE FROM dba_application_roles WHERE SCHEMA = 'SECUSER'; -- Zuteilung der Application Roles an den APP-Benutzer GRANT demo_enduser TO appuser; GRANT EXCUTE ON secuser.setpriv TO appuser; -- Application Roles sollen keine Default Rollen sein: ALTER USER appuser DEFAULT ROLE NONE; Folie 29 von 31

30 Secure Application Roles Programmeinheit Implementiert in separatem Security Schema ohne create session Privileg (account lock) Diverse Plausbilitäten einbauen: Hierzu sys_context('userenv ', ' ') oder v$session Z.B. authentication_type, ip_address, terminal, programm etc. Code schützen durch wrapping Folie 30 von 31

31 Virtual Private Database VPD = fine grain access control Kontext-abhängige, automatische Generierung von where-klauseln Eingeführt unter Version 8, unter 9 und 10 erweitert Komponenten Anwendungskontexte kennen name-value-paare Policy-Funktionen erzeugen Where-Klauseln Policies verbinden Funktionen, DB-Objekte und Operationen User A> SELECT * FROM x; where col = 'x' User B> SELECT * FROM x; where col = 'y' Folie 31 von 31

32 Virtual Private Database Anforderungen bei Webanwendungen Sessions mit wechselnden Identitäten Dadurch schnelle und effiziente Anpassung der Kontexte Technologien Globale Applikationskontexte Gespeichert in SGA, d.h. für alle Sessions verfügbar Können gekoppelt sein an User und Client-Identifier Funktions, Policies und Policy Groups wie gehabt Folie 32 von 31

33 Virtual Private Database -- Anlegen und autorisieren des globalen Contexts CREATE CONTEXT test_ctx USING secusr.secproc ACCESSED GLOBALLY; -- pauschales aktivieren (für alle) in SECPROC DBMS_SESSION.SET_CONTEXT (namespace => 'test_ctx',attribute => ' name1',value => ' wert1'); -- Ausschalten DBMS_SESSION.CLEAR_ALL_CONTEXT ('test_ctx'); -- Aktivieren für alle unter Schema USR DBMS_SESSION.SET_CONTEXT (namespace => 'test_ctx',attribute => ' name1',value => ' wert1', username => ' USR'); -- zusätzliche Kopplung an Client Identifier DBMS_SESSION.SET_CONTEXT (namespace => 'test_ctx',attribute => ' name1',value => ' wert1', username => ' USR',client_id => 'U'); Folie 33 von 31

34 Auditing Erweiterte Attribute, zb. DBA_COMMON_AUDIT_TRAIL AUDIT_TYPE Session_id Proxy_sessionid Global_uid Db_user Client_id Ext_name Comment_text (enthält Authentication_Type) Priv_used Folie 34 von 31

35 Danke für s Zuhören Folie 35 von 31