URL: https://linuxfr.org/users/samuel/journaux/sql-server-sous-linux-enjeux-de-securite Title: SQL Server sous Linux : enjeux de sécurité Authors: Samuel Date: 2021年03月16日T22:18:44+01:00 License: CC By-SA Tags: ubuntu, microsoft, sql-server, sécurité et debian Score: 42 **TL;DR:** Avec Microsoft SQL Server, la sécurité est une option. Et une option payante. Microsoft aime Linux, nous dit-il, et il nous permet maintenant d'installer nativement son serveur de base de données SQL Server (*cf.* [cette vidéo technique](https://media.ccc.de/v/ASG2019-131-how-microsoft-sql-server-went-multi-platform-sqlpal) pour comprendre comment ils on fait le portage). Seulement, **la configuration par défaut n'est pas sécurisée du tout**. Petite revue de quelques éléments à rectifier quand vous installez et utilisez SQL Server. La plupart de ces conseils sont aussi valables si vous utilisez le cloud de Microsoft. *remarque : ce journal ne prétend pas à l'exhaustivité. Je n'ai qu'une toute petite expérience de SQL Server.* Version testée : SQL server 2019 sur Ubuntu 18.04 (en l'occurrence installée sur Debian Buster). Les recommandations valent aussi pour d'autres distributions Linux. # Configuration de SQL server Voici [le manuel d'installation](https://docs.microsoft.com/fr-fr/sql/linux/quickstart-install-connect-ubuntu?view=sql-server-ver15). Ce qu'il ne précise pas, c'est que par défaut : 1. SQL server écoute sur toutes les adresses réseau (et pas uniquement localhost) 2. Le chiffrement n'est pas activé Selon votre cas d'usage, vous devrez nécessairement corriger l'un de ces deux points. ## Désactiver l'écoute sur le réseau Si vous prévoyez d'interroger SQL Server uniquement depuis localhost, alors il faut limiter son écoute au réseau local seulement. Pour ça, il faut ajouter les lignes suivantes au fichier de configuration, qui est par défaut `/var/opt/mssql/mssql.conf` : ``` [network] ipaddress = 127.0.0.1 ``` Il faut ensuite redémarrer mssql-server : ``` $ sudo systemctl restart mssql-server ``` ## Activer TLS (1.2) Si le serveur doit écouter sur le réseau, il est indispensable d'activer TLS. Pour cela, après avoir créé une paire clé privée / clé publique et un certificat correspondant à cette paire, il faut ajouter les options suivantes au fichier de configuration : ``` [network] privatekey=/chemin/de/votre/clé/privée cert=/chemin/de/la/chaine/de/certification/de/votre/clé forceencryption=1 min-tls-version=1.2 cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 ``` Signification des options : - `privatekey`/`cert` : fichiers de clé et certificats utilisés pour chiffrer et authentifier la connexion - `forceencryption` : refuser les connexions non chiffrées. Ça protège d'un équipement réseau indiscret (écoute passive). Ça ne protège d'une attaque active type homme-du-milieu que si le client vérifie le certificat présenté (voir ci-dessous). - `min-tls-version` : par défaut, SQL Server 2019 fonctionne avec TLS 1.0 (1999), TLS 1.1 (2006) et TLS 1.2 (2008). Il ne fonctionne pas avec TLS 1.3 (2018), qui apporte des garanties de sécurité supplémentaires. TLS 1.0 et 1.1 sont considérés comme "non sûrs" aujourd'hui : à moins que vous n'ayez de très vieux équipements qui doivent communiquer avec votre serveur, il vaut mieux désactiver complètement ces versions. - `cipherlist` : si TLS 1.2 est encore considéré comme raisonnablement sûr, toutes les suites de chiffrement n'ont pas les mêmes qualités. En particulier, certaines n'offrent pas la [confidentialité persistante](https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante), la protection contre un attaquant qui enregistrerait les flux réseau chiffrés dans un premier temps puis, dans un second temps, mettrait la main sur la clé privée du serveur. Dans un cas (sans confidentialité persistante), cette clé permet de déchiffrer les échanges passés, dans l'autre cas (avec) cela ne le permet pas. La liste indiquée ici reprend [celle de la configuration "intermédiaire" proposée par Mozilla](https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.1.1d&hsts=false&guideline=5.6). ## Désactiver TLS 1.0 et 1.1 sur le cloud Azure SQL Database Si vous avez une base de données Azure, la situation est à peine meilleure : un certificat vous est fourni et le chiffrement est activé. Ils utilisent [un certificat par datacenter](https://crt.sh/?dNSName=*.database.windows.net&exclude=expired&match==), valable pour tous leurs clients (cf. la liste des "Subject Alternative Name" de [ce certificat](https://crt.sh/?id=3880631378), par exemple). Seulement, là encore TLS 1.0 et 1.1 sont proposés par défaut, vous exposant à une attaque type "downgrade". Depuis [mai 2020](https://azure.microsoft.com/en-us/updates/sqldb-minimal-tls-version/), vous pouvez désactiver ces protocoles [à l'aide de la commande suivante](https://docs.microsoft.com/fr-fr/azure/azure-sql/database/connectivity-settings#minimal-tls-version) : ``` az sql server update -n sql-server-name -g sql-server-group --set minimalTlsVersion="1.2" ``` ## Les remontées d'informations vers Microsoft **Données d'utilisation** : Par défaut, Microsoft collecte des données sur l'utilisation du produit. Il n'est possible de désactiver cette remontée d'informations [que sur la version payante](https://docs.microsoft.com/fr-fr/sql/linux/usage-and-diagnostic-data-configuration-for-sql-server-linux?view=sql-server-ver15), avec les options suivantes dans le fichier de configuration : ``` [telemetry] customerfeedback = false ``` **Crash dumps** : Microsoft collecte aussi les images mémoires lors des plantages de l'application (crash dump) et [les conservent jusqu'à un mois](https://docs.microsoft.com/fr-fr/sql/sql-server/sql-server-privacy?view=sql-server-ver15#access-control). Ils préviennent que ces images sont susceptibles de contenir les identifiants d'accès à la base et des données personnelles contenus dans la base. Il ne semble pas possible de désactiver cette remontée d'informations, mais vous pouvez toujours restreindre l'accès de SQL server au réseau en créant le fichier `/etc/systemd/system/mssql-server.conf.d/blocage-reseau.conf` : ``` [Service] IPAddressDeny=all # Adaptez la ligne suivante : quelles IP auront besoin d'accéder à votre serveur ? IPAddressAllow=localhost 192.168.0.0/16 ``` Puis, pour prendre en compte cette modification et redémarrer SQL Server : ``` $ sudo systemctl daemon-reload $ sudo systemctl restart mssql-server.service ``` # sqlcmd : --insecure par défaut Vous connaissez l'option "--insecure" de curl, celle qui signifie que "oui, je me connecte en httpS, mais je me fiche de la validité du certificat, vas-y quand même" ? Sqlcmd, l'outil en ligne de commande pour se connecter à SQL server proposé par Microsoft, active ce comportement **par défaut**. Si vous voulez la sécurité apportée par TLS, il faut l'expliciter avec le drapeau "-N". [La documentation](https://docs.microsoft.com/fr-fr/sql/tools/sqlcmd-utility?view=sql-server-ver15) explique sobrement "This switch is used by the client to request an encrypted connection". Sans cette indication, vous êtes vulnérable à une attaque type homme du milieu qui peut soit retirer le chiffrement (s'il est partageur) soit vous présenter un certificat autosigné pour espionner la transaction et récupérer les identifiants d'accès. L'option "-C (trust the server certificate)" n'a d'effet que si l'option `-N` est présente et a pour effet de forcer l'utilisation de TLS mais sans vérification du certificat du serveur. On est donc protégé d'un attaquant se contentant d'observer la connexion, mais pas d'un équipement trafiquant les données (homme-du-milieu). # Résumé Synthèse des attaques possibles selon la configuration (NdM: image perdue) Serveur : ``` [network] privatekey=/chemin/de/votre/clé/privée cert=/chemin/de/la/chaine/de/certification/de/votre/clé forceencryption=1 min-tls-version=1.2 cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 ``` Client : sqlcmd **-N** Si vous hébergez des données très sensibles ou que votre serveur est accessible depuis internet, il vaut mieux payer une licence SQL Server et désactiver la remontée d'informations.

AltStyle によって変換されたページ (->オリジナル) /