\HKEY_LOCAL_MACHINE\SOFTWARE\Telelogic\DOORS_Server\9.5\Config
Si vous exécutez un système Windows 64 bits, la clé se trouve dans ce chemin :
\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Telelogic\DOORS_Server\9.5\Config
Les commutateurs -serverhostname et -secure sont destinés à activer la connexion sécurisée. Ces commutateurs sont référencés dans la rubrique Avant de commencer.
Les commutateurs d'activation de la sécurité du serveur sont des options de serveur. Lorsque la sécurité du serveur est activée à l'aide de l'argument de ligne de commande, le serveur mémorise sa valeur lors des exécutions ultérieures (lorsqu'aucun commutateur d'activation de la sécurité du serveur n'est fourni).
Par défaut, la sécurité du serveur est désactivée. Lorsque vous l'activez, elle se maintient (voir la remarque précédente).
Pour désactiver la sécurité du serveur, utilisez le commutateur -serverSecurityDisable.
Si Rational DOORS est configuré pour utiliser Rational Directory Server, les utilisateurs existants doivent être signés. Pour signer les utilisateurs existants, démarrez un client Rational DOORS, connectez-vous en tant qu'administrateur et exécutez l'autorisation DXL signTdsUsers(). Vous devez exécuter l'autorisation DXL chaque fois que vous changez le serveur de base de données Rational DOORS.
Par exemple, configurez le mot de passe à l'aide d'une commande au format suivant :
dbadmin.exe -d 36700@IBMEDSERV -keyDB "C:\path\to\key\db.kdb" -p NewPasswordAprès avoir affecté le mot de passe dbadmin, indiquez chaque requête à l'aide d'une commande au format suivant :
dbadmin.exe -d 36700@IBMEDSERV -keyDB "C:\path\to\key\db.kdb" -P NewPassword -lLorsque la sécurité du serveur est activée, les clients appliquent les droits d'accès habituels aux informations dans la base de données. L'accès utilisateur à la base de données est le même que le système utilise la sécurité serveur ou le modèle de sécurité Rational DOORS classique.
Toutefois, si un utilisateur obtient un accès non autorisé à la base de données, et qu'il a un accès en lecture à un module, il dispose de l'accès complet aux contenus du module.
Pour vous prémunir de ce danger, vérifiez que les modules qui contiennent des données sensibles sont protégés. Autorisez l'accès au module uniquement si un utilisateur en a besoin. Si un utilisateur n'a pas besoin d'accéder à un module, ne définissez pas l'accès en lecture pour celui-ci. Définissez son accès sur aucun. De cette manière, même si un utilisateur obtient un accès non autorisé à la base de données, il ne peut pas accéder au module.
Par exemple, pour définir la méthode sur clés d'utilisateur, entrez :
dbadmin.exe -d 36700@IBMEDSERV -keyDB C:\path\to\certificate\db\client_authentication.kdb -certName DBM1 -P samplePassword -sssAuthenticationMode UserKeys
Ces options sont valides pour le commutateur -sssAuthenticationMode :
UserKeys
UsernamePassword
UsernamePasswordAndUserKeys