Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:
SQL Server 2016 (13.x) e versioni successive
Questo articolo descrive l'architettura di sicurezza usata per integrare il motore di database di SQL Server e i componenti correlati con il framework di estendibilità in Machine Learning Services per SQL Server. Esamina gli elementi proteggibili, i servizi, l'identità del processo e le autorizzazioni. I punti chiave trattati in questo articolo includono lo scopo di launchpad, SQLRUserGroup e degli account worker, l'isolamento dei processi degli script esterni e il mapping delle identità utente agli account worker.
Per altre informazioni sui concetti e i componenti principali dell'estendibilità in SQL Server, vedere Architettura di estendibilità in Machine Learning Services per SQL Server.
Oggetti proteggibili per script esterno
Uno script esterno viene inviato come parametro di input a una stored procedure di sistema creata a questo scopo oppure viene incluso tramite wrapping in una stored procedure definita dall'utente. Lo script può essere scritto in R, Python o in linguaggi esterni, ad esempio Java o .NET. In alternativa, possono essere presenti modelli già sottoposti a training e archiviati in un formato binario in una tabella di database, che possono essere chiamati in una funzione T-SQL PREDICT.
Poiché lo script viene fornito tramite oggetti esistenti dello schema di database, stored procedure e tabelle, non esistono nuove entità a protezione diretta per SQL Server Machine Learning Services.
Indipendente dal modo in cui gli script vengono usati o da cosa sono costituiti, vengono creati e probabilmente salvati oggetti di database, ma non viene introdotto alcun nuovo tipo di oggetto per l'archiviazione dello script. Di conseguenza, la capacità di utilizzare, creare e salvare oggetti di database dipende in buona parte dalle autorizzazioni del database già definite per gli utenti.
Autorizzazioni
Il modello di sicurezza dei dati di SQL Server degli account di accesso e dei ruoli del database si estende allo script esterno. È necessario un account di accesso SQL Server o un account utente Windows per eseguire script esterni che usano dati di SQL Server o che vengono eseguiti con SQL Server come contesto di calcolo. Gli utenti di database che hanno le autorizzazioni necessarie per eseguire una query possono accedere agli stessi dati dallo script esterno.
L'account di accesso o l'account utente identifica l'entità di sicurezza, che può necessitare di più livelli di accesso, a seconda dei requisiti dello script esterno:
- Autorizzazione di accesso al database in cui sono abilitati script esterni.
- Autorizzazioni di lettura dei dati da oggetti protetti, ad esempio tabelle.
- Capacità di scrivere nuovi dati in una tabella, ad esempio un modello, o i risultati di assegnazione dei punteggi.
- La capacità di creare nuovi oggetti, ad esempio tabelle, procedure archiviate che utilizzano lo script esterno o funzioni personalizzate che utilizzano il processo di script esterno.
- Diritto di installare nuovi pacchetti nel computer SQL Server o usare i pacchetti forniti a un gruppo di utenti.
Ogni persona che esegue uno script esterno tramite SQL Server come contesto di esecuzione deve essere mappata a un utente nel database. Invece di impostare singolarmente autorizzazioni utente del database, è possibile creare ruoli per gestire i set di autorizzazioni e assegnare gli utenti ai ruoli.
Per altre informazioni, vedere Concedere agli utenti l'autorizzazione per Machine Learning Services per SQL Server.
Autorizzazioni per l'uso di uno strumento client esterno
Gli utenti che utilizzano uno script in uno strumento client esterno devono avere le proprie credenziali di accesso o il proprio account associati a un utente nel database, se devono eseguire uno script esterno nel database o accedere a oggetti e dati del database. Sono necessarie le stesse autorizzazioni indipendentemente dal fatto che lo script esterno venga inviato da un client di data science remoto o eseguito tramite una stored procedure T-SQL.
Ad esempio, si supponga di aver creato uno script esterno eseguito nel computer locale e di volerlo eseguire in SQL Server. È necessario assicurarsi che siano soddisfatte le condizioni seguenti:
- Il database consente le connessioni remote.
- L'account di accesso SQL o l'account Windows usato per l'accesso al database è stato aggiunto a SQL Server a livello di istanza.
- L'account di accesso SQL o l'utente Windows deve avere l'autorizzazione necessaria per eseguire script esterni. In genere, questa autorizzazione può essere aggiunta solo da un amministratore del database.
- L'account di accesso SQL o l'utente Windows deve essere aggiunto come utente, con le autorizzazioni appropriate, in ogni database in cui lo script esterno esegue una qualsiasi di queste operazioni:
- Recupero di dati.
- Scrittura o aggiornamento di dati.
- Creazione di nuovi oggetti, ad esempio tabelle o stored procedure.
Dopo avere effettuato il provisioning dell'account di accesso o dell'account utente Windows e avere concesso le autorizzazioni necessarie, è possibile eseguire uno script esterno in SQL Server usando un oggetto origine dati in R o la libreria revoscalepy in Python oppure chiamando una stored procedure contenente lo script esterno.
Ogni volta che da SQL Server viene avviato uno script esterno, il motore del database acquisisce il contesto di sicurezza dell'utente che ha avviato il processo e gestisce le associazioni dell'utente o del login agli oggetti a protezione diretta.
Di conseguenza, tutti gli script esterni avviati da un client remoto devono specificare le informazioni sull'account di accesso o sull'utente all'interno della stringa di connessione.
Servizi usati nell'elaborazione esterna (launchpad)
Il framework di estensibilità aggiunge un nuovo servizio NT all'elenco dei servizi in un'installazione di SQL Server: Launchpad di SQL Server (MSSSQLSERVER).
Il motore di database usa il servizio Launchpad di SQL Server per creare un'istanza di una sessione di script esterno come processo separato. Il processo viene eseguito con un account con privilegi limitati. Questo account è diverso da SQL Server, dal launchpad stesso e dall'identità utente con cui è stata eseguita la stored procedure o la query host. L'esecuzione dello script in un processo separato, con un account con privilegi limitati, è alla base del modello di sicurezza e di isolamento per gli script esterni in SQL Server.
SQL Server mantiene anche una mappatura tra l'identità dell'utente chiamante e l'account worker con privilegi limitati utilizzato per avviare il processo satellite. In alcuni scenari, in cui uno script o il codice richiama SQL Server per dati e operazioni, SQL Server può gestire il trasferimento di identità in modo uniforme. Uno script che contiene istruzioni SELECT o che chiama funzioni e altri oggetti di programmazione riesce in genere se l'utente chiamante ha autorizzazioni sufficienti.
Nota
Per impostazione predefinita, SQL Server Launchpad è configurato per essere eseguito con l'account NT Service\MSSQLLaunchpad, a cui sono assegnate tutte le autorizzazioni necessarie per eseguire script esterni. Per altre informazioni sulle opzioni configurabili, vedere Configurazione del servizio Launchpad di SQL Server.
Servizi usati nell'elaborazione esterna (launchpad)
Il framework di estensibilità aggiunge un nuovo servizio NT all'elenco dei servizi in un'installazione di SQL Server: Launchpad di SQL Server (MSSSQLSERVER).
Il motore di database usa il servizio Launchpad di SQL Server per creare un'istanza di una sessione di script esterno come processo separato. Il processo viene eseguito con l'identità utente del launchpad ma con la restrizione aggiuntiva di essere contenuto all'interno di un AppContainer. L'esecuzione dello script in un processo separato, con AppContainer, è alla base del modello di sicurezza e di isolamento per gli script esterni in SQL Server.
SQL Server mantiene anche una mappatura tra l'identità dell'utente chiamante e l'account di servizio con privilegi limitati usato per avviare il processo satellite. In alcuni scenari, in cui uno script o il codice richiama SQL Server per dati e operazioni, SQL Server può gestire il trasferimento di identità in modo uniforme. Uno script che contiene istruzioni SELECT o che chiama funzioni e altri oggetti di programmazione riesce in genere se l'utente chiamante ha autorizzazioni sufficienti.
Nota
Per impostazione predefinita, SQL Server Launchpad è configurato per essere eseguito con l'account NT Service\MSSQLLaunchpad, a cui sono assegnate tutte le autorizzazioni necessarie per eseguire script esterni. Per altre informazioni sulle opzioni configurabili, vedere Configurazione del servizio Launchpad di SQL Server.
Servizi usati nell'elaborazione esterna
Il framework di estendibilità aggiunge un nuovo daemon in un'installazione di SQL Server: mssql-launchpadd. mssql-launchpadd viene eseguito con l'account con privilegi limitati mssql_launchpadd creato quando viene installato il pacchetto mssql-server-extensibility.
È supportata una sola istanza del motore di database e all'istanza è associato un solo servizio launchpad. Quando viene eseguito uno script, il servizio launchpad avvia un processo launchpad separato con l'account utente con privilegi limitati mssql_satellite nel proprio nuovo namespace PID, IPC, di montaggio e di rete. Ogni processo satellite eredita l'account utente mssql_satellite di launchpad e usa tale account per la durata dell'esecuzione dello script.
Per altre informazioni, vedere Architettura di estendibilità in SQL Server Machine Learning Services.
Identità usate nell'elaborazione (SQLRUserGroup)
SQLRUserGroup (gruppo di utenti SQL limitato) viene creato dal programma di installazione di SQL Server e contiene un pool di account utente Windows locali con privilegi limitati. Quando è necessario un processo esterno, launchpad usa un account di lavoro disponibile per l'esecuzione del processo. Più precisamente, launchpad attiva un account worker disponibile, lo associa all'identità dell'utente chiamante ed esegue lo script con l'account worker.
SQLRUserGroup è collegato a un'istanza specifica. Per ogni istanza in cui è stato abilitato l'apprendimento automatico è necessario un pool di account di lavoro separato. Gli account non possono essere condivisi tra istanze.
La dimensione del pool di account utente è statica e il valore predefinito è 20, ovvero il pool supporta 20 sessioni simultaneamente. Il numero delle sessioni di runtime esterne che possono essere avviate simultaneamente è limitato dalla dimensione di questo pool di account utente.
I nomi degli account di lavoro nel pool usano il formato NomeIstanzaSQLnn. Ad esempio, in un'istanza predefinita SQLRUserGroup contiene gli account denominati MSSQLSERVER01, MSSQLSERVER02 e così via fino a MSSQLSERVER20.
Le attività parallelizzate non usano account aggiuntivi. Ad esempio, se un utente esegue un'attività di assegnazione di punteggi che usa l'elaborazione parallela, viene riutilizzato lo stesso account di lavoro per tutti i thread. Se si intende fare un uso intenso dell'apprendimento automatico, è possibile aumentare il numero di account necessari per l'esecuzione di script esterni. Per altre informazioni, vedere Ridimensionare l'esecuzione simultanea di script esterni in SQL Server Machine Learning Services.
Autorizzazioni concesse a SQLRUserGroup
Per impostazione predefinita, i membri di SQLRUserGroup hanno autorizzazioni di lettura ed esecuzione per i file nelle directory di SQL Server Binn, R_SERVICES e PYTHON_SERVICES. Questo include l'accesso a file eseguibili, librerie e set di dati predefiniti nelle distribuzioni R e Python installate con SQL Server.
Per proteggere risorse sensibili in SQL Server, è facoltativamente possibile definire un elenco di controllo di accesso che nega l'accesso a SQLRUserGroup. Al contrario, è possibile concedere autorizzazioni per le risorse dati locali presenti nel computer host, oltre che SQL Server stesso.
Per impostazione predefinita, SQLRUserGroup non ha un account di accesso al database o autorizzazioni per i dati. In alcuni casi, può essere necessario creare un account di accesso per consentire connessioni loopback, in particolare quando l'utente chiamante è un'identità Windows attendibile. Questo scenario è denominato autenticazione implicita. Per altre informazioni, vedere Aggiungere SQLRUserGroup come utente del database.
Mappatura delle identità
Quando viene avviata una sessione, launchpad associa l'identità dell'utente chiamante a un account worker. L'associazione di un utente Windows esterno o di un login SQL valido a un account del processo di lavoro è valida solo per la durata della stored procedure di SQL che esegue lo script esterno. Le query parallele dallo stesso account di accesso sono mappate allo stesso account utente di lavoro.
Durante l'esecuzione, launchpad crea cartelle temporanee per l'archiviazione dei dati di sessione, eliminandole al termine della sessione. Le directory sono ad accesso limitato. Per R, questa attività viene eseguita da RLauncher. Per Python, questa attività viene eseguita da PythonLauncher. Ogni singolo account di lavoro è limitato alla propria cartella e non può accedere a file in cartelle di livello superiore. Tuttavia, l'account di lavoro può leggere, scrivere o eliminare figli all'interno della cartella di lavoro della sessione creata. Un amministratore del computer può visualizzare le directory create per ogni processo. Ogni directory è identificata dal relativo GUID di sessione.
Isolamento tramite AppContainer
L'isolamento viene ottenuto tramite AppContainer. In fase di esecuzione, quando viene rilevato uno script esterno in una procedura archiviata o in una query, SQL Server chiama Launchpad richiedendo un programma di avvio specifico per l'estensione. Launchpad invoca l'ambiente di runtime appropriato in un processo sotto la propria identità e crea un'istanza di AppContainer per contenerlo. Questa modifica è utile perché la gestione degli account locali e delle password non è più necessaria. Inoltre, nelle installazioni in cui non sono consentiti account utente locali, l'eliminazione della dipendenza dall'account utente locale significa che è ora possibile usare questa funzionalità.
In base all'implementazione in SQL Server, gli ambienti AppContainer sono meccanismi interni. Anche se non vedrai alcuna evidenza concreta degli AppContainer in Process Monitor, puoi trovarli nelle regole del firewall in uscita create da Setup per impedire ai processi di effettuare chiamate di rete. Per altre informazioni, vedere Configurazione del firewall per i servizi di Machine Learning di SQL Server.
Mappatura delle identità
All'avvio di una sessione, launchpad esegue il mapping dell'identità dell'utente chiamante a un AppContainer.
Nota
In SQL Server 2019 e versioni successive SQLRUserGroup include un solo membro, che è ora il singolo account del servizio Launchpad di SQL Server, anziché più account di lavoro.
Mappatura delle identità
Il daemon launchpadd (due 'D' - mssql-launchpadd) esegue il mapping dell'identità dell'utente chiamante a un processo launchpad separato (una sola 'D') con una cartella "launchpad GUID" e un certificato satellite. Queste cartelle GUID del launchpad vengono create in /var/opt/mssql-extensibility/data/. Il processo launchpad usa questo certificato per eseguire l'autenticazione in SQL e quindi crea le cartelle temporanee per ogni GUID di sessione nella cartella GUID del launchpad. Il processo satellite (R, Python o ExtHost) può accedere alla cartella GUID del launchpad, al certificato in essa incluso e alla relativa cartella GUID della sessione.
Lo script SQL seguente stampa il contenuto delle cartelle del launchpad.
EXECUTE sp_execute_external_script @language = N'R'
,@script = N'
print("Contents of /var/opt/mssql-extensibility/data :");
print(system("ls -al /var/opt/mssql-extensibility/data"));
print("Contents of Launchpad GUID folder:");
print(system("ls -al /var/opt/mssql-extensibility/data/*"));
print(system("ls -al /var/opt/mssql-extensibility/data/*/*"))
'
,@input_data_1 = N'SELECT 1 AS hello'
Autenticazione implicita (richieste loopback)
L'autenticazione implicita descrive il comportamento delle richieste di connessione in cui i processi esterni in esecuzione come account di lavoro con privilegi limitati vengono presentati come identità utente attendibile a SQL Server in richieste loopback di dati o operazioni. Concettualmente l'autenticazione implicita è univoca per l'autenticazione di Windows, nelle stringhe di connessione di SQL Server che specificano una connessione trusted e in richieste provenienti da processi esterni come uno script R o Python. A volte è anche nota come loopback.
Le connessioni trusted possono essere usate da script esterni, ma solo con una configurazione aggiuntiva. Nell'architettura di estendibilità i processi esterni vengono eseguiti con account di lavoro ed ereditano le autorizzazioni dal gruppo SQLRUserGroup padre. Quando una stringa di connessione specifica Trusted_Connection=True, l'identità dell'account di lavoro viene presentata nella richiesta di connessione, che per impostazione predefinita è sconosciuta a SQL Server.
Perché le connessioni trusted riescano, è necessario creare un account di accesso al database per SQLRUserGroup. Dopo averlo fatto, qualsiasi connessione attendibile proveniente da un membro di SQLRUserGroup avrà diritti di accesso a SQL Server. Per istruzioni dettagliate, vedere Aggiungere SQLRUserGroup a un account di accesso al database.
Le connessioni fidate non sono il tipo più diffuso di richiesta di connessione. Quando lo script esterno specifica una connessione, è spesso più comune usare un account SQL oppure un nome utente completo e una password se la connessione avviene tramite un'origine dati ODBC.
Funzionamento dell'autenticazione implicita per sessioni di script esterni
Il diagramma seguente mostra l'interazione dei componenti di SQL Server con il runtime del linguaggio e descrive come viene eseguita l'autenticazione implicita per Windows.
Autenticazione implicita (richieste loopback)
L'autenticazione implicita descrive il comportamento delle richieste di connessione in cui i processi esterni in esecuzione in AppContainer vengono presentati come identità utente attendibile a SQL Server in richieste loopback di dati o operazioni. Concettualmente l'autenticazione implicita non è più univoca per l'autenticazione di Windows, nelle stringhe di connessione di SQL Server che specificano una connessione trusted e in richieste provenienti da processi esterni come uno script R o Python. A volte è anche nota come loopback.
Grazie alla gestione di identità e credenziali, AppContainer impedisce l'uso di credenziali utente per ottenere l'accesso alle risorse o ad altri ambienti. L'ambiente AppContainer crea un identificatore che usa le identità combinate dell'utente e dell'applicazione, in modo che le credenziali siano univoche per ogni coppia utente/applicazione e che l'applicazione non possa rappresentare l'utente. Per altre informazioni, vedere Isolamento tramite AppContainer.
Per altri dettagli sulle connessioni loopback, vedere Connessione loopback a SQL Server da uno script Python o R.
Funzionamento dell'autenticazione implicita per sessioni di script esterni
Il diagramma seguente mostra l'interazione dei componenti di SQL Server con il runtime del linguaggio e descrive come viene eseguita l'autenticazione implicita per Windows.
Autenticazione implicita (richieste loopback)
L'autenticazione implicita descrive il comportamento delle richieste di connessione in cui i processi esterni in esecuzione come utenti mssql_satellite con privilegi limitati nei rispettivi spazi dei nomi vengono presentati come identità utente attendibile a SQL Server in richieste loopback di dati o operazioni. A volte è anche nota come loopback.
Una connessione loopback viene stabilita utilizzando il certificato del satellite dalla cartella GUID del launchpad, affinché il processo satellite possa autenticarsi nuovamente a SQL Server. L'identità dell'utente chiamante viene associata a questo certificato e, di conseguenza, il processo satellite che si riconnette a SQL Server tramite il certificato può a sua volta essere ricondotto all'utente chiamante.
Per ulteriori informazioni, vedere Connessione di loopback a SQL Server da uno script Python o R.
Funzionamento dell'autenticazione implicita per sessioni di script esterni
Il diagramma seguente mostra l'interazione dei componenti di SQL Server con il runtime del linguaggio e descrive come viene eseguita l'autenticazione implicita in Linux.
La crittografia trasparente dei dati a riposo non è supportata.
La tecnologia Transparent Data Encryption (TDE) non è supportata per i dati inviati o ricevuti dal runtime dello script esterno. Il motivo è che il processo esterno viene eseguito esternamente al processo di SQL Server. Di conseguenza, i dati usati dal runtime esterno non vengono protetti dalla funzionalità di crittografia del motore di database. Questo comportamento non è diverso da quello di qualsiasi altro client in esecuzione nel computer SQL Server che legge dati dal database ed esegue una copia.
Di conseguenza, la tecnologia TDE non viene applicata ai dati usati in script esterni, né ai dati salvati su disco o ai risultati intermedi permanenti. Tuttavia, altri tipi di crittografia, ad esempio la crittografia unità BitLocker di Windows o la crittografia di terze parti applicata a livello di file o cartella, saranno comunque validi.
Nel caso di Always Encrypted, i runtime esterni non hanno accesso alle chiavi di crittografia. Di conseguenza, i dati non possono essere inviati agli script.