Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
gäller för:
SQL Server 2016 (13.x) och senare versioner
Den här artikeln beskriver säkerhetsarkitekturen som används för att integrera SQL Server-databasmotorn och relaterade komponenter med utökningsramverket i SQL Server Machine Learning Services. Den undersöker skyddsbara objekt, tjänster, processidentitet och behörigheter. Viktiga punkter som beskrivs i den här artikeln är syftet med launchpad, SQLRUserGroup- och arbetskonton, processisolering av externa skript och hur användaridentiteter mappas till arbetskonton.
Mer information om viktiga begrepp och komponenter för utökningsbarhet i SQL Server finns i Utökningsarkitektur i SQL Server Machine Learning Services.
Säkerhetsobjekt för externt skript
Ett externt skript skickas som en indataparameter till en system lagrad procedur som skapats för detta ändamål eller omsluts av en lagrad procedur som du definierar. Skriptet kan skrivas i R, Python eller externa språk som Java eller .NET. Du kan också ha modeller som förtränas och lagras i binärt format i en databastabell, som kan anropas i en T-SQL PREDICT-funktion .
Eftersom skriptet tillhandahålls via befintliga databasschemaobjekt, lagrade procedurer och tabeller finns det inga nya skyddsbara objekt för SQL Server Machine Learning Services.
Oavsett hur du använder skript eller, vad de består av, skapas databasobjekt och sparas förmodligen, men ingen ny objekttyp introduceras för lagring av skript. Därför beror möjligheten att använda, skapa och spara databasobjekt till stor del på databasbehörigheter som redan har definierats för dina användare.
Permissions
SQL Server:s datasäkerhetsmodell för databasinloggningar och roller utökas till externt skript. En SQL Server-inloggning eller Ett Windows-användarkonto krävs för att köra externa skript som använder SQL Server-data eller som körs med SQL Server som beräkningskontext. Databasanvändare som har behörighet att köra en fråga kan komma åt samma data från ett externt skript.
Inloggnings- eller användarkontot identifierar säkerhetsobjektet, som kan behöva flera åtkomstnivåer, beroende på kraven för externt skript:
- Behörighet att komma åt databasen där externa skript är aktiverade.
- Behörigheter för att läsa data från skyddade objekt, till exempel tabeller.
- Möjligheten att skriva nya data till en tabell, till exempel en modell, eller bedömningsresultat.
- Möjligheten att skapa nya objekt, till exempel tabeller, lagrade procedurer som använder det externa skriptet eller anpassade funktioner som använder externa skriptjobb.
- Rätten att installera nya paket på SQL Server-datorn eller använda paket som tillhandahålls till en grupp användare.
Varje person som kör ett externt skript med SQL Server som körningskontext måste mappas till en användare i databasen. I stället för att individuellt ange behörigheter för databasanvändare kan du skapa roller för att hantera uppsättningar med behörigheter och tilldela användare till dessa roller i stället för att individuellt ange användarbehörigheter.
Mer information finns i Ge användare behörighet till SQL Server Machine Learning Services.
Behörigheter när du använder ett externt klientverktyg
Användare som använder skript i ett externt klientverktyg måste ha sin inloggning eller sitt konto mappat till en användare i databasen om de behöver köra ett externt skript i databasen eller komma åt databasobjekt och data. Samma behörigheter krävs om det externa skriptet skickas från en fjärrdata science-klient eller körs med en T-SQL-lagrad procedur.
Anta till exempel att du har skapat ett externt skript som körs på den lokala datorn och att du vill köra skriptet på SQL Server. Du måste se till att följande villkor uppfylls:
- Databasen tillåter fjärranslutningar.
- SQL-inloggningen eller Windows-kontot som du använde för databasåtkomst har lagts till i SQL Server på instansnivå.
- SQL-inloggningen eller Windows-användaren måste ha behörighet att köra externa skript. I allmänhet kan den här behörigheten bara läggas till av en databasadministratör.
- SQL-inloggningen eller Windows-användaren måste läggas till som en användare med lämpliga behörigheter i varje databas där det externa skriptet utför någon av dessa åtgärder:
- Hämtar data.
- Skriva eller uppdatera data.
- Skapa nya objekt, till exempel tabeller eller lagrade procedurer.
När inloggningen eller Windows-användarkontot har etablerats och fått nödvändiga behörigheter kan du köra ett externt skript på SQL Server med hjälp av ett datakällobjekt i R eller biblioteket revoscalepy i Python, eller genom att anropa en lagrad procedur som innehåller det externa skriptet.
När ett externt skript startas från SQL Server hämtar säkerheten för databasmotorn säkerhetskontexten för den användare som startade jobbet och hanterar mappningarna för användaren eller inloggningen till skyddsbara objekt.
Därför måste alla externa skript som initieras från en fjärrklient ange inloggnings- eller användarinformationen som en del av anslutningssträngen.
Tjänster som används vid extern bearbetning (startplatta)
Utökningsramverket lägger till en ny NT-tjänst i listan över tjänster i en SQL Server-installation: SQL Server Launchpad (MSSSQLSERVER).
Databasmotorn använder SQL Server launchpad-tjänsten för att instansiera en extern skriptsession som en separat process. Processen körs under ett konto med låg behörighet. Det här kontot skiljer sig från SQL Server, själva startplattan och användaridentiteten under vilken den lagrade proceduren eller värdfrågan kördes. Att köra skript i en separat process, under ett konto med låg behörighet, är grunden för säkerhets- och isoleringsmodellen för externa skript i SQL Server.
SQL Server upprätthåller också en mappning av identiteten för den anropande användaren till det lågprivilegierade arbetskonto som används för att starta satellitprocessen. I vissa scenarier, där skript eller kod anropar tillbaka till SQL Server för data och åtgärder, kan SQL Server hantera identitetsöverföring sömlöst. Skript som innehåller SELECT-instruktioner eller anropande funktioner och andra programmeringsobjekt lyckas vanligtvis om den anropande användaren har tillräcklig behörighet.
Anmärkning
Som standard är SQL Server Launchpad konfigurerat att köras under NT Service\MSSQLLaunchpad, som etableras med alla nödvändiga behörigheter för att köra externa skript. Mer information om konfigurerbara alternativ finns i Konfiguration av SQL Server launchpad-tjänsten.
Tjänster som används vid extern bearbetning (startplatta)
Utökningsramverket lägger till en ny NT-tjänst i listan över tjänster i en SQL Server-installation: SQL Server launchpad (MSSSQLSERVER).
Databasmotorn använder SQL Server launchpad-tjänsten för att instansiera en extern skriptsession som en separat process. Processen körs under launchpad-användaridentiteten men med den extra begränsningen att finnas i en AppContainer. Att köra skript i en separat process, under AppContainer, är grunden för säkerhets- och isoleringsmodellen för externa skript i SQL Server.
SQL Server upprätthåller också en mappning av identiteten för den anropande användaren till det lågprivilegierade arbetskonto som används för att starta satellitprocessen. I vissa scenarier, där skript eller kod anropar tillbaka till SQL Server för data och åtgärder, kan SQL Server hantera identitetsöverföring sömlöst. Skript som innehåller SELECT-instruktioner eller anropande funktioner och andra programmeringsobjekt lyckas vanligtvis om den anropande användaren har tillräcklig behörighet.
Anmärkning
Som standard är SQL Server Launchpad konfigurerat att köras under NT Service\MSSQLLaunchpad, som etableras med alla nödvändiga behörigheter för att köra externa skript. Mer information om konfigurerbara alternativ finns i Konfiguration av SQL Server launchpad-tjänsten.
Tjänster som används vid extern bearbetning
Utökningsramverket lägger till en ny daemon i en SQL Server-installation: mssql-launchpadd. mssql-launchpadd körs under det lågprivilegierade kontot mssql_launchpadd som skapas när paketet mssql-server-extensibility har installerats.
Endast en databasmotorinstans stöds och det finns en launchpadd-tjänst som är bunden till instansen. När ett skript körs, startar launchpadd-service en separat launchpad-process med det lågprivilegierade användarkontot mssql_satellite i sin egen nya PID-, IPC-, monterings- och nätverksnamnrymd. Varje satellitprocess ärver mssql_satellite användarkontot för launchpad och använder det under skriptkörningens varaktighet.
Mer information finns i Utökningsarkitektur i SQL Server Machine Learning Services.
Identiteter som används vid bearbetning (SQLRUserGroup)
SQLRUserGroup (SQL-begränsad användargrupp) skapas av SQL Server-installationsprogrammet och innehåller en pool med lokala Windows-användarkonton med låg behörighet. När en extern process behövs tar launchpad ett tillgängligt arbetskonto och använder det för att köra en process. Mer specifikt aktiverar launchpad ett tillgängligt arbetskonto, mappar det till den anropande användarens identitet och kör skriptet under arbetskontot.
SQLRUserGroup är länkad till en specifik instans. En separat pool med arbetskonton behövs för varje instans där maskininlärning har aktiverats. Konton kan inte delas mellan instanser.
Storleken på användarkontopoolen är statisk och standardvärdet är 20, vilket stöder 20 samtidiga sessioner. Antalet externa körningssessioner som kan startas samtidigt begränsas av storleken på den här användarkontopoolen.
Arbetskontonamn i poolen har formatet SQLInstanceNamenn. I en standardinstans innehåller SQLRUserGroup till exempel konton med namnet MSSQLSERVER01, MSSQLSERVER02 och så vidare upp till MSSQLSERVER20.
Parallelliserade uppgifter använder inte ytterligare konton. Om en användare till exempel kör en bedömningsuppgift som använder parallell bearbetning återanvänds samma arbetskonto för alla trådar. Om du tänker använda maskininlärning mycket kan du öka antalet konton som används för att köra externa skript. Mer information finns i Skala samtidig körning av externa skript i SQL Server Machine Learning Services.
Behörigheter som beviljats TILL SQLRUserGroup
Som standard har medlemmar i SQLRUserGroup läs- och körningsbehörigheter för filer i SQL Server Binn, R_SERVICES och PYTHON_SERVICES kataloger. Detta omfattar åtkomst till körbara filer, bibliotek och inbyggda datauppsättningar i R- och Python-distributionerna som är installerade med SQL Server.
Om du vill skydda känsliga resurser på SQL Server kan du definiera en åtkomstkontrollista (ACL) som nekar åtkomst till SQLRUserGroup. Däremot kan du även bevilja behörigheter till lokala dataresurser som finns på värddatorn, förutom själva SQL Server.
SqlRUserGroup har inte någon databasinloggning eller behörighet till några data. Under vissa omständigheter kanske du vill skapa en inloggning för att tillåta loopback-anslutningar, särskilt när en betrodd Windows-identitet är den anropande användaren. Den här funktionen kallas underförstådd autentisering. Mer information finns i Lägga till SQLRUserGroup som databasanvändare.
Identitetsmappning
När en session startas mappar launchpad identiteten för den anropande användaren till ett arbetskonto. Mappningen av en extern Windows-användare eller giltig SQL-inloggning till ett arbetskonto är endast giltig under hela den SQL-lagrade procedur som kör det externa skriptet. Parallella frågor från samma inloggning mappas till samma användarkonto.
Under körningen skapar launchpad tillfälliga mappar för att lagra sessionsdata och tar bort dem när sessionen avslutas. Katalogerna är åtkomstbegränsade. För R utför RLauncher den här uppgiften. För Python utför PythonLauncher den här uppgiften. Varje enskilt arbetskonto är begränsat till sin egen mapp och kan inte komma åt filer i mappar över sin egen nivå. Arbetskontot kan dock läsa, skriva eller ta bort underordnade under den sessionsarbetsmapp som skapades. Om du är administratör på datorn kan du visa de kataloger som skapats för varje process. Varje katalog identifieras av dess sessions-GUID.
AppContainer-isolering
Isolering uppnås via AppContainers. Under körning, när ett externt skript identifieras i en lagrad procedur eller fråga, anropar SQL Server Launchpad med en begäran om en startprogram som är specifik för tillägget. Launchpad anropar lämplig körningsmiljö i en process under sin identitet och instansierar en AppContainer för att kapsla in den. Den här ändringen är fördelaktig eftersom lokal konto- och lösenordshantering inte längre krävs. För installationer där lokala användarkonton är förbjudna innebär eliminering av beroendet för det lokala användarkontot att du nu kan använda den här funktionen.
Som implementerats av SQL Server är AppContainers en intern mekanism. Även om du inte ser fysiska bevis på AppContainers i Process Monitor kan du hitta dem i utgående brandväggsregler som skapats av installationsprogrammet för att förhindra att processer gör nätverksanrop. Mer information finns i Brandväggskonfiguration för SQL Server Machine Learning Services.
Identitetsmappning
När en session startas mappar launchpad identiteten för den anropande användaren till en AppContainer.
Anmärkning
I SQL Server 2019 och senare har SQLRUserGroup bara en medlem som nu är det enda SQL Server launchpad-tjänstkontot i stället för flera arbetskonton.
Identitetsmappning
Launchpadd (dubbel D - mssql-launchpadd) daemon mappar identiteten för den anropande användaren till en separat startplatta (enda D)-process med en "launchpad GUID"-mapp och ett satellitcertifikat. Dessa GUID-mappar för startplattan skapas under /var/opt/mssql-extensibility/data/. Launchpad-processen använder det här certifikatet för att autentisera tillbaka till SQL och skapar sedan tillfälliga mappar för varje sessions-GUID under mappen launchpad GUID. Satellitprocessen (R, Python eller ExtHost) kan komma åt mappen launchpad GUID, certifikatet under den och dess session-GUID-mapp.
Följande SQL-skript skriver ut innehållet i launchpad-mapparna.
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'
Underförstådd autentisering (loopback-begäranden)
Underförstådd autentisering beskriver beteendet för anslutningsbegäran där externa processer som körs som arbetskonton med låg behörighet visas som en betrodd användaridentitet för SQL Server vid loopback-begäranden för data eller åtgärder. Som koncept är underförstådd autentisering unik för Windows-autentisering, i SQL Server-anslutningssträngar som anger en betrodd anslutning, på begäranden som kommer från externa processer som R- eller Python-skript. Det kallas ibland även för en loopback.
Betrodda anslutningar kan användas från ett externt skript, men bara med ytterligare konfiguration. I utökningsarkitekturen körs externa processer under arbetskonton och ärver behörigheter från den överordnade SQLRUserGroup. När en anslutningssträng anger Trusted_Connection=Truevisas identiteten för arbetskontot på anslutningsbegäran, som är okänd som standard för SQL Server.
Om du vill att betrodda anslutningar ska lyckas måste du skapa en databasinloggning för SQLRUserGroup. När du har gjort det har alla betrodda anslutningar från någon medlem i SQLRUserGroup inloggningsrättigheter till SQL Server. Stegvisa instruktioner finns i Lägga till SQLRUserGroup i en databasinloggning.
Betrodda anslutningar är inte den mest använda formuleringen av en anslutningsbegäran. När ett externt skript anger en anslutning kan det vara vanligare att använda en SQL-inloggning eller ett fullständigt angivet användarnamn och lösenord om anslutningen är till en ODBC-datakälla.
Så här fungerar underförstådd autentisering för externa skriptsessioner
Följande diagram visar interaktionen mellan SQL Server-komponenter och språkkörningen och hur den utför underförstådd autentisering i Windows.
Underförstådd autentisering (loopback-begäranden)
Underförstådd autentisering beskriver beteendet för anslutningsbegäran där externa processer som körs under AppContainers visas som en betrodd användaridentitet för SQL Server vid loopback-begäranden för data eller åtgärder. Som koncept är underförstådd autentisering inte längre unik för Windows-autentisering, i SQL Server-anslutningssträngar som anger en betrodd anslutning, på begäranden som kommer från externa processer som R- eller Python-skript. Det kallas ibland även för en loopback.
Genom att hantera identiteter och autentiseringsuppgifter förhindrar AppContainer användning av användarautentiseringsuppgifter för att få åtkomst till resurser eller inloggning till andra miljöer. AppContainer-miljön skapar en identifierare som använder användarens och programmets kombinerade identiteter, så autentiseringsuppgifterna är unika för varje användar-/programparning och programmet kan inte personifiera användaren. Mer information finns i AppContainer-isolering.
Mer information om loopback-anslutningar finns i Loopback-anslutning till SQL Server från ett Python- eller R-skript.
Så här fungerar underförstådd autentisering för externa skriptsessioner
Följande diagram visar interaktionen mellan SQL Server-komponenter och språkkörningen och hur den utför underförstådd autentisering i Windows.
Underförstådd autentisering (loopback-begäranden)
Underförstådd autentisering beskriver beteendet för anslutningsbegäran där externa processer som körs som lågprivilegierade mssql_satellite-användare i sina egna namnområden visas som en betrodd användaridentitet för SQL Server på loopback-begäranden om data eller åtgärder. Det kallas ibland även för en loopback.
En loopback-anslutning uppnås med hjälp av satellitcertifikatet från mappen launchpad GUID för att autentisera tillbaka till SQL Server via satellitprocessen. Identiteten för den anropande användaren mappas till det här certifikatet och därför kan satellitprocessen som ansluter tillbaka till SQL Server med certifikatet mappas tillbaka till den anropande användaren.
Mer information finns i Loopback-anslutning till SQL Server från ett Python- eller R-skript.
Så här fungerar underförstådd autentisering för externa skriptsessioner
Följande diagram visar interaktionen mellan SQL Server-komponenter och språkkörningen och hur den utför underförstådd autentisering i Linux.
Inget stöd för transparent datakryptering i vila
Transparent datakryptering (TDE) stöds inte för data som skickas till eller tas emot från den externa skriptkörningen. Anledningen är att den externa processen körs utanför SQL Server-processen. Därför skyddas inte data som används av den externa körningen av databasmotorns krypteringsfunktioner. Det här beteendet skiljer sig inte från någon annan klient som körs på SQL Server-datorn som läser data från databasen och gör en kopia.
Därför tillämpas inte TDE på data som du använder i externa skript, eller på data som sparats på disken eller på några bevarade mellanliggande resultat. Andra typer av kryptering, till exempel Windows BitLocker-kryptering eller kryptering från tredje part som tillämpas på fil- eller mappnivå, gäller dock fortfarande.
När det gäller Always Encrypted har externa körmiljöer inte åtkomst till krypteringsnycklarna. Data kan därför inte skickas till skripten.
Nästa steg
I den här artikeln har du lärt dig komponenterna och interaktionsmodellen för säkerhetsarkitekturen som är inbyggd i utökningsramverket. Viktiga punkter som beskrivs i den här artikeln är syftet med launchpad, SQLRUserGroup- och arbetskonton, processisolering av externa skript och hur användaridentiteter mappas till arbetskonton.
Som ett nästa steg läser du anvisningarna för att bevilja behörigheter. För servrar som använder Windows-autentisering bör du också läsa Lägg till SQLRUserGroup i en databasinloggning för att lära dig när ytterligare konfiguration krävs.