Beveiligingsarchitectuur voor het uitbreidbaarheidsframework in SQL Server Machine Learning Services

Services die worden gebruikt bij externe bewerking (launchpad)

Het uitbreidbaarheidsframework voegt één nieuwe NT-service toe aan de lijst met services in een SQL Server-installatie: SQL Server Launchpad (MSSSQLSERVER).

De database-engine maakt gebruik van de SQL Server Launchpad-service om een externe scriptsessie te instantiëren als een afzonderlijk proces. Het proces wordt uitgevoerd onder een account met lage bevoegdheden. Dit account verschilt van SQL Server, launchpad zelf en de gebruikersidentiteit waaronder de opgeslagen procedure of hostquery is uitgevoerd. Het uitvoeren van scripts in een afzonderlijk proces, onder een account met lage bevoegdheden, is de basis van het beveiligings- en isolatiemodel voor externe scripts in SQL Server.

SQL Server onderhoudt ook een koppeling van de identiteit van de aanroepende gebruiker aan het lage-privilege werknemersaccount dat wordt gebruikt om het satellietproces te starten. In sommige scenario's, waarbij script of code terugroept naar SQL Server voor gegevens en bewerkingen, kan SQL Server de identiteitsoverdracht naadloos beheren. Script met SELECT-instructies of aanroepende functies en andere programmeerobjecten slaagt doorgaans als de aanroepende gebruiker over voldoende machtigingen beschikt.

Services die worden gebruikt in externe verwerking (launchpad)

Met het uitbreidbaarheidsframework wordt één nieuwe NT-service toegevoegd aan de lijst met services in een SQL Server-installatie: SQL Server launchpad (MSSSQLSERVER).

De database-engine maakt gebruik van de SQL Server Launchpad-service om een externe scriptsessie te instantiëren als een afzonderlijk proces. Het proces wordt uitgevoerd onder de identiteit van de launchpad-gebruiker, maar met de toegevoegde beperking dat deze zich in een AppContainer bevindt. Het uitvoeren van scripts in een afzonderlijk proces, onder AppContainer, is de basis van het beveiligings- en isolatiemodel voor externe scripts in SQL Server.

SQL Server onderhoudt ook een toewijzing van de identiteit van de aanroepende gebruiker aan het laagbevoorrechte werkaccount dat wordt gebruikt om het satellietproces te starten. In sommige scenario's, waarbij script of code terugroept naar SQL Server voor gegevens en bewerkingen, kan SQL Server de identiteitsoverdracht naadloos beheren. Script met SELECT-instructies of aanroepende functies en andere programmeerobjecten slaagt doorgaans als de aanroepende gebruiker over voldoende machtigingen beschikt.

Services die worden gebruikt in externe verwerking

Met het uitbreidbaarheidsframework wordt één nieuwe daemon toegevoegd aan een SQL Server-installatie: mssql-launchpadd. mssql-launchpadd wordt uitgevoerd onder het account met beperkte bevoegdheden mssql_launchpadd dat wordt gemaakt wanneer het mssql-server-extensibility-pakket is geïnstalleerd.

Er wordt slechts één exemplaar van de database-engine ondersteund en er is één launchpadd-service gebonden aan het exemplaar. Wanneer een script wordt uitgevoerd, start de launchpad-service een afzonderlijk launchpad-proces met het gebruikersaccount met lage bevoegdheden mssql_satellite in een eigen nieuwe PID-, IPC-, mount- en netwerknaamruimte. Elk satellietproces neemt het mssql_satellite gebruikersaccount van launchpad over en gebruikt dat voor de duur van de uitvoering van het script.

Zie De architectuur voor uitbreidbaarheid in SQL Server Machine Learning Services voor meer informatie.

Identiteiten die voor verwerking worden gebruikt (SQLRUserGroup)

SQLRUserGroup (BEPERKTE SQL-gebruikersgroep) wordt gemaakt door SQL Server Setup en bevat een groep lokale Windows-gebruikersaccounts met lage bevoegdheden. Wanneer een extern proces nodig is, neemt launchpad een beschikbaar werkaccount en gebruikt het om een proces uit te voeren. Launchpad activeert een beschikbaar werkaccount, wijst het toe aan de identiteit van de aanroepende gebruiker en voert het script uit onder het werkaccount.

• SQLRUserGroup is gekoppeld aan een specifiek exemplaar. Er is een afzonderlijke groep werkaccounts nodig voor elk exemplaar waarop machine learning is ingeschakeld. Accounts kunnen niet worden gedeeld tussen instanties.

• De grootte van de gebruikersaccountgroep is statisch en de standaardwaarde is 20, die ondersteuning biedt voor 20 gelijktijdige sessies. Het aantal externe runtimesessies dat tegelijkertijd kan worden gestart, wordt beperkt door de grootte van deze gebruikersaccountgroep.

• Namen van werkrekeningnamen in de pool hebben het formaat SQLInstanceNamenn. Op een standaardexemplaar bevat SQLRUserGroup bijvoorbeeld accounts met de naam MSSQLSERVER01, MSSQLSERVER02, enzovoort, tot MSSQLSERVER20.

Geparallelliseerde taken verbruiken geen extra accounts. Als een gebruiker bijvoorbeeld een scoretaak uitvoert die gebruikmaakt van parallelle verwerking, wordt hetzelfde werkaccount opnieuw gebruikt voor alle threads. Als u van plan bent om intensief gebruik te maken van machine learning, kunt u het aantal accounts verhogen dat wordt gebruikt voor het uitvoeren van externe scripts. Voor meer informatie, zie Gelijktijdige uitvoering van externe scripts schalen in SQL Server Machine Learning Services.

Machtigingen verleend aan SQLRUserGroup

Leden van SQLRUserGroup hebben standaard lees- en uitvoermachtigingen voor bestanden in de SQL Server-binn, R_SERVICES en PYTHON_SERVICES mappen. Dit omvat toegang tot uitvoerbare bestanden, bibliotheken en ingebouwde gegevenssets in de R- en Python-distributies die zijn geïnstalleerd met SQL Server.

Als u gevoelige resources op SQL Server wilt beveiligen, kunt u desgewenst een toegangsbeheerlijst (ACL) definiëren die de toegang tot SQLRUserGroup weigert. U kunt daarentegen ook machtigingen verlenen aan lokale gegevensbronnen die aanwezig zijn op een hostcomputer, behalve SQL Server zelf.

SQLRUserGroup heeft standaard geen databaseaanmelding of machtigingen voor gegevens. Onder bepaalde omstandigheden wilt u mogelijk een aanmelding maken om loopback-verbindingen toe te staan, met name wanneer een vertrouwde Windows-identiteit de aanroepende gebruiker is. Deze mogelijkheid wordt impliciete verificatie genoemd. Zie SQLRUserGroup toevoegen als databasegebruiker voor meer informatie.

Identiteitstoewijzing

Wanneer een sessie wordt gestart, wijst launchpad de identiteit van de aanroepende gebruiker toe aan een werkaccount. De toewijzing van een externe Windows-gebruiker of geldige SQL-aanmelding aan een werknemeraccount is alleen geldig voor de duur van de SQL-opgeslagen procedure die het externe script uitvoert. Parallel queries van dezelfde login worden toegewezen aan hetzelfde gebruikersaccount.

Tijdens de uitvoering maakt Launchpad tijdelijke mappen voor het opslaan van sessiegegevens, waarbij deze worden verwijdert wanneer de sessie wordt afgesloten. De mappen hebben beperkte toegang. RLauncher voert deze taak uit. Voor Python voert PythonLauncher deze taak uit. Elk afzonderlijk werkaccount is beperkt tot een eigen map en heeft geen toegang tot bestanden in mappen boven het eigen niveau. Het werknemersaccount kan echter subitems lezen, schrijven of verwijderen onder de werksessie-map die is gemaakt. Als u een beheerder bent op de computer, kunt u de mappen weergeven die voor elk proces zijn gemaakt. Elke directory wordt geïdentificeerd door de sessie-GUID.

AppContainer-isolatie

Isolatie wordt bereikt via AppContainers. Wanneer tijdens runtime een extern script wordt gedetecteerd in een opgeslagen procedure of query, roept SQL Server launchpad aan met een aanvraag voor een extensiespecifiek startprogramma. Launchpad roept de juiste runtime-omgeving aan in een proces onder de bijbehorende identiteit en instantieert een AppContainer om deze te bevatten. Deze wijziging is nuttig omdat lokaal account- en wachtwoordbeheer niet meer vereist is. Bij installaties waarbij lokale gebruikersaccounts zijn verboden, betekent het verwijderen van de afhankelijkheid van het lokale gebruikersaccount ook dat u deze functie nu kunt gebruiken.

Zoals geïmplementeerd door SQL Server, zijn AppContainers een intern mechanisme. Hoewel u geen fysiek bewijs ziet van AppContainers in Procesmonitor, kunt u deze vinden in uitgaande firewallregels die zijn gemaakt door Setup om te voorkomen dat processen netwerkoproepen uitvoeren. Zie Firewall-configuratie voor SQL Server Machine Learning Services voor meer informatie.

Identiteitstoewijzing

Wanneer een sessie wordt gestart, wijst launchpad de identiteit van de aanroepende gebruiker toe aan een AppContainer.

Identiteitstoewijzing

Launchpadd (double 'D' - mssql-launchpadd) daemon wijst de identiteit van de aanroepende gebruiker toe aan een afzonderlijk launchpad (één 'D') proces met een map launchpad GUID en een satellietcertificaat. Deze launchpad GUID-mappen worden gemaakt onder /var/opt/mssql-extensibility/data/. Het launchpad-proces gebruikt dit certificaat om terug te verifiëren bij SQL en maakt vervolgens tijdelijke mappen voor elke sessie-GUID onder de map launchpad GUID. Het satellietproces (R, Python of ExtHost) heeft toegang tot de launchpad-GUID-map, het certificaat eronder en zijn sessie-GUID-map.

Met het volgende SQL-script wordt de inhoud van de launchpad-mappen afgedrukt.

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'

Impliciete verificatie (loopback-aanvragen)

Impliciete verificatie beschrijft het gedrag van verbindingsaanvragen waaronder externe processen die worden uitgevoerd als werkaccounts met beperkte bevoegdheden worden weergegeven als een vertrouwde gebruikersidentiteit voor SQL Server bij loopback-aanvragen voor gegevens of bewerkingen. Als concept is impliciete verificatie uniek voor Windows-verificatie, in SQL Server-verbindingsreeksen die een vertrouwde verbinding opgeven, op aanvragen die afkomstig zijn van externe processen zoals R of Python-script. Het wordt soms ook wel een loopback genoemd.

Vertrouwde verbindingen kunnen worden gebruikt vanuit een extern script, maar alleen met extra configuratie. In de uitbreidbaarheidsarchitectuur worden externe processen uitgevoerd onder werkaccounts, waarbij machtigingen worden overgenomen van de bovenliggende SQLRUserGroup. Wanneer een verbindingsreeks opgeeft Trusted_Connection=True, wordt de identiteit van het werkaccount weergegeven in de verbindingsaanvraag. Deze is standaard onbekend bij SQL Server.

Als u vertrouwde verbindingen wilt laten slagen, moet u een databaseaanmelding maken voor de SQLRUserGroup. Nadat u dit hebt gedaan, heeft elke vertrouwde verbinding van een lid van SQLRUserGroup aanmeldingsrechten voor SQL Server. Zie SQLRUserGroup toevoegen aan een databaseaanmelding voor stapsgewijze instructies.

Vertrouwde verbindingen zijn niet de meest gebruikte formulering van een verbindingsaanvraag. Wanneer een extern script een verbinding opgeeft, kan het gebruikelijker zijn om een SQL-aanmelding te gebruiken of een volledig opgegeven gebruikersnaam en wachtwoord als de verbinding met een ODBC-gegevensbron is.

Hoe impliciete verificatie werkt voor externe scriptsessies

In het volgende diagram ziet u de interactie van SQL Server-onderdelen met de taalruntime en hoe hiermee impliciete verificatie in Windows wordt uitgevoerd.

Impliciete verificatie (loopback-aanvragen)

Impliciete verificatie beschrijft het gedrag van verbindingsaanvragen waaronder externe processen die worden uitgevoerd onder AppContainers worden gepresenteerd als een vertrouwde gebruikersidentiteit voor SQL Server bij loopback-aanvragen voor gegevens of bewerkingen. Als concept is impliciete verificatie niet langer uniek voor Windows-verificatie, in SQL Server-verbindingsreeksen die een vertrouwde verbinding opgeven, op aanvragen die afkomstig zijn van externe processen zoals R of Python-script. Het wordt soms ook wel een loopback genoemd.

Door identiteit en referenties te beheren, voorkomt AppContainer het gebruik van gebruikersreferenties om toegang te krijgen tot resources of om u aan te melden bij andere omgevingen. De AppContainer-omgeving maakt een id die gebruikmaakt van de gecombineerde identiteiten van de gebruiker en de toepassing. Referenties zijn dus uniek voor elke gebruiker/toepassingskoppeling en de toepassing kan de gebruiker niet imiteren. Zie AppContainer-isolatie voor meer informatie.

Zie Loopback-verbinding met SQL Server vanuit een Python- of R-script voor meer informatie over loopback-verbindingen.

Hoe impliciete verificatie werkt voor externe scriptsessies

In het volgende diagram ziet u de interactie van SQL Server-onderdelen met de taalruntime en hoe hiermee impliciete verificatie in Windows wordt uitgevoerd.

Impliciete verificatie (loopback-aanvragen)

Impliciete verificatie beschrijft het gedrag van verbindingsaanvragen waaronder externe processen die worden uitgevoerd als lage bevoegdheden mssql_satellite gebruikers in hun eigen naamruimten worden gepresenteerd als een vertrouwde gebruikersidentiteit voor SQL Server bij loopback-aanvragen voor gegevens of bewerkingen. Het wordt soms ook wel een loopback genoemd.

Een loopback-verbinding wordt gerealiseerd door het satellietcertificaat uit de GUID-map van het lanceerplatform te gebruiken om SQL Server te verifiëren via het satellietproces. De identiteit van de aanroepende gebruiker wordt toegewezen aan dit certificaat en daarom kan het satellietproces dat via het certificaat verbinding maakt met SQL Server, worden toegewezen aan de aanroepende gebruiker.

Zie Loopback-verbinding met SQL Server vanuit een Python- of R-script voor meer informatie.

Hoe impliciete verificatie werkt voor externe scriptsessies

In het volgende diagram ziet u de interactie van SQL Server-onderdelen met de taalruntime en hoe dit impliciete verificatie in Linux doet.