Sicherer und optimierter Benutzerzugriff in einer Db2-Verbunddatenbank auf AWS mithilfe vertrauenswürdiger Kontexte

Erstellt von Sai Parthasaradhi (AWS)

Umgebung: PoC oder Pilotprojekt	Technologien: Datenbanken; Sicherheit, Identität, Compliance	Arbeitslast: IBM
AWS-Dienste: Amazon EC2

Übersicht

Viele Unternehmen migrieren ihre älteren Mainframe-Workloads zu Amazon Web Services (AWS). Diese Migration beinhaltet die Umstellung von IBM Db2 for z/OS-Datenbanken auf Db2 für Linux, Unix und Windows (LUW) auf Amazon Elastic Compute Cloud (Amazon EC2). Während einer schrittweisen Migration von lokal zu AWS müssen Benutzer möglicherweise auf Daten in IBM Db2 z/OS und in Db2 LUW auf Amazon EC2 zugreifen, bis alle Anwendungen und Datenbanken vollständig auf Db2 LUW migriert sind. In solchen Szenarien für den Fernzugriff auf Daten kann die Benutzerauthentifizierung eine Herausforderung sein, da verschiedene Plattformen unterschiedliche Authentifizierungsmechanismen verwenden.

Dieses Muster beschreibt, wie Sie einen Verbundserver auf Db2 für LUW mit Db2 for z/OS als Remote-Datenbank einrichten. Das Muster verwendet einen vertrauenswürdigen Kontext, um die Identität eines Benutzers von Db2 LUW an Db2 z/OS weiterzugeben, ohne sich in der entfernten Datenbank erneut authentifizieren zu müssen. Weitere Informationen zu vertrauenswürdigen Kontexten finden Sie im Abschnitt Zusätzliche Informationen.

Voraussetzungen und Einschränkungen

Voraussetzungen

• Ein aktives AWS-Konto

• Eine Db2-Instance, die auf einer Amazon EC2 EC2-Instance läuft

• Eine Remote-Datenbank von Db2 for z/OS, die lokal ausgeführt wird

• Das lokale Netzwerk, das über AWS Site-to-Site VPN oder AWS Direct Connect mit AWS verbunden ist

Architektur

Zielarchitektur

Tools

AWS-Services

• Amazon Elastic Compute Cloud (Amazon EC2) bietet skalierbare Rechenkapazität in der AWS-Cloud. Sie können so viele virtuelle Server wie nötig nutzen und sie schnell nach oben oder unten skalieren.

• Mit AWS Site-to-Site VPN können Sie den Datenverkehr zwischen Instances, die Sie auf AWS starten, und Ihrem eigenen Remote-Netzwerk weiterleiten.

Andere Dienste

• db2cli ist der Db2-Befehl für die interaktive Befehlszeilenschnittstelle (CLI).

Epen

Aktivieren Sie den Verbund in der Db2-LUW-Datenbank, die auf AWS ausgeführt wird

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Aktivieren Sie den Verbund auf der DB2 LUW-DB.	Führen Sie den folgenden Befehl aus, um den Verbund auf DB2 LUW zu aktivieren. update dbm cfg using federated YES	DBA
Starten Sie die Datenbank neu.	Führen Sie den folgenden Befehl aus, um die Datenbank neu zu starten. db2stop force; db2start;	DBA

Katalogisieren Sie die entfernte Datenbank

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Katalogisieren Sie das Remote-Db2 z/OS-Subsystem.	Verwenden Sie den folgenden Beispielbefehl, um die entfernte Db2 z/OS-Datenbank auf Db2 LUW zu katalogisieren, die auf AWS ausgeführt wird. catalog TCPIP NODE tcpnode REMOTE mainframehost SERVER mainframeport	DBA
Katalogisieren Sie die entfernte Datenbank.	Verwenden Sie den folgenden Beispielbefehl, um die entfernte Datenbank zu katalogisieren. catalog db dbnam1 as ndbnam1 at node tcpnode	DBA

Erstellen Sie die Remoteserver-Definition

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Sammeln Sie Benutzeranmeldeinformationen für die entfernte Db2 z/OS-Datenbank.	Bevor Sie mit den nächsten Schritten fortfahren, sammeln Sie die folgenden Informationen: Name des Db2 z/OS-Subsystems — Der katalogisierte Db2 z/OS-Name auf der LUW aus dem vorherigen Schritt (zum Beispiel) ndbnam1 Db2 z/OS-Version — Die Version des Db2 z/OS-Subsystems (zum Beispiel) 12 Db2 z/OS-Benutzer-ID — Der Benutzer mit der BIND-Berechtigung, die nur zum Erstellen der Serverdefinition benötigt wird (zum Beispiel) dbuser1 Db2 z/OS-Passwort — Das Passwort für dbuser1 (zum Beispiel) dbpasswd Db2 z/OS-Proxybenutzer — Die ID des Proxybenutzers, die verwendet wird, um eine vertrauenswürdige Verbindung herzustellen (z. B.) zproxy Db2 z/OS Proxy-Passwort — Das Passwort für den zproxy Benutzer (zum Beispiel) zproxy	DBA
Erstellen Sie den DRDA-Wrapper.	Führen Sie den folgenden Befehl aus, um den DRDA-Wrapper zu erstellen. CREATE WRAPPER DRDA;	DBA
Erstellen Sie die Serverdefinition.	Führen Sie den folgenden Beispielbefehl aus, um die Serverdefinition zu erstellen. CREATE SERVER ndbserver TYPE DB2/ZOS VERSION 12 WRAPPER DRDA AUTHORIZATION "dbuser1" PASSWORD "dbpasswd" OPTIONS ( DBNAME 'ndbnam1',FED_PROXY_USER 'ZPROXY' ); In dieser Definition wird der Proxybenutzer FED_PROXY_USER angegeben, der für den Aufbau vertrauenswürdiger Verbindungen zur Db2 z/OS-Datenbank verwendet wird. Die Benutzer-ID und das Kennwort für die Autorisierung sind nur für die Erstellung des Remoteserverobjekts in der Db2 LUW-Datenbank erforderlich. Sie werden später während der Laufzeit nicht verwendet.	DBA

Benutzerzuordnungen erstellen

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie eine Benutzerzuordnung für den Proxybenutzer.	Führen Sie den folgenden Befehl aus, um eine Benutzerzuordnung für den Proxybenutzer zu erstellen. CREATE USER MAPPING FOR ZPROXY SERVER ndbserver OPTIONS (REMOTE_AUTHID 'ZPROXY', REMOTE_PASSWORD 'zproxy');	DBA
Erstellen Sie Benutzerzuordnungen für jeden Benutzer auf Db2 LUW.	Erstellen Sie Benutzerzuordnungen für alle Benutzer in der Db2 LUW-Datenbank auf AWS, die über den Proxybenutzer auf Remote-Daten zugreifen müssen. Führen Sie den folgenden Befehl aus, um die Benutzerzuordnungen zu erstellen. CREATE USER MAPPING FOR PERSON1 SERVER ndbserver OPTIONS (REMOTE_AUTHID 'USERZID', USE_TRUSTED_CONTEXT 'Y'); Die Anweisung gibt an, dass ein Benutzer auf Db2 LUW (PERSON1) eine vertrauenswürdige Verbindung zur entfernten Db2 z/OS-Datenbank () herstellen kann. USE_TRUSTED_CONTEXT 'Y' Nachdem die Verbindung über den Proxybenutzer hergestellt wurde, kann der Benutzer mithilfe der Db2 z/OS-Benutzer-ID () auf die Daten zugreifen. REMOTE_AUTHID 'USERZID'	DBA

Erstellen Sie das vertrauenswürdige Kontextobjekt

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie das vertrauenswürdige Kontextobjekt.	Verwenden Sie den folgenden Beispielbefehl, um das vertrauenswürdige Kontextobjekt in der entfernten Db2 z/OS-Datenbank zu erstellen. CREATE TRUSTED CONTEXT CTX_LUW_ZOS BASED UPON CONNECTION USING SYSTEM AUTHID ZPROXY ATTRIBUTES ( ADDRESS '10.10.10.10' ) NO DEFAULT ROLE ENABLE WITH USE FOR PUBLIC WITHOUT AUTHENTICATION; In dieser Definition CTX_LUW_ZOS steht ein beliebiger Name für das vertrauenswürdige Kontextobjekt. Das Objekt enthält die Proxy-Benutzer-ID und die IP-Adresse des Servers, von dem die vertrauenswürdige Verbindung ausgehen muss. In diesem Beispiel ist der Server die Db2-LUW-Datenbank auf AWS. Sie können den Domainnamen anstelle der IP-Adresse verwenden. Die Klausel WITH USE FOR PUBLIC WITHOUT AUTHENTICATION gibt an, dass das Wechseln der Benutzer-ID bei einer vertrauenswürdigen Verbindung für jede Benutzer-ID zulässig ist. Ein Passwort muss nicht angegeben werden.	DBA

Zugehörige Ressourcen

• IBM Resource Access Control Facility (RACF)

• IBM Db2 LUW-Verbund

• Vertrauenswürdige Kontexte

Zusätzliche Informationen

Vertrauenswürdige Db2-Kontexte

Ein vertrauenswürdiger Kontext ist ein Db2-Datenbankobjekt, das eine Vertrauensstellung zwischen einem Verbundserver und einem entfernten Datenbankserver definiert. Um eine vertrauenswürdige Beziehung zu definieren, spezifiziert der vertrauenswürdige Kontext Vertrauensattribute. Es gibt drei Arten von Vertrauensattributen:

• Die Systemautorisierungs-ID, die die erste Datenbankverbindungsanforderung stellt

• Die IP-Adresse oder der Domainname, von dem aus die Verbindung hergestellt wird

• Die Verschlüsselungseinstellung für die Datenkommunikation zwischen dem Datenbankserver und dem Datenbankclient

Eine vertrauenswürdige Verbindung wird hergestellt, wenn alle Attribute einer Verbindungsanforderung mit den Attributen übereinstimmen, die in einem vertrauenswürdigen Kontextobjekt angegeben sind, das auf dem Server definiert ist. Es gibt zwei Arten von vertrauenswürdigen Verbindungen: implizite und explizite. Nachdem eine implizite vertrauenswürdige Verbindung hergestellt wurde, erbt ein Benutzer eine Rolle, die ihm außerhalb des Geltungsbereichs dieser vertrauenswürdigen Verbindungsdefinition nicht zur Verfügung steht. Nachdem eine explizite vertrauenswürdige Verbindung hergestellt wurde, können Benutzer auf dieselbe physische Verbindung mit oder ohne Authentifizierung umgeschaltet werden. Darüber hinaus können Db2-Benutzern Rollen zugewiesen werden, die Rechte spezifizieren, die nur innerhalb der vertrauenswürdigen Verbindung verwendet werden dürfen. Dieses Muster verwendet eine explizite vertrauenswürdige Verbindung.

Vertrauenswürdiger Kontext in diesem Muster

Nachdem das Muster vollständig ist, greift PERSON1 auf Db2 LUW mithilfe eines föderierten vertrauenswürdigen Kontextes auf Remotedaten von Db2 z/OS zu. Die Verbindung für PERSON1 wird über einen Proxybenutzer hergestellt, wenn die Verbindung von der IP-Adresse oder dem Domänennamen stammt, der in der Definition des vertrauenswürdigen Kontextes angegeben ist. Nachdem die Verbindung hergestellt wurde, wird die entsprechende Db2 z/OS-Benutzer-ID von PERSON1 ohne erneute Authentifizierung ausgetauscht, und der Benutzer kann auf der Grundlage der für diesen Benutzer eingerichteten Db2-Berechtigungen auf die Daten oder Objekte zugreifen.

Vorteile verbundener vertrauenswürdiger Kontexte

• Bei diesem Ansatz wird das Prinzip der geringsten Rechte beibehalten, indem die Verwendung einer gemeinsamen Benutzer-ID oder Anwendungs-ID vermieden wird, für die eine Obermenge aller von allen Benutzern benötigten Rechte erforderlich wäre.

• Die tatsächliche Identität des Benutzers, der die Transaktion sowohl in der Verbunddatenbank als auch in der Remote-Datenbank durchführt, ist immer bekannt und kann überprüft werden.

• Die Leistung verbessert sich, da die physische Verbindung von allen Benutzern wiederverwendet wird, ohne dass sich der Verbundserver erneut authentifizieren muss.