Partager via

Sécuriser les conteneurs SQL Server Linux

  • Article

S’applique à : SQL Server - Linux

Les conteneurs SQL Server 2017 (14.x) démarrent par défaut en tant qu’utilisateur racine, ce qui peut provoquer des problèmes de sécurité. Cet article décrit les options de sécurité à votre disposition lors de l’exécution de conteneurs SQL Server Linux, puis explique comment créer un conteneur SQL Server en tant qu’utilisateur non racine.

Les exemples de cet article supposent que vous utilisez Docker, mais vous pouvez appliquer les mêmes principes à d’autres outils d’orchestration de conteneurs comme Kubernetes.

Générer et exécuter des conteneurs SQL Server 2017 non-root

Suivez la procédure ci-dessous pour créer un conteneur SQL Server 2017 (14.x) qui démarre en tant qu’utilisateur mssql (non racine).

Notes

Les conteneurs SQL Server 2019 (15.x) et versions ultérieures démarrent automatiquement avec un compte non racine, contrairement aux conteneurs SQL Server 2017 (14.x) qui démarrent par défaut en tant qu’utilisateur racine. Pour plus d’informations sur l’exécution de conteneurs SQL Server avec un compte non root, consultez Configuration de la sécurité.

  1. Téléchargez l’exemple de fichier Dockerfile pour les conteneurs SQL Server non racines et enregistrez-le en tant que dockerfile.

  2. Exécutez la commande suivante dans le contexte du répertoire de fichier Dockerfile pour générer le conteneur SQL Server non racine :

    cd <path to dockerfile>
docker build -t 2017-latest-non-root .

  3. Démarrez le conteneur.

    Important

    La variable d’environnement SA_PASSWORD est dépréciée. Utilisez MSSQL_SA_PASSWORD à la place.

    docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword@" --cap-add SYS_PTRACE --name sql1 -p 1433:1433 -d 2017-latest-non-root

    Notes

    L’indicateur --cap-add SYS_PTRACE est requis pour les conteneurs SQL Server non racine afin de générer des vidages à des fins de dépannage.

  4. Vérifiez que le conteneur s’exécute en tant qu’utilisateur non racine :

    docker exec -it sql1 bash

    Exécutez whoami pour retourner l’utilisateur qui s’exécute dans le conteneur.

    whoami

Exécuter le conteneur comme un autre utilisateur non racine sur l’hôte

Pour exécuter le conteneur SQL Server en tant qu’autre utilisateur non racine, ajoutez l’indicateur -u sur la commande docker run. Le conteneur non racine a comme restriction qu’il doit s’exécuter dans le groupe root, sauf si un volume est monté sur /var/opt/mssql qui est accessible à l’utilisateur non racine. Le groupe root n’accorde pas d’autorisations racines supplémentaires à l’utilisateur non racine.

Exécuter en tant qu’utilisateur avec un UID 4000

Vous pouvez démarrer SQL Server avec un UID personnalisé. Par exemple, la commande suivante démarre SQL Server avec l’UID 4000 :

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u 4000:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Avertissement

Vérifiez que le conteneur SQL Server comporte un utilisateur nommé, par exemple mssql ou root. Sinon, sqlcmd ne pourra pas s’exécuter dans ce conteneur. Vous pouvez vérifier si le conteneur SQL Server s’exécute en tant qu’utilisateur nommé en exécutant whoami dans le conteneur.

Exécuter le conteneur non racine en tant qu’utilisateur racine

Vous pouvez si nécessaire exécuter le conteneur non racine en tant qu’utilisateur racine. Cette action a également pour effet d’accorder automatiquement toutes les autorisations de fichier au conteneur, car il dispose de privilèges plus élevés.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" -u 0:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Exécuter en tant qu’utilisateur sur votre ordinateur hôte

Vous pouvez démarrer SQL Server avec un utilisateur existant sur l’ordinateur hôte à l’aide de la commande suivante :

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u $(id -u myusername):0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Exécuter en tant qu’utilisateur ou groupe différent

Vous pouvez démarrer SQL Server avec un utilisateur ou groupe personnalisé. Dans cet exemple, le volume monté dispose des autorisations configurées pour l’utilisateur ou le groupe sur l’ordinateur hôte.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u $(id -u myusername):$(id -g myusername) -v /path/to/mssql:/var/opt/mssql -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Configurer des autorisations de stockage persistant pour les conteneurs non racine

Pour permettre à l’utilisateur non racine d’accéder aux fichiers de base de données qui se trouvent sur des volumes montés, vérifiez que l’utilisateur ou le groupe sous lequel vous exécutez le conteneur peut accéder en lecture et en écriture au stockage de fichiers persistant.

Vous pouvez obtenir la propriété actuelle des fichiers de base de données à l’aide de cette commande.

ls -ll <database file dir>

Exécutez l’une des commandes suivantes si SQL Server n’a pas accès aux fichiers de base de données persistants.

Accorder au groupe racine un accès en lecture et en écriture aux fichiers de base de données

Accordez au groupe racine des autorisations sur les répertoires suivants afin que le conteneur SQL Server non racine ait accès aux fichiers de base de données.

chgrp -R 0 <database file dir>
chmod -R g=u <database file dir>

Définir l’utilisateur non-racine comme propriétaire des fichiers

Il peut s’agir de l’utilisateur non racine par défaut ou de tout autre utilisateur non racine de votre choix. Dans cet exemple, nous définissons UID 10001 en tant qu’utilisateur non racine.

chown -R 10001:0 <database file dir>

Chiffrer les connexions aux conteneurs SQL Server Linux

Important

Lors de la configuration des options d’authentification ou de chiffrement Active Directory telles que Transparent Data Encryption (TDE) et SSL pour SQL Server sur Linux ou des conteneurs, plusieurs fichiers, comme le keytab, les certificats et la clé d’ordinateur, sont créés par défaut sous le dossier /var/opt/mssql/secrets ; l’accès à ces fichiers est limité par défaut aux utilisateurs mssql et root. Quand vous configurez un stockage persistant pour les conteneurs SQL Server, utilisez la même stratégie d’accès, en vous assurant que le chemin sur l’hôte ou le volume partagé mappé au dossier /var/opt/mssql/secrets à l’intérieur du conteneur est aussi protégé et accessible uniquement aux utilisateurs mssql et root sur l’hôte. Si l’accès à ce chemin/dossier est compromis, un utilisateur malveillant peut accéder à ces fichiers critiques, compromettant alors la hiérarchie de chiffrement et/ou les configurations Active Directory.

Pour chiffrer les connexions à des conteneurs Linux SQL Server, il vous faut un certificat qui respecte les exigences suivantes.

Voici un exemple de chiffrement de la connexion à des conteneurs Linux SQL Server. Ici, nous utilisons un certificat auto-signé, qui ne doit pas être utilisé dans des scénarios de production. Pour ces environnements, vous devez utiliser à la place des certificats d’autorité de certification.

  1. Créez un certificat auto-signé, qui convient seulement aux environnements de test et hors production.

    openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=sql1.contoso.com' -keyout /container/sql1/mssql.key -out /container/sql1/mssql.pem -days 365

    Dans l’exemple de code précédent, sql1 est le nom d’hôte du conteneur SQL : lors de la connexion à ce conteneur, le nom utilisé dans la chaîne de connexion sera donc sql1.contoso.com,port. Vérifiez également que le chemin du dossier /container/sql1/ existe avant d’exécuter la commande ci-dessus.

  2. Veillez à définir les autorisations appropriées sur les fichiers mssql.key et mssql.pem, afin d’éviter des erreurs lors du montage des fichiers sur le conteneur SQL Server :

    chmod 440 /container/sql1/mssql.pem
chmod 440 /container/sql1/mssql.key

  3. Créez un fichier mssql.conf avec le contenu ci-dessous pour activer le chiffrement lancé par le serveur. Pour le chiffrement lancé par le client, remplacez la dernière ligne par forceencryption = 0.

    [network]
tlscert = /etc/ssl/certs/mssql.pem
tlskey = /etc/ssl/private/mssql.key
tlsprotocols = 1.2
forceencryption = 1

    Notes

    Pour certaines distributions Linux, le chemin pour le stockage du certificat et de la clé peut également être : /etc/pki/tls/certs/ et /etc/pki/tls/private/, respectivement. Vérifiez le chemin avant de mettre à jour mssql.conf pour les conteneurs SQL Server. L’emplacement que vous définissez dans mssql.conf sera l’emplacement où l’instance SQL Server dans le conteneur va rechercher le certificat et sa clé. Dans ce cas, cet emplacement est /etc/ssl/certs/ et /etc/ssl/private/.

    Le fichier mssql.conf est également créé sous le même emplacement de dossier, /container/sql1/. Après avoir effectué les étapes ci-dessus, vous devez avoir les trois fichiers mssql.conf, mssql.key et mssql.pem dans le dossier sql1.

  4. Déployez le conteneur SQL Server avec la commande suivante :

    docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=P@ssw0rd" -p 5434:1433 --name sql1 -h sql1 -v /container/sql1/mssql.conf:/var/opt/mssql/mssql.conf -v   /container/sql1/mssql.pem:/etc/ssl/certs/mssql.pem -v /container/sql1/mssql.key:/etc/ssl/private/mssql.key -d mcr.microsoft.com/mssql/server:2019-latest

    Dans la commande précédente, nous avons monté les fichiers mssql.conf, mssql.pem et mssql.key dans le conteneur, et fait correspondre le port 1433 (le port par défaut de SQL Server) dans le conteneur au port 5434 sur l’hôte.

    Notes

    Si vous utilisez RHEL 8 et ultérieur, vous pouvez également utiliser la commande podman run au lieu de docker run.

Suivez les sections « Inscription du certificat sur une machine cliente » et « Exemples de chaînes de connexion » documentées dans Chiffrement à l’initiative du client pour commencer le chiffrement des connexions à SQL Server sur des conteneurs SQL Server sur Linux.

Contenu connexe

  • Bien démarrer avec les images conteneur SQL Server 2017 (14.x) sur Docker en suivant le démarrage rapide
  • Bien démarrer avec les images conteneur SQL Server 2019 (15.x) sur Docker en suivant le démarrage rapide