Sicherheitsarchitektur für das Erweiterbarkeitsframework in SQL Server Machine Learning Services

In der externen Verarbeitung verwendete Dienste (Launchpad)

Das Erweiterbarkeitsframework fügt einen neuen NT-Dienst zur Liste der Dienste in einer SQL Server-Installation hinzu: SQL Server-Launchpad (MSSSQLSERVER).

Die Datenbank-Engine verwendet den SQL Server-Launchpad-Dienst, um eine externe Skriptsitzung als separaten Prozess zu instanziieren. Der Prozess wird mit einem Konto mit geringen Rechten ausgeführt. Dieses Konto unterscheidet sich von SQL Server, Launchpad und der Benutzeridentität, unter der die gespeicherte Prozedur oder Hostabfrage ausgeführt wurde. Die Ausführung von Skripts in einem separaten Prozess unter einem Konto mit niedrigen Berechtigungen ist die Grundlage des Sicherheits- und Isolationsmodells für externe Skripts in SQL Server.

SQL Server verwaltet außerdem die Zuordnung der Identität des aufrufenden Benutzers zum Workerkonto mit geringen Berechtigungen, das zum Starten des Satellitenprozesses verwendet wird. In einigen Szenarios, in denen Skripts oder Code für Daten und Vorgänge an SQL Server zurückgerufen werden, kann SQL Server den Identitätstransfer nahtlos steuern. Skripts, die SELECT-Anweisungen oder aufrufende Funktionen und andere Programmierobjekte enthalten, werden in den meisten Fällen erfolgreich sein, wenn der aufrufende Benutzer über ausreichende Berechtigungen verfügt.

In der externen Verarbeitung verwendete Dienste (Launchpad)

Das Erweiterbarkeitsframework fügt einen neuen NT-Dienst zur Liste der Dienste in einer SQL Server-Installation hinzu: SQL Server-Launchpad (MSSSQLSERVER).

Die Datenbank-Engine verwendet den SQL Server-Launchpad-Dienst, um eine externe Skriptsitzung als separaten Prozess zu instanziieren. Der Prozess wird mit der Launchpad-Benutzeridentität ausgeführt, weist jedoch die Einschränkung auf, dass er sich in einer AppContainer-Instanz befindet. Die Ausführung von Skripts in einem separaten Prozess unter einer AppContainer-Instanz ist die Grundlage des Sicherheits- und Isolationsmodells für externe Skripts in SQL Server.

SQL Server verwaltet außerdem die Zuordnung der Identität des aufrufenden Benutzers zum Workerkonto mit geringen Berechtigungen, das zum Starten des Satellitenprozesses verwendet wird. In einigen Szenarios, in denen Skripts oder Code für Daten und Vorgänge an SQL Server zurückgerufen werden, kann SQL Server den Identitätstransfer nahtlos steuern. Skripts, die SELECT-Anweisungen oder aufrufende Funktionen und andere Programmierobjekte enthalten, werden in den meisten Fällen erfolgreich sein, wenn der aufrufende Benutzer über ausreichende Berechtigungen verfügt.

In der externen Verarbeitung verwendete Dienste

Das Erweiterbarkeitsframework fügt einen neuen Daemon in einer SQL Server-Installation hinzu: mssql-launchpadd. mssql-launchpadd wird unter dem Konto „mssql-launchpadd“ mit geringen Berechtigungen ausgeführt, das erstellt wird, wenn das Paket „mssql-server-extensibility“ installiert wird.

Nur eine Instanz der Datenbank-Engine wird unterstützt, und es ist ein launchpadd-Dienst an die Instanz gebunden. Wenn ein Skript ausgeführt wird, startet der launchpadd-Dienst einen separaten Launchpadprozess mit dem mssql_satellite-Benutzerkonto mit geringen Berechtigungen und eigener neuer PID, IPC, Einbindung und Netzwerknamespace. Jeder Satellitenprozess erbt das mssql_satellite-Benutzerkonto des Launchpads und verwendet dieses für die Dauer der Skriptausführung.

Weitere Informationen finden Sie unter Erweiterbarkeitsarchitektur in SQL Server Machine Learning Services.

Bei der Verarbeitung verwendete Identitäten (SQLRUserGroup)

SQLRUserGroup (eingeschränkte SQL-Benutzergruppe) wird durch das SQL Server-Setup erstellt und enthält einen Pool von lokalen Windows-Benutzerkonten mit niedriger Berechtigung. Wenn ein externer Prozess benötigt wird, verwendet Launchpad ein verfügbares Workerkonto zum Ausführen eines Prozesses. Genauer gesagt, Launchpad aktiviert ein verfügbares Workerkonto, ordnet es der Identität des aufrufenden Benutzers zu und führt das Skript unter dem Workerkonto aus.

• SQLRUserGroup ist mit einer bestimmten Instanz verknüpft. Für jede Instanz, für die maschinelles Lernen aktiviert wurde, wird ein separater Pool von Workerkonten benötigt. Konten können nicht zwischen Instanzen freigegeben werden.

• Die Größe des Benutzerkontenpools ist statisch und der Standardwert ist 20, wodurch 20 gleichzeitige Sitzungen unterstützt werden. Die Anzahl der externen Laufzeitsitzungen, die gleichzeitig gestartet werden können, ist durch die Größe dieses Benutzerkontenpools beschränkt.

• Workerkontonamen im Pool weisen das Format „SQLInstanznamenn“ auf. Auf einer Standardinstanz beispielsweise enthält SQLRUserGroup Konten mit den Namen MSSQLSERVER01, MSSQLSERVER02 und so weiter bis zu MSSQLSERVER20.

Für parallel ausgeführte Aufgaben sind keine zusätzlichen Konten erforderlich. Wenn ein Benutzer beispielsweise eine Bewertungstask ausführt, die parallel verarbeitet wird, wird für alle Threads das gleiche Workerkonto wiederverwendet. Wenn Sie beabsichtigen, die Machine Learning-Funktion intensiv zu nutzen, können Sie die Anzahl der Konten erhöhen, die für die Ausführung externer Skripts verwendet werden. Weitere Informationen finden Sie unter Skalieren der gleichzeitige Ausführung externer Skripts in SQL Server-Machine Learning Services.

Für SQLRUserGroup erteilte Berechtigungen

Mitglieder von SQLRUserGroup verfügen standardmäßig über Lese- und Ausführungsberechtigungen für Dateien in den SQL Server-Verzeichnissen Binn, R_SERVICES und PYTHON_SERVICES. Dies umfasst Zugriff auf ausführbare Dateien, Bibliotheken und integrierte Datasets in den R- und Python-Verteilungen, die mit SQL Server installiert werden.

Um vertrauliche Ressourcen in SQL Server zu schützen, können Sie optional eine Zugriffssteuerungsliste (ACL) definieren, die den Zugriff auf SQLRUserGroup verweigert. Umgekehrt können Sie auch Berechtigungen für lokale Datenressourcen vergeben, die auf dem Hostcomputer vorhanden sind, mit Ausnahme von SQL Server selbst.

SQLRUserGroup verfügt von Haus aus über keine Anmeldekonten für Datenbanken oder Berechtigungen für Daten. Unter bestimmten Umständen sollten Sie ein Anmeldekonto erstellen, um Loopbackverbindungen zuzulassen, insbesondere wenn es sich beim aufrufenden Benutzer um eine vertrauenswürdige Windows-Identität handelt. Diese Möglichkeit wird als implizite Authentifizierung bezeichnet. Weitere Informationen finden Sie unter Hinzufügen von SQLRUserGroup als Datenbankbenutzer.

Identitätszuordnung

Wenn eine Sitzung gestartet wird, ordnet Launchpad die Identität des aufrufenden Benutzers einem Workerkonto zu. Diese Zuordnung eines externen Windows-Benutzers oder einer gültigen SQL-Anmeldung zu einem Workerkonto gilt nur für die Lebensdauer der gespeicherten SQL-Prozedur, die das externe Skript ausführt. Parallele Abfragen von derselben Anmeldung werden demselben Benutzerworkerkonto zugeordnet.

Während der Ausführung erstellt Launchpad temporäre Ordner zum Speichern von Sitzungsdaten und löscht diese nach Beendigung der Sitzung. Der Zugriff auf die Verzeichnisse ist eingeschränkt. Für R wird diese Task von RLauncher ausgeführt. Für Python wird diese Task von PythonLauncher ausgeführt. Jedes einzelne Workerkonto ist auf seinen eigenen Ordner beschränkt und kann nicht auf Dateien in übergeordneten Verzeichnissen zugreifen. Allerdings kann das Workerkonto untergeordnete Elemente unter dem erstellten Sitzungsarbeitsordner lesen, schreiben oder löschen. Wenn Sie Administrator auf dem Computer sind, können Sie die Verzeichnisse anzeigen, die für jeden Prozess erstellt wurden. Jedes Verzeichnis wird durch die Sitzungs-GUID identifiziert.

Informationen zur AppContainer-Isolation

Die Isolation wird durch AppContainer-Instanzen erzielt. Wenn zur Laufzeit ein externes Skript in einer gespeicherten Prozedur oder Abfrage erkannt wird, ruft SQL Server Launchpad mit der Anforderung eines erweiterungsspezifischen Startprogramms auf. Launchpad ruft die entsprechende Laufzeitumgebung in einem Prozess unter seiner Identität auf und instanziiert einen AppContainer, um ihn aufzunehmen. Diese Änderung hat den Vorteil, dass keine lokalen Konten und Kennwörter mehr verwaltet werden müssen. Zudem kann dank dem Wegfall der Abhängigkeit von lokalen Benutzerkonten dieses Feature nun in Installationen verwendet werden, bei denen lokale Benutzerkonten nicht zulässig sind.

Gemäß der Implementierung durch SQL Server handelt es sich bei AppContainern um einen internen Mechanismus. Obwohl sich AppContainer im Prozessmonitor physisch nicht nachweisen lassen, sind sie dennoch in Firewallregeln für ausgehenden Datenverkehr zu finden, die beim Setup erstellt werden, um zu verhindern, dass Prozesse Netzwerkaufrufe ausführen. Weitere Informationen finden Sie unter Firewallkonfiguration für SQL Server Machine Learning Services.

Identitätszuordnung

Wenn eine Sitzung gestartet wird, ordnet Launchpad die Identität des aufrufenden Benutzers einer AppContainer-Instanz zu.

Identitätszuordnung

Der Launchpadd-Daemon (doppeltes D, mssql-launchpadd) weist die Identität des aufrufenden Benutzers einem separaten Launchpad-Prozess (mit einem D) einem „launchpad GUID“-Ordner und einem Satellitenzertifikat zu. Diese „launchpad GUID“-Ordner werden unter /var/opt/mssql-extensibility/data/ erstellt. Der Launchpad-Prozess verwendet dieses Zertifikat für die Authentifizierung mit SQL und erstellt dann temporäre Ordner für jede Sitzungs-GUID im Ordner „launchpad GUID“. Der Satellitenprozess (R, Python oder ExtHost) kann auf den Ordner „launchpad GUID“, das darin enthaltene Zertifikat und den Ordner „session GUID“ zugreifen.

Das folgende SQL-Skript gibt die Inhalte der Launchpad-Ordner aus.

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'

Implizite Authentifizierung (Loopbackanforderungen)

Eine implizierte Authentifizierung beschreibt das Verhalten von Verbindungsanforderungen, bei dem externe Prozesse, die als Workerkonten mit niedriger Berechtigung ausgeführt werden, als vertrauenswürdige Benutzeridentität für SQL Server bei Loopbackanforderungen für Daten oder Vorgänge dargestellt werden. Als Konzept ist die implizite Authentifizierung einzigartig für die Windows-Authentifizierung, bei SQL Server-Verbindungszeichenfolgen, die eine vertrauenswürdige Verbindung angeben, und bei Anforderungen, die von externen Prozessen wie R- oder Python-Skripts stammen. Sie wird manchmal auch als Loopback bezeichnet.

Vertrauenswürdige Verbindungen können über externe Skripts hergestellt werden, jedoch nur, wenn eine zusätzliche Konfiguration vorgenommen wird. In der Erweiterungsarchitektur werden externe Prozesse unter Workerkonten ausgeführt und erben Berechtigungen vom übergeordneten SQLRUserGroup-Verzeichnis. Wenn eine Verbindungszeichenfolge Trusted_Connection=True angibt, wird die Identität des Workerkontos für die Verbindungsanforderung angezeigt, die SQL Server standardmäßig nicht bekannt ist.

Um vertrauenswürdige Verbindungen erfolgreich herzustellen, müssen Sie ein Datenbankanmeldekonto für die SQLRUserGroup erstellen. Danach verfügt jede vertrauenswürdige Verbindung jedes SQLRUserGroup-Mitglieds über die Anmeldeberechtigung für SQL Server. Detaillierte Anweisungen finden Sie unter Erstellen von Anmeldeinformationen für SQLRUserGroup.

Vertrauenswürdige Verbindungen sind nicht die am häufigsten verwendete Variante einer Verbindungsanforderung. Wenn das externe Skript eine Verbindung angibt, ist es üblicher, ein SQL-Anmeldekonto oder einen vollständig angegebenen Benutzernamen und ein Kennwort zu verwenden, sofern die Verbindung zu einer ODBC-Datenquelle besteht.

Funktionsweise der impliziten Authentifizierung für externe Skriptsitzungen

Das folgende Diagramm zeigt die Interaktion von SQL Server-Komponenten mit der Language Runtime und die damit verbundene Authentifizierung in Windows.

Implizite Authentifizierung (Loopbackanforderungen)

Eine implizierte Authentifizierung beschreibt das Verhalten von Verbindungsanforderungen, bei dem externe Prozesse in AppContainer-Instanzen, als vertrauenswürdige Benutzeridentität für SQL Server bei Loopbackanforderungen für Daten oder Vorgänge dargestellt werden. Als Konzept ist die implizite Authentifizierung nicht mehr einzigartig für die Windows-Authentifizierung, bei SQL Server-Verbindungszeichenfolgen, die eine vertrauenswürdige Verbindung angeben, und bei Anforderungen, die von externen Prozessen wie R- oder Python-Skripts stammen. Sie wird manchmal auch als Loopback bezeichnet.

Durch die Verwaltung von Identitäten und Anmeldeinformationen verhindert die AppContainer-Instanz die Verwendung von Benutzeranmeldeinformationen, um Zugriff auf Ressourcen zu erhalten oder eine Anmeldung bei anderen Umgebungen durchzuführen. Die AppContainer-Umgebung erstellt einen Bezeichner, der die kombinierten Identitäten des Benutzers und der Anwendung verwendet, damit die Anmeldeinformationen für jeden Benutzer und jede Anwendung eindeutig sind und die Anwendung nicht die Identität des Benutzers annehmen kann. Weitere Informationen finden Sie unter AppContainer-Isolation.

Weitere Informationen zu Loopbackverbindungen finden Sie unter Loopbackverbindung mit SQL Server mithilfe eines Python- oder R-Skripts.

Funktionsweise der impliziten Authentifizierung für externe Skriptsitzungen

Das folgende Diagramm zeigt die Interaktion von SQL Server-Komponenten mit der Language Runtime und die damit verbundene Authentifizierung in Windows.

Implizite Authentifizierung (Loopbackanforderungen)

Eine implizierte Authentifizierung beschreibt das Verhalten von Verbindungsanforderungen, bei dem externe Prozesse, die als mssql_satellite-Benutzer in ihren eigenen Namespaces mit niedriger Berechtigung ausgeführt werden, als vertrauenswürdige Benutzeridentität für SQL Server bei Loopbackanforderungen für Daten oder Vorgänge dargestellt werden. Sie wird manchmal auch als Loopback bezeichnet.

Eine Loopbackverbindung wird mithilfe des Satellitenzertifikats aus dem Ordner „launchpad GUID“ hergestellt, um die Authentifizierung bei SQL Server mit dem Satellitenprozess durchzuführen. Die Identität des aufrufenden Benutzers wird diesen Zertifikat zugewiesen, wodurch der Satellitenprozess, der die Verbindung zu SQL Server mithilfe des Zertifikats herstellt, dem aufrufenden Benutzer zugeordnet werden kann.

Weitere Informationen finden Sie unter Loopbackverbindung mit SQL Server über ein Python- oder R-Skript.

Funktionsweise der impliziten Authentifizierung für externe Skriptsitzungen

Das folgende Diagramm zeigt die Interaktion von SQL Server-Komponenten mit der Language Runtime und die damit verbundene Authentifizierung in Linux.