Aracılığıyla paylaş

SQL Server Machine Learning Services'da genişletilebilirlik çerçevesi için güvenlik mimarisi

Şunlar için geçerlidir: SQL Server 2016 (13.x) ve sonraki sürümleri

Bu makalede, SQL Server veritabanı altyapısını ve ilgili bileşenleri SQL Server Machine Learning Services'daki genişletilebilirlik çerçevesiyle tümleştirmek için kullanılan güvenlik mimarisi açıklanmaktadır. Güvenli hale getirilebilir öğeler, hizmetler, işlem kimliği ve izinleri inceler. Bu makalede ele alınan önemli noktalar arasında başlatma çubuğu, SQLRUserGroup ve çalışan hesaplarının amacı, dış betiklerin işlem yalıtımı ve kullanıcı kimliklerinin çalışan hesaplarıyla nasıl eşlendiği yer alır.

SQL Server'da temel kavramlar ve genişletilebilirlik bileşenleri hakkında daha fazla bilgi için bkz. SQL Server Machine Learning Services'da genişletilebilirlik mimarisi.

Dış betik için güvenli hale getirilebilir öğeler

Dış betik, bu amaçla oluşturulan bir sistem saklı yordamına giriş parametresi olarak gönderilir veya sizin tanımladığınız bir saklı yordamla sarmalanır. Betik R, Python veya Java ya da .NET gibi dış dillerde yazılabilir. Alternatif olarak, T-SQL PREDICT işlevinde çağrılabilen, önceden eğitilmiş ve veritabanı tablosunda ikili biçimde depolanan modelleriniz olabilir.

Betik, mevcut veritabanı şeması nesneleri, saklı yordamlar ve tablolar aracılığıyla sağlandığından, SQL Server Machine Learning Services için yeni güvenlik unsurları bulunmamaktadır.

Betiği nasıl kullandığınıza veya nelerden oluştuğuna bakılmaksızın, veritabanı nesneleri oluşturulur ve büyük olasılıkla kaydedilir, ancak betiği depolamak için yeni nesne türü kullanılmamıştır. Sonuç olarak, veritabanı nesnelerini kullanma, oluşturma ve kaydetme özelliği büyük ölçüde kullanıcılarınız için önceden tanımlanmış veritabanı izinlerine bağlıdır.

Permissions

SQL Server'ın veritabanı oturum açma bilgileri ve rollerinden oluşan veri güvenlik modeli dış betiklere kadar uzanır. SQL Server verilerini kullanan veya işlem bağlamı olarak SQL Server ile çalışan dış betikleri çalıştırmak için SQL Server oturum açma veya Windows kullanıcı hesabı gerekir. Sorgu yürütme izinleri olan veritabanı kullanıcıları, dış betikten aynı verilere erişebilir.

Oturum açma veya kullanıcı hesabı, dış betik gereksinimlerine bağlı olarak birden çok erişim düzeyine ihtiyacı olabilecek güvenlik sorumlusunu tanımlar:

  • Dış betiklerin etkin olduğu veritabanına erişim izni.
  • Tablolar gibi güvenli nesnelerden veri okuma izinleri.
  • Model veya puanlama sonuçları gibi bir tabloya yeni veri yazma özelliği.
  • Tablolar, dış betiği kullanan saklı yordamlar veya dış betik işini kullanan özel işlevler gibi yeni nesneler oluşturma olanağı.
  • SQL Server bilgisayarına yeni paketler yükleme veya bir kullanıcı grubuna sağlanan paketleri kullanma hakkı.

Yürütme bağlamı olarak SQL Server kullanarak dış betik çalıştıran her kişi veritabanındaki bir kullanıcıyla eşlenmelidir. Veritabanı kullanıcı izinlerini tek tek ayarlamak yerine, izin kümelerini yönetmek için roller oluşturabilir ve kullanıcı izinlerini ayrı ayrı ayarlamak yerine kullanıcıları bu rollere atayabilirsiniz.

Daha fazla bilgi için bkz. Kullanıcılara SQL Server Machine Learning Services için izin verme.

Dış istemci aracı kullanırken izinler

Veritabanında dış bir betik çalıştırmaları veya veritabanı nesneleri ve verilerine erişmeleri gereken dış istemci aracında betik kullanan kullanıcıların, giriş bilgileri veya hesapları veritabanındaki bir kullanıcıyla eşleştirilmiş olmalıdır. Dış betiğin uzak bir veri bilimi istemcisinden gönderilmesi veya T-SQL saklı yordamı kullanılarak çalıştırılması için aynı izinler gereklidir.

Örneğin, yerel bilgisayarınızda çalışan bir dış betik oluşturduğunuzu ve bu betiği SQL Server'da çalıştırmak istediğinizi varsayalım. Aşağıdaki koşulların karşılandığından emin olmalısınız:

  • Veritabanı uzak bağlantılara izin verir.
  • Veritabanı erişimi için kullandığınız SQL oturum açma bilgileri veya Windows hesabı SQL Server'a örnek düzeyinde eklendi.
  • SQL oturum açma veya Windows kullanıcısının dış betikleri çalıştırma izni olmalıdır. Genel olarak, bu izin yalnızca veritabanı yöneticisi tarafından eklenebilir.
  • SQL oturum açma veya Pencere kullanıcısı, dış betiğin şu işlemlerden herhangi birini gerçekleştirdiği her veritabanında uygun izinlere sahip bir kullanıcı olarak eklenmelidir:
    • Veriler alınıyor.
    • Veri yazma veya güncelleştirme.
    • Tablolar veya saklı yordamlar gibi yeni nesneler oluşturma.

Oturum açma veya Windows kullanıcı hesabı sağlanıp gerekli izinler verildikten sonra, R'deki bir veri kaynağı nesnesini veya Python'daki revoscalepy kitaplığını kullanarak veya dış betiği içeren saklı yordamı çağırarak SQL Server'da bir dış betik çalıştırabilirsiniz.

SQL Server'dan bir dış betik başlatıldığında, veritabanı motoru güvenliği, işi başlatan kullanıcının güvenlik bağlamını alır ve kullanıcı veya oturum açmanın güvenli hale getirilebilir nesnelerle olan eşlemelerini yönetir.

Bu nedenle, uzak istemciden başlatılan tüm dış betikler, bağlantı dizesinin bir parçası olarak oturum açma bilgilerini veya kullanıcı bilgilerini belirtmelidir.

Dış işlemede kullanılan hizmetler (başlatma çubuğu)

Genişletilebilirlik çerçevesi, SQL Server yüklemesindeki hizmetler listesine yeni bir NT hizmeti ekler: SQL Server Launchpad (MSSSQLSERVER).

Veritabanı altyapısı, ayrı bir işlem olarak bir dış betik oturumu örneği oluşturmak için SQL Server başlatma çubuğu hizmetini kullanır. İşlem düşük ayrıcalıklı bir hesap altında çalışır. Bu hesap SQL Server'dan, başlatma çubuğundan ve saklı yordamın veya konak sorgusunun yürütüldiği kullanıcı kimliğinden farklıdır. Betiği düşük ayrıcalıklı bir hesap altında ayrı bir işlemde çalıştırmak, SQL Server'daki dış betikler için güvenlik ve yalıtım modelinin temelini oluşturur.

SQL Server, çağıran kullanıcının kimliğinin uydu işlemini başlatmak için kullanılan düşük ayrıcalıklı çalışan hesabıyla eşlemesini de korur. Betiğin veya kodun veri ve işlemler için SQL Server'a geri çağırdığı bazı senaryolarda SQL Server, kimlik aktarımını sorunsuz bir şekilde yönetebilir. Select deyimlerini veya çağrı işlevlerini ve diğer programlama nesnelerini içeren betik, çağıran kullanıcının yeterli izinlere sahip olması durumunda genellikle başarılı olur.

Uyarı

Varsayılan olarak, SQL Server Launchpad dış betikleri çalıştırmak için gerekli tüm izinlerle sağlanan NT Service\MSSQLLaunchpad altında çalışacak şekilde yapılandırılır. Yapılandırılabilir seçenekler hakkında daha fazla bilgi için bkz. SQL Server başlatma çubuğu hizmeti yapılandırması.

Dış işlemede kullanılan hizmetler (başlatma çubuğu)

Genişletilebilirlik çerçevesi, SQL Server yüklemesindeki hizmetler listesine yeni bir NT hizmeti ekler: SQL Server başlatma çubuğu (MSSSQLSERVER).

Veritabanı altyapısı, ayrı bir işlem olarak bir dış betik oturumu örneği oluşturmak için SQL Server başlatma çubuğu hizmetini kullanır. İşlem başlatma çubuğu kullanıcı kimliği altında çalışır, ancak bir AppContainer içinde yer alma kısıtlaması eklenir. Betiği AppContainer altında ayrı bir işlemde çalıştırmak, SQL Server'daki dış betikler için güvenlik ve yalıtım modelinin temelini oluşturur.

SQL Server, çağıran kullanıcının kimliğinin uydu işlemini başlatmak için kullanılan düşük ayrıcalıklı çalışan hesabıyla eşlemesini de korur. Betiğin veya kodun veri ve işlemler için SQL Server'a geri çağırdığı bazı senaryolarda SQL Server, kimlik aktarımını sorunsuz bir şekilde yönetebilir. Select deyimlerini veya çağrı işlevlerini ve diğer programlama nesnelerini içeren betik, çağıran kullanıcının yeterli izinlere sahip olması durumunda genellikle başarılı olur.

Uyarı

Varsayılan olarak, SQL Server Launchpad dış betikleri çalıştırmak için gerekli tüm izinlerle sağlanan NT Service\MSSQLLaunchpad altında çalışacak şekilde yapılandırılır. Yapılandırılabilir seçenekler hakkında daha fazla bilgi için bkz. SQL Server başlatma çubuğu hizmeti yapılandırması.

Dış işlemede kullanılan hizmetler

Genişletilebilirlik çerçevesi, SQL Server yüklemesine yeni bir daemon ekler: mssql-launchpadd. mssql-launchpadd, mssql-server-genişletilebilirlik paketi yüklendiğinde oluşturulan düşük ayrıcalıklı hesap mssql_launchpadd altında çalışır.

Yalnızca bir veritabanı altyapısı örneği desteklenir ve örneğe bağlı bir başlatma çubuğu hizmeti vardır. Bir betik yürütüldüğünde, launchpadd hizmeti, kendi yeni PID, IPC, bağlama ve ağ ad alanında düşük ayrıcalıklı kullanıcı hesabı mssql_satellite ile ayrı bir launchpad işlemi başlatır. Her uydu işlemi launchpad'in mssql_satellite kullanıcı hesabını devralır ve betik yürütme süresi boyunca bunu kullanır.

Daha fazla bilgi için bkz. SQL Server Machine Learning Services'da genişletilebilirlik mimarisi.

İşlemede kullanılan kimlikler (SQLRUserGroup)

SQLRUserGroup (SQL kısıtlanmış kullanıcı grubu) SQL Server Kurulumu tarafından oluşturulur ve düşük ayrıcalıklı yerel Windows kullanıcı hesapları havuzu içerir. Dış işlem gerektiğinde, Launchpad kullanılabilir bir işçi hesabını alır ve bunu bir işlem çalıştırmak için kullanır. Daha spesifik olarak, launchpad mevcut bir işlemci hesabını etkinleştirir, bunu çağıran kullanıcının kimliğiyle ilişkilendirir ve betiği işlemci hesabı altında çalıştırır.

  • SQLRUserGroup belirli bir örneğe bağlıdır. Makine öğrenmesinin etkinleştirildiği her örnek için ayrı bir çalışan hesabı havuzu gerekir. Hesaplar örnekler arasında paylaşılamaz.

  • Kullanıcı hesabı havuzunun boyutu statiktir ve varsayılan değer 20'dir ve bu da 20 eşzamanlı oturumu destekler. Aynı anda başlatılabilir dış çalışma zamanı oturumlarının sayısı, bu kullanıcı hesabı havuzunun boyutuyla sınırlıdır.

  • Havuzdaki çalışan hesabı adları SQLInstanceNamenn biçimindedir. Örneğin, varsayılan örnekte SQLRUserGroup , MSSQLSERVER20 kadar MSSQLSERVER01, MSSQLSERVER02 vb. adlı hesaplar içerir.

Paralelleştirilmiş görevler ek hesaplar kullanmaz. Örneğin, bir kullanıcı paralel işleme kullanan bir puanlama görevi çalıştırıyorsa, aynı çalışan hesabı tüm iş parçacıkları için yeniden kullanılır. Makine öğrenmesini yoğun bir şekilde kullanmayı planlıyorsanız, dış betikleri çalıştırmak için kullanılan hesap sayısını artırabilirsiniz. Daha fazla bilgi için bkz. SQL Server Machine Learning Services'da dış betiklerin eşzamanlı yürütülmesini ölçeklendirme.

SQLRUserGroup'a verilen izinler

Varsayılan olarak , SQLRUserGroup üyeleri SQL Server Binn, R_SERVICES ve PYTHON_SERVICES dizinlerindeki dosyalar üzerinde okuma ve yürütme izinlerine sahiptir. Bu, SQL Server ile yüklenen R ve Python dağıtımlarındaki yürütülebilir dosyalara, kitaplıklara ve yerleşik veri kümelerine erişimi içerir.

SQL Server'da hassas kaynakları korumak için isteğe bağlı olarak SQLRUserGroup'a erişimi reddeden bir erişim denetimi listesi (ACL) tanımlayabilirsiniz. Buna karşılık, SQL Server'ın kendisinden başka konak bilgisayarda bulunan yerel veri kaynaklarına da izin vekleyebilirsiniz.

Tasarım gereği, SQLRUserGroup'un veritabanı girişi veya herhangi bir veri izni yoktur. Belirli durumlarda, özellikle de arayan kullanıcı güvenilen bir Windows kimliği olduğunda, geri döngü bağlantılarına izin vermek için bir oturum açma bilgisi oluşturmak isteyebilirsiniz. Bu özellik zımni kimlik doğrulaması olarak adlandırılır. Daha fazla bilgi için bkz. SQLRUserGroup'ı veritabanı kullanıcısı olarak ekleme.

Kimlik eşleme

Oturum başlatıldığında başlatma çubuğu, çağıran kullanıcının kimliğini bir çalışan hesabıyla eşler. Bir dış Windows kullanıcısının veya geçerli SQL oturum açma bilgilerinin çalışan hesabıyla eşlemesi yalnızca dış betiği yürüten SQL saklı yordamının ömrü boyunca geçerlidir. Aynı oturum açma işleminden paralel sorgular aynı kullanıcı çalışan hesabına eşlenir.

Yürütme sırasında başlatma çubuğu oturum verilerini depolamak için geçici klasörler oluşturur ve oturum sona erdiğinde bunları siler. Dizinler erişim kısıtlanmış. R için RLauncher bu görevi gerçekleştirir. Python için PythonLauncher bu görevi gerçekleştirir. Her bir çalışan hesabı kendi klasörüyle sınırlıdır ve kendi düzeyinin üzerindeki klasörlerdeki dosyalara erişemez. Ancak, çalışan hesabı, oluşturulan oturum çalışma klasörü altındaki alt klasörleri okuyabilir, yazabilir veya silebilir. Bilgisayarda yöneticiyseniz, her işlem için oluşturulan dizinleri görüntüleyebilirsiniz. Her dizin kendi oturum GUID'siyle tanımlanır.

AppContainer yalıtımı

Yalıtım , AppContainers aracılığıyla elde edilir. Çalışma zamanında, bir saklı yordamda veya sorguda bir dış betik algılandığında, SQL Server, uzantıya özgü bir başlatıcı için launchpad'e bir istek gönderir. Launchpad, kendi kimliği altında bir işlemde uygun çalışma zamanı ortamını çağırır ve onu kapsayacak bir AppContainer örneği oluşturur. Yerel hesap ve parola yönetimi artık gerekli olmadığından bu değişiklik yararlıdır. Ayrıca, yerel kullanıcı hesaplarının yasaklandığı yüklemelerde, yerel kullanıcı hesabı bağımlılığının ortadan kaldırılması artık bu özelliği kullanabileceğiniz anlamına gelir.

SQL Server tarafından uygulandığı gibi AppContainers bir iç mekanizmadır. İşlem İzleyicisi'nde AppContainers'ın fiziksel kanıtını görmezsiniz ancak işlemlerin ağ çağrıları yapmasını önlemek için bunları Kurulum tarafından oluşturulan giden güvenlik duvarı kurallarında bulabilirsiniz. Daha fazla bilgi için bkz . SQL Server Machine Learning Services için güvenlik duvarı yapılandırması.

Kimlik eşleme

Bir oturum başlatıldığında başlatma çubuğu, çağıran kullanıcının kimliğini bir AppContainer ile eşler.

Uyarı

SQL Server 2019 ve sonraki sürümlerde , SQLRUserGroup'un artık birden çok çalışan hesabı yerine tek bir SQL Server başlatma çubuğu hizmet hesabı olan tek bir üyesi vardır.

Kimlik eşleme

Launchpadd (çift 'D' - mssql-launchpadd) daemon, çağıran kullanıcının kimliğini, "launchpad GUID" klasörü ve uydu sertifikasıyla ayrı bir launchpad (tek 'D') işlemiyle eşleştirir. Bu başlatma çubuğu GUID klasörleri altında /var/opt/mssql-extensibility/data/oluşturulur. Başlatma çubuğu işlemi, SQL'de kimlik doğrulaması yapmak için bu sertifikayı kullanır ve ardından başlatma çubuğu GUID klasörü altında her oturum GUID'i için geçici klasörler oluşturur. Uydu (R, Python veya ExtHost) işlemi, başlatma platformu GUID klasörüne, altındaki sertifikaya ve oturum GUID klasörüne erişebilir.

Aşağıdaki SQL betiği başlatma çubuğu klasörlerinin içeriğini yazdırır.

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'

Zımni kimlik doğrulaması (geri döngü istekleri)

Zımni kimlik doğrulaması, düşük ayrıcalıklı çalışan hesapları kullanan dış işlemlerin, veri veya işlemler için loopback isteklerinde SQL Server'a güvenilir bir kullanıcı kimliği olarak sunulduğu bağlantı isteği davranışını açıklar. Kavram olarak, zımni kimlik doğrulaması, R veya Python betiği gibi dış işlemlerden kaynaklanan isteklerde güvenilen bağlantı belirten SQL Server bağlantı dizelerinde Windows kimlik doğrulamasına özgüdür. Bazen geri döngü olarak da adlandırılır.

Güvenilen bağlantılar dış betikten kullanılabilir, ancak yalnızca ek yapılandırmayla çalışır. Genişletilebilirlik mimarisinde dış işlemler çalışan hesapları altında çalıştırılır ve izinleri üst SQLRUserGroup'tan devralır. Bir bağlantı dizesi Trusted_Connection=True belirttiğinde, bağlantı isteğinde çalışan hesabının kimliği sunulur ve bu, varsayılan olarak SQL Server tarafından bilinmez.

Güvenilir bağlantıların başarılı olması için SQLRUserGroup için bir veritabanı oturum açma bilgisi oluşturmanız gerekir. Bunu yaptıktan sonra, SQLRUserGroup'un herhangi bir üyesinden gelen tüm güvenilen bağlantılar SQL Server'da oturum açma haklarına sahiptir. Adım adım yönergeler için bkz. Veritabanı oturum açma bilgilerine SQLRUserGroup ekleme.

Güvenilen bağlantılar, bağlantı isteğinin en yaygın kullanılan formülasyonu değildir. Harici bir betik bir bağlantıyı belirlediğinde, bir ODBC veri kaynağına bağlantı durumunda SQL kullanıcı girişi veya eksiksiz belirtilmiş bir kullanıcı adı ve şifresi kullanmak daha yaygın olabilir.

Dış betik oturumlarında zımni kimlik doğrulaması nasıl çalışır?

Aşağıdaki diyagramda SQL Server bileşenlerinin dil çalışma zamanıyla etkileşimi ve Windows'ta kimlik doğrulamasının nasıl ima ettiği gösterilmektedir.

Windows'ta zımni kimlik doğrulaması

Geri döngü istekleri ile zımni kimlik doğrulaması

Zımni kimlik doğrulaması , AppContainers altında çalışan dış işlemlerin veri veya işlemler için geri döngü isteklerinde SQL Server'a güvenilir kullanıcı kimliği olarak sunulduğu bağlantı isteği davranışını açıklar. Kavram olarak, zımni kimlik doğrulaması artık R veya Python betiği gibi dış işlemlerden kaynaklanan isteklerde güvenilen bağlantı belirten SQL Server bağlantı dizelerinde Windows kimlik doğrulamasına özgü değildir. Bazen geri döngü olarak da adlandırılır.

AppContainer, kimlik ve kimlik bilgilerini yöneterek kaynaklara erişim kazanmak veya diğer ortamlarda oturum açmak için kullanıcı kimlik bilgilerinin kullanılmasını engeller. AppContainer ortamı, kullanıcının ve uygulamanın birleşik kimliklerini kullanan bir tanımlayıcı oluşturur, bu nedenle kimlik bilgileri her kullanıcı/uygulama eşleştirmesi için benzersizdir ve uygulama kullanıcının kimliğine bürünemez. Daha fazla bilgi için bkz. AppContainer Yalıtımı.

Geri döngü bağlantıları hakkında daha fazla bilgi için bkz. Python veya R betiğinden SQL Server'a geri döngü bağlantısı.

Dış betik oturumlarında zımni kimlik doğrulaması nasıl çalışır?

Aşağıdaki diyagramda SQL Server bileşenlerinin dil çalışma zamanıyla etkileşimi ve Windows'ta kimlik doğrulamasının nasıl ima ettiği gösterilmektedir.

Windows'ta zımni kimlik doğrulaması

Zımni kimlik doğrulaması (geri döngü istekleri)

Zımni kimlik doğrulaması, kendi ad alanlarında düşük ayrıcalıklı mssql_satellite kullanıcılar olarak çalışan dış işlemlerin veri veya işlemler için geri döngü isteklerinde SQL Server'a güvenilir bir kullanıcı kimliği şeklinde sunulmasını belirten bağlantı isteği davranışını tanımlar. Bazen geri döngü olarak da adlandırılır.

Geri döngü bağlantısı, uydu işlemi tarafından SQL Server'da yeniden kimlik doğrulaması yapmak için fırlatma rampası GUID klasöründeki uydu sertifikası kullanılarak gerçekleştirilir. Çağıran kullanıcının kimliği bu sertifikayla eşlenir ve bu nedenle sertifikayı kullanarak SQL Server'a geri bağlanan uydu işlemi, çağıran kullanıcıya geri eşlenebilir.

Daha fazla bilgi için bkz. Python veya R betiğinden SQL Server'a geri döngü bağlantısı.

Dış betik oturumlarında zımni kimlik doğrulaması nasıl çalışır?

Aşağıdaki diyagramda SQL Server bileşenlerinin dil çalışma zamanıyla etkileşimi ve Linux'ta kimlik doğrulamasının nasıl ima ettiği gösterilmektedir.

Linux'ta zımni kimlik doğrulaması

Dinlenimdeki Saydam Veri Şifreleme desteği yok

Saydam Veri Şifrelemesi (TDE), dış betik çalışma zamanı ortamına gönderilen veya alınan veriler için desteklenmez. Bunun nedeni, dış işlemin SQL Server işleminin dışında çalışmasıdır. Bu nedenle, dış çalışma zamanı tarafından kullanılan veriler veritabanı altyapısının şifreleme özellikleri tarafından korunmaz. Bu davranış, veritabanından veri okuyan ve kopyalayan SQL Server bilgisayarında çalışan diğer istemcilerden farklı değildir.

Sonuç olarak, TDE dış betiklerde kullandığınız verilere, diske kaydedilmiş verilere veya kalıcı ara sonuçlara uygulanmaz . Ancak, dosya veya klasör düzeyinde uygulanan Windows BitLocker şifrelemesi veya üçüncü taraf şifrelemesi gibi diğer şifreleme türleri yine de geçerlidir.

Always Encrypted söz konusu olduğunda, dış çalışma zamanlarının şifreleme anahtarlarına erişimi yoktur. Bu nedenle betiklere veri gönderilemez.

Sonraki Adımlar

Bu makalede, genişletilebilirlik çerçevesinde yerleşik olarak bulunan güvenlik mimarisinin bileşenlerini ve etkileşim modelini öğrendiniz. Bu makalede ele alınan önemli noktalar arasında başlatma çubuğu, SQLRUserGroup ve çalışan hesaplarının amacı, dış betiklerin işlem yalıtımı ve kullanıcı kimliklerinin çalışan hesaplarıyla nasıl eşlendiği yer alır.

Sonraki adım olarak , izin verme yönergelerini gözden geçirin. Windows kimlik doğrulaması kullanan sunucular için, ek yapılandırmanın ne zaman gerekli olduğunu öğrenmek amacıyla SQLRUserGroup'u bir veritabanı oturum açma bilgisine ekleme konusunu da gözden geçirmeniz gerekir.

  • Last updated on