DB2 Universal Database - Systemverwaltung


Verwenden von DCE-Sicherheitsservices zur Überprüfung von Benutzern

Im Hinblick auf die Sicherheit für Ihre verteilte Datenbankumgebung sind die DCE-Sicherheitsservices (DCE - Distributed Computing Environment Security Services) eine gute Wahl, da DCE folgende Funktionen bereitstellt:

DB2 unterstützt DCE-Standardanmeldekontexte (Default Login Contexts), Verbindungsanmeldekontexte (Connection Login Contexts) und delegierte Kontexte (Delegated Contexts). Ein Standardanmeldekontext wird eingerichtet, wenn ein Benutzer den Befehl dce_login auf einem Client ausführt. Nachfolgende DB2-Befehle haben Zugriff auf diesen Kontext und können Benutzerauthentifizierungen ohne weitere Beteiligung des Benutzers (d. h., ohne daß der Benutzer eine Benutzer-ID oder ein Kennwort angeben muß) durchführen. Ein Verbindungsanmeldekontext wird für eine DB2-Sitzung mit Hilfe der Benutzer-ID und dem Kennwort eingerichtet, die im Befehl CONNECT oder ATTACH mit Klausel USER/USING angegeben wurden. Ein delegierter Anmeldekontext kommt zustande, wenn ein DB2-Client als Teil einer DCE-Server-Anwendung verwendet wird. Die DCE-Server-Anwendung (die auch ein DB2-Client ist) empfängt Anforderungen von einer DCE-Client-Anwendung, von der die ursprüngliche Identität des Benutzers definiert wird. Vorausgesetzt, der DCE-Client und der DCE-Server sind korrekt konfiguriert, um dem DCE-Server die Stellvertreterfunktion für den DCE-Client zu ermöglichen, empfängt DB2 das Stellvertreter-Token und leitet es an den DB2-Server weiter. Dadurch kann der DB2-Server zur Verarbeitung der Anforderungen die ursprüngliche Identität des DCE-Client verwenden und muß nicht die Identität des DCE-Servers verwenden. Informationen, wie ein delegierter Anmeldekontext eingerichtet werden kann, können der DCE-Dokumentation für Ihre Plattform entnommen werden.
Anmerkung:Es gibt mehrere Lieferantenprodukte, die DCE unterstützen. Für einen reibungslosen Betrieb von DB2 UDB für Windows NT mit dem DCE-Produkt von IBM im Bereich der Sicherheitsservices wurden zwei neue DLL-Dateien zur Verfügung gestellt: db2dces.ibm und db2dcec.ibm. (Diese DLL-Dateien sind nur für Windows NT gültig.) Wenn Sie das DCE-Produkt von IBM für Sicherheitsservices erwerben und verwenden, müssen diese beiden Dateien entsprechend nach db2dces.dll bzw. db2dcec.dll kopiert werden. Wenn Sie das DCE-Produkt eines anderen Lieferanten erwägen, wenden Sie sich an die Serviceorganisation des Lieferanten und an die Serviceorganisation von DB2 UDB, um zu ermitteln, ob die DCE-Implementierung des Lieferanten für alle Sicherheitsservices mit DB2 UDB funktioniert.

Einrichten eines DB2-Benutzers für DCE

Benutzer müssen in der DCE-Registrierdatenbank (Distributed Computing Environment Registry) registriert werden und über korrekte Attribute verfügen, bevor sie mit DB2 verwendet werden können. In der entsprechenden plattformspezifischen DCE-Dokumentation finden Sie Informationen zur Erstellung eines DCE-Principal.

Jeder DB2-Benutzer, der einen Server mit DCE-Authentifizierung verwenden will, muß einen DCE-Principal und einen Benutzereintrag in der DCE-Registrierdatenbank mit der Markierung CLIENT definiert haben. Dieser Principal muß außerdem einen Eintrag in seinem Abschnitt für die erweiterten Registrierungsattribute (ERA - Extended Registry Attributes) haben, der angibt, welcher Berechtigungsname für diesen Principal verwendet wird, wenn er die Verbindung zu einem bestimmten Server mit DCE-Authentifizierung herstellt.

Es kann auch wünschenswert sein, Benutzer-Principals als Mitglieder von Gruppen zu definieren, um in der Datenbank Gruppenzugriffsrechte zu verwenden. Ähnliche Informationen im Gruppen-ERA ordnen dem Gruppennamen einen DB2-Berechtigungsnamen zu. Der Berechtigungsname ist ein sekundärer Berechtigungsname, jedoch gelten dieselben Einschränkungen. Bitte entnehmen Sie Ihrer DCE-Dokumentation die weiteren Informationen zur Erstellung von Gruppen und zum Hinzufügen von Mitgliedern.

Die Informationen im ERA ordnen einen DCE-Principal eines Benutzers oder einen Gruppennamen einem DB2-Berechtigungsnamen für einen bestimmten DCE-Principal-Namen eines Servers zu. Zur Verwendung eines ERA muß ein ERA-Schema definiert werden, das das Format dieses Attributs angibt. Dies muß einmal für jede DCE-Zelle ausgeführt werden und kann durch die Ausführung der folgenden Schritte erfolgen:

  1. Melden Sie sich bei DCE als gültiger DCE-Administrator an.
  2. Rufen Sie dcecp auf und geben Sie folgendes ein:
      > xattrschema create /.:/sec/xattrschema/db2map \
      > -aclmgr {{principal r m r m } {group r m r m }} \
      > -annotation {Schema entry for DB2 database access} \
      > -encoding stringarray \
      > -multivalued no \
      > -uuid 1cbe84ca-9df3-11cf-84cd-02608c2cd17b
    

Dadurch wird das ERA (Extended Registry Attribute) db2map erstellt.

Zum Anzeigen dieser Zuordnung geben Sie den folgenden Befehl in die dcecp-Eingabeaufforderung ein:

  > xattrschema show /.:/sec/xattrschema/db2map

Es wird folgendes angezeigt:

{axlmgr
{{principal {{query r} {update m} {test r} {delete m}}}
{group     {{query r} {update m} {test r} {delete m}}}}}
{annotation {Schema entry for DB2 database access}}
{applydefs no}
{intercell rejects}
{multivalued no}
{reserved no}
{scope {}}
{trigbind {}}
{trigtype none}
{unique no}
{uuid 1cbe84ca-9df3-11cf-84cd-02608c2cd17b}
Anmerkung:Einschränkungen für den Inhalt des Berechtigungsnamens im ERA werden von DCE nicht umgesetzt. Wenn einem DCE-Principal oder einer DCE-Gruppe ein ungültiger Berechtigungsname gegeben wird, entsteht ein Fehler, wenn von DB2 der Versuch unternommen wird, diesen Benutzer zu überprüfen. (Beachten Sie, daß die Authentifizierung bei den Befehlen CONNECT, ATTACH, DB2START bzw. bei jeder anderen Operation stattfinden kann, bei der eine Authentifizierung erforderlich ist.) Es ist außerdem sehr zu empfehlen, bei der Zuweisung von Berechtigungsnamen für DCE-Prinzipals sicherzustellen, daß die Namen eins-zu-eins und eindeutig zugewiesen werden. DCE überprüft diese Bedingungen nicht.

Wenn ein DB2-Client auf einen DB2 Universal Database-Server zugreifen soll, müssen nach Ihrer Registrierung als DCE-Principals die ERA-Informationen hinzugefügt werden, um die Zuordnung zwischen Principal-Name und Berechtigungsname herzustellen. Dies muß für jeden Benutzer bzw. jede Gruppe einmal ausgeführt werden und kann durch Ausführen der folgenden Schritte erfolgen:

Einrichten eines DB2-Servers zur Verwendung von DCE

Server müssen in der DCE-Registrierdatenbank (Distributed Computing Environment Registry) als Principals registriert werden und über korrekte Attribute verfügen, bevor sie mit DB2 verwendet werden können. In der entsprechenden plattformspezifischen DCE-Dokumentation finden Sie Informationen zur Erstellung eines DCE-Server-Principal.

Der DCE-Sicherheits-Client-Laufzeitcode muß installiert sein und für das Server-Exemplar zugänglich sein.

Jeder DB2-Server, der DCE zur Authentifizierung verwenden will, muß sich bei DCE zum Zeitpunkt der Ausführung von DB2START registrieren. Damit dies nicht manuell geschehen muß, stellt DCE eine Methode zur Verfügung, mit der ein Server die Informationen zur eigenen Benutzer-ID und zum eigenen Kennwort (Schlüssel) in einer speziellen Datei verwaltet, die als Chiffrierschlüsseldatei (Keytab File) bezeichnet wird. Bei Ausführung von DB2START liest DB2 die Konfigurationsdatei des Datenbankmanagers und ruft die Authentifizierungsart für das Exemplar ab. Wenn DB2 feststellt, daß die Authentifizierungsart DCE ist, werden vom DB2-Server DCE-Aufrufe abgesetzt, um die Informationen aus der Chiffrierschlüsseldatei abzurufen. Mit diesen abgerufenen Informationen wird der Server bei DCE registriert. Diese Registrierung ermöglicht es dem Server, DCE-Token von DCE-Clients zu empfangen und sie zur Überprüfung dieser Benutzer zu verwenden.

Der Exemplaradministrator muß die Chiffrierschlüsseldatei (Keytab File) für das Exemplar mit Hilfe von DCE-Befehlen erstellen. Detaillierte Informationen zur Erstellung einer Chiffrierschlüsseldatei finden Sie in der DCE-Dokumentation für Ihre Plattform. Lesen Sie in diesem Dokument die Einzelangaben zur Chiffrierschlüsseldatei (Keytab File) und zu den Befehlen dcecp keytab und rgy_edit. Die DB2-Chiffrierschlüsseldatei muß den Namen keytab.db2 erhalten und sich im Unterverzeichnis security des Verzeichnisses sqllib für das Exemplar befinden. (Auf Intel-Betriebssystemen muß sich die Datei im Unterverzeichnis security des durch INSTANCENAME definierten Unterverzeichnisses im Verzeichnis sqllib befinden. INSTANCENAME ist der Exemplarname der Datenbank, mit der Sie arbeiten.) Sie sollte nur einen Eintrag für den Server-Principal für das angegebene Exemplar enthalten. Alle weiteren Einträge führen bei der Ausführung von DB2START zu einem Fehler. Auf UNIX-Plattformen muß diese Datei mit Dateizugriffsrechten geschützt werden, so daß nur der Exemplareigner Schreib-/Lesezugriffsrechte besitzt.

Es folgt ein Beispiel für die Erstellung der Chiffrierschlüsseldatei:

Damit DB2 nach erfolgreicher DCE-Konfiguration mit der DCE-Authentifizierung gestartet wird, muß DB2 angewiesen werden, die DCE-Authentifizierung zu verwenden, indem die Konfigurationsdatei des Datenbankmanagers durch Angeben der Authentifizierungsart "DCE" aktualisiert wird. Dies geschieht durch Eingabe des folgenden CLP-Befehls:

   db2 update database manager configuration using authentication DCE
   sysadm_group DCE_group_name

Führen Sie anschließend den Befehl dce_login für einen gültigen DB2-DCE-Benutzer aus, der über die Berechtigung SYSADM verfügt, und setzen Sie DB2START ab.
Anmerkung:Bevor Sie DB2 mit DCE-Authentifizierung starten, stellen Sie sicher, daß Sie einen DCE-Benutzer-Principal für die Verwendung als Ihr SYSADM für das Exemplar definiert haben, so daß Sie eine gültige DCE-Benutzer-ID haben, von der aus Sie das Exemplar starten, stoppen und verwalten können. Anweisungen hierzu finden Sie in Einrichten eines DB2-Benutzers für DCE.

Stellen Sie über diese Anweisungen hinaus sicher, daß der erstellte Principal ein Mitglied der Gruppe SYSADM_GROUP für dieses Exemplar ist. Standardmäßig lautet dieser Gruppenname DB2ADMIN für die DCE-Authentifizierung, wenn keine Gruppe explizit angegeben ist (d. h., wenn SYSADM_GROUP gleich null ist), jedoch kann er aktualisiert werden, bevor die Authentifizierungsart für das Exemplar in einen Gruppennamen (Berechtigungsnamen) Ihrer Wahl geändert wird. Die von Ihnen ausgewählte DCE-Gruppe muß ein definiertes ERA (Extended Registry Attribute) haben, das ihr den angegebenen Berechtigungsnamen für die Gruppe SYSADM_GROUP zuordnet.

Eine der Funktionen des DB2-Verwaltungs-Servers ist das Starten von DB2-Exemplaren. Bei AUTHENTICATION = DCE muß der DCE-Principal, der in der DB2-Chiffrierschlüsseldatei für das Exemplar verwendet wird, eine gültige Zuordnung von DCE-Principal zur DB2-Berechtigungs-ID (authid) haben. Diese Zuordnung ist für den DB2-Verwaltungs-Server erforderlich, damit er das DB2-Exemplar starten kann. Die gültige Zuordnung ermöglicht dieser ID, sowohl als Client als auch als Server zu fungieren.

Einrichten eines DB2-Client-Exemplars zur Verwendung von DCE

Ein Nur-Client-Exemplar kann zur Verwendung der DCE-Authentifizierung für lokale Operationen eingerichtet werden, indem die Konfigurationsdatei des Datenbankmanagers aktualisiert und die Authentifizierungsart auf den Wert DCE gesetzt wird. Eine Chiffrierschlüsseldatei ist für ein Nur-Client-Exemplar nicht erforderlich, da es keinen Server gibt, der sich bei DCE registrieren muß. Im allgemeinen ist es nicht empfehlenswert (oder erforderlich), daß ein Nur-Client-Exemplar von DB2 die DCE-Authentifizierung verwendet. Sie wird jedoch unterstützt.

Ein Client, der auf eine ferne Datenbank mit DCE-Sicherheit zugreifen will, muß Zugriff auf das entsprechende DCE-Sicherheitsprodukt haben. Der Client kann wahlfrei die Authentifizierungsart für die Zieldatenbank im Datenbankverzeichnis katalogisieren. Wenn der Client die DCE-Authentifizierung angibt, muß auch der vollständig qualifizierte DCE-Server-Principal-Name angegeben werden. Wenn DCE-Authentifizierung im Verzeichnis nicht definiert wird, werden die Informationen zur Authentifizierung und zum Principal vom Server bei Ausführung von CONNECT abgerufen.

DB2-Einschränkungen bei der Verwendung der DCE-Sicherheit

Die Verwendung der DCE-Authentifizierung führt zu Einschränkungen bei bestimmten SQL-Funktionen, die von DB2 zur Verfügung gestellt werden und die Unterstützung von Gruppen betreffen. Folgende Einschränkungen sind bei Verwendung der DCE-Authentifizierung zu beachten:

  1. Bei der Verwendung der Anweisungen GRANT und REVOKE müssen die Schlüsselwörter USER und GROUP zur Qualifikation des angegebenen Berechtigungsnamens angegeben werden. Ansonsten wird ein Fehler gemeldet.
  2. Bei der Verwendung der Klausel AUTHORIZATION der Anweisung CREATE SCHEMA wird die Gruppenzugehörigkeit des angegebenen Berechtigungsnamens bei der Auswertung der Berechtigungen zur Ausführung der Anweisungen, die dieser Klausel folgen, nicht berücksichtigt. Dies kann zu einem Berechtigungsfehler während der Ausführung der Anweisung CREATE SCHEMA führen.
  3. Wenn ein Paket von einem anderen Benutzer als dem ursprünglichen Binder des Pakets erneut gebunden wird, werden die Zugriffsrechte des ursprünglichen Binders erneut ausgewertet. In diesem Fall wird eine Gruppenzugehörigkeit des ursprünglichen Binders bei der Neuauswertung der Zugriffsrechte nicht berücksichtigt. Dies kann zu einem Berechtigungsfehler beim erneuten Binden führen.

Die DCE-Authentifizierung, wie sie von DB2 durchgeführt wird, arbeitet mit dem Fluß von DCE-Tickets, die mit Hilfe der GSSAPI-Schnittstelle (OSF DCE Generic Security Services Application Programming Interface) abgerufen werden. Sämtliche Authentifizierung für DCE-Sicherheit findet auf der Datenbankprotokollebene statt. Bestimmte Kommunikationseinrichtungen bieten eventuell eine zusätzliche Sicherheit für die Übertragungsebene, die nicht unbedingt in DCE integriert ist. In den Fällen, in den die Authentifizierung auf Übertragungsebene vollständig unabhängig von der Authentifizierung auf der Datenbankprotokollebene erfolgen kann, gibt es keine Einschränkungen. Jedoch müssen die Kriterien sowohl der Authentifizierung auf Datenbankprotokollebene als auch der auf Übertragungsebene erfüllt werden, bevor eine Verbindung erfolgreich hergestellt werden kann. In Fällen, in denen die Funktionen zur Authentifizierung auf Datenbankprotokollebene und auf Übertragungsprotokollebene interagieren, kann ihre Verwendung eingeschränkt sein, wenn einige Kombinationen zu einer Sicherheitsbeeinträchtigung führen.

Die DCE-Authentifizierung kann in Verbindung mit der TCPIP-SOCKS-Unterstützung verwendet werden. Die beiden Sicherheitseinrichtungen arbeiten jedoch unabhängig voneinander. Dies kann bedeuten, daß der Benutzer nicht nur einen gültigen DCE-Anmeldekontext angeben muß, sondern auch mit einer Benutzer-ID des lokalen Betriebssystems angemeldet sein muß, die die Kriterien des SOCKS-Servers erfüllt.

Die DCE-Authentifizierung kann in Verbindung mit benannten NT-Pipes (NT Named Pipes) verwendet werden. Die beiden Sicherheitseinrichtungen arbeiten jedoch unabhängig voneinander. Der Benutzer muß nicht nur einen gültigen DCE-Anmeldekontext angeben, sondern auch mit einer Benutzer-ID an der NT-Domäne angemeldet sein, die die Kriterien der Unterstützung der benannten NT-Pipes erfüllt.

Zur Vermeidung einer möglichen Verwirrung, wenn sowohl DCE-Principals als auch Benutzer-IDs des lokalen Betriebssystems zur Authentifizierung herangezogen werden, wie in den beiden obigen Beispielen, kann eine integrierte DCE-Anmeldung verwendet werden. In diesem Fall wird der Benutzer bei der Anmeldung an einem System außerdem automatisch in den entsprechenden DCE-Principal angemeldet. In der DCE-Dokumentation für Ihre Plattform finden Sie Informationen zur Verwendung dieser Einrichtung, wenn sie unterstützt wird. Beachten Sie, daß bei diesem Verfahren derselbe Name für den DCE-Principal und die ID des lokalen Betriebssystems verwendet wird. Dies bedeutet u. U., daß derselbe Wert, der im verschlüsselten DCE-Ticket enthalten ist, auch unverschlüsselt über die Leitung der Übertragungsebene geht.

Die DCE-Authentifizierung kann nur mit der APPC-Kommunikation verwendet werden, wenn der Parameter SECURITY auf den Wert NONE gesetzt ist. Der Grund dafür ist, daß die Möglichkeit ausgeschaltet werden soll, daß ein unverschlüsselter Principal und/oder ein Kennwort auf der Übertragungsebene gesendet wird, während ein verschlüsseltes DCE-Token für denselben Principal auf der Datenbankprotokollebene verwendet wird. Zum gegenwärtigen Zeitpunkt wird die DCE-Sicherheit auf der APPC-Ebene nicht unterstützt.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]