Udostępnij za pośrednictwem

Zabezpieczanie kontenerów programu SQL Server z systemem Linux

  • Artykuł

Dotyczy:programu SQL Server — Linux

Kontenery programu SQL Server 2017 (14.x) są domyślnie uruchamiane jako użytkownik główny, co może powodować pewne problemy z zabezpieczeniami. W tym artykule omówiono opcje zabezpieczeń, które są dostępne podczas uruchamiania kontenerów programu SQL Server Linux oraz jak utworzyć kontener programu SQL Server jako użytkownik niebędący użytkownikiem głównym.

W przykładach w tym artykule założono, że używasz platformy Docker, ale możesz zastosować te same zasady do innych narzędzi orkiestracji kontenerów, w tym platformy Kubernetes.

Kompilowanie i uruchamianie kontenerów innych niż główne kontenery programu SQL Server 2017

Wykonaj następujące kroki, aby utworzyć kontener programu SQL Server 2017 (14.x), który jest uruchamiany jako użytkownik mssql (inny niż użytkownik główny).

Notatka

Kontenery dla SQL Server 2019 (15.x) i nowszych wersji są automatycznie uruchamiane jako nie-root, podczas gdy kontenery SQL Server 2017 (14.x) są domyślnie uruchamiane jako root. Aby uzyskać więcej informacji na temat uruchamiania kontenerów programu SQL Server jako kontenerów innych niż root, zobacz Secure SQL Server Linux containers.

  1. Pobierz przykładowy plik Dockerfile dla kontenerów programu SQL Server innych niż root i zapisz go jako dockerfile.

  2. Uruchom następujące polecenie w kontekście katalogu dockerfile, aby skompilować kontener programu SQL Server inny niż główny:

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

  3. Uruchom kontener.

    Ważny

    Zmienna środowiskowa SA_PASSWORD jest przestarzała. Zamiast tego użyj MSSQL_SA_PASSWORD.

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

    Notatka

    Flaga --cap-add SYS_PTRACE jest wymagana dla kontenerów programu SQL Server innych niż root w celu wygenerowania zrzutów na potrzeby rozwiązywania problemów.

  4. Sprawdź, czy kontener działa jako użytkownik niebędący użytkownikiem głównym:

    docker exec -it sql1 bash

    Uruchom whoami, który zwraca użytkownika działającego w kontenerze.

    whoami

Uruchamianie kontenera jako inny użytkownik niebędący użytkownikiem głównym na hoście

Aby uruchomić kontener programu SQL Server jako inny użytkownik niebędący użytkownikiem głównym, dodaj flagę -u do polecenia docker run. Kontener bez uprawnień administratora ma ograniczenie, że musi działać w ramach grupy root, chyba że do /var/opt/mssql zamontowano wolumin, do którego użytkownik bez uprawnień głównych może uzyskać dostęp. Grupa root nie udziela żadnych dodatkowych uprawnień głównych użytkownikowi niebędącemu użytkownikiem głównym.

Uruchamianie jako użytkownik z identyfikatorem UID 4000

Program SQL Server można uruchomić przy użyciu niestandardowego identyfikatora UID. Na przykład następujące polecenie uruchamia program SQL Server z identyfikatorem UID 4000:

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

Ostrzeżenie

Upewnij się, że kontener programu SQL Server ma nazwanego użytkownika, takiego jak mssql lub root, w przeciwnym razie sqlcmd nie będzie mógł działać w kontenerze. Możesz sprawdzić, czy kontener programu SQL Server jest uruchomiony jako nazwany użytkownik, uruchamiając whoami w kontenerze.

Uruchamianie kontenera innego niż główny jako użytkownik główny

W razie potrzeby jako użytkownik główny można uruchomić kontener inny niż główny, co również automatycznie przyznaje wszystkie uprawnienia do pliku kontenerowi, ponieważ ma wyższe uprawnienia.

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

Uruchom jako użytkownik na maszynie hosta

Program SQL Server można uruchomić przy użyciu istniejącego użytkownika na maszynie hosta za pomocą następującego polecenia:

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

Uruchom jako inny użytkownik i grupa

Program SQL Server można uruchomić przy użyciu niestandardowego użytkownika i grupy. W tym przykładzie zainstalowany wolumin ma uprawnienia skonfigurowane dla użytkownika lub grupy na maszynie hosta.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" --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

Skonfiguruj trwałe uprawnienia magazynu dla kontenerów nie-root

Aby zezwolić użytkownikowi niebędącemu administratorem na dostęp do plików bazy danych, które znajdują się na zainstalowanych woluminach, upewnij się, że użytkownik lub grupa, w ramach której uruchomiono kontener, może odczytywać pliki i zapisywać je w trwałym magazynie plików.

Za pomocą tego polecenia możesz uzyskać bieżącą własność plików bazy danych.

ls -ll <database file dir>

Uruchom jedno z następujących poleceń, jeśli program SQL Server nie ma dostępu do utrwalanych plików bazy danych.

Udzielanie grupie głównej dostępu do odczytu/zapisu do plików bazy danych

Przyznaj grupie głównej uprawnienia do następujących katalogów, aby kontener programu SQL Server inny niż główny miał dostęp do plików bazy danych.

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

Ustawianie użytkownika innego niż główny jako właściciela plików

Może to być domyślny użytkownik niebędący użytkownikiem głównym lub inny użytkownik inny niż główny, który chcesz określić. W tym przykładzie ustawiliśmy identyfikator UID 10001 jako użytkownika niebędącego użytkownikiem głównym.

chown -R 10001:0 <database file dir>

Szyfrowanie połączeń z kontenerami systemu Linux programu SQL Server

Ważny

Podczas konfigurowania opcji uwierzytelniania lub szyfrowania usługi Active Directory, takich jak Transparent Data Encryption (TDE) i SSL dla programu SQL Server w systemie Linux lub kontenerach, istnieje kilka plików, takich jak kartę klucza, certyfikaty i klucz komputera, które są tworzone domyślnie w folderze /var/opt/mssql/secretsi dostęp do którego jest domyślnie ograniczony do mssql i root użytkowników. Podczas konfigurowania magazynu trwałego dla kontenerów programu SQL Server należy użyć tej samej strategii dostępu, zapewniając, że ścieżka na hoście lub udostępnionym woluminie zamapowanym na folder /var/opt/mssql/secrets wewnątrz kontenera jest chroniona i dostępna tylko dla mssql i root użytkowników na hoście. Jeśli dostęp do tej ścieżki/folderu zostanie naruszony, złośliwy użytkownik może uzyskać dostęp do tych krytycznych plików, naruszyć hierarchię szyfrowania i/lub konfiguracje usługi Active Directory.

Aby szyfrować połączenia z kontenerami systemu Linux programu SQL Server, potrzebny jest certyfikat z następującymi wymaganiami .

Poniżej przedstawiono przykład sposobu szyfrowania połączenia z kontenerami systemu Linux programu SQL Server. W tym miejscu używamy certyfikatu z podpisem własnym, który nie powinien być używany w scenariuszach produkcyjnych. W takich środowiskach należy zamiast tego używać certyfikatów urzędu certyfikacji.

  1. Utwórz certyfikat z podpisem własnym, który jest odpowiedni tylko dla środowisk testowych i nieprodukcyjnych.

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

    W poprzednim przykładzie kodu sql1 jest nazwą hosta kontenera SQL, więc podczas nawiązywania połączenia z tym kontenerem nazwa używana w parametrach połączenia będzie sql1.contoso.com,port. Należy również upewnić się, że ścieżka folderu /container/sql1/ już istnieje przed uruchomieniem powyższego polecenia.

  2. Upewnij się, że ustawiono odpowiednie uprawnienia do plików mssql.key i mssql.pem, aby uniknąć błędów podczas instalowania plików w kontenerze programu SQL Server:

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

  3. Teraz utwórz plik mssql.conf z poniższą zawartością, aby włączyć szyfrowanie zainicjowane przez serwer. W przypadku szyfrowania zainicjowanego przez klienta zmień ostatni wiersz na forceencryption = 0.

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

    Notatka

    W przypadku niektórych dystrybucji systemu Linux ścieżka do przechowywania certyfikatu i klucza może być również: /etc/pki/tls/certs/ i /etc/pki/tls/private/ odpowiednio. Przed zaktualizowaniem mssql.conf dla kontenerów programu SQL Server sprawdź ścieżkę. Lokalizacja ustawiona w mssql.conf będzie lokalizacją, w której program SQL Server w kontenerze będzie wyszukiwać certyfikat i jego klucz. W takim przypadku lokalizacje to /etc/ssl/certs/ i /etc/ssl/private/.

    Plik mssql.conf jest również tworzony w tej samej lokalizacji folderu /container/sql1/. Po wykonaniu powyższych kroków w folderze sql1 powinny znajdować się trzy pliki: mssql.conf, mssql.keyi mssql.pem.

  4. Wdróż kontener programu SQL Server za pomocą następującego polecenia:

    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

    W poprzednim poleceniu zamontowaliśmy mssql.conf, mssql.pemi mssql.key plików do kontenera i zamapowaliśmy port 1433 (domyślny port programu SQL Server) w kontenerze na port 5434 na hoście.

    Notatka

    Jeśli używasz systemu RHEL 8 lub nowszych wersji, możesz również użyć polecenia podman run zamiast docker run.

Postępuj zgodnie z sekcjami "Register the certificate on your client machine" (Rejestrowanie certyfikatu na komputerze klienckim) i "Example connection strings" (Przykładowe parametry połączenia) opisane w Client Initiated Encryption w celu rozpoczęcia szyfrowania połączeń z programem SQL Server w kontenerach systemu Linux.

Powiązana zawartość

  • Rozpocznij pracę z obrazami kontenerów programu SQL Server 2017 (14.x) na platformie Docker, przechodząc przez przewodnik Szybki start
  • Rozpocznij korzystanie z obrazów kontenerów SQL Server 2019 (15.x) na platformie Docker, zapoznając się z przewodnikiem szybkiego startu
  • Rozpocznij pracę z obrazami kontenerów programu SQL Server 2022 (16.x) na platformie Docker, korzystając z szybkiego startu