SQL Server vu par Christian Robert

SQL Server 2005 : Mise en place d’une sécurité à base de certificat sous SQL Server 2005

Généralement lors de l'utilisation de serveurs multiples sous SQL Server l'utilisation d'un domaine dans lequel se trouvent tous les serveurs SQL Server est fortement conseillée. Même s'il existe des astuces pour se passer d'un domaine, celui facilite grandement la vie.

Mais dans certains cas l'utilisation d'un domaine est impossible pour des questions de sécurité et l'authentification entre 2 serveurs SQL Server reste tout de même une nécessite. Prenons par exemple le cas d'un serveur SQL Server présent dans une DMZ, c'est prendre un grand risque que de joindre ce dernier au domaine de l'entreprise.

Heureusement SQL Server 2005 est arrivé avec une solution alternative très intéressante, l'authentification par certificat.

Anciennement une connexion distante sur un serveur ne peut se faire que si vous êtes dans un domaine, que les 2 serveurs de base de données sont dans ce même domaine et que vous vous connectez à l'aide de l'authentification Windows. Autre choix possible l'utilisation de serveur liés permettant de mapper manuellement un compte de sécurité local avec un compte de sécurité distant (encore fois t'il que les mots de passe ne changent pas).

Sinon point de salut, impossible de connecter à distance avec un même compte. Dans l'exemple ci-dessous les 2 serveurs sont dans des domaines différents et un Login SQL intitulé « ConnexionX » tente de se connecter sur le second serveur B par exemple pour une mise en place de mirroring. La tentative de connexion échoue.

Dans le cas d'une configuration sécurisée à base de certificat, ce même Login « ConnexionX », dispose d'un certificat (peut importe la manière dont il a été généré) avec la paire clef publique / privée. Ce certificat est recopié partiellement (uniquement la composante publique de celui-ci) sur le second serveur et est associé à un autre login (ici « ConnexionY »). Dès lors que ConnexionX se connecte le serveur B celui-ci disposera des droits accordés au Login ConnexionY

L'intérêt est bien d'avoir 2 serveurs distincts se connectant l'un à l'autre avec seulement quelques comptes servant au dialogue. Cette configuration bien qu'intéressante hors d'un domaine devient cependant complexe lorsque le nombre de serveurs en cause augmente.

L'utilisation ce type d'authentification se fera dans les quelques cas suivant :

• Serveurs liés avec connexion SQL
• Replication
• Mirroring
• Service broker avec connexion distante
• Etc.

Pour paramétrer tout cas, quelques scripts…

Côté Serveur A pour une mise en place de d'une communication sécurisé pour un database mirroring :

USE master
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '{425C4D21-AD5D-4807-A612-74C212759F7E}';
GO

CREATE CERTIFICATE A_CERT
   WITH SUBJECT = 'A', START_DATE = '20070101',  EXPIRY_DATE = '20501231';
GO


CREATE ENDPOINT A_MIRROR_END
   STATE = STARTED
   AS TCP (
      LISTENER_PORT = 7024
      , LISTENER_IP = (192.168.25.2)
   )
   FOR DATABASE_MIRRORING (
      AUTHENTICATION = CERTIFICATE A_CERT
      , ENCRYPTION = DISABLED
      , ROLE = PARTNER
   );
GO

BACKUP CERTIFICATE A_CERT TO FILE = 'C:\A_CERT.cer';
GO

Même chose à exécuter sur le second serveur (mais pour un autre certificat : B_CERT). Ensuite on recopie les fichiers de certificat générés sur les serveurs on les copies sur le ou les autres serveurs (ici A_CERT est copié sur B et B_CERT sur A).

Puis pour autoriser les connexions entrantes sur le serveur, je me positionne sur le serveur B (on présume ici que B_MIRROR_END existe déjà et que le fichier de A_CERT a été copié dans le système de fichier) :

USE master;
CREATE LOGIN B_login WITH PASSWORD = '{9CDA5CAF-9F82-4989-B300-5B90E02D64B1}';
GO

CREATE USER B_user FOR LOGIN B_login;
GO

CREATE CERTIFICATE B_CERT
   AUTHORIZATION B_user
   FROM FILE = 'C:\B_CERT.cer'
GO

GRANT CONNECT ON ENDPOINT::A_MIRROR_END TO B_login;
GO

On reproduit le même type de script sur A ensuite (A et B inversé) et la configuration est prête.

Dans cet exemple, les mots de base sont générés à base de GUID, c'est uniquement pour avoir un mot de passe suffisamment fort que j'ai cela et aléatoire, ce n'est en aucun cas une obligation.

Bonne sécurité…