Gesicherte Verbindungen mit DB2

Gesicherte Verbindungen ermöglichen dem Anwendungsserver die Verwendung gesicherter DB2-Kontextobjekte zum Aufbau von Verbindungen mit einem Benutzer, dessen Berechtigungsnachweise vom DB2-Server für das Öffnen einer Verbindung anerkannt werden. Durch das Erstellen eines gesicherten Kontextes wird dieser Benutzer anschließend als vertrauenswürdig anerkannt und kann andere Benutzeridentitäten im DB2-Server ohne erneute Authentifizierung zusichern. Dieser Prozess erhöht außerdem die Sicherheit Ihrer DB2-Datenbank, da es nicht mehr erforderlich ist, alle Berechtigungen einem einzelnen Benutzer zuzuordnen. Die Implementierung gesicherter Verbindungen führt zur Weitergabe der Clientidentität. Gleichzeitig wird das Verbindungspooling verwendet, um Leistungseinbußen zu vermeiden, die dann entstehen, wenn Verbindungen geschlossen und mit einer anderen Identität erneut geöffnet werden.

Einschränkung: Wenn Sie die Funktionalität für vertrauenswürdige Verbindungen verwenden möchten, müssen Sie DB2 Database for Linux, UNIX und Windows Version 9.5 oder höher oder DB2 Database Version 9.1 oder höher für z/OS verwenden. Sie können gesicherte Verbindungen verwenden, wenn Version 7.0 auf einem iSeries-System installiert ist, vorausgesetzt, eine unterstützte Version von DB2 ist auf einer anderen Plattform als dem iSeries-System installiert und DB2 Universal Driver wird verwendet. Weitere Supportinformationen können Sie der Liste der unterstützten Software für den Anwendungsserver entnehmen.

Damit der erhebliche Aufwand verringert wird, der zum Aufbau neuer Verbindungen erforderlich ist, verwaltet der Verbindungsmanager einen Verbindungspool, in dem jede Verbindung über den Berechtigungsnachweis verfolgt wird, unter dem sie ursprünglich geöffnet wurde. Wenn eine Anwendung eine Verbindung benötigt, verwendet der Verbindungsmanager das Berechtigungsnachweisobjekt, um eine freie Verbindung aus dem Verbindungspool zuzuordnen. Wenn keine freie Verbindung verfügbar ist und die maximale Anzahl an Verbindungen noch nicht erreicht wurde, öffnet der Verbindungspoolmanager unter Verwendung des betreffenden Berechtigungsnachweisobjekts eine neue Verbindung. Diese Verbindungszuordnung ist die Standardverbindungszuordnung, die der Anwendungsserver verwendet, und sie wird als N:1-Zuordnung des Berechtigungsnachweises bezeichnet, da die Verbindung unter Verwendung des Berechtigungsnachweisobjekts im Subjekt geöffnet wird, das normalerweise nicht der RunAs-Identität entspricht. Diese einfache Zuordnung unterstützt ein einfaches Verbindungspooling, aber die Identität des Callers (Aufrufenden) wird niemals an den Datenbankserver weitergegeben.

Damit die Identität des Callers an den Datenbankserver weitergegeben wird, können Sie ein JAAS-Anmeldemodul (Java™ Authentication and Authorization Service) integrieren. Mit dieser Methode kann der Benutzerberechtigungsnachweis im Anwendungsserver dem Benutzerberechtigungsnachweis zugeordnet werden, der für den Sicherheitsrealm des Datenbankservers geeignet ist. Diese Strategie behält die Identität des Callers bei, verwendet jedoch kein Verbindungspooling.

Gesicherte Verbindungen werden anstelle der Standardzuordnung oder einer JAAS-Zuordnung verwendet, um eine Verbindung zur Datenquelle herzustellen. Gesicherte Verbindungen unterstützen die Weitergabe der Clientidentität und können das Verbindungspooling verwenden, um Leistungseinbußen zu vermeiden, die entstehen, wenn Verbindungen geschlossen und mit einer anderen Identität erneut geöffnet werden. Gesicherte Verbindungen nutzen das gesicherte DB2-Kontextobjekt.

Der gesicherte DB2-Kontext ist ein Objekt, das der Datenbankadministrator definiert und das eine Systemberechtigungs-ID sowie eine Reihe von Vertrauensattributen enthält. Die Vertrauensattribute legen die Kriterien einer Verbindung fest, die erfüllt werden müssen, damit die Verbindung als gesicherte Verbindung gilt. Die Beziehung zwischen einer Datenbankverbindung und einem gesicherten Kontext wird hergestellt, wenn die Verbindung zum DB2-Server aufgebaut wird. Nachdem ein gesicherter Kontext definiert und eine erste gesicherte Verbindung zum DB2-Datenbankserver aufgebaut wurde, kann der Anwendungsserver diese Datenbankverbindung von einem anderen Benutzer ohne vollständige erneute Authentifizierung verwenden. Dies liegt daran, dass ein Authentifizierungstoken zusammen mit der Benutzeridentität erforderlich ist. Die Datenbank authentifiziert den Benutzer und prüft anschließend die Berechtigung des Benutzers für den Datenbankzugriff, bevor sie die Verarbeitung von Datenbankanforderungen für diesen Benutzer zulässt.
[z/OS]Einschränkung: Für einen z/OS-Server muss die Benutzeridentität die RACF-ID (Resource Access Control Facility) sein.

Die Verwendung der gesicherten Verbindung stellt die Plug-in-Punkte bereit, die erforderlich sind, damit Sie Ihre eigene gesicherte Implementierung des gesichertenDB2-Kontextes hinzufügen können. Gesicherte Verbindungen trennen die Identität, die zum Erstellen der Verbindung verwendet wurde, von der Identität, die die Services des Back-End-Servers aufruft. Die Verbindung wird von einem Benutzer aufgebaut, dessen Berechtigungsnachweise für das Öffnen der Verbindung vom DB2-Server anerkannt sind. Derselbe Benutzer wird dann auch für die Zusicherung der Identität der anderen Benutzer anerkannt. Diese Zusicherung erhöht auch die Datenbanksicherheit, weil es in diesem Fall nicht mehr erforderlich ist, alle Berechtigungen einem einzelnen Benutzer zu erteilen.

Wenn die Anwendung eine Verbindung zur Datenbank anfordert, kann der Datenbankmanager eine inaktive gesicherte Verbindung ermitteln und die Benutzeridentität gegenüber dem Back-End-Server zusichern. Alle auf dem Back-End-Server ausgeführten Operationen werden von der zugesicherten Benutzeridentität ausgeführt. Möglicherweise muss dennoch eine Identitätszuordnung ausgeführt werden, wenn der Back-End-Server ein anderes Benutzerrepository verwendet als der Anwendungsserver.

Eine neue Zuordnungskonfiguration mit dem Namen TrustedConnectionMapping implementiert gesicherte Verbindungen. Die Konfiguration TrustedConnectionMapping ordnet das RunAs-Subjekt einem Ressourcensubjekt zu, das folgende Elemente enthält:
  • ein Ressourcen-Principal-Objekt, das dieses Ressourcenobjekt darstellt
  • ein PasswordCredential-Objekt in der Gruppe der privaten Berechtigungsnachweise
  • ein IdentityPrincipal-Objekt in der Principal-Gruppe
Das Principal-Objekt stellt die RunAs-Identität dar. Das PasswordCredential-Objekt enthält eine Kombination aus Benutzer-ID und Kennwort, die der Ressourcenadapter zum Aufbau einer gesicherten Verbindung verwendet. Das IdentityPrincipal-Objekt enthält standardmäßig die RunAs-Identität, kann aber so geändert werden, dass es die Identität des Callers verwendet. Das IdentityPrincipal-Objekt enthält außerdem eine ursprüngliche Benutzeridentität, die den Benutzer darstellt, der die Anforderung ursprünglich gesendet hat, einen optionalen Realmnamen, der die Gruppe der Registrys angibt, in denen die Benutzeridentität definiert ist, und ein optionales Sicherheitstoken, bei dem es sich um einen serialisierten Sicherheitskontext des Benutzers handelt.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_trustedconnections
Dateiname:csec_trustedconnections.html