Bagikan melalui

Arsitektur keamanan untuk kerangka kerja ekstensibilitas di SQL Server Pembelajaran Mesin Services

  • Artikel

Berlaku untuk: SQL Server 2016 (13.x) dan versi yang lebih baru

Artikel ini menjelaskan arsitektur keamanan yang digunakan untuk mengintegrasikan mesin database SQL Server dan komponen terkait dengan kerangka kerja ekstensibilitas di SQL Server Pembelajaran Mesin Services. Ini memeriksa keamanan, layanan, identitas proses, dan izin. Poin utama yang tercakup dalam artikel ini mencakup tujuan launchpad, akun SQLRUserGroup dan pekerja, isolasi proses skrip eksternal, dan bagaimana identitas pengguna dipetakan ke akun pekerja.

Untuk informasi selengkapnya tentang konsep utama dan komponen ekstensibilitas di SQL Server, lihat Arsitektur ekstensibilitas di SQL Server Pembelajaran Mesin Services.

Securables untuk skrip eksternal

Skrip eksternal dikirimkan sebagai parameter input ke prosedur tersimpan sistem yang dibuat untuk tujuan ini, atau dibungkus dalam prosedur tersimpan yang Anda tentukan. Skrip dapat ditulis dalam bahasa R, Python, atau eksternal seperti Java atau .NET. Atau, Anda mungkin memiliki model yang telah dilatih sebelumnya dan disimpan dalam format biner dalam tabel database, dapat dipanggil dalam fungsi T-SQL PREDICT .

Karena skrip disediakan melalui objek skema database yang ada, prosedur dan tabel tersimpan, tidak ada keamanan baru untuk SQL Server Pembelajaran Mesin Services.

Terlepas dari bagaimana Anda menggunakan skrip atau, apa yang terdiri dari, objek database akan dibuat dan mungkin disimpan, tetapi tidak ada jenis objek baru yang diperkenalkan untuk menyimpan skrip. Akibatnya, kemampuan untuk menggunakan, membuat, dan menyimpan objek database sangat bergantung pada izin database yang sudah ditentukan untuk pengguna Anda.

Izin

Model keamanan data login dan peran database SQL Server meluas ke skrip eksternal. Login SQL Server atau akun pengguna Windows diperlukan untuk menjalankan skrip eksternal yang menggunakan data SQL Server atau yang berjalan dengan SQL Server sebagai konteks komputasi. Pengguna database yang memiliki izin untuk menjalankan kueri dapat mengakses data yang sama dari skrip eksternal.

Akun masuk atau pengguna mengidentifikasi prinsip keamanan, yang mungkin memerlukan beberapa tingkat akses, tergantung pada persyaratan skrip eksternal:

  • Izin untuk mengakses database tempat skrip eksternal diaktifkan.
  • Izin untuk membaca data dari objek aman seperti tabel.
  • Kemampuan untuk menulis data baru ke tabel, seperti model, atau hasil penilaian.
  • Kemampuan untuk membuat objek baru, seperti tabel, prosedur tersimpan yang menggunakan skrip eksternal, atau fungsi kustom yang menggunakan pekerjaan skrip eksternal.
  • Hak untuk menginstal paket baru di komputer SQL Server, atau menggunakan paket yang disediakan untuk sekelompok pengguna.

Setiap orang yang menjalankan skrip eksternal menggunakan SQL Server sebagai konteks eksekusi harus dipetakan ke pengguna dalam database. Daripada mengatur izin pengguna database secara individual, Anda dapat membuat peran untuk mengelola sekumpulan izin, dan menetapkan pengguna ke peran tersebut, daripada mengatur izin pengguna secara individual.

Untuk informasi selengkapnya, lihat Memberi pengguna izin ke SQL Server Pembelajaran Mesin Services.

Izin saat menggunakan alat klien eksternal

Pengguna yang menggunakan skrip di alat klien eksternal harus memiliki login atau akun mereka yang dipetakan ke pengguna dalam database jika mereka perlu menjalankan skrip eksternal dalam database, atau mengakses objek dan data database. Izin yang sama diperlukan apakah skrip eksternal dikirim dari klien ilmu data jarak jauh atau dijalankan menggunakan prosedur tersimpan T-SQL.

Misalnya, asumsikan bahwa Anda membuat skrip eksternal yang berjalan di komputer lokal Anda, dan Anda ingin menjalankan skrip tersebut di SQL Server. Anda harus memastikan bahwa kondisi berikut terpenuhi:

  • Database memungkinkan koneksi jarak jauh.
  • Login SQL atau akun Windows yang Anda gunakan untuk akses database telah ditambahkan ke SQL Server di tingkat instans.
  • Login SQL atau pengguna Windows harus memiliki izin untuk menjalankan skrip eksternal. Umumnya, izin ini hanya dapat ditambahkan oleh administrator database.
  • Login SQL atau pengguna Jendela harus ditambahkan sebagai pengguna, dengan izin yang sesuai, di setiap database tempat skrip eksternal melakukan salah satu operasi ini:
    • Mengambil data.
    • Menulis atau memperbarui data.
    • Membuat objek baru, seperti tabel atau prosedur tersimpan.

Setelah akun masuk atau pengguna Windows disediakan dan diberikan izin yang diperlukan, Anda dapat menjalankan skrip eksternal di SQL Server dengan menggunakan objek sumber data di R atau pustaka revoscalepy di Python, atau dengan memanggil prosedur tersimpan yang berisi skrip eksternal.

Setiap kali skrip eksternal diluncurkan dari SQL Server, keamanan mesin database mendapatkan konteks keamanan pengguna yang memulai pekerjaan, dan mengelola pemetaan pengguna atau masuk ke objek yang dapat diamankan.

Oleh karena itu, semua skrip eksternal yang dimulai dari klien jarak jauh harus menentukan informasi masuk atau pengguna sebagai bagian dari string koneksi.

Layanan yang digunakan dalam pemrosesan eksternal (launchpad)

Kerangka kerja ekstensibilitas menambahkan satu layanan NT baru ke daftar layanan dalam penginstalan SQL Server: SQL Server Launchpad (MSSSQLSERVER).

Mesin database menggunakan layanan launchpad SQL Server untuk membuat instans sesi skrip eksternal sebagai proses terpisah. Proses berjalan di bawah akun dengan hak istimewa rendah. Akun ini berbeda dari SQL Server, launchpad itu sendiri, dan identitas pengguna di mana prosedur tersimpan atau kueri host dijalankan. Menjalankan skrip dalam proses terpisah, di bawah akun hak istimewa rendah, adalah dasar dari model keamanan dan isolasi untuk skrip eksternal di SQL Server.

SQL Server juga mempertahankan pemetaan identitas pengguna panggilan ke akun pekerja dengan hak istimewa rendah yang digunakan untuk memulai proses satelit. Dalam beberapa skenario, di mana skrip atau kode memanggil kembali ke SQL Server untuk data dan operasi, SQL Server dapat mengelola transfer identitas dengan mulus. Skrip yang berisi pernyataan SELECT atau fungsi panggilan dan objek pemrograman lainnya biasanya akan berhasil jika pengguna panggilan memiliki izin yang memadai.

Catatan

Secara default, Launchpad SQL Server dikonfigurasi untuk berjalan di bawah NT Service\MSSQLLaunchpad, yang disediakan dengan semua izin yang diperlukan untuk menjalankan skrip eksternal. Untuk informasi selengkapnya tentang opsi yang dapat dikonfigurasi, lihat Konfigurasi layanan launchpad SQL Server.

Layanan yang digunakan dalam pemrosesan eksternal (launchpad)

Kerangka kerja ekstensibilitas menambahkan satu layanan NT baru ke daftar layanan dalam penginstalan SQL Server: launchpad SQL Server (MSSSQLSERVER).

Mesin database menggunakan layanan launchpad SQL Server untuk membuat instans sesi skrip eksternal sebagai proses terpisah. Proses berjalan di bawah identitas pengguna launchpad tetapi dengan pembatasan tambahan terkandung di dalam AppContainer. Menjalankan skrip dalam proses terpisah, di bawah AppContainer, adalah dasar dari model keamanan dan isolasi untuk skrip eksternal di SQL Server.

SQL Server juga mempertahankan pemetaan identitas pengguna panggilan ke akun pekerja dengan hak istimewa rendah yang digunakan untuk memulai proses satelit. Dalam beberapa skenario, di mana skrip atau kode memanggil kembali ke SQL Server untuk data dan operasi, SQL Server dapat mengelola transfer identitas dengan mulus. Skrip yang berisi pernyataan SELECT atau fungsi panggilan dan objek pemrograman lainnya biasanya akan berhasil jika pengguna panggilan memiliki izin yang memadai.

Catatan

Secara default, Launchpad SQL Server dikonfigurasi untuk berjalan di bawah NT Service\MSSQLLaunchpad, yang disediakan dengan semua izin yang diperlukan untuk menjalankan skrip eksternal. Untuk informasi selengkapnya tentang opsi yang dapat dikonfigurasi, lihat Konfigurasi layanan launchpad SQL Server.

Layanan yang digunakan dalam pemrosesan eksternal

Kerangka kerja ekstensibilitas menambahkan satu daemon baru dalam penginstalan SQL Server: mssql-launchpadd. mssql-launchpadd berjalan di bawah akun dengan hak istimewa rendah mssql_launchpadd yang dibuat ketika paket mssql-server-extensibility diinstal.

Hanya satu instans mesin database yang didukung dan ada satu layanan launchpadd yang terikat ke instans. Ketika skrip dijalankan, layanan launchpadd memulai proses launchpad terpisah dengan akun pengguna dengan hak istimewa rendah mssql_satellite di PID, IPC, pemasangan, dan namespace jaringan barunya sendiri. Setiap proses satelit mewarisi akun pengguna mssql_satellite launchpad dan menggunakannya selama durasi eksekusi skrip.

Untuk informasi selengkapnya, lihat Arsitektur ekstensibilitas di SQL Server Pembelajaran Mesin Services.

Identitas yang digunakan dalam pemrosesan (SQLRUserGroup)

SQLRUserGroup (grup pengguna terbatas SQL) dibuat oleh Penyiapan SQL Server dan berisi kumpulan akun pengguna Windows lokal dengan hak istimewa rendah. Ketika proses eksternal diperlukan, launchpad mengambil akun pekerja yang tersedia dan menggunakannya untuk menjalankan proses. Lebih khusus lagi, launchpad mengaktifkan akun pekerja yang tersedia, memetakannya ke identitas pengguna panggilan, dan menjalankan skrip di bawah akun pekerja.

  • SQLRUserGroup ditautkan ke instans tertentu. Kumpulan akun pekerja terpisah diperlukan untuk setiap instans tempat pembelajaran mesin diaktifkan. Akun tidak dapat dibagikan antar instans.

  • Ukuran kumpulan akun pengguna bersifat statis dan nilai defaultnya adalah 20, yang mendukung 20 sesi bersamaan. Jumlah sesi runtime eksternal yang dapat diluncurkan secara bersamaan dibatasi oleh ukuran kumpulan akun pengguna ini.

  • Nama akun pekerja di kumpulan memiliki format SQLInstanceNamenn. Misalnya, pada instans default, SQLRUserGroup berisi akun bernama MSSQLSERVER01, MSSQLSERVER02, dan sebagainya, hingga MSSQLSERVER20.

Tugas paralel tidak menggunakan akun tambahan. Misalnya, jika pengguna menjalankan tugas penilaian yang menggunakan pemrosesan paralel, akun pekerja yang sama digunakan kembali untuk semua utas. Jika Anda berniat memanfaatkan pembelajaran mesin dengan berat, Anda dapat meningkatkan jumlah akun yang digunakan untuk menjalankan skrip eksternal. Untuk informasi selengkapnya, lihat Menskalakan eksekusi skrip eksternal secara bersamaan di SQL Server Pembelajaran Mesin Services.

Izin yang diberikan ke SQLRUserGroup

Secara default, anggota SQLRUserGroup telah membaca dan menjalankan izin pada file di direktori SQL Server Binn, R_SERVICES, dan PYTHON_SERVICES . Ini termasuk akses ke executable, pustaka, dan himpunan data bawaan dalam distribusi R dan Python yang diinstal dengan SQL Server.

Untuk melindungi sumber daya sensitif di SQL Server, Anda dapat secara opsional menentukan daftar kontrol akses (ACL) yang menolak akses ke SQLRUserGroup. Sebaliknya, Anda juga dapat memberikan izin ke sumber daya data lokal yang ada di komputer host, selain dari SQL Server itu sendiri.

Secara desain, SQLRUserGroup tidak memiliki login atau izin database ke data apa pun. Dalam keadaan tertentu, Anda mungkin ingin membuat login untuk mengizinkan koneksi loopback, terutama ketika identitas Windows tepercaya adalah pengguna panggilan. Kemampuan ini disebut autentikasi tersirat. Untuk informasi selengkapnya, lihat Menambahkan SQLRUserGroup sebagai pengguna database.

Pemetaan identitas

Saat sesi dimulai, launchpad memetakan identitas pengguna panggilan ke akun pekerja. Pemetaan pengguna Windows eksternal atau masuk SQL yang valid ke akun pekerja hanya berlaku untuk masa pakai prosedur tersimpan SQL yang menjalankan skrip eksternal. Kueri paralel dari login yang sama dipetakan ke akun pekerja pengguna yang sama.

Selama eksekusi, launchpad membuat folder sementara untuk menyimpan data sesi, menghapusnya saat sesi selesai. Direktori dibatasi aksesnya. Untuk R, RLauncher melakukan tugas ini. Untuk Python, PythonLauncher melakukan tugas ini. Setiap akun pekerja individu dibatasi untuk foldernya sendiri, dan tidak dapat mengakses file dalam folder di atas tingkatnya sendiri. Namun, akun pekerja dapat membaca, menulis, atau menghapus anak-anak di bawah folder kerja sesi yang dibuat. Jika Anda adalah administrator di komputer, Anda dapat melihat direktori yang dibuat untuk setiap proses. Setiap direktori diidentifikasi oleh GUID sesinya.

Isolasi AppContainer

Isolasi dicapai melalui AppContainers. Pada waktu proses, ketika skrip eksternal terdeteksi dalam prosedur atau kueri tersimpan, SQL Server memanggil launchpad dengan permintaan peluncur khusus ekstensi. Launchpad memanggil lingkungan runtime yang sesuai dalam proses di bawah identitasnya, dan membuat instans AppContainer untuk memuatnya. Perubahan ini bermanfaat karena akun lokal dan manajemen kata sandi tidak lagi diperlukan. Selain itu, pada penginstalan di mana akun pengguna lokal dilarang, penghapusan dependensi akun pengguna lokal berarti Anda sekarang dapat menggunakan fitur ini.

Seperti yang diimplementasikan oleh SQL Server, AppContainers adalah mekanisme internal. Meskipun Anda tidak akan melihat bukti fisik AppContainers di Monitor Proses, Anda dapat menemukannya dalam aturan firewall keluar yang dibuat oleh Penyiapan untuk mencegah proses melakukan panggilan jaringan. Untuk informasi selengkapnya, lihat Konfigurasi firewall untuk SQL Server Pembelajaran Mesin Services.

Pemetaan identitas

Saat sesi dimulai, launchpad memetakan identitas pengguna panggilan ke AppContainer.

Catatan

Di SQL Server 2019 dan yang lebih baru, SQLRUserGroup hanya memiliki satu anggota yang sekarang menjadi akun layanan launchpad SQL Server tunggal alih-alih beberapa akun pekerja.

Pemetaan identitas

Daemon launchpadd (double 'D' - mssql-launchpadd) memetakan identitas pengguna panggilan ke proses launchpad terpisah (single 'D') dengan folder "launchpad GUID" dan sertifikat satelit. Folder GUID launchpad ini dibuat di bawah /var/opt/mssql-extensibility/data/. Proses launchpad menggunakan sertifikat ini untuk mengautentikasi kembali ke SQL, lalu membuat folder sementara untuk setiap GUID sesi di bawah folder GUID launchpad. Proses satelit (R, Python, atau ExtHost) dapat mengakses folder GUID launchpad, sertifikat di bawahnya, dan folder GUID sesinya.

Skrip SQL berikut mencetak konten folder 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'

Autentikasi tersirat (permintaan loopback)

Autentikasi tersirat menjelaskan perilaku permintaan koneksi di mana proses eksternal yang berjalan sebagai akun pekerja dengan hak istimewa rendah disajikan sebagai identitas pengguna tepercaya ke SQL Server pada permintaan loopback untuk data atau operasi. Sebagai konsep, autentikasi tersirat unik untuk autentikasi Windows, di SQL Server string koneksi menentukan koneksi tepercaya, pada permintaan yang berasal dari proses eksternal seperti skrip R atau Python. Terkadang juga disebut sebagai loopback.

Koneksi tepercaya dapat digunakan dari skrip eksternal, tetapi hanya dengan konfigurasi tambahan. Dalam arsitektur ekstensibilitas, proses eksternal berjalan di bawah akun pekerja, mewarisi izin dari SQLRUserGroup induk. Ketika string koneksi menentukan Trusted_Connection=True, identitas akun pekerja disajikan pada permintaan koneksi, yang tidak diketahui secara default ke SQL Server.

Agar koneksi tepercaya berhasil, Anda harus membuat login database untuk SQLRUserGroup. Setelah melakukannya, setiap koneksi tepercaya dari setiap anggota SQLRUserGroup memiliki hak masuk ke SQL Server. Untuk instruksi langkah demi langkah, lihat Menambahkan SQLRUserGroup ke login database.

Koneksi tepercaya bukan rumusan permintaan koneksi yang paling banyak digunakan. Ketika skrip eksternal menentukan koneksi, mungkin lebih umum untuk menggunakan login SQL, atau nama pengguna dan kata sandi yang sepenuhnya ditentukan jika koneksi ke sumber data ODBC.

Cara kerja autentikasi tersirat untuk sesi skrip eksternal

Diagram berikut menunjukkan interaksi komponen SQL Server dengan runtime bahasa dan bagaimana hal itu menyiratkan autentikasi di Windows.

Autentikasi tersirat di Windows

Autentikasi tersirat (permintaan loopback)

Autentikasi tersirat menjelaskan perilaku permintaan koneksi di mana proses eksternal yang berjalan di bawah AppContainers disajikan sebagai identitas pengguna tepercaya ke SQL Server pada permintaan loopback untuk data atau operasi. Sebagai konsep, autentikasi tersirat tidak lagi unik untuk autentikasi Windows, di SQL Server string koneksi s menentukan koneksi tepercaya, pada permintaan yang berasal dari proses eksternal seperti skrip R atau Python. Terkadang juga disebut sebagai loopback.

Dengan mengelola identitas dan kredensial, AppContainer mencegah penggunaan kredensial pengguna untuk mendapatkan akses ke sumber daya atau masuk ke lingkungan lain. Lingkungan AppContainer membuat pengidentifikasi yang menggunakan identitas gabungan pengguna dan aplikasi, sehingga kredensial unik untuk setiap pasangan pengguna/aplikasi dan aplikasi tidak dapat meniru pengguna. Untuk informasi selengkapnya, lihat Isolasi AppContainer.

Untuk detail selengkapnya mengenai koneksi loopback, lihat Koneksi loopback ke SQL Server dari skrip Python atau R.

Cara kerja autentikasi tersirat untuk sesi skrip eksternal

Diagram berikut menunjukkan interaksi komponen SQL Server dengan runtime bahasa dan bagaimana hal itu menyiratkan autentikasi di Windows.

Autentikasi tersirat di Windows

Autentikasi tersirat (permintaan loopback)

Autentikasi tersirat menjelaskan perilaku permintaan koneksi di mana proses eksternal berjalan sebagai hak istimewa rendah mssql_satellite pengguna di namespace layanan mereka sendiri disajikan sebagai identitas pengguna tepercaya ke SQL Server pada permintaan loopback untuk data atau operasi. Terkadang juga disebut sebagai loopback.

Koneksi loopback dicapai dengan menggunakan sertifikat satelit dari folder GUID launchpad untuk mengautentikasi kembali ke SQL Server oleh proses satelit. Identitas pengguna panggilan dipetakan ke sertifikat ini dan karenanya proses satelit yang terhubung kembali ke SQL Server menggunakan sertifikat dapat dipetakan kembali ke pengguna panggilan.

Untuk informasi selengkapnya, lihat Koneksi loopback ke SQL Server dari skrip Python atau R.

Cara kerja autentikasi tersirat untuk sesi skrip eksternal

Diagram berikut menunjukkan interaksi komponen SQL Server dengan runtime bahasa dan bagaimana hal itu menyiratkan autentikasi di Linux.

Autentikasi tersirat di Linux

Tidak ada dukungan untuk Enkripsi Data Transparan saat tidak aktif

Enkripsi Data Transparan (TDE) tidak didukung untuk data yang dikirim atau diterima dari runtime skrip eksternal. Alasannya adalah bahwa proses eksternal berjalan di luar proses SQL Server. Oleh karena itu, data yang digunakan oleh runtime eksternal tidak dilindungi oleh fitur enkripsi mesin database. Perilaku ini tidak berbeda dari klien lain yang berjalan di komputer SQL Server yang membaca data dari database dan membuat salinan.

Sebagai konsekuensinya, TDE tidak diterapkan ke data apa pun yang Anda gunakan dalam skrip eksternal, atau ke data apa pun yang disimpan ke disk, atau ke hasil perantara yang dipertahankan. Namun, jenis enkripsi lainnya, seperti enkripsi Windows BitLocker atau enkripsi pihak ketiga yang diterapkan pada tingkat file atau folder, masih berlaku.

Dalam kasus Always Encrypted, runtime eksternal tidak memiliki akses ke kunci enkripsi. Oleh karena itu, data tidak dapat dikirim ke skrip.

Langkah berikutnya

Dalam artikel ini, Anda mempelajari komponen dan model interaksi arsitektur keamanan yang dibangun ke dalam kerangka kerja ekstensibilitas. Poin utama yang tercakup dalam artikel ini mencakup tujuan launchpad, akun SQLRUserGroup dan pekerja, isolasi proses skrip eksternal, dan bagaimana identitas pengguna dipetakan ke akun pekerja.

Sebagai langkah selanjutnya, tinjau instruksi untuk memberikan izin. Untuk server yang menggunakan autentikasi Windows, Anda juga harus meninjau Tambahkan SQLRUserGroup ke login database untuk mempelajari kapan konfigurasi tambahan diperlukan.