Strengere gesetzliche Regelungen und geschäftliche Gründe erfordern es, dass Daten über die bisherigen Ansätze hinaus geschützt werden und sich ihre Nutzung nachweisen lässt. Dies führt zu mehrstufigen Sicherheitsverfahren (Multilevel Security), die eine Klassifikation von Objekten (Daten) und Subjekten (Benutzern) nach hierarchischen Sicherheitsstufen und nicht hierarchischen Sicherheitskategorien erlauben. Unautorisierte Benutzer sollen gehindert werden, auf bestimmte Daten zuzugreifen oder deren Sicherheitsklassifikation herabsetzen zu können.
Fazit
• In beiden Systemen lassen sich über Kennsatz-gesteuerte Sicherheitsrichtlinien relativ einfach fein abgestimmte, von den Datenwerten abhängige Zugriffsrechte definieren. Der Vorteil dieser Implementierungen ist, dass sie gar nicht oder nur mit SYSDBA-Rechten (Oracle) umgangen werden können.
• Im Ergebnis unterscheidet sich die mehrstufige Zugriffssicherung von DB2 und Oracle nicht, der Weg dorthin ist allerdings sehr unterschiedlich: Auf der Ebene der Befehlszeile sind die Definitionen in DB2 einfacher zu formulieren als in Oracle. Oracle besitzt dafür aber ein grafisches Werkzeug, das DB2 nicht bieten kann. Mit diesem Tool lassen sich die Definitionen anlegen, ohne dass der Sicherheitsadministrator profunde SQL-Kenntnisse besitzen muss.
• DB2 verfügt mit maximal 16 Komponenten einer Policy und dem standardmäßigen Schutz von Zeilen und Spalten über deutlich mehr Möglichkeiten als Oracle mit seinen drei Komponenten und dem fehlenden Schutz für Spalten im Standard. Andererseits ist es in Oracle möglich, die Standardanwendung OLS zu verlassen und über die VPD-Routinen eine individuelle, beliebig komplexe Sicherheitslösung zu implementieren.
• Schließlich muss noch darauf hingewiesen werden, dass diese wichtigen Sicherheitsfunktionen bei beiden Herstellern den Enterprise-Editionen vorbehalten sind. Für mehr Sicherheit verlangen die Hersteller auch mehr Geld.
Implementierungen im Vergleich
Tätigkeit/Vorgehen DB2 Oracle
1. Implementierungsansatz IBM hat bekannte SQL-Befehle wie CREATE, GRANT oder REVOKE zur Oracle hat sich für eine Implementierung der LBAC-Funktionalität mit Implementierung der LBAC-Funktionalität erweitert. Das grafische Werkzeug für PL/SQL-Routinen entschieden. Grundsätzlich können die Definitionen den Administrator, das Control Center, unterstützt bisher nicht die Definition der im Policy Manager (OPM) ohne Kenntnis der Routinen getroffen werden. LBAC-Funktionen.
2. Definieren der Komponenten In DB2 müssen erst die Komponenten per CREATE-Befehl definiert werden. Entfällt, da fest vorgegeben als Level, Compartment, Group.
3. Definieren der Die Policy wird unter Angabe der Komponenten mit CREATE definiert, aber Das Definieren der OLS Security Policy erfolgt bei gleichzeitiger Angabe Sicherheitsrichtlinie ohne Angabe der Label-Spalte. der Label-Spalte per Prozeduraufruf.
4. Definieren der Entfällt, da dies bereits bei der Definition der Komponenten erfolgt ist. Da die Komponenten einer Policy vorgegeben sind, können gleich die Komponentenwerte Komponentenwerte definiert werden.
5. Definition von Labels Die möglichen sinnvollen Werte-Kombinationen der Security Policy mit ihren Wie in DB2 können die möglichen sinnvollen Wertekombinationen der Komponenten können als Labels definiert und unter dem Label-Namen Security Policy mit ihren Komponenten als Labels definiert werden. In angesprochen werden. Oracle werden Ihnen numerische Label-Tags zugeordnet, die so gewählt werden können, dass sie für Gruppierung oder Sortierung in Auswertungen nutzbar sind.
6. Zuordnung von Zur Vergabe von Label-Berechtigungen an Benutzer müssen diese Labels Es werden Benutzer-Labels bei gleichzeitiger Zuordnung zu User-IDs Labels zu User-IDs definiert werden. Die Zuordnung zum Benutzer erfolgt mit dem GRANT-Befehl. definiert.
7. Richtlinie der Tabelle Die definierte Policy muss der Tabelle mit ALTER TABLE zugeordnet werden. Die definierte Policy muss der Tabelle per Prozeduraufruf zugeordnet zuordnen und Label-Spalte Außerdem muss die Tabelle um die Label-Spalte erweitert (ALTER TABLE) und werden. Die Label-Spalte wurde bereits zuvor (3) mit der Policy definieren mit den gewünschten Datenwerten gefüllt werden. Das kann der Datenbank- definiert. Administrator vornehmen, der dazu allerdings eine Ausnahmeberechtigung (Exemption) benötigt.
8. Label erzeugen Weil die Tabelle um die Label-Spalte erweitert worden ist, lassen sich die Auch hier sind die Labels für die Daten mit UPDATE-Befehlen zu erzeugen. Labels für die Daten mit UPDATE-Befehlen erzeugen.
9. Label-Werte abfragen Das Setzen der Labels lässt sich kontrollieren. Die Labels werden mit der Das Setzen der Labels lässt sich kontrollieren. Die Labels werden mit der Funktion seclabel_to_char() lesbar gemacht. Funktion label_to_char() lesbar gemacht.
Codebeispiel auf www.computerwoche.de
Wer ein mehrstufiges Sicherungskonzept in seiner IBM- oder Oracle-Datenbank ausprobieren möchte, hat dazu Gelegenheit auf Computerwoche.de. Dort finden Sie den Code für eine Kennsatz-gesteuerte Sicherung beider Systeme. Grundlage sind eine zu schützende Mitarbeitertabelle und die dazugehörige Abteilungstabelle. Die Mitarbeitertabelle enthält neben den Stammdaten wie Adresse oder Geburtsdatum auch die Tarif- und Gehaltsdaten. Sie darf nur von bestimmten Mitarbeitern in speziellen Bereichen eingesehen und gepflegt werden.
Die Langfassung des Artikels samt Codebeispiel stehen unter www.computerwoche.de/587293.
Standard-SQL reicht nicht
Der klassische Ansatz im Standard der Datenbankabfrage-Sprache SQL kennt nur die Vergabe von Berechtigungen auf Objektebene, nicht aber auf der Ebene von Zeilen oder Spalten und auch nicht in Abhängigkeit von den Dateninhalten. Zwar kann man mit Hilfe von Datensichten Zeilen und Spalten ausblenden, bei Zeilen auch abhängig von Datenwerten, aber diesen Möglichkeiten sind starre Grenzen gesetzt. Außerdem werden mit den wachsenden Anforderungen an die Zugriffssteuerung die Objektstrukturen erheblich komplexer.
Ein anderer, weit verbreiteter Ansatz zur Implementierung von Sicherheitskriterien ist deren Realisierung im Anwendungscode: Hier können beliebige Anforderungen flexibel, allerdings mit entsprechendem Aufwand individuell umgesetzt werden. Wird jedoch die Anwendung umgangen, oder wird über andere Werkzeuge auf die Daten zugegriffen, so wirken die implementierten Berechtigungssteuerungen nicht.
Risiko Benutzer-IDs
Beliebt ist es in diesem Zusammenhang, vom Anwendungs-Server mit internen Benutzer-IDs auf die Datenbank zuzu- greifen. Diese Benutzer-IDs verfügen dann über den vollen Berechtigungsumfang für den Zugriff auf die Daten, unabhängig davon, welche Berechti- gungen der reale Benutzer am Bildschirm hat. Werden solche Benutzer-IDs gehackt beziehungsweise geraten sie durch Fahrlässigkeit oder Missbrauch in falsche Hände, so ist die Datenbank offen wie ein Scheunentor.
Um dies zu verhindern, sind Wege zur Einführung mehrstufiger Sicherheitssysteme gefragt. Einer davon ist die Nutzung von Kennsätzen (Labels). Diese enthalten die Klassifikation der Daten entsprechend ihrer Sensitivität (Object Labels) oder die Berechtigungen des Benutzers (Subject Labels). Über solche Labels werden lesende und schreibende Zugriffe auf der Ebene von Zeilen und Spalten der Tabellen einer Datenbank gesteuert. Dazu werden die Kennsätze der Daten und der Benutzer miteinander verglichen. Ein Sicherheitsadministrator erstellt Sicherheitsrichtlinien (Policies) und definiert die Labels für Objekte und Benutzer.
Datenbanken sind vorbereitet
Oracle und IBM, die führenden Hersteller von Datenbank-Management-Systemen, bieten heute Kennsatz-gesteuerte Sicherheitslösungen als Bestandteil ihrer Datenbankprodukte an. Die Lösungen lassen sich ohne eigenen Programmieraufwand durch den Anwender nutzen. Die Vorteile dieser Sicherheitsverfahren sind:
- Ihre zentrale Implementierung in der Datenbank statt in Anwendungsprogrammen oder in Fremdsoftware,
- sie lassen sich nicht umgehen und
- es besteht kein Codieraufwand.
Um die Sicherheitskriterien festzulegen, müssen zuvor die Anwendungen, die zu verarbeitenden Informationen und die Benutzeranforderungen analysiert werden. Die Ergebnisse sind in einem Sicherheitskonzept festzuhalten: Aus der Analyse der Informationen ergibt sich die Klassifikation der Daten nach ihrer Sensitivität, und für die Benutzer werden die Zugriffskriterien ermittelt und die Kennsätze festgelegt.
Die technische Implementierung erfolgt in fünf Schritten:
1. Definition der Policy und ihrer Komponenten;
2. Definition der Daten-Labels;
3. Definition der Benutzer-Labels;
4. Anwenden der Policy auf die Objekte (Tabellen);
5. Erzeugen der konkreten Label-Werte in den Objekten.
IBM DB2 9.1
Wie sich eine Kennsatz-gesteuerte Sicherheit in DB2 und Oracle implementieren lässt, wird im Folgenden erläutert. Zu den neuen Funktionen in DB2 for LUW (Linux, Unix, Windows), Version 9, zählt die Berechtigungssteuerung Label Based Access Control (LBAC). Dazu gehört auch ein neues Berechtigungsprofil, der Security Administrator (SECADM). Nur der darf die Sicherheitsrichtlinien (Security Policies) und Kennsätze (Labels) definieren und vergeben beziehungsweise die Label-Berechtigungen widerrufen. Dazu ist kein anderes Profil befugt, auch nicht der Systemadministrator (SYSADM).
Aufgaben des SECADM
Der Security Administrator ordnet die Sicherheitsrichtlinien den Objekten (Tabellen) zu, wobei ein Objekt nur eine Sicherheitsrichtlinie besitzen kann. Die Security Policies bestehen aus Komponenten, die jeweils eines der Kriterien abbilden, nach denen der Zugriff gesteuert werden soll. Solche Kriterien können Vertraulichkeitsstufen von Daten, Abteilungszugehörigkeit oder Niederlassungsort sein. Für die Komponenten stehen drei Strukturen zur Verfügung:
- Set (Aufzählung),
- Array (geordnete Aufzählung, einfache Hierarchie) und
- Tree (Baumstruktur, komplexe Hierarchie).
Eine Security Policy kann aus maximal 16 Komponenten bestehen. Die Security-Labels lassen sich Tabellenzeilen oder Tabellenspalten zuordnen. Durch den Vergleich der Daten- und Benutzer-Labels wird festgestellt, ob ein Zugriff erlaubt ist. Ist dies nicht der Fall, behandelt DB2 die Daten, als ob sie nicht existierten. Auch Funktionen wie COUNT() oder SUM() berücksichtigen nur die Daten, zu deren Zugriff der Benutzer berechtigt ist. Greift ein Benutzer auf Spalten zu, für die er nicht berechtigt ist, erhält er eine Fehlermeldung.
Oracle 10g
Oracle verfügt schon länger über weitergehende Lösungsansätze zur Datensicherheit. Bereits Version 8 des Datenbank-Management-Systems enthielt mit der Technik "Virtual Private Database" (VPD) einen Werkzeugkasten (Toolkit) zur Implementierung von individuellen Zugriffskontrollen. Einfach dargestellt ermöglicht VPD für definierte Tabellen die automatische Generierung von Prädikaten, die den WHERE-Klauseln der SQL-Befehle eines Benutzers von diesem unbemerkt hinzugefügt werden. Zur Nutzung von VPD müssen eigene Routinen in Oracle erstellt werden.
In der Version 9 hat Oracle mit Oracle Label Security (OLS) eine fertige Lösung mit Security Labels auf Basis der VPD-Technik zur Verfügung gestellt. Sie erfordert keine individuelle Programmierung mehr. Leider verwendet Oracle mehr als einen Begriff für diese Sicherheitsfunktionen. Neben VPD gibt es die Bezeichnung Fine Grained Access Control (FGAC), oder es wird von Row Level Security (RLS) gesprochen.
Auch in Oracle werden Sicherheitsrichtlinien (Policies) und Komponenten definiert. Allerdings bestehen die Security Labels aus drei vorgegebenen Komponenten:
- der hierarchischen Stufe (Level),
- der optionalen, nicht hierarchischen Aufteilung (Compartment) und
- der optionalen Gruppe (Group), die hierarchisch definiert werden kann.
Zur Verwaltung der Label Security besitzt Oracle die Rolle LBAC_DBA, die der User-ID des Sicherheitsadministrators zugeordnet werden kann. Außerdem wird bei Aktivierung der Label Security in der Datenbank die User-ID LBACSYS als Eigentümer der entsprechenden Objekte definiert.
Die Rolle der Admin
Im Gegensatz zu DB2 stehen in Oracle die Systemadministratoren - bei Anmeldung als SYSDBA - oberhalb der Label Security. Sie haben also uneingeschränkten Zugriff auf die sonst durch Labels geschützten Daten. Zur Unterstützung bei der Einrichtung und Pflege der Sicherheitsrichtlinien verfügt Oracle mit dem OPM (Oracle Policy Manager) über ein grafisches Werkzeug, mit dem in den meisten Fällen die Definitionen komfortabel und ohne Kenntnis der Befehlssyntax angelegt werden können.
Implementierung im Vergleich
Wie sich die Security-Implementierungen von DB2 und Oracle unterscheiden, zeigt die Tabelle "Implementierungen im Vergleich". In beiden Fällen handelt es sich um eine Erweiterung des bisherigen Konzepts, bei dem die normalen Berechtigungen in relationalen Datenbanken, die mit den Befehlen GRANT und REVOKE vergeben und entzogen werden, zwar den lesenden oder ändernden Zugriff auf Tabellen steuern können, dies aber nicht in Abhängigkeit von Spalteninhalten möglich ist. Mit LBAC oder OLS lässt sich der Zugriff auf Daten auch inhaltlich steuern, allerdings abhängig von der speziellen Spalte (Security Label), die mit entsprechenden Werten gefüllt werden muss. Zur Steuerung über Kennsätze muss also zunächst eine Sicherheitsrichtlinie definiert werden, die zum Beispiel aus den zwei folgenden Komponenten bestehen kann: Die eine bildet die tarifliche Eingruppierung der Mitarbeiter eines Unternehmens ab, die andere die Aufbauorganisation der Firma, um die Abteilungszugehörigkeit der Mitarbeiter darzustellen.
Die Sicherheitsstufen nach Tarifzugehörigkeit kann man nach einer einfachen Hierarchie (in DB2 "array", in Oracle "level") ordnen, was den Vorteil hat, dass der Benutzer mit höherem Berechtigungsumfang auch die niedrigeren Stufen sehen kann. Zum Beispiel sieht ein Sachbearbeiter mit Stufe "AT" (außer Tarif) auch die Daten der Tarifangestellten. Um die Aufbauorganisation des Unternehmens abzubilden, reicht diese einfache Hierarchie nicht mehr, dafür ist eine komplexe Hierarchie in Form einer Baumstruktur (in DB2 "tree", in Oracle "group") nötig.
Weiter ist davon auszugehen, dass die Tabellenzeilen nicht einheitlich gegen unbefugten Zugriff geschützt werden sollen, da die Spalten unterschiedlich heikle Informationen enthalten: Angaben wie Namen, Telefonnummer oder Abteilungszugehörigkeit lassen sich allen Firmenangehörigen zugänglich machen, die Gehaltsdaten aber nur den Sachbearbeitern der Personalabteilung. Die Sicherheitseinstufung erfolgt demnach auf Spalten- und Zeilenebene.
In DB2 können mit LBAC auch Spalten durch Vorgabe eines festen Labels geschützt werden. Zum Beispiel können die Spalten Tarifgruppe, Grundgehalt, Zulage und L_Bonus (Leistungsbonus) durch Labels für alle Mitarbeiter außerhalb der Personalabteilung gesperrt werden. Greifen nicht berechtigte Mitarbeiter auf diese Spalten zu, so erhalten sie eine Fehlermeldung. Zusätzlich werden die Zeilen noch nach den bisher definierten Kriterien geschützt, so dass Manager nur auf Daten der Mitarbeiter ihrer eigenen Abteilung zugreifen können.
Wann Programmierung nötig ist
In Oracle können die Label-Prüfungen auf bestimmte Spalten beschränkt werden, so dass ein Anwender alle Zeilen lesen kann, wenn er nur die ungeschützten Spalten aufruft. Werden die geschützten Spalten selektiert, gelten die Label-Berechtigungen, und es werden nur die Zeilen angezeigt, für die der Benutzer bezogen auf die geschützten Spalten auch berechtigt wurde. Die Realisierung dieser Funktion ist aber nicht mehr mit Hilfe des Policy Managers möglich, sondern muss direkt über die Prozeduraufrufe definiert werden. Ein Schutz von Spalten zusätzlich zu dem Schutz auf Zeilenebene ist in OLS nicht vorgesehen, kann aber durch Eigenprogrammierung mit VPD auch realisiert werden. (ue)