Datenanbieter für die Sicherheit und den Schutz von DB2
Sie können die Datenanbieter für DB2 verwenden, um Windows-Datenverbraucheranwendungen mit IBM DB2-Remoteverwaltungsservern für relationale Datenbanken zu verbinden. Der Datenanbieter dient als standardmäßigen DRDA (Distributed Relational Database Architecture)-Anwendungsanforderer, der das DRDA-Protokoll und Formate, die mit den IBM DB2-Serverprodukten kompatibel sind, unterstützt.
Sie können die Datenanbieter nutzen, indem Sie strukturierte Abfragesprach-Anweisungen ausstellen. Diese enthalten DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) für Verwaltungs- und Datenbearbeitungsanweisungen für Lese- und Schreibvorgänge. Die Datenanbieter verbindet die Windows-Clientanwendungen mit den DB2-Serverdatenbanken über ein Übertragungssteuerungsprotokoll über ein TCP/IP-Netzwerk (Internet Protocol) oder SNA (Systems Network Architecture) Hochleistungs-Rounting via Internet-Protokoll (HPR/IP), die mindestens eines der optionalen Sicherheitsfeatures verwenden, die weiter unten in diesem Thema beschrieben werden sollen.
Sicherheit
Benutzerkonto
Die Datenanbieter Tools, Datenzugriffstool und Datenlinks, werden im Kontext eines Benutzerkontos ausgeführt. Das Benutzerkonto muss Mitglied der lokalen Gruppen HIS-Administratoren und HIS-Laufzeitbenutzer sein.
Zugriffssteuerungsliste für Ordner
Für jedes Benutzerkonto ist die Einstellung der Zugriffssteuerungsliste für Ordner erforderlich, die der lokalen Gruppe der HIS Administratoren und der HIS-Laufzeitbenutzer zugeordnet ist.
Programme\Microsoft Host Integration Server 2020
Programme\Microsoft Host Integration Server 2020\system
Programme\Microsoft Host Integration Server 2020\ SysWOW64
Programme\Microsoft Host Integration Server 2020\traces
Dokumente\Host Integration Server\Data Sources
Schutz
Der Datenanbieter gewährt der öffentlichen DB2-Gruppe Berechtigungen zum Ausführen des DB2-Pakets
Beim Erstellen von DB2-Paketen legen das Datenzugriffstool und die DB2-Datenanbieter die Ausführungsberechtigungen der DB2-Pakete auf PUBLIC(öffentlich) fest. Dies schließt alle DB2-Benutzer mit ein. Damit die Sicherheit auf Ihrem DB2-Server optimiert wird, wird empfohlen, die Ausführungsberechtigungen für PUBLIC (öffentlich) für diese Pakete zu widerrufen und sie nur ausgewählten DB2-Benutzern oder -Gruppen zu erteilen.
Data Tools speichert die Authentifizierungs- und Anmeldeinformationen als Klartext in der UDL-Datei (Universal Data Link) oder in der Verbindungsfolge-Datei (TXT)
Der Datenquellen-Assistent und die Datenverknüpfungen speichern die Authentifizierungs-Anmeldeinformationen (Benutzername und Kennwort) als Klartext in der UDL- (Universal Data Link) oder Verbindungszeichenfolgen-Datei (TXT). Es wird empfohlen, die Datenanbieter für die Verwendung von Enterprise Single Sign-On (ESSO) so zu konfigurieren, dass sie die Zuordnungen von Windows Active Directory-Konten zu IBM DB2-Anmeldeinformationen sicher speichert. Der Datenanbieter kann diese Zuordnungen zur Laufzeit abrufen, um Benutzer sicher bei IBM DB2-Remotedatenbankservern zu authentifizieren. Sie sollten den Datenanbieter In-Process mit dem Datenconsumer und den Data Tools ausführen.
DRDA unterstützt schwache integrierte Verschlüsselung basierend auf DES
Optional unterstützt der DRDA-Dienst auch die Authentifizierung und Verschlüsselung mithilfe schwacher 56-Bit-DES-Technologien (Data Encryption Standard). Es wird empfohlen, den Datenanbieter so zu konfigurieren, dass er eine starke Datenverschlüsselung verwendet, indem Sie SSL V3.0 (Secure Sockets Layer) oder TLS V2.0 (Transport Layer Security) verwenden. Um nur die Authentifizierung zu verschlüsseln, können Sie den AES (Advanced Encryption Standard) verwenden, um starke 256-Bit-Verschlüsselung zu unterstützen.
Der Datenanbieter stellt die Verbindung mit unverschlüsseltem Benutzernamen und Kennwort (rein-Text) her
Standardmäßig stellt der Datenanbieter die Verbindung mit den DB2-Remoteservern über ein TCP/IP-Netzwerk mithilfe von Standardauthentifizierung her. Dabei werden der Benutzername und das Kennwort unverschlüsselt als reiner Text übertragen. Es wird empfohlen, dass Sie den Datenanbieter für die Verwendung der Authentifizierungsverschlüsselung mittels Kerberos, SSL V3.0 (Secure Sockets Layer) oder TLS V1.0 (Transport Layer Security) oder für Authentifizierungsverschlüsselung mittels AES konfigurieren.
Der Datenanbieter sendet und empfängt unverschlüsselte Daten.
Der Datenanbieter sendet und empfängt unverschlüsselte Daten. Es wird empfohlen, dass Sie den Datenanbieter für die Verwendung der Datenverschlüsselung mittels SSL V3.0 (Secure Sockets Layer) oder TLS V1.0 (Transport Layer Security) konfigurieren.
Verschlüsselungsstandards für DB2
Die folgende Tabelle beschreibt die unterstützten Verschlüsselungsstandards für DB2.
| Verschlüsselung | Authentifizierung | Daten |
|---|---|---|
| Kerberos | Ja | Nein |
| SSL V3 | Ja | Yes |
| TLS V2 | Yes | Ja |
| AES | Ja | Nein |
Datenconsumer und Data Tools lesen und schreiben Verbindungsdateien für und von unsichere(n) Ordner(n)
Datenconsumer und Data Tools lesen und schreiben Verbindungsdateien für und von unsichere(n Ordnern. Sie sollten die UDL-Dateien (Universal Data Link) auf dem Host Integration Server im Verzeichnis „Data Sources“ oder in einem Programmverzeichnis speichern, das dann mithilfe von lokalen Administratorrechten gesichert wird. Die Verbindungsinformationen sollten in den sicheren Datenspeichern der Datenconsumer und der Data Tools dauerhaft gespeichert werden, und der Datenanbieter sollte In-Process mit dem Datenconsumer und den Data Tools ausgeführt werden.
Datenconsumer und Data Tools können Verbindungen mit ungültigen Eigenschaften anfordern
Datenconsumer und Data Tools können Verbindungen mit ungültigen Eigenschaften anfordern. Sie sollten die Datenconsumer verwenden, die Verbindungen mithilfe der Datenanbieter-Verbindungsobjekte herstellen, statt nicht überprüfte Wertpaare aus Argument und Name in Verbindungszeichenfolgen zu übergeben. Sie sollten einen Timeoutwert für Verbindungen festlegen, um ungültige Verbindungsversuche abzubrechen.
Datenverbraucher und Datentools können Befehle mit ungültigen Daten anfordern
Datenverbraucher und Datentools können Befehle mit ungültigen Daten anfordern. Verwenden Sie möglichst die Datenconsumer, die Befehle mithilfe des Datenanbieterbefehls mit Parameterobjekten erstellen, um Parametertypen zu überprüfen, statt nicht geprüfte Befehlszeichenfolgen mit Inline-Datenwerten zu übergeben. Sie sollten einen Timeoutwert für die Befehlsausführung festlegen, um ungültige Versuche zur Befehlsausführung abzubrechen. Sie sollten verteilte DRDA-Arbeitseinheiten (DUW, Distributed Unit of Work) anstelle von Remote-Arbeitseinheiten (RUW, Remote Unit of Work) für den Schutz von Datenconsumern verwenden, die mit zweiphasigen Committransaktionen arbeiten.