Information Systems Audit and Control Association Revision von DB2-Anwendungen

Ordnungsmerkmale

erschienen in: <kes> 2005#3, Seite 58

Rubrik: ISACA informiert

Schlagwort: DB2-Revision

Zusammenfassung: Welche Rechte benötigen Benutzer, um eine Mainframe-Anwendung mit DB2-Zugriff zu nutzen? Dieser Aspekt wird in der Prüfungspraxis von DB2-relevanten Systemen und Verfahren noch immer häufig unvollständig oder falsch verstanden.

Autor: Von Christoph Franke, Ober-Olm

DB2 wird seit vielen Jahren als das strategische Datenbank-Management-System (DBMS) im Mainframe-Umfeld eingesetzt. Die Anwendungsarchitektur war – und ist für Legacy-Anwendungen – vordergründig sehr einfach: Eine (in der Regel) in COBOL, PL/I erstellte Anwendung mit fest kodierten SQL-Anweisungen läuft unter dem Customer Information Control System (CICS), Information Management System (IMS) oder als Batch-Verarbeitung. Dieser Programmierstil, die Verwendung von "statischem SQL", wird in recht seltenen Ausnahmen dahingehend durchbrochen, dass die SQL-Anweisungen erst zur Laufzeit zusammengesetzt werden und man somit von "dynamischem SQL" redet. Für den Anwendungsentwickler sind diese zwei Techniken gut durchschaubar und beherrschbar. Hinsichtlich der Beherrschbarkeit ergeben sich jedoch für Administratoren und – verschärft – für Sicherheitsadministratoren evidente Unterschiede. Das geht so weit, dass diese beiden Wege total verschiedene Sicherheitsarchitekturen erfordern.

Tatsächlich liegen bei DB2 für z/OS die effektiven Autorisierungskontrollen in einer speziellen Ausprägung vor, wenn man über so genanntes statisches SQL redet, das üblicherweise in Legacy-Anwendungen zum Einsatz kommt. Zugriffe auf DB2 erfolgen hierauf aus allen lokalen Trägerumgebungen, wobei vorwiegend IMS und CICS für Online-Verfahren und Time Sharing Option (TSO) sowie IMS für den Batch-Betrieb anzutreffen sind. Weiterhin erfolgen oftmals Remote-Zugriffe über die Distributed Data Facility (DDF). Sofern DDF als TCP/IP-Listener arbeitet, ist zunächst davon auszugehen, dass DB2 aus dem gesamten Intranet-Umfeld als Server ansprechbar ist.

In allen Fällen ist zu folgern, dass das Serversystem DB2 eine effektive Zugangskontrolle benötigt. Diese Kontrolle erledigt die Resource Access Control Facility (RACF) nur, sofern ein entsprechender Eintrag für das DB2-Subsystem in der RACF-Routertable gemacht und die Klasse DSNR im RACF aktiviert ist. Die hierbei genutzten Profilnamen sind abhängig von der Art des zugreifenden Systems (vgl. Abb. 1).

[Illustration]
Abbildung 1: Zugriffswege und RACF-Profile auf DB2

Vergabe von DB2-Rechten

DB2-Rechte können auf verschiedene Weise an Benutzer, genauer gesagt an Autorisierungs-IDs, vergeben werden. Die Vergabe administrativer Rechte (SYSADM, DBADM, …) ist für die Betrachtung operativer Anwendungen nicht relevant und soll daher hier nicht näher behandelt werden.

Jedes DB2-Objekt (vorrangig Tabellen bzw. Views) wird beim Anlegen einem SCHEMA zugeordnet (im DB2-Katalog als CREATOR geführt). Dieses SCHEMA ist faktisch Besitzer und hat explizit alle Rechte am entsprechenden Objekt. Somit hat jeder DB2-Prozess, der das SCHEMA als SQLID nutzen kann, ebenfalls alle Rechte an diesem Objekt. Des Weiteren kann der Besitzer eines Objekts (oder ein Administrator) Rechte durch die SQL-Anweisung GRANT an andere SQLIDs vergeben – inklusive der generischen IDs PUBLIC und PUBLIC AT ALL LOCATIONS.

Zudem besteht seit DB2 Version 6 die Möglichkeit, DB2-Rechte über RACF-Profile in speziellen DB2-Klassen abzubilden: Erkennungsmerkmale sind der RACF-DB2-Exit DSNX§XAC sowie aktivierte RACF-Klassen wie DSNADM, MDSNTB oder GDSNTB. Dieser Aspekt wird in diesem Artikel nicht weiter verfolgt, da mit RACF lediglich ein anderes "Aufbewahrungsbehältnis" für die Rechte zum Tragen kommt, die tatsächlich verwendeten Rechte und Autorisierungen jedoch unverändert bleiben.

[Illustration]
Abbildung 2: RACF-DB2-Exits – RACF-Gruppen als Erweiterung der Autorisierungs-ID

DB2 kennt – wie jedes gängige relationale DBMS – den Begriff der SQLID als Identifikation einer SQL-Anfrage. Im Sinne einer exakten Terminologie sollte man allerdings die SQLID von der Autorisierungs-ID unterscheiden, auch wenn sie zunächst identisch scheinen. Beide IDs werden von DB2 aus der RACF-Userid gebildet, wobei noch einer von zwei möglichen DB2-Userexits durchlaufen wird, um zunächst die so genannte Composite Authorization ID zu bilden. Während die (current) SQLID zur Bestimmung des Schema beim Ressourcenzugriff verwendet wird, dient die (composite) Authorization-ID der Prüfung der Zugriffsrechte auf die Ressource.

Die zwei angesprochenen DB2-RACF-Exits (DSN3@ATH und DSN3@SGN) liegen als Assembler-Source-Module vor und werden in der Mehrzahl der Installationen modifiziert. Der Identify-Exit (DSN3@ATH) wird bei jedem Zugang zum DB2 durchlaufen. Der Signon-Exit (DSN3@ATH) wird zusätzlich pro Ausführung einer Anwendung aus CICS oder IMS-Online durchlaufen. Die Standardaktion der Exits besteht lediglich darin, die RACF-Userid und alle zugeordneten RACF-Gruppen als Composite Authorization ID bereitzustellen und eine dieser IDs als SQLID zu setzen; jedoch sind Modifikationen jeder Art möglich, da die Exits APF-autorisiert laufen (APF= Authorized Programming Facility): Programme, die "APF-autorisiert" ausgeführt werden, können im Supervisor-State Zugriff auf alle Betriebssystemressourcen nehmen.

Diese DB2-Exits haben jedoch nichts mit der Autorisierungsprüfung im DB2 zu tun, stehen in keinem Zusammenhang mit der externen RACF-Security und erzeugen keine RACF-SMF-Sätze! Es findet also – trotz der so genannten DB2-RACF-Exits – keine Protokollierung von Zugriffsversuchen im Rahmen der RACF-SMF-Protokollierung statt. Ein reiner RACF-Auditor kann den Komplex der DB2-Zugriffskontrollen somit nicht sehen.

(K)ein Plan?

Im Rahmen der Programmumwandlung für DB2 entsteht pro Modul ein Database Request Module (DBRM), das mit den Kommandos BIND PACKAGE beziehungsweise BIND PLAN für DB2 aufbereitet wird. Sofern Packages verwendet werden (was heute der Normalfall ist), werden diese in so genannten Collections gruppiert und Collections wiederum Plänen zugeordnet.

Dem Prüfer kann hier das Wissen genügen, dass einer lokalen z/OS-Anwendung ein Plan zugewiesen werden muss, um SQL-Anweisungen ausführen zu können, während eine Remote-Anwendung auf Basis der Einzel-Packages (identischer Name mit dem jeweiligen Modul) läuft. Für den folgenden Abschnitt ist somit bei der Betrachtung von Remote-Anwendungen der Begriff PLAN durch PACKAGE zu ersetzen.

Nach dem Passieren der Zugangskontrolle benötigt ein Prozess gewisse Minimalrechte, um SQL-Anwendungen starten zu können, da DB2 keine integrierte SQL-Schnittstelle besitzt. Für lokale Verarbeitungen wird dabei immer das so genannte GRANT EXECUTE on PLAN benötigt. Verwendet die Anwendung nur statisches SQL, so sind keine weiteren Rechte notwendig – der Benutzer der Anwendung kann alle im Plan erreichbaren SQL-Anweisungen nutzen. Somit ist in der Regel die Granulierung der Rechte auf Nutzerebene durch ein anwendungsinternes Berechtigungssystem notwendig. Oder anders herum formuliert: DB2 prüft nicht, ob der Endbenutzer der Applikation Rechte an den Daten hat!

Bei Verwendung von dynamischem SQL (erkennbar an der SQL-Anweisung PREPARE) benötigt die Composite Authorization ID jedoch noch zusätzlich die notwendigen Rechte (Select, Insert, Update oder Delete) an den zu verarbeitenden Tabellen oder Views. In diesem Fall könnte theoretisch auf ein anwendungsinternes Berechtigungssystem verzichtet werden, jedoch verbietet sich diese Maßnahme oft aus architektonischen Gründen oder aufgrund von Nachweisverpflichtungen. Bei dieser Form von Anwendungen ist durch den Prüfer unbedingt abzuschätzen, ob die berechtigten SQLIDs auch unter Umgehung der Anwendung mit interaktiven SQL-Tools (z. B. QMF, SPUFI, MS Access o. Ä.) genutzt werden können, da das anwendungsinterne Berechtigungssystem in diesem Fall nicht greift.

Risikoeinschätzung

Eine der wichtigsten Fragen zur Einschätzung des Risikos von DB2-Anwendungen ist, welche DB2-Vorgänge (lesend, ändernd) vorgenommen und welche DB2-Ressourcen verarbeitet werden. Verwendet eine Applikation nur statisches SQL, kann der Prüfer pro Modul feststellen, welche SQL-Anweisungen im Code enthalten sind, da sie in der DB2-Systemtabelle abgelegt sind (SYSIBM.SYSPACKSTMT). Eine Aussage auf Anwendungsniveau kann nur über eine zusätzliche, stützende Analyse der Sourcen (Kontrollflussanalyse) erarbeitet werden. Die entsprechende ressourcenbezogene Betrachtung – welche Module verwenden diese Tabelle? – ist ebenfalls möglich; hierzu dienen Informationen aus der Systemtabelle SYSIBM.SYSTABAUTH.

Bei der Verwendung von dynamischem SQL sind diese Rückschlüsse allerdings nicht mehr mit DB2-Mitteln machbar, da keine Datenverwendungsnachweise im DB2-Systemkatalog liegen. Der Prüfer ist in dem Fall am Scheideweg: Entweder betrachtet er die eingehenden Autorisierungs-IDs und ihre DB2-Tabellenrechte (Ansatz bei der DB2-fokussierten Systemprüfung) oder er untersucht inhaltlich die Generierungsfunktionen für die dynamischen SQL-Anweisungen hinsichtlich ihrer Möglichkeiten, um das praxisrelevante Risiko abzuschätzen. Die Spannweite reicht hier von "Ein-/Ausblenden von Selektionen innerhalb einer SQL-Anweisung" mit vernachlässigbarem Zusatzrisiko bis hin zu "Freitext-SQL-Eingabe à la SPUFI" mit vollem Zusatzrisiko (SPUFI=SQL Processor Using File Input, IBM-Standard-Tool für SQL-Eingaben).

Aufgrund der sich ergebenden Probleme hinsichtlich des direkten Datenzugriffs auf DB2-Daten und eines erhöhten Administrationsaufwands bei wenig durchdachten Strukturen wurde dynamisches SQL in der Vergangenheit übrigens häufig einfach verboten. Diese Vogel-Strauß-Politik ist aber heutzutage nicht mehr haltbar, da beispielsweise Java-Anwendungen (etwa J2EE-Web-Applikationen) immer mit dynamischem SQL arbeiten.

Fazit

DB2-Security ist eigentlich ganz einfach zu prüfen, sobald man weiß, was eine Anwendung macht und wie sie es macht. Somit empfiehlt es sich für die Prüfung von DB2-Systemen fast immer, einige Applikationen mit zum Prüfungsgegenstand zu machen. Versucht man DB2 ohne Applikationssicht zu prüfen, wird man möglicherweise recht erfreuliche Prüfungsergebnisse vorfinden, jedoch nur den kleineren Teil der tatsächlich stattfindenden Workload geprüft haben, da der Prüfungsplan in dem Fall oftmals bei den Tabellenrechten endet: Nicht geprüft werden Berechtigungen auf die statischen Module via GRANT EXECUTE. Weiterhin lässt sich die Kritikalität der Exits ohne Praxisinformationen über die Eingangsparameter nicht bewerten. Sie sollten dabei nicht einfach glauben, dass nur Userids als Input für die Exits (vgl. Abb. 2) auftreten können – überzeugen Sie sich davon!

Dipl.-Inform. Christoph Franke, CISA, ist Inhaber der F-IT Christoph Franke IT-Dienstleistungen ([externer Link] www.F-IT.biz).

Weitere Informationen

ISACA German Chapter e. V.
Eichenstrasse 7
46535 Dinslaken
[externer Link] www.isaca.de

Bernd Wojtyna
Vorstand Facharbeit
Tel.: +49 251 288-4253
E-Mail: Bernd.Wojtyna@extern.Sparkassen-Informatik.de