Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
SQL Server 2016 (13.x) i nowsze wersje
W tym artykule opisano architekturę zabezpieczeń używaną do integrowania aparatu bazy danych programu SQL Server i powiązanych składników z platformą rozszerzalności w usługach SQL Server Machine Learning Services. Analizuje elementy zabezpieczalne, usługi, tożsamość procesu i uprawnienia. Kluczowe kwestie omówione w tym artykule obejmują cel platformy startowej, SQLRUserGroup i konta pracowników, izolację skryptów zewnętrznych oraz sposób mapowania tożsamości użytkowników na konta pracowników.
Aby uzyskać więcej informacji na temat kluczowych pojęć i składników rozszerzalności w programie SQL Server, zobacz Architektura rozszerzalności w usługach SQL Server Machine Learning Services.
Obiekty zabezpieczalne dla skryptu zewnętrznego
Skrypt zewnętrzny jest przesyłany jako parametr wejściowy do systemowej procedury składowanej utworzonej w tym celu lub jest opakowany w zdefiniowaną procedurę składowaną. Skrypt może być napisany w językach R, Python lub zewnętrznych, takich jak Java lub .NET. Alternatywnie możesz mieć modele, które są wstępnie wytrenowane i przechowywane w formacie binarnym w tabeli bazy danych, które można wywołać w funkcji PREDICT języka T-SQL.
Ponieważ skrypt jest dostarczany za pośrednictwem istniejących obiektów schematu bazy danych, procedur składowanych i tabel, nie ma nowych obiektów zabezpieczanych w usługach SQL Server Machine Learning Services.
Niezależnie od sposobu używania skryptu lub tego, co składają się z nich, obiekty bazy danych zostaną utworzone i prawdopodobnie zapisane, ale nie wprowadzono nowego typu obiektu do przechowywania skryptu. W związku z tym możliwość korzystania, tworzenia i zapisywania obiektów bazy danych zależy w dużej mierze od uprawnień bazy danych zdefiniowanych już dla użytkowników.
Permissions
Model zabezpieczeń danych programu SQL Server dotyczący identyfikatorów logowania i ról bazy danych ma zastosowanie również do skryptów zewnętrznych. Do uruchamiania zewnętrznych skryptów korzystających z danych SQL Server lub działających w kontekście obliczeniowym SQL Server wymagany jest identyfikator logowania programu SQL Server lub konto użytkownika systemu Windows. Użytkownicy bazy danych, którzy mają uprawnienia do wykonywania zapytania, mogą uzyskać dostęp do tych samych danych ze skryptu zewnętrznego.
Do identyfikacji podmiotu zabezpieczeń służy identyfikator logowania lub konto użytkownika, który może potrzebować wielu poziomów dostępu w zależności od wymagań zewnętrznego skryptu.
- Uprawnienie dostępu do bazy danych, w której są włączone skrypty zewnętrzne.
- Uprawnienia do odczytywania danych z zabezpieczonych obiektów, takich jak tabele.
- Możliwość zapisywania nowych danych w tabeli, takich jak model lub wyniki oceniania.
- Możliwość tworzenia nowych obiektów, takich jak tabele, procedury składowane wykorzystujące skrypt zewnętrzny lub funkcje niestandardowe korzystające z zadania skryptowego.
- Prawo do instalowania nowych pakietów na komputerze z programem SQL Server lub używania pakietów udostępnianych grupie użytkowników.
Każda osoba, która uruchamia zewnętrzny skrypt używając SQL Server jako kontekstu wykonywania, musi być odwzorowana jako użytkownik w bazie danych. Zamiast indywidualnie ustawiać uprawnienia użytkownika bazy danych, można tworzyć role do zarządzania zestawami uprawnień i przypisywać użytkowników do tych ról, a nie indywidualnie ustawiać uprawnienia użytkownika.
Aby uzyskać więcej informacji, zobacz Przyznawanie użytkownikom uprawnień do usług SQL Server Machine Learning Services.
Uprawnienia podczas korzystania z zewnętrznego narzędzia klienckiego
Użytkownicy używający skryptu w zewnętrznym narzędziu klienckim muszą mieć swoje dane logowania lub konto zamapowane na użytkownika w bazie danych, jeśli muszą uruchomić zewnętrzny skrypt w bazie danych lub uzyskać dostęp do obiektów i danych bazy danych. Te same uprawnienia są wymagane, czy skrypt zewnętrzny jest wysyłany ze zdalnego klienta nauki o danych, czy uruchamiany przy użyciu procedury składowanej języka T-SQL.
Załóżmy na przykład, że utworzono skrypt zewnętrzny uruchamiany na komputerze lokalnym i chcesz uruchomić ten skrypt w programie SQL Server. Należy upewnić się, że spełnione są następujące warunki:
- Baza danych zezwala na połączenia zdalne.
- Identyfikator logowania SQL lub konto Windows, którego użyto do uzyskiwania dostępu do bazy danych, zostało dodane do SQL Server na poziomie instancji.
- Identyfikator logowania SQL lub użytkownik systemu Windows musi mieć uprawnienia do wykonywania skryptów zewnętrznych. Ogólnie rzecz biorąc, to uprawnienie można dodać tylko przez administratora bazy danych.
- Identyfikator logowania SQL lub użytkownik systemu Windows musi zostać dodany jako użytkownik z odpowiednimi uprawnieniami w każdej bazie danych, w której skrypt zewnętrzny wykonuje dowolną z tych operacji:
- Pobieranie danych.
- Zapisywanie lub aktualizowanie danych.
- Tworzenie nowych obiektów, takich jak tabele lub procedury składowane.
Po aprowizacji logowania lub konta użytkownika systemu Windows i udzieleniu niezbędnych uprawnień można uruchomić skrypt zewnętrzny w programie SQL Server przy użyciu obiektu źródła danych w języku R lub biblioteki revoscalepy w języku Python lub wywołując procedurę składowaną zawierającą skrypt zewnętrzny.
Za każdym razem, gdy skrypt zewnętrzny jest uruchamiany z programu SQL Server, zabezpieczenia aparatu bazy danych uzyskują kontekst zabezpieczeń użytkownika, który uruchomił zadanie, i zarządzają mapowaniem użytkownika lub logowania do zabezpieczanych obiektów.
W związku z tym wszystkie skrypty zewnętrzne inicjowane przez klienta zdalnego muszą określać dane logowania lub użytkownika w ramach parametrów połączenia.
Usługi używane w przetwarzaniu zewnętrznym (launchpad)
Struktura rozszerzalności dodaje jedną nową usługę NT do listy usług w instalacji programu SQL Server: SQL Server Launchpad (MSSSQLSERVER).
Silnik bazy danych używa usługi launchpad programu SQL Server dla utworzenia sesji skryptu zewnętrznego jako osobnego procesu. Proces jest uruchamiany na koncie o niskich uprawnieniach. To konto różni się od programu SQL Server, samego startpada i tożsamości użytkownika, w ramach której wykonano procedurę składowaną lub zapytanie hosta. Uruchamianie skryptu w osobnym procesie w ramach konta o niskim poziomie uprawnień jest podstawą modelu zabezpieczeń i izolacji dla skryptów zewnętrznych w programie SQL Server.
SQL Server również utrzymuje odwzorowanie tożsamości użytkownika wykonującego wywołanie na niskouprawne konto robocze, używane do uruchomienia procesu satelitarnego. W niektórych scenariuszach, w których skrypt lub kod wywołuje wywołania z powrotem do programu SQL Server na potrzeby danych i operacji, program SQL Server może bezproblemowo zarządzać transferem tożsamości. Skrypt zawierający instrukcje SELECT lub wywołujące funkcje i inne obiekty programowania zwykle powiedzie się, jeśli wywołujący użytkownik ma wystarczające uprawnienia.
Uwaga / Notatka
Domyślnie program SQL Server Launchpad jest skonfigurowany do uruchamiania w obszarze NT Service\MSSQLLaunchpad, który jest aprowizowany przy użyciu wszystkich niezbędnych uprawnień do uruchamiania skryptów zewnętrznych. Aby uzyskać więcej informacji na temat konfigurowalnych opcji, zobacz Konfiguracja usługi launchpad programu SQL Server.
Usługi używane w przetwarzaniu zewnętrznym (launchpad)
Struktura rozszerzalności dodaje nową usługę NT do listy usług w instalacji programu SQL Server: launchpad programu SQL Server (MSSSQLSERVER).
Silnik bazy danych używa usługi launchpad programu SQL Server dla utworzenia sesji skryptu zewnętrznego jako osobnego procesu. Proces działa pod tożsamością użytkownika launchpad, ale z dodatkowym ograniczeniem przebywania wewnątrz kontenera AppContainer. Uruchamianie skryptu w osobnym procesie w obszarze AppContainer jest podstawą modelu zabezpieczeń i izolacji dla skryptów zewnętrznych w programie SQL Server.
SQL Server również utrzymuje odwzorowanie tożsamości użytkownika wykonującego wywołanie na niskouprawne konto robocze, używane do uruchomienia procesu satelitarnego. W niektórych scenariuszach, w których skrypt lub kod wywołuje wywołania z powrotem do programu SQL Server na potrzeby danych i operacji, program SQL Server może bezproblemowo zarządzać transferem tożsamości. Skrypt zawierający instrukcje SELECT lub wywołujące funkcje i inne obiekty programowania zwykle powiedzie się, jeśli wywołujący użytkownik ma wystarczające uprawnienia.
Uwaga / Notatka
Domyślnie program SQL Server Launchpad jest skonfigurowany do uruchamiania w obszarze NT Service\MSSQLLaunchpad, który jest aprowizowany przy użyciu wszystkich niezbędnych uprawnień do uruchamiania skryptów zewnętrznych. Aby uzyskać więcej informacji na temat konfigurowalnych opcji, zobacz Konfiguracja usługi launchpad programu SQL Server.
Usługi używane w przetwarzaniu zewnętrznym
Struktura rozszerzalności dodaje jeden nowy demon w instalacji SQL Server: mssql-launchpadd. Narzędzie mssql-launchpadd działa na koncie o niskim poziomie uprawnień mssql_launchpadd tworzonym podczas instalowania pakietu mssql-server-extensibility.
Obsługiwana jest tylko jedna instancja aparatu bazy danych i jedna usługa launchpadd powiązana z instancją. Po wykonaniu skryptu usługa launchpada uruchamia oddzielny proces launchpada z kontem użytkownika o niskich uprawnieniach mssql_satellite we własnej, nowej przestrzeni identyfikatorów PID, IPC, montowania i sieci. Każdy proces satelitarny dziedziczy konto użytkownika mssql_satellite launchpad i używa go przez czas wykonywania skryptu.
Aby uzyskać więcej informacji, zobacz Architektura rozszerzalności w usługach SQL Server Machine Learning Services.
Tożsamości używane w przetwarzaniu (SQLRUserGroup)
SqlRUserGroup (grupa użytkowników z ograniczeniami SQL) jest tworzona przez instalatora programu SQL Server i zawiera pulę lokalnych kont użytkowników systemu Windows o niskich uprawnieniach. Gdy wymagany jest proces zewnętrzny, Launchpad przyjmuje dostępne konto robocze i używa go do uruchomienia procesu. Mówiąc dokładniej, launchpad aktywuje dostępne konto pracownika, przypisuje je do tożsamości użytkownika wywołującego i uruchamia skrypt na koncie pracownika.
Grupa SQLRUserGroup jest połączona z określonym wystąpieniem. Dla każdego wystąpienia, na którym włączono uczenie maszynowe, jest wymagana oddzielna pula kont pracowników. Nie można współdzielić kont między instancjami.
Rozmiar puli kont użytkownika jest statyczny, a wartość domyślna to 20, która obsługuje 20 równoczesnych sesji. Liczba sesji zewnętrznego środowiska uruchomieniowego, które można uruchomić jednocześnie, jest ograniczona przez rozmiar tej puli kont użytkowników.
Nazwy kont roboczych w puli mają format SQLInstanceNamenn. Na przykład w wystąpieniu domyślnym grupa SQLRUserGroup zawiera konta o nazwie MSSQLSERVER01, MSSQLSERVER02 i tak dalej, aż do MSSQLSERVER20.
Zadania równoległe nie korzystają z dodatkowych kont. Jeśli na przykład użytkownik uruchamia zadanie oceniania korzystające z przetwarzania równoległego, to to samo konto procesu roboczego jest używane ponownie dla wszystkich wątków. Jeśli zamierzasz intensywnie korzystać z uczenia maszynowego, możesz zwiększyć liczbę kont używanych do uruchamiania skryptów zewnętrznych. Aby uzyskać więcej informacji, zobacz Skalowanie współbieżnego wykonywania skryptów zewnętrznych w usługach SQL Server Machine Learning Services.
Uprawnienia przyznane grupie SQLRUserGroup
Domyślnie członkowie grupy SQLRUserGroup mają uprawnienia do odczytu i wykonywania plików w katalogach SQL Server Binn, R_SERVICES i PYTHON_SERVICES. Obejmuje to dostęp do plików wykonywalnych, bibliotek i wbudowanych zestawów danych w dystrybucjach języka R i Python zainstalowanych za pomocą programu SQL Server.
Aby chronić poufne zasoby w programie SQL Server, opcjonalnie można zdefiniować listę kontroli dostępu (ACL), która nie zezwala na dostęp do grupy użytkowników SQLRUserGroup. Z drugiej strony można również udzielić uprawnień do lokalnych zasobów danych, które istnieją na komputerze hosta, oprócz samego programu SQL Server.
Zgodnie z projektem grupa SQLRUserGroup nie ma konta do logowania się do bazy danych ani uprawnień do jakichkolwiek danych. W pewnych okolicznościach możesz utworzyć konto logowania, aby zezwolić na połączenia sprzężenia zwrotnego, szczególnie wtedy, gdy zaufana tożsamość systemu Windows jest użytkownikiem wywołującym. Ta funkcja jest nazywana dorozumianym uwierzytelnianiem. Aby uzyskać więcej informacji, zobacz Dodawanie grupy SQLRUserGroup jako użytkownika bazy danych.
Mapowanie tożsamości
Gdy sesja zostaje rozpoczęta, launchpad przypisuje tożsamość wywołującego użytkownika do konta użytkownika pracownika. Mapowanie zewnętrznego użytkownika systemu Windows lub prawidłowego logowania SQL do konta pracownika jest prawidłowe tylko na czas działania procedury składowanej SQL, która wykonuje skrypt zewnętrzny. Zapytania równoległe z tego samego identyfikatora logowania są mapowane na to samo konto procesu roboczego użytkownika.
Podczas wykonywania launchpad tworzy foldery tymczasowe do przechowywania danych sesji, usuwając je po zakończeniu sesji. Katalogi są ograniczone do dostępu. W przypadku języka R, RLauncher wykonuje to zadanie. W przypadku języka Python polecenie PythonLauncher wykonuje to zadanie. Każde indywidualne konto pracownika jest ograniczone do własnego folderu i nie może uzyskiwać dostępu do plików w folderach powyżej własnego poziomu. Jednak konto użytkownika roboczego może odczytywać, zapisywać lub usuwać elementy podrzędne w utworzonym folderze roboczym sesji. Jeśli jesteś administratorem na komputerze, możesz wyświetlić katalogi utworzone dla każdego procesu. Każdy katalog jest identyfikowany przez identyfikator GUID sesji.
Izolacja aplikacji AppContainer
Izolacja jest osiągana za pośrednictwem aplikacji AppContainers. W czasie wykonywania, gdy skrypt zewnętrzny zostanie wykryty w procedurze składowanej lub zapytaniu, program SQL Server wywołuje launchpad z żądaniem uruchamiania specyficznego dla rozszerzenia. Launchpad wywołuje odpowiednie środowisko uruchomieniowe w procesie w ramach jego tożsamości i tworzy instancję AppContainer, aby ją zawierało. Ta zmiana jest korzystna, ponieważ zarządzanie kontami lokalnymi i hasłami nie jest już wymagane. Ponadto w przypadku instalacji, w których konta użytkowników lokalnych są zabronione, eliminacja zależności konta użytkownika lokalnego oznacza, że można teraz używać tej funkcji.
Zgodnie z implementacją programu SQL Server moduły AppContainers są mechanizmem wewnętrznym. Chociaż fizyczne dowody aplikacji AppContainers nie będą widoczne w monitorze procesów, można je znaleźć w regułach zapory ruchu wychodzącego utworzonych przez Instalatora, aby uniemożliwić procesom wykonywanie wywołań sieciowych. Aby uzyskać więcej informacji, zobacz Konfiguracja zapory dla usług SQL Server Machine Learning Services.
Mapowanie tożsamości
Po rozpoczęciu sesji launchpad mapuje tożsamość wywołującego użytkownika na AppContainer.
Uwaga / Notatka
W programie SQL Server 2019 i nowszych grupa SQLRUserGroup ma tylko jednego członka, którym jest teraz pojedyncze konto usługi launchpad SQL Server, zamiast wielu kont pracowników.
Mapowanie tożsamości
Daemon Launchpadd (dwukrotne "D" — mssql-launchpadd) mapuje tożsamość użytkownika wywołującego do oddzielnego procesu launchpad (z pojedynczym "D") z folderem "launchpad GUID" oraz certyfikatem satelitarnym. Te foldery GUID launchpad są tworzone w obszarze /var/opt/mssql-extensibility/data/. Proces launchpad używa tego certyfikatu do ponownego uwierzytelniania w SQL, a następnie tworzy foldery tymczasowe dla każdego identyfikatora GUID sesji w folderze launchpad GUID. Proces satelity (R, Python lub ExtHost) może uzyskać dostęp do folderu GUID launchpada, do certyfikatu zawartego w nim oraz do jego folderu GUID sesji.
Poniższy skrypt SQL wyświetla zawartość folderów 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'
Sugerowane uwierzytelnianie (żądania sprzężenia zwrotnego)
Uwierzytelnianie implikowane opisuje zachowanie żądania połączenia, w ramach którego zewnętrzne procesy uruchomione jako konta procesów roboczych o niskim poziomie uprawnień są prezentowane jako zaufana tożsamość użytkownika w programie SQL Server w przypadku żądań sprzężenia zwrotnego dla danych lub operacji. Jako koncepcja, uwierzytelnienie domniemane jest unikalne dla uwierzytelniania systemu Windows, w parametrach połączenia SQL Server określających zaufane połączenie do żądań pochodzących z procesów zewnętrznych, takich jak skrypt w języku R lub Python. Czasami jest również określany jako sprzężenie zwrotne.
Zaufane połączenia są dostępne z zewnętrznego skryptu, ale tylko z dodatkową konfiguracją. W architekturze rozszerzalności procesy zewnętrzne działają pod kontami pracowników, dziedzicząc uprawnienia od nadrzędnej grupy SQLRUserGroup. Gdy parametr połączenia określa Trusted_Connection=True, tożsamość konta procesu roboczego jest wyświetlana w żądaniu połączenia, które jest domyślnie nieznane dla programu SQL Server.
Aby pomyślnie nawiązać zaufane połączenia, należy utworzyć identyfikator logowania bazy danych dla grupy SQLRUserGroup. Po wykonaniu tej czynności każde zaufane połączenie od dowolnego członka grupy SQLRUserGroup ma prawa logowania do programu SQL Server. Aby uzyskać instrukcje krok po kroku, zobacz Add SQLRUserGroup to a database login (Dodawanie elementu SQLRUserGroup do logowania bazy danych).
Zaufane połączenia nie są najczęściej używanym sformułowaniem żądania połączenia. Gdy skrypt zewnętrzny określa połączenie, może być częściej używany identyfikator logowania SQL lub w pełni określona nazwa użytkownika i hasło, jeśli połączenie jest ze źródłem danych ODBC.
Jak działa domniemane uwierzytelnianie dla sesji skryptów zewnętrznych
Na poniższym diagramie przedstawiono interakcję składników programu SQL Server ze środowiskiem uruchomieniowym języka oraz sposób domniemanego uwierzytelniania w systemie Windows.
Sugerowane uwierzytelnianie (żądania sprzężenia zwrotnego)
Uwierzytelnianie implikowane opisuje zachowanie żądania połączenia, w ramach którego zewnętrzne procesy działające w ramach aplikacji AppContainers są prezentowane jako zaufana tożsamość użytkownika w programie SQL Server w przypadku żądań sprzężenia zwrotnego dla danych lub operacji. W ramach koncepcji uwierzytelnianie implikowane nie jest już unikatowe dla uwierzytelniania systemu Windows, w parametrach połączenia programu SQL Server określających zaufane połączenie na żądaniach pochodzących z procesów zewnętrznych, takich jak skrypt języka R lub Python. Czasami jest również określany jako pętla zwrotna.
Zarządzając tożsamościami i poświadczeniami, aplikacja AppContainer uniemożliwia korzystanie z poświadczeń użytkownika w celu uzyskania dostępu do zasobów lub logowania się do innych środowisk. Środowisko AppContainer tworzy identyfikator, który używa połączonych tożsamości użytkownika i aplikacji, dlatego poświadczenia są unikatowe dla każdej pary użytkownika i aplikacji, a aplikacja nie może podszywać się pod użytkownika. Aby uzyskać więcej informacji, zobacz AppContainer Isolation (Izolacja aplikacji).
Aby uzyskać więcej informacji na temat połączeń sprzężenia zwrotnego, zobacz Loopback connection to SQL Server from a Python or R script (Połączenie sprzężenia zwrotnego z programem SQL Server ze skryptu języka Python lub R).
Jak działa domniemane uwierzytelnianie dla sesji zewnętrznych skryptów
Na poniższym diagramie przedstawiono interakcję składników programu SQL Server ze środowiskiem uruchomieniowym języka oraz pokazano, jak odbywa się uwierzytelnianie implicite w systemie Windows.
Domniemane uwierzytelnianie (żądania pętli zwrotnej)
Uwierzytelnianie implikowane opisuje zachowanie żądania połączenia, w ramach którego procesy zewnętrzne działające jako użytkownicy z niskimi uprawnieniami mssql_satellite w ich dedykowanych przestrzeniach nazw prezentują się jako zaufana tożsamość użytkownika w programie SQL Server przy pętlowych żądaniach o dane lub operacje. Czasami jest również określany jako pętla zwrotna.
Połączenie pętli zwrotnej jest osiągane przy użyciu certyfikatu satelity z folderu GUID launchpad w celu ponownego uwierzytelnienia do programu SQL Server za pomocą procesu satelitarnego. Tożsamość użytkownika wywołującego jest mapowana na ten certyfikat, dlatego proces satelitarny łączący się z programem SQL Server przy użyciu certyfikatu można zamapować z powrotem na użytkownika wywołującego.
Aby uzyskać więcej informacji, zobacz Loopback connection to SQL Server from a Python or R script (Połączenie sprzężenia zwrotnego z programem SQL Server ze skryptu języka Python lub języka R).
Jak działa domniemane uwierzytelnianie dla sesji skryptów zewnętrznych
Na poniższym diagramie przedstawiono interakcję składników programu SQL Server ze środowiskiem wykonawczym języka oraz to, jak w systemie Linux odbywa się uwierzytelnianie domniemane.
Brak obsługi funkcji Transparent Data Encryption dla danych w stanie spoczynku
Funkcja Transparent Data Encryption (TDE) nie jest obsługiwana w przypadku danych wysyłanych do środowiska uruchomieniowego skryptu zewnętrznego ani odbieranych z niego. Przyczyną jest to, że proces zewnętrzny jest uruchamiany poza procesem programu SQL Server. W związku z tym dane używane przez zewnętrzne środowisko uruchomieniowe nie są chronione przez funkcje szyfrowania silnika bazy danych. To zachowanie nie różni się od innego klienta uruchomionego na komputerze z programem SQL Server, który odczytuje dane z bazy danych i tworzy kopię.
W związku z tym funkcja TDE nie jest stosowana do żadnych danych używanych w skryptach zewnętrznych ani do żadnych danych zapisanych na dysku ani do utrwalonego wyniku pośredniego. Jednak inne typy szyfrowania, takie jak szyfrowanie funkcją BitLocker systemu Windows lub szyfrowanie innych firm stosowane na poziomie pliku lub folderu, nadal mają zastosowanie.
W przypadku funkcji Always Encrypted środowiska uruchomieniowe zewnętrzne nie mają dostępu do kluczy szyfrowania. W związku z tym nie można wysyłać danych do skryptów.
Dalsze kroki
W tym artykule przedstawiono składniki i model interakcji architektury zabezpieczeń wbudowanej w platformę rozszerzalności. Kluczowe kwestie omówione w tym artykule obejmują cel platformy startowej, SQLRUserGroup i konta pracowników, izolację skryptów zewnętrznych oraz sposób mapowania tożsamości użytkowników na konta pracowników.
W następnym kroku zapoznaj się z instrukcjami dotyczącymi udzielania uprawnień. W przypadku serwerów korzystających z uwierzytelniania systemu Windows należy również zapoznać się z artykułem Add SQLRUserGroup to a database login to learn when additional configuration is required (Dodawanie grupy SQLRUserGroup do logowania bazy danych ), aby dowiedzieć się, kiedy wymagana jest dodatkowa konfiguracja.