Schutz
Dieses Thema beschreibt die unterstützten Standards für den Schutz von DB2.
Verschlüsselungsstandards für DB2
Die folgende Tabelle beschreibt die unterstützten Verschlüsselungsstandards für DB2.
| Verschlüsselung | Authentifizierung | Daten |
|---|---|---|
| Kerberos | Ja | Nein |
| Secure Sockets Layer (SSL) V3 | Ja | Ja |
| Transport Layer Security (TLS) V1 | Ja | Ja |
| Advanced Encryption Standard (AES) | Ja | Nein |
Konfiguration für den Schutz
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-Anmeldeinformationen als Klartext in der UDL-Datei (Universal Data Link)
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, den Datenanbieter für die Verwendung von Enterprise Single Sign-On (SSO) zu konfigurieren, wodurch Zuordnungen von Windows Active Directory-Konten zu IBM DB2-Anmeldeinformationen sicher gespeichert werden. Der Datenanbieter ruft diese Zuordnungen zur Laufzeit ab, um Benutzer sicher bei IBM DB2-Remotedatenbankservern zu authentifizieren. Sie sollten den Datenanbieter In-Process mit dem Datenconsumer und den Data Tools ausführen.
Datenanbieter stellt die Verbindung mit unverschlüsseltem Benutzernamen und Kennwort (Nur-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.
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.
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. UDL-Dateien (Universal Data Link) sollten auf dem Host Integration Server im Verzeichnis „Data Sources“ oder in einem Programmverzeichnis gespeichert werden, 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.