Comment protéger votre base de données SQL Server contre les attaques MITM avec DataSunrise
1 Qu’est-ce que le MITM ?
Lorsqu’un client se connecte à un serveur via un canal sécurisé, il existe un risque qu’un tiers s’intercale entre eux et soit capable d’écouter et d’interférer avec les communications. Les attaques réseau lancées par l’intermédiaire d’un tel tiers sont appelées attaques de type Man in the Middle (MITM). Il existe de nombreuses façons de réaliser une telle attaque, mais le principe fondamental est de faire en sorte que le client se connecte secrètement au serveur de l’attaquant.
2 Comment se protéger contre le MITM ?
La principale méthode de protection contre les attaques MITM consiste à analyser l’infrastructure réseau au moment de la connexion au serveur et à détecter des paramètres suspects qui ne sont pas typiques pour la connexion à un serveur donné. Si le protocole SSL est utilisé pour la protection, le client peut vérifier le certificat du serveur lors de l’échange initial. Un certificat peut comporter de nombreux paramètres, échangés entre le client et le serveur lors de l’authentification. La pratique standard pour SSL est d’interrompre immédiatement une connexion si l’une des parties accepte un paramètre (nom de répertoire, DNS, e-mail, GUID, IP, UPN, URL ou tout autre) qui n’est pas pertinent pour les paramètres de son environnement. Mais même une telle vérification du certificat ne peut garantir une sécurité totale, car l’infrastructure du client peut être modifiée de manière significative au moment de l’attaque pour passer la vérification. C’est pourquoi des méthodes supplémentaires de validation du certificat sont souvent mises en œuvre. L’une de ces méthodes consiste à faire signer un certificat par une autorité de confiance. On considère qu’il est impossible de falsifier une telle signature, et chaque client peut en vérifier l’authenticité. C’est pourquoi tout certificat signé par une autorité spéciale peut être considéré comme plus ou moins sûr, selon l’autorité de l’émetteur.
3 Protection contre le MITM dans MS SQL Server
La vérification du certificat est facultative dans MS SQL, mais elle est activée par défaut. Deux paramètres majeurs participant à la vérification d’un certificat sont la date d’expiration du certificat et le nom de l’hôte pour lequel le certificat a été délivré (Common Name). Si un certificat est expiré ou n’est pas délivré pour l’hôte avec lequel la connexion est établie, la connexion sera immédiatement interrompue avec une notification à l’utilisateur. Dans le cas où une autorité de certification intervient dans la vérification supplémentaire du certificat, le client vérifiera sa signature. Dans de tels cas, un certificat racine de cette autorité doit être présent dans le stockage des certificats. De nombreux systèmes d’exploitation modernes incluent des ensembles préétablis de certificats racines des autorités les plus fiables, c’est pourquoi, lors du choix d’une autorité de certification pour la signature d’un certificat d’entreprise, il est judicieux de sélectionner celle figurant dans la liste.
4 Les certificats dans DataSunrise
Le proxy de DataSunrise est digne de confiance, mais il reste néanmoins un tiers dans la connexion, c’est pourquoi tous les moyens de protection du client contre le MITM seront activés lors de la connexion via 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 réalité, ces clés ne sont pas associées au serveur final qui héberge le proxy de DataSunrise. C’est ce certificat que le client vérifiera si la protection contre le MITM est activée.
5 Configurations possibles de DataSunrise incluant la protection contre le MITM
Pour offrir un niveau de protection similaire entre une connexion directe et une connexion via proxy, il est nécessaire de configurer correctement les hôtes de DataSunrise et du client. Plusieurs options de configuration sont possibles.
Un ensemble de clés et un certificat par défaut offrent une protection minimale. Il n’est pas garanti que le certificat par défaut corresponde au nom d’hôte CN=DataSunrise Database Security Suite. C’est pourquoi la première chose à 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
Il s’agit du cas le plus simple, lorsqu’un administrateur dispose d’une seule instance de DataSunrise et d’un seul serveur MS SQL, et qu’il existe un ensemble limité et établi de clients pouvant accéder aux serveurs 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 pour générer de nouvelles clés. Créez un fichier proxy.cfg (« commonName » doit inclure le nom réel de l’hôte 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 proxy.config :
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 la courbe “secp256r1” et un certificat délivré pour 365 jours avec l’algorithme de signature « sha384 ».
De plus, un fichier certificate.cer doit être généré et installé dans le stockage des certificats de confiance du client.
5.1.2 Installation d’un certificat et des clés du proxy via l’interface graphique
Si un utilisateur possède déjà un ensemble de clés et un certificat, ils peuvent être installés via l’interface web de DataSunrise.
Pour définir les clés et le certificat pour un proxy, effectuez les étapes suivantes :
- Créez un groupe de clés SSL de type côté client.
- Remplissez ce groupe avec tous les paramètres nécessaires en encodage Base64 : un certificat, une clé privée, des paramètres DH, des paramètres EC
- Associez ce groupe à une instance en le sélectionnant dans la liste des groupes de clés
Les deux options (5.1.1 et 5.1.2) nécessitent de redémarrer le Core de DataSunrise après avoir remplacé les clés, et d’installer un certificat créé pour DataSunrise dans le stockage des certificats de confiance du côté client.
5.2 Plusieurs instances de DataSunrise
La configuration suivante concerne plusieurs instances de DataSunrise. Si vous utilisez les conseils décrits dans le cas général ci-dessus, il sera nécessaire d’installer un ensemble complet de certificats sur le côté client et de surveiller leur validité. Pour éviter d’éventuelles erreurs, vous pouvez signer tous les certificats avec une seule autorité de certification. Deux options sont également possibles.
5.2.1 Votre propre Autorité de Certification
Cette option permet de créer votre propre autorité de certification sans dépendances supplémentaires au niveau du système d’exploitation. L’autorité d’un tel émetteur de certificats sera 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 # répertoire racine
database = $dir/index # fichier d'index
new_certs_dir = $dir/new # répertoire des nouveaux certificats
certificate = $dir/ca.cer # Le certificat de l'AC
serial = $dir/serial # fichier de numéro de série
private_key = $dir/private/ca.pem # clé privée de l'AC
RANDFILE = $dir/private/.rand # fichier de nombres aléatoires
default_days = 365 # durée de validité par défaut
default_crl_days = 30 # délai avant le prochain CRL
default_md = sha384
policy = policy_any # politique par défaut
email_in_dn = no # Ne pas ajouter l'e-mail dans le DN du certificat
name_opt = ca_default # option d'affichage du nom du sujet
cert_opt = ca_default # option d'affichage du certificat
#copy_extensions = none # Ne pas copier les extensions depuis la requête
[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 (et sa clé) sera utilisé pour signer tous les certificats futurs. Ainsi, ./db/ca.cer doit être installé dans le stockage des certificats de confiance de tous les clients qui vérifieront les certificats 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\
Les clés générées et les pfx empaquetés (clé et certificat) seront enregistrés dans le dossier db\private\
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
À chaque génération de proxy.pem, un nouvel ensemble de clés sera créé, correspondant à un proxy.pem nouvellement généré. Après le remplacement de proxy.pem dans DataSunrise, il est nécessaire de redémarrer le Core pour que les changements prennent effet. Une fois en possession d’un nouvel ensemble de clés, vous pouvez également utiliser la méthode 5.1.2 pour ajouter les clés via l’interface utilisateur sans modifier le proxy.pem.
5.2.2 Utilisation d’une Autorité de Certification d’entreprise
Si la protection de plusieurs hôtes clients est requise, ou s’il existe plusieurs hôtes DataSunrise inclus dans un réseau d’entreprise (domaine) ou plusieurs réseaux de confiance (forêt), il serait pratique d’utiliser Active Directory Certificate Services. Dans ce cas, vous pouvez utiliser certreq pour générer un proxy.pem. Prenons un fichier proxy.cfg tel que décrit dans la sous-section 5.1.1 et générons un proxy.pem (les commandes doivent être exécutées en tant qu’utilisateur disposant des privilèges suffisants pour délivrer 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 permettant de sélectionner un centre de certification d’entreprise qui sera utilisé pour délivrer un nouveau certificat. En général, 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.
Une fois le proxy.pem installé, aucune configuration supplémentaire du client réseau n’est requise, car après l’installation d’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 dans la sous-section 5.1.2 pour ajouter les clés via l’interface web sans modifier le proxy.pem.
5.3 Un grand nombre de clients
Lorsqu’il est nécessaire d’appliquer un certificat à un grand nombre de clients, vous pouvez utiliser les stratégies de groupe. Reportez-vous au guide Microsoft suivant : Déployer des certificats via les Stratégies de groupe .
6 Conclusion
En utilisant l’une des méthodes décrites ci-dessus, vous pouvez atteindre un haut niveau de sécurité pour la connexion via proxy, mais c’est à vous de choisir la méthode qui convient le mieux à votre infrastructure. Pour assurer une sécurité complète de votre base de données SQL Server, vous pouvez utiliser les outils DataSunrise suivants :
