Freigeben über

Schützen von SQL Server Linux-Containern

  • Artikel

Gilt für: SQL Server – Linux

SQL Server 2017 (14.x)-Container werden standardmäßig als Stammbenutzer gestartet, was zu Sicherheitsbedenken führen kann. In diesem Artikel werden die Sicherheitsoptionen beschrieben, die beim Ausführen von SQL Server Linux-Containern verfügbar sind, und wie Sie einen SQL Server-Container als Nicht-Root-Benutzer erstellen.

In den Beispielen in diesem Artikel wird davon ausgegangen, dass Sie Linux verwenden. Sie können dieselben Prinzipien jedoch auf andere Containerorchestrierungstools anwenden, einschließlich Kubernetes.

Erstellen und Ausführen von SQL Server 2017-Containern ohne Root-Berechtigung

Führen Sie die folgenden Schritte aus, um einen SQL Server 2017 (14.x)-Container zu erstellen, der als mssql-Nicht-Root-Benutzer gestartet wird.

Hinweis

Container für SQL Server 2019 (15.x) oder neuere Versionen werden automatisch als Nicht-Stammcontainer gestartet, während SQL Server 2017-Container (14.x) standardmäßig als Stammcontainer gestartet werden. Weitere Informationen zum Ausführen von SQL Server-Containern als Nichtstammcontainer finden Sie unter Konfigurieren der Sicherheit.

  1. Laden Sie das Beispiel-Dockerfile für SQL Server-Container ohne Root-Berechtigung herunter, und speichern Sie es als dockerfile.

  2. Führen Sie den folgenden Befehl im Kontext des dockerfile-Verzeichnisses aus, um den SQL Server-Container ohne Root-Berechtigung zu erstellen:

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

  3. Starten Sie den Container.

    Wichtig

    Die Umgebungsvariable SA_PASSWORD ist veraltet. Verwenden Sie stattdessen MSSQL_SA_PASSWORD.

    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

    Hinweis

    Das --cap-add SYS_PTRACE-Flag wird für SQL Server-Container ohne Root-Berechtigung benötigt, um Sicherungsdateien für die Problembehandlung zu erzeugen.

  4. Überprüfen Sie, ob der Container als Nicht-Root-Benutzer ausgeführt wird:

    docker exec -it sql1 bash

    Führen Sie whoami aus, um den Benutzer zurückzugeben, der innerhalb des Containers ausgeführt wird.

    whoami

Ausführen eines Containers als anderer Nicht-Root-Benutzer auf dem Host

Um den SQL Server-Container als anderer Nicht-Root-Benutzer auszuführen, fügen Sie dem docker run-Befehl das -u-Flag hinzu. Der Container ohne Root-Berechtigung hat die Einschränkung, dass er als Teil der root-Gruppe ausgeführt werden muss, es sei denn, es wird ein Volume für /var/opt/mssql bereitgestellt, auf das der Nicht-Root-Benutzer zugreifen kann. Die root-Gruppe gewährt dem Nicht-Root-Benutzer keine zusätzlichen Root-Berechtigungen.

Ausführen als Benutzer mit einer UID 4000

Sie können SQL Server mit einer benutzerdefinierten UID starten. Der folgende Befehl startet beispielsweise SQL Server mit der 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

Warnung

Stellen Sie sicher, dass der SQL Server-Container einen benannten Benutzer wie mssql oder root aufweist. Andernfalls kann sqlcmd nicht innerhalb des Containers ausgeführt werden. Sie können überprüfen, ob der SQL Server-Container als benannter Benutzer ausgeführt wird, indem Sie whoami innerhalb des Containers ausführen.

Ausführen des Containers ohne Root-Berechtigung als Root-Benutzer

Sie können den Nicht-Stammcontainer bei Bedarf als Stammbenutzer ausführen, wodurch dem Container automatisch alle Dateiberechtigungen gewährt werden, da er über höhere Rechte verfügt.

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

Ausführen als Benutzer auf Ihrem Hostcomputer

Mit dem folgenden Befehl können Sie SQL Server mit einem vorhandenen Benutzer auf dem Hostcomputer starten:

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

Ausführen als anderer Benutzer und Gruppe

Sie können SQL Server mit einem benutzerdefinierten Benutzer oder einer benutzerdefinierten Gruppe starten. In diesem Beispiel verfügt das bereitgestellte Volume über Berechtigungen, die für den Benutzer oder die Gruppe auf dem Hostcomputer konfiguriert sind.

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

Konfigurieren von persistenten Speicherberechtigungen für Container ohne Root-Berechtigung

Um dem Nicht-Stammbenutzer den Zugriff auf Datenbankdateien zu ermöglichen, die sich auf bereitgestellten Volumes befinden, stellen Sie sicher, dass der Benutzer oder die Gruppe, unter dem oder der Sie den Container ausführen, Lese-/Schreibvorgänge im persistenten Dateispeicher ausführen kann.

Mit diesem Befehl können Sie den aktuellen Besitzer der Datenbankdateien ermitteln.

ls -ll <database file dir>

Führen Sie einen der folgenden Befehle aus, wenn SQL Server keinen Zugriff auf persistierte Datenbankdateien hat.

Zuweisen von Root-Gruppenzugriffsberechtigungen zum Lesen und Schreiben von Datenbankdateien

Erteilen Sie die Root-Gruppenberechtigungen für die folgenden Verzeichnisse, damit der SQL Server-Container ohne Root-Berechtigungen Zugriff auf Datenbankdateien hat.

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

Festlegen des Nicht-Root-Benutzers als Besitzer der Dateien

Dies kann der standardmäßig festgelegte Nicht-Root-Benutzer oder ein anderer Nicht-Root-Benutzer sein, den Sie angeben möchten. In diesem Beispiel haben wir die UID 10001 als Nicht-Root-Benutzer festgelegt.

chown -R 10001:0 <database file dir>

Verschlüsseln von Verbindungen mit SQL Server Linux-Containern

Wichtig

Beim Konfigurieren von Active Directory-Authentifizierungs- oder Verschlüsselungsoptionen wie Transparent Data Encryption (TDE) und SSL für SQL Server für Linux oder Container gibt es mehrere Dateien, z. B. die Schlüsseltabelle, Zertifikate und Computerschlüssel, die standardmäßig im Ordner /var/opt/mssql/secrets erstellt werden und auf die standardmäßig nur mssql- und root-Benutzer zugreifen dürfen. Verwenden Sie beim Konfigurieren von persistentem Speicher für SQL Server-Container dieselbe Zugriffsstrategie. Dadurch wird sichergestellt, dass der Pfad auf dem Host oder dem freigegebenen Volume dem Ordner /var/opt/mssql/secrets im Container zugeordnet wird, geschützt ist und auch nur für mssql- oder root-Benutzer auf dem Host zugänglich ist. Wenn der Zugriff auf diesen Pfad bzw. Ordner kompromittiert ist, kann ein böswilliger Benutzer Zugriff auf diese kritischen Dateien erhalten, wodurch die Verschlüsselungshierarchie und/oder die Active Directory-Konfigurationen gefährdet werden.

Zum Verschlüsseln von Verbindungen mit SQL Server Linux-Containern benötigen Sie ein Zertifikat mit den folgenden Anforderungen.

Das folgende Beispiel zeigt, wie die Verbindungen mit SQL Server für Linux-Containern verschlüsselt werden können. Hier verwenden wir ein selbstsigniertes Zertifikat, das nicht für Produktionsszenarien verwendet werden sollte. Für solche Umgebungen sollten Sie stattdessen CA-Zertifikate verwenden.

  1. Erstellen Sie ein ausschließlich für Test- und Nichtproduktionsumgebungen geeignetes selbstsigniertes Zertifikat.

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

    Im vorherigen Codebeispiel ist der Hostname des SQL-Containers sql1, sodass beim Herstellen einer Verbindung mit diesem Container der in der Verbindungszeichenfolge verwendete Name sql1.contoso.com,port lautet. Sie müssen auch sicherstellen, dass der Ordnerpfad /container/sql1/ bereits vorhanden ist, bevor Sie den obigen Befehl ausführen.

  2. Stellen Sie sicher, dass Sie die richtigen Berechtigungen für die Dateien mssql.key und mssql.pem festlegen, um Fehler beim Einbinden der Dateien in den SQL Server-Container zu vermeiden:

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

  3. Erstellen Sie nun eine mssql.conf-Datei mit folgendem Inhalt, um die serverinitiierte Verschlüsselung zu aktivieren. Ändern Sie für die clientinitiierte Verschlüsselung die letzte Zeile in forceencryption = 0.

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

    Hinweis

    Bei einigen Linux-Distributionen kann der Pfad zum Speichern des Zertifikats bzw. des Schlüssels auch „/etc/pki/tls/certs/“ bzw. „/etc/pki/tls/private/“ lauten. Überprüfen Sie den Pfad, bevor Sie mssql.conf für SQL Server-Container aktualisieren. Der Speicherort, den Sie in mssql.conf festlegen, ist der, an dem SQL Server im Container nach dem Zertifikat und dessen Schlüssel suchen wird. In diesem Fall entspricht der Speicherort /etc/ssl/certs/ und /etc/ssl/private/.

    Die Datei mssql.conf wird ebenfalls im selben Ordner unter /container/sql1/ erstellt. Nachdem Sie die obigen Schritte ausgeführt haben, sollten Sie über die drei Dateien mssql.conf, mssql.key und mssql.pem im Ordner sql1 verfügen.

  4. Stellen Sie den SQL Server-Container mit dem folgenden Befehl bereit:

    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

    Mir dem vorherigen Befehl haben Sie die Dateien mssql.conf, mssql.pem und mssql.key in den Container eingebunden und den Port 1433 (SQL Server-Standardport) im Container dem Port 5434 auf dem Host zugeordnet.

    Hinweis

    Wenn Sie RHEL 8 oder höher verwenden, können Sie auch den podman run-Befehl anstelle von docker run verwenden.

Befolgen Sie unter Vom Client initiierte Verschlüsselung die Anweisungen in den Abschnitten „Registrieren des Zertifikats auf dem Clientcomputer“ und „Exemplarische Verbindungszeichenfolgen“, um mit der Verschlüsselung von Verbindungen mit SQL Server für Linux-Containern zu beginnen.

Zugehöriger Inhalt

  • Der Schnellstart erleichtert Ihnen den Einstieg in die Verwendung von SQL Server 2017-Containerimages (14.x) in Docker.
  • Der Schnellstart erleichtert Ihnen den Einstieg in die Verwendung von SQL Server 2019-Containerimages (15.x) in Docker.
  • Der Schnellstart vereinfacht Ihnen den Einstieg in die Verwendung von Containerimages in SQL Server 2022 (16.x) in Docker.