Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
platí pro:
SQL Server 2016 (13.x) a novější verze
Tento článek popisuje architekturu zabezpečení, která se používá k integraci databázového stroje SQL Serveru a souvisejících komponent s architekturou rozšiřitelnosti ve službě SQL Server Machine Learning Services. Zkoumá zabezpečitelné objekty, služby, identitu procesu a oprávnění. Klíčové body popsané v tomto článku zahrnují účel launchpadu, SQLRUserGroup a pracovních účtů, izolaci procesů externích skriptů a způsob mapování identit uživatelů na pracovní účty.
Další informace o klíčových konceptech a součástech rozšiřitelnosti sql Serveru najdete v tématu Architektura rozšiřitelnosti ve službě SQL Server Machine Learning Services.
Zabezpečení pro externí skript
Externí skript se odešle jako vstupní parametr pro systém uloženou proceduru vytvořenou pro tento účel nebo je zabalen do uložené procedury, kterou definujete. Skript může být napsaný v jazyce R, Python nebo externích jazycích, jako je Java nebo .NET. Alternativně můžete mít modely, které jsou předem natrénované a uložené v binárním formátu v databázové tabulce, volatelné ve funkci T-SQL PREDICT .
Vzhledem k tomu, že skript je poskytován prostřednictvím existujících objektů schématu databáze, uložených procedur a tabulek, neexistují žádné nové zabezpečitelné služby SQL Server Machine Learning Services.
Bez ohledu na to, jak používáte skript, nebo z toho, co se skládají, se vytvoří a pravděpodobně uloží databázové objekty, ale pro ukládání skriptu se nezavádějí žádné nové typy objektů. V důsledku toho schopnost využívat, vytvářet a ukládat databázové objekty závisí z velké části na oprávněních databáze, která jsou pro vaše uživatele už definovaná.
Povolení
Model zabezpečení dat SQL Serveru pro přihlášení a role databáze se rozšiřuje na externí skript. Pro spouštění externích skriptů, které používají data SQL Serveru nebo které běží s SQL Serverem jako výpočetní kontext, se vyžaduje přihlášení k SQL Serveru nebo uživatelský účet systému Windows. Uživatelé databáze, kteří mají oprávnění ke spuštění dotazu, mají přístup ke stejným datům z externího skriptu.
Přihlašovací nebo uživatelský účet identifikuje objekt zabezpečení, který může v závislosti na požadavcích na externí skript potřebovat více úrovní přístupu:
- Oprávnění pro přístup k databázi, kde jsou povoleny externí skripty.
- Oprávnění ke čtení dat ze zabezpečených objektů, jako jsou tabulky.
- Možnost zapisovat nová data do tabulky, jako je model nebo výsledky vyhodnocování.
- Možnost vytvářet nové objekty, jako jsou tabulky, uložené procedury, které používají externí skript, nebo vlastní funkce, které používají úlohu externího skriptu.
- Právo nainstalovat nové balíčky na počítač s SQL Serverem nebo použít balíčky poskytnuté skupině uživatelů.
Každá osoba, která spouští externí skript pomocí SQL Serveru jako kontext spuštění, musí být namapována na uživatele v databázi. Místo individuálního nastavení uživatelských oprávnění databáze byste mohli vytvářet role pro správu sad oprávnění a přiřazovat uživatele k těmto rolím, a ne jednotlivě nastavovat uživatelská oprávnění.
Další informace najdete v tématu Udělení oprávnění uživatelům ke službě SQL Server Machine Learning Services.
Oprávnění při použití externího klientského nástroje
Uživatelé, kteří používají skript v externím klientském nástroji, musí mít své přihlašovací jméno nebo účet namapovaný na uživatele v databázi, pokud potřebují spustit externí skript v databázi nebo přistupovat k databázovým objektům a datům. Stejná oprávnění jsou vyžadována bez ohledu na to, jestli je externí skript odeslán ze vzdáleného klienta pro datové vědy nebo spuštěn pomocí uložené procedury T-SQL.
Předpokládejme například, že jste vytvořili externí skript, který běží na místním počítači, a chcete tento skript spustit na SQL Serveru. Musíte zajistit splnění následujících podmínek:
- Databáze umožňuje vzdálená připojení.
- Přihlašovací účet SQL nebo účet Systému Windows, který jste použili pro přístup k databázi, byl přidán na SQL Server na úrovni instance.
- Přihlašovací jméno SQL nebo uživatel Systému Windows musí mít oprávnění ke spouštění externích skriptů. Obecně platí, že toto oprávnění může přidat pouze správce databáze.
- Přihlašovací jméno SQL nebo uživatel okna musí být přidán jako uživatel s příslušnými oprávněními v každé databázi, kde externí skript provádí některou z těchto operací:
- Načítání dat
- Zápis nebo aktualizace dat
- Vytváření nových objektů, jako jsou tabulky nebo uložené procedury
Po zřízení přihlašovacího nebo uživatelského účtu systému Windows s potřebnými oprávněními můžete na SQL Serveru spustit externí skript pomocí objektu zdroje dat v jazyce R nebo knihovny revoscalepy v Pythonu nebo voláním uložené procedury, která obsahuje externí skript.
Při každém spuštění externího skriptu z SQL Serveru získá zabezpečení databázového stroje kontext zabezpečení uživatele, který úlohu spustil, a spravuje mapování uživatele nebo přihlášení k zabezpečitelným objektům.
Proto musí všechny externí skripty iniciované vzdáleným klientem zadat přihlašovací údaje nebo informace o uživateli jako součást připojovacího řetězce.
Služby používané při externím zpracování (launchpad)
Architektura rozšiřitelnosti přidá jednu novou službu NT do seznamu služeb v instalaci SQL Serveru: SQL Server Launchpad (MSSSQLSERVER).
Databázový stroj používá službu launchpad SQL Serveru k vytvoření instance relace externího skriptu jako samostatného procesu. Tento proces běží pod účtem s nízkými oprávněními. Tento účet se liší od SQL Serveru, samotného launchpadu a identity uživatele, pod kterou se spustila uložená procedura nebo hostitelský dotaz. Spouštění skriptu v samostatném procesu v rámci účtu s nízkými oprávněními je základem modelu zabezpečení a izolace pro externí skripty na SQL Serveru.
SQL Server také udržuje mapování identity uživatele, který volá, na uživatelský účet s nízkými oprávněními, který se používá ke spuštění satelitního procesu. V některých scénářích, kdy skript nebo kód volá zpět sql Server pro data a operace, sql Server dokáže bezproblémově spravovat přenos identit. Skript obsahující příkazy SELECT nebo volající funkce a další programovací objekty budou obvykle úspěšné, pokud má volající uživatel dostatečná oprávnění.
Poznámka:
Ve výchozím nastavení je sql Server Launchpad nakonfigurovaný tak, aby běžel v rámci nt Service\MSSQLLaunchpad, který je zřízený se všemi potřebnými oprávněními ke spouštění externích skriptů. Další informace o konfigurovatelných možnostech najdete v tématu Konfigurace služby launchpad SYSTÉMU SQL Server.
Služby používané při externím zpracování (launchpad)
Architektura rozšiřitelnosti přidá jednu novou službu NT do seznamu služeb v instalaci SQL Serveru: SQL Server launchpad (MSSSQLSERVER).
Databázový stroj používá službu launchpad SQL Serveru k vytvoření instance relace externího skriptu jako samostatného procesu. Tento proces běží pod identitou uživatele launchpadu, ale s přidaným omezením obsaženým v appContaineru. Spouštění skriptu v samostatném procesu v rámci AppContainer je základem modelu zabezpečení a izolace pro externí skripty na SQL Serveru.
SQL Server také udržuje mapování identity uživatele, který vyvolává volání, na pracovní účet s nízkými oprávněními, který se používá ke spuštění satelitního procesu. V některých scénářích, kdy skript nebo kód volá zpět sql Server pro data a operace, sql Server dokáže bezproblémově spravovat přenos identit. Skript obsahující příkazy SELECT nebo volající funkce a další programovací objekty budou obvykle úspěšné, pokud má volající uživatel dostatečná oprávnění.
Poznámka:
Ve výchozím nastavení je sql Server Launchpad nakonfigurovaný tak, aby běžel v rámci nt Service\MSSQLLaunchpad, který je zřízený se všemi potřebnými oprávněními ke spouštění externích skriptů. Další informace o konfigurovatelných možnostech najdete v tématu Konfigurace služby launchpad SYSTÉMU SQL Server.
Služby používané při externím zpracování
Architektura rozšiřitelnosti přidá do instalace SQL Serveru jeden nový proces démon: mssql-launchpadd. mssql-launchpadd běží v rámci účtu s nízkým oprávněním mssql_launchpadd, který se vytvoří při instalaci balíčku mssql-server-extensibility.
Podporována je pouze jedna instance databázového stroje a jedna služba launchpadd je připojena k instanci. Při spuštění skriptu spustí služba launchpadd samostatný proces launchpadu s nízko privilegovaným uživatelským účtem mssql_satellite ve vlastním novém PID, IPC, přípojném a síťovém oboru názvů. Každý satelitní proces dědí uživatelský účet mssql_satellite launchpadu a používá ho po dobu trvání provádění skriptu.
Další informace najdete v tématu Architektura rozšiřitelnosti ve službě SQL Server Machine Learning Services.
Identity používané při zpracování (SQLRUserGroup)
SQLRUserGroup (skupina uživatelů s omezeným přístupem SQL) je vytvořena instalačním programem SYSTÉMU SQL Server a obsahuje fond místních uživatelských účtů systému Windows s nízkými oprávněními. Pokud je potřeba externí proces, launchpad vezme dostupný pracovní účet a použije ho ke spuštění procesu. Konkrétně launchpad aktivuje dostupný pracovní účet, mapuje ho na identitu volajícího uživatele a spustí skript pod pracovním účtem.
SQLRUserGroup je propojená s konkrétní instancí. Pro každou instanci, ve které je povoleno strojové učení, je potřeba samostatný fond pracovních účtů. Účty nelze sdílet mezi instancemi.
Velikost fondu uživatelských účtů je statická a výchozí hodnota je 20, která podporuje 20 souběžných relací. Počet externích relací modulu runtime, které lze spustit současně, je omezen velikostí tohoto fondu uživatelských účtů.
Názvy pracovních účtů ve fondu mají formát SQLInstanceNamenn. Například u výchozí instance obsahuje SQLRUserGroup účty s názvem MSSQLSERVER01, MSSQLSERVER02 atd. až do MSSQLSERVER20.
Paralelizované úlohy nespotřebovávají další účty. Pokud například uživatel spustí úlohu vyhodnocování, která používá paralelní zpracování, použije se stejný pracovní účet pro všechna vlákna. Pokud máte v úmyslu provádět velké využití strojového učení, můžete zvýšit počet účtů, které se používají ke spouštění externích skriptů. Další informace najdete v tématu Škálování souběžného spouštění externích skriptů ve službě SQL Server Machine Learning Services.
Oprávnění udělená skupině SQLRUserGroup
Ve výchozím nastavení mají členové skupiny SQLRUserGroup oprávnění ke čtení a spouštění souborů v adresářích SQL Server Binn, R_SERVICES a PYTHON_SERVICES . To zahrnuje přístup ke spustitelným souborům, knihovnám a integrovaným datovým sadám v distribucích R a Python nainstalovaných s SQL Serverem.
Pokud chcete chránit citlivé prostředky na SQL Serveru, můžete volitelně definovat seznam řízení přístupu (ACL), který zakazuje přístup k SQLRUserGroup. Naopak můžete také udělit oprávnění místním datovým prostředkům, které existují na hostitelském počítači, kromě samotného SQL Serveru.
SQLRUserGroup záměrně nemá přihlašovací údaje databáze ani oprávnění k žádným datům. Za určitých okolností můžete chtít založit účet, který umožní loopback spojení, zejména v případě, že důvěryhodná identita systému Windows je volajícím uživatelem. Tato funkce se nazývá implicitní ověřování. Další informace naleznete v tématu Přidání sqlRUserGroup jako uživatele databáze.
Mapování identit
Po spuštění relace launchpad mapuje identitu volajícího uživatele na pracovní účet. Mapování externího uživatele systému Windows nebo platného přihlášení SQL k pracovnímu účtu je platné pouze po dobu životnosti uložené procedury SQL, která spouští externí skript. Paralelní dotazy ze stejného přihlášení se mapují na stejný uživatelský pracovní účet.
Během provádění launchpad vytvoří dočasné složky pro ukládání dat relace a jejich odstranění při ukončení relace. Adresáře jsou omezené na přístup. RLauncher v případě R provede tuto úlohu. PythonLauncher v Pythonu provádí tuto úlohu. Každý jednotlivý pracovní účet je omezen na vlastní složku a nemůže přistupovat k souborům ve složkách nad vlastní úrovní. Pracovní účet však může číst, zapisovat nebo odstraňovat podsložky nebo soubory v pracovní složce relace, která byla vytvořena. Pokud jste správcem počítače, můžete zobrazit adresáře vytvořené pro každý proces. Každý adresář je identifikovaný identifikátorem GUID relace.
Izolace AppContainer
Izolace se dosahuje prostřednictvím AppContainers. Když se v uložené proceduře nebo dotazu zjistí externí skript, SQL Server volá launchpad s požadavkem na spouštěč konkrétní rozšíření. Launchpad vyvolá příslušné běhové prostředí v procesu pod jeho identitou a vytvoří instanci AppContainer, která ho bude obsahovat. Tato změna je užitečná, protože místní účet a správa hesel se už nevyžadují. Také u instalací, kde jsou zakázány místní uživatelské účty, odstranění závislostí místních uživatelských účtů znamená, že teď můžete tuto funkci použít.
Jak je implementované SQL Serverem, AppContainers jsou interním mechanismem. I když v nástroji Process Monitor neuvidíte fyzické důkazy o službě AppContainers, můžete je najít v odchozích pravidlech brány firewall vytvořených nastavením, abyste zabránili procesům v provádění síťových volání. Další informace najdete v tématu Konfigurace brány firewall pro službu SQL Server Machine Learning Services.
Mapování identit
Když je zahájena relace, Launchpad mapuje identitu volajícího uživatele na AppContainer.
Poznámka:
V SQL Serveru 2019 a novějším má SQLRUserGroup pouze jeden člen, který je nyní jediným účtem služby launchpad SQL Serveru místo více pracovních účtů.
Mapování identit
Démon Launchpadd (double 'D' - mssql-launchpadd) mapuje identitu volajícího uživatele na samostatný proces launchpadu (jeden D) se složkou launchpad GUID a satelitním certifikátem. Tyto složky GUID spouštěcího panelu jsou vytvořeny v části /var/opt/mssql-extensibility/data/. Proces launchpadu používá tento certifikát pro ověření zpětného připojení k SQL a poté vytvoří dočasné složky pro každý identifikátor GUID relace ve složce GUID launchpadu. Satelitní proces (R, Python nebo ExtHost) má přístup ke složce GUID launchpadu, certifikátu pod ním a ke složce GUID relace.
Následující skript SQL vytiskne obsah složek launchpadu.
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'
Implicitní ověřování (žádosti zpětné smyčky)
Implicitní ověřování popisuje chování žádosti o připojení, při kterém se externí procesy spuštěné jako účty pracovníků s nízkými oprávněními prezentují jako důvěryhodné uživatelské identity pro SQL Server při interních požadavcích na data nebo operace. Jako koncept je implicitní ověřování jedinečné pro ověřování systému Windows, v připojovacích řetězcích SQL Serveru určujících důvěryhodné připojení u požadavků pocházejících z externích procesů, jako je skript R nebo Python. Někdy se také označuje jako loopback.
Důvěryhodná připojení je možné použít z externího skriptu, ale pouze s dodatečnou konfigurací. V architektuře rozšiřitelnosti se externí procesy spouští pod pracovními účty, které dědí oprávnění z nadřazené skupiny SQLRUserGroup. Pokud připojovací řetězec určuje Trusted_Connection=True, identita pracovního účtu se zobrazí v žádosti o připojení, která je ve výchozím nastavení pro SQL Server neznámá.
Aby byla důvěryhodná připojení úspěšná, je nutné vytvořit přihlášení k databázi pro sqlRUserGroup. Jakmile to uděláte, jakékoli důvěryhodné připojení od libovolného člena sqlRUserGroup má přihlašovací práva k SQL Serveru. Podrobné pokyny najdete v tématu Přidání sqlRUserGroup do přihlášení k databázi.
Důvěryhodná připojení nejsou nejčastěji používanou formulací žádosti o připojení. Pokud externí skript určuje připojení, může být běžnější použít přihlášení SQL nebo plně zadané uživatelské jméno a heslo, pokud je připojení ke zdroji dat ODBC.
Jak funguje implicitní ověřování pro relace externích skriptů
Následující diagram znázorňuje interakci komponent SYSTÉMU SQL Server s modulem runtime jazyka a způsob odvozeného ověřování ve Windows.
Implicitní ověřování (smyčkové požadavky)
Implicitní ověřování popisuje chování žádosti o připojení, ve kterém jsou externí procesy běžící v prostředí AppContainers prezentovány jako uživatelská identita důvěryhodná pro SQL Server při loopback požadavcích pro data nebo operace. Jako koncept už implicitní ověřování není jedinečné pro ověřování systému Windows, v připojovacích řetězcích SQL Serveru určujících důvěryhodné připojení u požadavků pocházejících z externích procesů, jako je skript R nebo Python. Někdy se také označuje jako zpětné smyčky.
Když spravujete identitu a přihlašovací údaje, AppContainer brání použití přihlašovacích údajů uživatele k získání přístupu k prostředkům nebo přihlášení k jiným prostředím. Prostředí AppContainer vytvoří identifikátor, který používá kombinované identity uživatele a aplikace, takže přihlašovací údaje jsou jedinečné pro každou dvojici uživatelů a aplikací a aplikace nemůže zosobnit uživatele. Další informace naleznete v tématu Izolace AppContainer.
Další podrobnosti týkající se připojení zpětné smyčky najdete v tématu Připojení zpětné smyčky k SQL Serveru ze skriptu Pythonu nebo R.
Jak funguje implicitní ověřování pro relace externích skriptů
Následující diagram znázorňuje interakci komponent SYSTÉMU SQL Server s modulem runtime jazyka a způsob odvozeného ověřování ve Windows.
Implicitní ověřování (zpětnovazební žádosti)
Implicitní ověřování popisuje chování žádosti o připojení, ve kterém jsou externí procesy spuštěné s nízkými oprávněními uživateli mssql_satellite ve vlastních jmenných prostorech prezentovány jako důvěryhodné uživatelské identity pro SQL Server při smyčkových požadavcích na data nebo operace. Někdy se také označuje jako zpětné smyčky.
Připojení zpětné smyčky se dosahuje pomocí satelitního certifikátu ze složky GUID spouštěcího panelu k ověření zpět na SQL Server satelitním procesem. Identita volajícího uživatele je namapována na tento certifikát a proto je možné namapovat satelitní proces, který se připojuje zpět k SQL Serveru pomocí certifikátu, zpět na volajícího uživatele.
Další informace najdete v tématu Připojení zpětné smyčky k SQL Serveru ze skriptu Pythonu nebo jazyka R.
Jak funguje implicitní ověřování pro relace externích skriptů
Následující diagram znázorňuje interakci komponent SQL Serveru s modulem runtime jazyka a to, jak implicitní ověřování v Linuxu funguje.
Bez podpory transparentního šifrování dat v klidu
Transparentní šifrování dat (TDE) není podporováno pro data odesílaná do běhového prostředí externího skriptu nebo přijímaná z běhového prostředí externího skriptu. Důvodem je, že externí proces běží mimo proces SQL Serveru. Proto data používaná externím modulem runtime nejsou chráněna funkcemi šifrování databázového stroje. Toto chování se neliší od jakéhokoli jiného klienta spuštěného na počítači s SQL Serverem, který čte data z databáze a vytváří kopii.
V důsledku toho se transparentní šifrování dat nepoužije na žádná data, která používáte v externích skriptech, ani na žádná data uložená na disk, nebo na žádné trvale uložené průběžné výsledky. Stále ale platí i jiné typy šifrování, jako je šifrování Nástroje Windows BitLocker nebo šifrování třetích stran použité na úrovni souboru nebo složky.
V případě funkce Always Encrypted nemají externí moduly runtime přístup k šifrovacím klíčům. Proto nelze data odeslat do skriptů.
Další kroky
V tomto článku jste se seznámili s komponentami a modelem interakce architektury zabezpečení integrované do architektury rozšiřitelnosti. Klíčové body popsané v tomto článku zahrnují účel launchpadu, SQLRUserGroup a pracovních účtů, izolaci procesů externích skriptů a způsob mapování identit uživatelů na pracovní účty.
V dalším kroku si projděte pokyny k udělení oprávnění. U serverů, které používají ověřování systému Windows, byste také měli zkontrolovat přidání sqlRUserGroup do přihlášení k databázi , abyste se dozvěděli, kdy je vyžadována další konfigurace.