Comment protéger votre base de données SQL Server contre les attaques MITM avec DataSunrise
1 Qu’est-ce que MITM?
Lorsqu’un client se connecte à un serveur via un canal protégé, il existe un risque qu’une tierce partie se connecte entre eux qui a la capacité d’écouter et d’interférer avec les communications. Les attaques réseau lancées par le biais d’une telle tierce partie sont appelées attaques de l’homme du milieu (MITM). Il existe de nombreuses façons de mener une telle attaque, mais le principe de base est de faire en sorte que le client se connecte secrètement au serveur de l’attaquant.
2 Comment se protéger contre MITM?
La principale méthode de protection contre les attaques MITM est d’analyser l’infrastructure réseau au moment de la connexion au serveur et de détecter des paramètres suspects qui ne sont pas typiques pour la connexion à un certain serveur. Si le protocole SSL est utilisé pour la protection, un client peut vérifier le certificat du serveur lors de la poignée de main. Un certificat peut avoir beaucoup de paramètres, échangés entre le client et le serveur lors de l’authentification. La pratique standard pour SSL est de mettre fin à une connexion immédiatement si une partie accepte un paramètre (Nom de répertoire, DNS, Email, GUID, IP, UPN, URL et tout autre) qui n’est pas pertinent pour les paramètres de son environnement. Mais même une telle vérification de certificat ne peut garantir une sécurité totale, car l’infrastructure du client au moment de l’attaque peut être significativement modifiée pour passer le contrôle. C’est pour cela que des méthodes supplémentaires de validation du certificat sont souvent utilisées. Une de ces méthodes est la signature d’un certificat par une autorité de confiance. Il est convenu qu’il est impossible de falsifier une telle signature, et chaque client peut vérifier son authenticité. C’est pourquoi tout certificat signé par une autorité spéciale pourrait être accepté comme plus ou moins sûr, en fonction de l’autorité de l’émetteur.
3 Protection contre MITM dans MS SQL Server
Le contrôle du certificat est facultatif dans MS SQL, mais il est activé par défaut. Les deux principaux paramètres participant à une vérification de certificat sont la date d’expiration du certificat et le nom de l’hôte pour lequel le certificat est émis (Nom commun). Si un certificat est expiré, ou s’il n’est pas délivré pour l’hôte d’un serveur avec lequel une connexion est établie, la connexion sera immédiatement interrompue avec notification de l’utilisateur. Dans le cas où une autorité de certification est impliquée dans la vérification supplémentaire du certificat, le client vérifiera sa signature. Dans de tels cas, il devrait y avoir un certificat racine de cette autorité dans le stockage des certificats. Beaucoup de systèmes d’exploitation modernes incluent des ensembles pré-construits de certificats racine des autorités les plus fiables, c’est pourquoi lors de la sélection d’une autorité de certification pour signer un certificat d’entreprise, il serait sage de sélectionner celui de la liste.
Dans SSMS moderne, il y a une case à cocher supplémentaire «Faire confiance au certificat du serveur» sur la page de connexion du serveur. Elle est utilisée pour vérifier le certificat du serveur. Lors de la connexion à un serveur via ODBC, il y a un paramètre supplémentaire, “TrustServerCertificate”, dans la chaîne de connexion. La valeur “Oui” désactive le contrôle et “non” – l’active.
4 Certificats dans DataSunrise
Le proxy de DataSunrise est de confiance, mais, néanmoins une tierce partie de la connexion, c’est pourquoi tous les moyens de protection du client contre MITM seraient activés au moment de la connexion avec un tel proxy.
Dans DataSunrise, chaque instance de base de données fonctionne avec un ensemble de clés privées et un certificat. Du point de vue du client, cet ensemble appartient au serveur, mais en général, ces clés ne sont associées d’aucune manière au serveur de fin qui sert le proxy de DataSunrise. C’est ce certificat que le client vérifiera si la protection contre MITM est activée.
5 Possibles configurations de DataSunrise incluant la protection contre MITM
Pour fournir un niveau de protection similaire de connexion directe et de connexion proxy, il est nécessaire de configurer correctement les hôtes de DataSunrise et du client. Il pourrait y avoir plusieurs options de configuration.
Un ensemble par défaut de clés et un certificat fournissent une protection minimale. Il n’est pas garanti que le certificat par défaut correspond au nom d’hôte CN=DataSunrise Database Security Suite. C’est pourquoi la première chose que vous devriez faire pour sécuriser une connexion est de générer un nouvel ensemble de clés et un certificat.
Un ensemble de clés de base et un certificat sont inclus dans le fichier proxy.pem. C’est ce fichier qui doit être remplacé.
5.1 Cas général
C’est le cas le plus simple, lorsqu’un administrateur n’a à sa disposition qu’une seule instance de DataSunrise et un serveur MS SQL. Et il y a un ensemble établi et limité de clients qui peuvent accéder aux serveurs donnés via DataSunrise. Ce cas implique deux options:
5.1.1 Génération de proxy.pem (certificat auto-signé)
C’est la méthode la plus simple de génération de nouvelles clés. Créer un fichier proxy.cfg (“commonName” doit inclure le nom réel de l’hôte de DataSunrise):
[req]
distinguished_name = req_distinguished_name
prompt = no
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected] Exécutez le fichier .bat suivant dans le dossier où se trouve le fichier de configuration du proxy:
SET RANDFILE=random
SET PASS=R0T3qSW2s0459koH54
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -config proxy.cfg -new -key key.pem -out certificate.req
openssl req -sha384 -x509 -config proxy.cfg -days 365 -key key.pem -in certificate.req -out certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req key.pem dh.pem ec.pem Après l’exécution du script, nous devrions obtenir un fichier proxy.pem avec une clé RSA de 2048 bits, une clé DH de 1024 bits, des paramètres EC avec une courbe “secp256r1” et un certificat émis pour 365 jours avec l’algorithme de signature “sha384”.
En outre, il devrait être généré un fichier certificate.cer qui devrait être installé dans le stockage sécurisé des certificats du client.
5.1.2 Installation d’un certificat et de clés de proxy via l’UI
Si un utilisateur a déjà un ensemble de clés et un certificat, ils peuvent être installés via l’UI web de DataSunrise.
Pour définir les clés et un certificat pour un proxy, effectuez les opérations suivantes:
- Créez un groupe de clés SSL de type Client Side.
- Remplissez ce groupe avec tous les paramètres nécessaires en codage Base64 : un certificat, une clé privée, les paramètres DH, les paramètres EC
- Connectez ce groupe à une instance en le sélectionnant dans la liste Key Group
Les deux options (5.1.1 et 5.1.2) vous demandent de redémarrer le Core de DataSunrise après avoir remplacé les clés, et d’installer un certificat créé pour DataSunrise dans un stockage de certificats de confiance du côté du client.
5.2 Plusieurs instances de DataSunrise
La configuration suivante est pour plusieurs instances de DataSunrise. Si vous utilisez les conseils du cas général décrits ci-dessus, il serait nécessaire d’installer un ensemble complet de certificats du côté du client et de surveiller leur applicabilité. Pour éviter d’éventuelles erreurs, vous pouvez signer tous les certificats avec une seule autorité de certification. Il y a aussi deux options.
5.2.1 Votre propre autorité de certification
Cette option est pour créer votre propre autorité de certification sans dépendances supplémentaires du système d’exploitation. L’autorité d’un tel émetteur de certificats serait minimale.
Préparez l’infrastructure:
mkdir db
mkdir db\new
mkdir db\private
echo. 2>db\index
echo 01> ./db/serial
echo unique_subject = no> ./db/index.attr Remplissez le fichier ca.cfg:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = DataSunrise
organizationalUnitName = IT
commonName = DataSunrise
emailAddress = [email protected] Remplissez le fichier proxy.cfg:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected]
[ca]
.default_ca = CA_default
[CA_default]
dir = ./db # top dir
database = $dir/index # index file.
new_certs_dir = $dir/new # new certs dir
certificate = $dir/ca.cer # The CA cert
serial = $dir/serial # serial no file
private_key = $dir/private/ca.pem # CA private key
RANDFILE = $dir/private/.rand # random number file
.default_days = 365 # how long to certify for
.default_crl_days = 30 # how long before next CRL
default_md = sha384
policy = policy_any # default policy
email_in_dn = no # Don't add the email into cert DN
name_opt = ca_default # Subject name display option
cert_opt = ca_default # Certificate display option
#copy_extensions = none # Don't copy extensions from request
[policy_any]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional Générez un certificat racine ./db/ca.cer et une clé ./db/private/ca.pem. Ce certificat (sa clé) sera utilisé pour signer tous les futurs certificats. Ainsi, ./db/ca.cer devrait être installé dans un stockage de certificats de confiance de tous les clients qui vérifieront les certificats de DataSUnrise:
./db/private/ca.pem:
SET RANDFILE=.\db\private\.rand
SET PASS=TxK7T88C27
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\ca.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\ca.pem -out .\db\private\ca.pem
openssl req -new -x509 -days 3650 -key .\db\private\ca.pem -out .\db\ca.cer -config ca.cfg
openssl x509 -noout -text -in .\db\ca.cer Générez et signez proxy.pem:
SET RANDFILE=.\db\private\.rand
SET /P serial=<.\db\serial
SET PASS=RTqSWs0koH
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\%serial%.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\%serial%.pem -out .\db\private\%serial%.pem
openssl req -new -key .\db\private\%serial%.pem -nodes -config proxy.cfg -out .\db\private\%serial%.req
openssl ca -batch -config proxy.cfg -infiles .\db\private\%serial%.req
openssl ecparam -genkey -name secp256r1 -out .\db\private\%serial%.ec.pem
openssl dhparam -out .\db\private\%serial%.dh.pem 1024
COPY .\db\new\%serial%.pem+key.pem+.\db\new\%serial%.dh.pem+.\db\new\%serial%.ec.pem proxy.pem /b
MOVE .\db\new\%serial%.pem .\db\new\%serial%.cer Les certificats créés seront enregistrés dans le dossier db\new\n
Les clés générées et les pfx emballés (clé et certificat) seront enregistrés dans le dossier db\private\n
Exemple. Un ensemble de clés numéro “01”:
db\new\01.cer — Nouveau certificat db\private\01.pem — Nouvelle clé privée RSA db\private\01.dh.pem — Nouveaux paramètres DH db\private\01.ec.pem — Nouveaux paramètres et clé EC
A chaque génération de proxy.pem, un nouvel ensemble de clés sera créé. Il correspondra au proxy.pem nouvellement généré. Après le remplacement du proxy.pem dans DataSunrise, il est nécessaire de redémarrer le Core pour que les modifications prennent effet. Ayant un nouvel ensemble de clés, vous pouvez aussi utiliser la méthode 5.1.2 pour ajouter les clés à l’UI sans changer le proxy.pem.
5.2.2 Exécution d’une autorité de certification d’entreprise
Si vous devez protéger plusieurs hôtes clients, ou s’il y a plusieurs hôtes de DataSunrise inclus dans un réseau d’entreprise (domaine) ou plusieurs réseaux de confiance (forêt), il serait pratique d’utiliser les services de certificat Active Directory. Dans ce cas, vous pouvez utiliser certreq pour générer un proxy.pem. Prenons un proxy.cfg décrit au sous-point 5.1.1. et générons un proxy.pem (les commandes doivent être exécutées en tant qu’utilisateur avec des privilèges suffisants pour émettre de nouveaux certificats ou en tant qu’administrateur de domaine):
SET RANDFILE=random
SET PASS=89RT90qSWs020koH12
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -config proxy.cfg -new -key key.pem -out certificate.req
certreq -submit -attrib "CertificateTemplate:WebServer" certificate.req certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req certreq affichera une boîte de dialogue pour sélectionner un centre de certification d’entreprise qui devrait être utilisé pour émettre un nouveau certificat. Habituellement, il n’y a qu’un seul centre dans une telle liste:
Mais cela dépend de l’infrastructure du domaine d’entreprise. Consultez votre administrateur si nécessaire.
Après avoir installé le proxy.pem, aucune configuration supplémentaire du client réseau n’est requise, car après l’installation de AD CS, le certificat racine couvre automatiquement tous les hôtes du domaine/forêt.
En utilisant un ensemble de clés et un certificat (certificate.cer, key.pem, dh.pem, ec.pem), vous pouvez également utiliser la méthode décrite au sous-point 5.1.2 pour ajouter des clés via l’interface web sans changer le proxy.pem.
5.3 Beaucoup de clients
Quand vous avez besoin d’appliquer un certificat à un grand nombre de clients, vous pouvez utiliser des politiques de groupe. Reportez-vous au guide Microsoft suivant : https://technet.microsoft.com/en-us/library/cc770315%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 (Déployer des certificats à l’aide de la politique de groupe)
6 Conclusion
En utilisant n’importe quelle méthode décrite ci-dessus, vous pouvez atteindre un haut niveau de sécurité de connexion proxy, mais c’est à vous de choisir la méthode qui convient le mieux à votre infrastructure. Pour assurer une sécurité totale pour votre base de données SQL Server, vous pouvez utiliser les outils suivants de DataSunrise :
