Delen via

Sql Server Linux-containers beveiligen

  • Artikel

van toepassing op:SQL Server- - Linux

SQL Server 2017-containers (14.x) worden standaard gestart als hoofdgebruiker, wat enkele beveiligingsproblemen kan veroorzaken. Dit artikel bevat informatie over beveiligingsopties die u hebt bij het uitvoeren van SQL Server Linux-containers en het bouwen van een SQL Server-container als een niet-hoofdgebruiker.

In de voorbeelden in dit artikel wordt ervan uitgegaan dat u Docker gebruikt, maar u kunt dezelfde principes toepassen op andere hulpprogramma's voor containerindeling, waaronder Kubernetes.

Niet-hoofd-SQL Server 2017-containers bouwen en uitvoeren

Volg deze stappen om een SQL Server 2017-container (14.x) te bouwen die wordt gestart als de mssql (niet-hoofdgebruiker).

Notitie

Containers voor SQL Server 2019 (15.x) en latere versies worden automatisch gestart als niet-hoofdmap, terwijl SQL Server 2017-containers (14.x) standaard als hoofdmap worden gestart. Zie Beveiligde SQL Server Linux-containersvoor meer informatie over het uitvoeren van SQL Server-containers als niet-hoofdcontainers.

  1. Download het Dockerfile-voorbeeldbestand voor niet-hoofd-SQL Server-containers en sla het bestand op als dockerfile.

  2. Voer de volgende opdracht uit in de context van de dockerfile-map om de niet-hoofd-SQL Server-container te bouwen:

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

  3. Start de container.

    Belangrijk

    De omgevingsvariabele SA_PASSWORD is afgeschaft. Gebruik in plaats daarvan 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

    Notitie

    De vlag --cap-add SYS_PTRACE is vereist voor niet-root SQL Server-containers om dumps te genereren voor probleemoplossingsdoeleinden.

  4. Controleer of de container wordt uitgevoerd als niet-hoofdgebruiker:

    docker exec -it sql1 bash

    Voer whoamiuit om de gebruiker te tonen die binnen de container draait.

    whoami

Container uitvoeren als een andere niet-hoofdgebruiker op de host

Als u de SQL Server-container wilt uitvoeren als een andere niet-hoofdgebruiker, voegt u de -u vlag toe aan de opdracht docker run. De niet-rootcontainer heeft de beperking dat deze moet draaien als onderdeel van de root groep, tenzij een volume is gemonteerd op /var/opt/mssql waartoe de niet-rootgebruiker toegang heeft. De root groep verleent geen extra hoofdmachtigingen aan de niet-hoofdgebruiker.

Als gebruiker uitvoeren met een UID 4000

U kunt SQL Server starten met een aangepaste UID. Met de volgende opdracht start u bijvoorbeeld SQL Server met 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

Waarschuwing

Zorg ervoor dat de SQL Server-container een benoemde gebruiker heeft, zoals mssql of root, anders kan sqlcmd- niet worden uitgevoerd in de container. U kunt controleren of de SQL Server-container wordt uitgevoerd als een benoemde gebruiker door whoami in de container uit te voeren.

Voer de niet-rootcontainer uit als root-gebruiker.

U kunt de niet-hoofdcontainer indien nodig uitvoeren als hoofdgebruiker, waarmee ook alle bestandsmachtigingen automatisch aan de container worden verleend, omdat deze een hogere bevoegdheid heeft.

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

Als gebruiker uitvoeren op uw hostcomputer

U kunt SQL Server starten met een bestaande gebruiker op de hostcomputer met de volgende opdracht:

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

Als een andere gebruiker en groep uitvoeren

U kunt SQL Server starten met een aangepaste gebruiker en groep. In dit voorbeeld heeft het gekoppelde volume machtigingen geconfigureerd voor de gebruiker of groep op de hostcomputer.

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

Permanente opslagmachtigingen configureren voor niet-hoofdcontainers

Als u de niet-hoofdgebruiker toegang wilt geven tot databasebestanden die zich op gekoppelde volumes bevinden, moet u ervoor zorgen dat de gebruiker of groep waaronder u de container uitvoert, kan lezen van en schrijven naar de permanente bestandsopslag.

U kunt het huidige eigendom van de databasebestanden ophalen met deze opdracht.

ls -ll <database file dir>

Voer een van de volgende opdrachten uit als SQL Server geen toegang heeft tot persistente databasebestanden.

De hoofdgroep lees-/schrijftoegang verlenen tot de databasebestanden

Ververleent de hoofdgroep machtigingen aan de volgende mappen, zodat de niet-hoofd-SQL Server-container toegang heeft tot databasebestanden.

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

De niet-hoofdgebruiker instellen als eigenaar van de bestanden

Dit kan de standaard niet-rootgebruiker zijn of een andere niet-rootgebruiker die u wilt opgeven. In dit voorbeeld stellen we UID 10001 in als de niet-hoofdgebruiker.

chown -R 10001:0 <database file dir>

Verbindingen met SQL Server Linux-containers versleutelen

Belangrijk

Bij het configureren van Active Directory-verificatie of versleutelingsopties, zoals Transparent Data Encryption (TDE) en SSL voor SQL Server op Linux of containers, zijn er verschillende bestanden, zoals de keytab, certificaten en computersleutel, die standaard worden gemaakt onder de map /var/opt/mssql/secrets, en toegang waartoe standaard wordt beperkt tot mssql en root gebruikers. Wanneer u permanente opslag voor SQL Server-containers configureert, gebruikt u dezelfde toegangsstrategie om ervoor te zorgen dat het pad op de host of het gedeelde volume dat is toegewezen aan de map /var/opt/mssql/secrets in de container is beveiligd en alleen toegankelijk is voor de mssql en root gebruikers op de host. Als de toegang tot dit pad/deze map is aangetast, kan een kwaadwillende gebruiker toegang krijgen tot deze kritieke bestanden, wat de versleutelingshiërarchie en/of Active Directory-configuraties in gevaar brengt.

Als u verbindingen met SQL Server Linux-containers wilt versleutelen, hebt u een certificaat nodig met de volgende vereisten.

Hier volgt een voorbeeld van hoe de verbinding kan worden versleuteld met SQL Server Linux-containers. Hier gebruiken we een zelfondertekend certificaat, dat niet moet worden gebruikt voor productiescenario's. Voor dergelijke omgevingen moet u in plaats daarvan CA-certificaten gebruiken.

  1. Maak een zelfondertekend certificaat dat alleen geschikt is voor test- en niet-productieomgevingen.

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

    In het vorige codevoorbeeld is sql1 de hostnaam van de SQL-container, dus wanneer u verbinding maakt met deze container, wordt de naam die in de verbindingsreeks wordt gebruikt, sql1.contoso.com,port. U moet er ook voor zorgen dat het mappad /container/sql1/ al bestaat voordat u de bovenstaande opdracht uitvoert.

  2. Zorg ervoor dat u de juiste machtigingen instelt voor de mssql.key- en mssql.pem-bestanden, zodat u fouten vermijdt wanneer u de bestanden koppelt aan de SQL Server-container:

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

  3. Maak nu een mssql.conf-bestand met de onderstaande inhoud om de door de server geïnitieerde versleuteling in te schakelen. Wijzig voor client geïnitieerde versleuteling de laatste regel in forceencryption = 0.

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

    Notitie

    Voor sommige Linux-distributies kan het pad voor het opslaan van het certificaat en de sleutel ook zijn: /etc/pki/tls/certs/ en /etc/pki/tls/private/ respectievelijk. Controleer het pad voordat u de mssql.conf voor SQL Server-containers bijwerkt. De locatie die u in de mssql.conf instelt, is de locatie waar SQL Server in de container naar het certificaat en de bijbehorende sleutel zoekt. In dit geval is die locatie /etc/ssl/certs/ en /etc/ssl/private/.

    Het mssql.conf bestand wordt ook gemaakt onder dezelfde maplocatie /container/sql1/. Nadat u de bovenstaande stappen hebt uitgevoerd, hebt u drie bestanden: mssql.conf, mssql.keyen mssql.pem in de map sql1.

  4. Implementeer de SQL Server-container met de volgende opdracht:

    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

    In de vorige opdracht hebben we de mssql.conf, mssql.pemen mssql.key bestanden gekoppeld aan de container en de standaardpoort 1433 (SQL Server) in de container toegewezen aan poort 5434 op de host.

    Notitie

    Als u RHEL 8 en latere versies gebruikt, kunt u ook podman run opdracht gebruiken in plaats van docker run.

Volg de secties 'Het certificaat registreren op uw clientcomputer' en 'Voorbeeldverbindingstekenreeksen' die worden beschreven in client geïnitieerde versleuteling om te beginnen met het versleutelen van verbindingen met SQL Server op Linux-containers.

Verwante inhoud

  • Ga aan de slag met containerafbeeldingen van SQL Server 2017 (14.x) in Docker door de snelle start door te nemen.
  • Ga aan de slag met containerinstallatiekopieën van SQL Server 2019 (15.x) in Docker door de quickstart te doorlopen
  • Ga aan de slag met containerinstallatiekopieën van SQL Server 2022 (16.x) in Docker door de quickstart te doorlopen