Proteggere i contenitori Linux di SQL Server

  • Articolo

Si applica a:SQL Server - Linux

I contenitori di SQL Server 2017 (14.x) vengono avviati come utente ROOT per impostazione predefinita, causando alcuni problemi di sicurezza. Questo articolo illustra le opzioni di sicurezza disponibili quando si eseguono contenitori Linux di SQL Server e come creare un contenitore di SQL Server come utente non root.

Gli esempi in questo articolo ipotizzano che si usi Docker, ma è possibile applicare gli stessi principi ad altri strumenti di orchestrazione dei contenitori, tra cui Kubernetes.

Compilare ed eseguire contenitori di SQL Server 2017 non root

Eseguire la procedura seguente per creare un contenitore di SQL Server 2017 (14.x) che si avvia come utente mssql (non root).

Nota

I contenitori di SQL Server 2019 (15.x) e versioni successive vengono avviati automaticamente come contenitori non root, mentre i contenitori di SQL Server 2017 (14.x) vengono avviati come contenitori root per impostazione predefinita. Per altre informazioni sull'esecuzione di contenitori SQL Server come contenitori non radice, vedere Configurare la sicurezza.

  1. Scaricare il dockerfile di esempio per il contenitore di SQL Server non root e salvarlo come dockerfile.

  2. Eseguire il comando seguente nel contesto della directory dockerfile per compilare il contenitore di SQL Server non radice:

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

  3. Avviare il contenitore.

    Importante

    La variabile di ambiente SA_PASSWORD è deprecata. Utilizzare invece 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

    Nota

    Il flag --cap-add SYS_PTRACE è necessario per i contenitori di SQL Server non radice per generare dump a scopo di risoluzione dei problemi.

  4. Verificare che il contenitore sia in esecuzione come utente non radice:

    docker exec -it sql1 bash

    Eseguire whoami, che restituirà l'utente in esecuzione nel contenitore.

    whoami

Eseguire il contenitore come un altro utente non root nell'host

Per eseguire il contenitore di SQL Server come un altro utente non root, aggiungere il flag -u al comando docker run. Il contenitore non root prevede una restrizione, ovvero deve essere eseguito nell’ambito del gruppo root, a meno che non venga montato un volume in /var/opt/mssql a cui l'utente non root può accedere. Il gruppo root non concede alcuna autorizzazione root aggiuntiva all'utente non root.

Eseguire come utente con UID 4000

È possibile avviare SQL Server con un UID personalizzato. Ad esempio, il comando seguente avvia SQL Server con 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

Avviso

Accertarsi che il contenitore di SQL Server disponga di un utente designato, ad esempio mssql o root. In caso contrario non sarà possibile eseguire sqlcmd all'interno del contenitore. È possibile verificare se il contenitore di SQL Server è in esecuzione come utente denominato eseguendo whoami nel contenitore.

Eseguire il contenitore non radice come utente radice

Se necessario, è possibile eseguire il contenitore non root come utente root, il che concede anche tutte le autorizzazioni di file automaticamente al contenitore perché ha privilegi più elevati.

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

Eseguire come utente nel computer host

È possibile avviare SQL Server con un utente esistente nel computer host con il comando seguente:

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

Eseguire come utente e gruppo diversi

È possibile avviare SQL Server con un utente e un gruppo personalizzati. In questo esempio, il volume montato ha le autorizzazioni configurate per l'utente o il gruppo nel computer host.

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

Configurare le autorizzazioni di archiviazione permanenti per i contenitori non root

Per consentire all'utente non root di accedere ai file di database in volumi montati, accertarsi che l'utente o il gruppo con cui viene eseguito il contenitore possa leggere e scrivere nell'archivio file permanente.

È possibile ottenere la proprietà corrente dei file di database con questo comando.

ls -ll <database file dir>

Se SQL Server non ha accesso ai file di database persistenti, eseguire uno dei comandi seguenti.

Concedere al gruppo root l'accesso in lettura/scrittura ai file di database

Concedere le autorizzazioni per il gruppo radice alle directory seguenti in modo che il contenitore di SQL Server non radice abbia accesso ai file di database.

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

Impostare l'utente non root come proprietario dei file

Può trattarsi dell'utente non root predefinito o di qualsiasi altro utente non root che si vuole specificare. In questo esempio si imposta UID 10001 come utente non radice.

chown -R 10001:0 <database file dir>

Crittografare le connessioni ai contenitori Linux di SQL Server

Importante

Quando si configurano opzioni di autenticazione o crittografia di Active Directory, ad esempio Transparent Data Encryption (TDE) e SSL per SQL Server in Linux o dei contenitori, sono disponibili vari file, ad esempio la keytab, i certificati e la chiave del computer, creati per impostazione predefinita nella cartella /var/opt/mssql/secrets e l'accesso ai quali è limitato per impostazione predefinita agli utenti mssql e root. Quando si configura l'archivio permanente per i contenitori SQL Server, usare la stessa strategia di accesso, assicurandosi che il percorso del volume host o condiviso mappato alla cartella /var/opt/mssql/secrets all'interno del contenitore sia protetto e accessibile solo agli utenti mssql e root nell'host. Se l'accesso a questo percorso/cartella viene compromesso, un utente malintenzionato può accedere a questi file critici, compromettendo la gerarchia di crittografia e/o le configurazioni di Active Directory.

Per crittografare le connessioni ai contenitori Linux di SQL Server, è necessario un certificato con i requisiti seguenti.

Nel seguito è riportato un esempio di come è possibile crittografare la connessione a contenitori Linux di SQL Server. Qui si utilizza un certificato autofirmato che non deve essere usato per gli scenari di produzione. Per questi ambienti, usare invece i certificati della CA.

  1. Creare un certificato autofirmato, adatto solo per ambienti di test e non di produzione.

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

    Nell’esempio di codice precedente, sql1 è il nome host del contenitore SQL, quindi quando ci si connette a questo contenitore il nome usato nella stringa di connessione sarà sql1.contoso.com,port. Accertarsi anche che il percorso della cartella /container/sql1/ esista già prima di eseguire il comando precedente.

  2. Assicurarsi di impostare le autorizzazioni corrette per i file mssql.key e mssql.pem, in modo da evitare errori quando si montano i file nel contenitore SQL:

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

  3. Creare ora un file mssql.conf con il contenuto seguente per abilitare la crittografia avviata dal server. Per la crittografia avviata dal client, modificare l'ultima riga in forceencryption = 0.

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

    Nota

    Per alcune distribuzioni di Linux il percorso per l'archiviazione del certificato e della chiave può anche essere rispettivamente /etc/pki/tls/certs/ e /etc/pki/tls/private/. Verificare il percorso prima di aggiornare mssql.conf per i contenitori SQL Server. Il percorso impostato in mssql.conf sarà il percorso in cui SQL Server nel contenitore cercherà il certificato e la relativa chiave. In questo caso, la posizione è /etc/ssl/certs/ e /etc/ssl/private/.

    Viene anche creato il file mssql.conf nello stesso percorso della cartella /container/sql1/. Al termine dell'esecuzione dei passaggi precedenti, i tre file mssql.conf, mssql.key e mssql.pem dovrebbero essere presenti nella cartella sql1.

  4. Implementare il contenitore SQL Server con il comando seguente:

    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

    Nel comando precedente, sono stati montati i file mssql.conf, mssql.pem e mssql.key nel contenitore ed è stato eseguito il mapping della porta 1433 (porta predefinita di SQL Server) nel contenitore alla porta 5434 dell'host.

    Nota

    Se si usano RHEL 8 e versioni successive, è anche possibile usare il comando podman run anziché docker run.

Vedere le sezioni "Registrare il certificato nel computer client" ed "Esempi di stringhe di connessione" documentate in Crittografia avviata dal client per iniziare a crittografare le connessioni ai contenitori di SQL Server in Linux.

Contenuto correlato

  • Per informazioni introduttive sull'uso delle immagini del contenitore di SQL Server 2017 (14.x) in Docker, vedere questo articolo di avvio rapido
  • Per informazioni introduttive sull'uso delle immagini del contenitore di SQL Server 2019 (15.x) in Docker, vedere questo articolo di avvio rapido
  • Per informazioni introduttive sull'uso delle immagini del contenitore di SQL Server 2022 (16.x) in Docker, vedere questo articolo di avvio rapido