Sicherer Kennwortspeicher

Ab IBM Spectrum Protect Version 8.1.2 und Version 7.1.8 wird die Position des IBM Spectrum Protect-Kennworts geändert.

In Version 8.1.0 und Version 7.1.6 und früheren Clients wurde das IBM Spectrum Protect-Kennwort im Windows -Register für Windows-Clients gespeichert und in der TSM.PWD-Datei auf UNIX- und Linux®-Clients gespeichert.

Ab Version 8.1.2 und Version 7.1.8 werden die IBM® Global Security Kit (GSKit) Keystores zum Speichern aller IBM Spectrum Protect-Kennwörter verwendet. Der Importprozess für Serverzertifikate ist vereinfacht. Informationen zum Importieren von Serverzertifikaten finden Sie unter IBM Spectrum Protect-Client/Server-Kommunikation mit Secure Sockets Layer konfigurieren.

Wenn Sie ein Upgrade auf den Client von IBM Spectrum Protect 8.1.2 oder höher von einem früheren Client durchführen, der die alten Kennwortpositionen verwendet, werden die vorhandenen Kennwörter in die folgenden Dateien in dem neuen Kennwortspeicher migriert:

TSM.KDB: In dieser Datei werden die verschlüsselten Kennwörters gespeichert.
TSM.sth: In dieser Datei wird der Verschlüsselungszufallsschlüssel gespeichert, mit dem Kennwörter in der Datei TSM.KDB verschlüsselt werden. Diese Datei wird durch das Dateisystem geschützt. Diese Datei wird für automatisierte Operationen benötigt.
TSM.IDX: Eine indexierte Datei zur Protokollierung der Kennwörter in der Datei TSM.KDB.

Linux-Betriebssysteme Windows-Betriebssysteme Bei Data Protection for VMware-Clients wird das Verwaltungskennwort des Data Protection for VMware-GUI-Servers in einen Schlüsselspeicher migriert.

Kennwortpositionen auf Windows-Clients

Auf Windows-Clients werden die Kennwörter im Registrierungsschlüssel SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes und im Registrierungsschlüssel SOFTWARE\IBM\ADSM\CurrentVersion\Nodes in den neuen Kennwortspeicher umgelagert.

Die Kennworteinträge in diesen Registrierungsschlüsseln werden nach der Migration gelöscht.

Die migrierten Server- und Verschlüsselungskennwörter werden in den Kennwortspeichern in separaten Unterverzeichnissen des verborgenen Verzeichnisses C:\ProgramData\Tivoli\TSM\baclient gespeichert. Durch eine derartige Trennung der Serverkennwörter ist es möglich, dass ein Administrator einem Benutzer ohne Verwaltungsaufgaben den Zugriff auf einzelne Kennwörter gewährt, ohne dass dieser Benutzer Zugriff auf alle anderen Kennwörter erhält. Die folgenden Verzeichnisse sind Beispiele für Kennwortdateipositionen:

C:\ProgramData\Tivoli\TSM\BAClient\NodeName\ServerName
C:\ProgramData\Tivoli\TSM\BAClient\(VCB)\ServerName
C:\ProgramData\Tivoli\TSM\BAClient\(DOMAIN)\ServerName
C:\ProgramData\Tivoli\TSM\BAClient\(FILER)\ServerName

Der Zugriff auf die Kennwortstashdateien (TSM.sth) ist auf den Ersteller des Schlüsselspeichers, auf Administratoren und das System beschränkt. Für eine einfache Änderung von Zugriffssteuerungslisten für Kennwortdateien steht Windows-Benutzern ein Dienstprogramm (dsmcutil addace) zur Verfügung. Weitere Informationen finden Sie in ADDACE und in DELETEACE.

Kennwortpositionen auf UNIX -und Linux -Clients

Auf UNIX- und Linux-Clients werden die in den Dateien TSM.PWD vorhandenen Kennwörter in den neuen Kennwortspeicher an derselben Position migriert. Bei Rootbenutzern lautet die Standardposition für den Kennwortspeicher /etc/adsm. Bei Benutzern ohne Rootberechtigung wird die Position des Kennwortspeichers mit der Option passworddir angegeben.

Die Datei TSM.PWD wird nach der Migration gelöscht.

Anmerkung: In den folgenden Situationen befindet sich der neue Kennwortspeicher nicht an der Standardposition (/etc/adsm):

Die Datei TSM.PWD ist im Verzeichnis /etc/adsm nicht vorhanden.
Die Optionsdatei gibt eine Option passworddir an, die auf eine andere Position zeigt.

Trusted Communication Agent nicht mehr verfügbar

Der Trusted Communications Agent (TCA), der zuvor von Nicht-Root-Benutzern in Version 8.1.0 und Version 7.1.6 und früheren Clients verwendet wurde, ist nicht mehr verfügbar. Rootbenutzer können Benutzern ohne Rootberechtigung die Verwaltung ihrer Dateien mit den folgenden Methoden ermöglichen:

Help-Desk: Bei der Help-Desk-Methode führt der Rootbenutzer alle Sicherungs- und Zurückschreibungsoperationen aus. Der Benutzer ohne Rootberechtigung muss sich an den Rootbenutzer wenden, um die Sicherung oder Zurückschreibung bestimmter Dateien anzufordern.
Berechtigter Benutzer: Bei der Methode mit einem berechtigten Benutzer erhält ein Benutzer ohne Rootberechtigung Schreib-/Lesezugriff auf den Kennwortspeicher. Hierbei wird die Option passworddir verwendet, um auf eine Kennwortposition zu zeigen, auf die der Benutzer ohne Rootberechtigung Schreib-/Lesezugriff hat. Mit dieser Methode können Benutzer ohne Rootberechtigung ihre eigenen Dateien sichern und zurückschreiben, die Verschlüsselung verwenden und ihre eigenen Kennwörter mit der Option passwordaccess generate verwalten.
Weitere Informationen enthält der Abschnitt Benutzern ohne Rootberechtigung die Verwaltung eigener Daten ermöglichen.

Ist keine dieser Methoden zufriedenstellend, müssen Sie die früheren Clients verwenden, die über den Trusted Communication Agent (TCA) verfügen.

Kennwortpositionen in Clusterumgebungen

Wird der Client in einer Clusterumgebung ausgeführt (CLUSTERNODE YES in der Clientoptionsdatei), werden die Kennwortdateien in einem Unterverzeichnis des Verzeichnisses der Clientoptionsdatei gespeichert. Der Name des Unterverzeichnisses lautet:

NODES\NodeName\ServerName

Verwenden Sie für die Speicherung einer verschlüsselten Kennwortdatei während der Einrichtung einer Clusterumgebung die Option clustersharedfolder, um die Verzeichnisposition anzugeben, an der die verschlüsselte Kennwortdatei gespeichert werden soll. Weitere Informationen finden Sie unter Clustersharedfolder.

In einer Clusterkonfiguration wird die Optionsdatei auf einer Clusterplatte gespeichert, damit der Übernahmeknoten auf sie zugreifen kann. Die Kennwortdateien müssen auch auf einer Clusterplatte gespeichert werden, damit das generierte Kennwort des Clients für Sichern/Archivieren dem Übernahmeknoten nach einer Störung zur Verfügung steht.

Wenn sich beispielsweise die Datei dsm.opt im Verzeichnis c:\ClusterStorage\Volume1\SPData befindet, der Knotenname Cluster-B und der Servername Bigdata lautet, ist die Position für Kennwortdateien

C:\ClusterStorage\Volume1\SPdata\Nodes\Cluster-B\Bigdata