Saya mengalami masalah dengan mengizinkan pengguna saya untuk menjalankan Paket SSIS dengan cara yang masuk akal karena berbagai tingkat hak istimewa yang diperlukan.
Skenario : kami telah membuat data warehouse, dengan dua paket SSIS berbeda yang bertanggung jawab untuk memuatnya dengan data, satu harus dijalankan secara otomatis (melalui pekerjaan SQL Agent, dan berfungsi dengan baik), dan yang lainnya harus dijalankan di- permintaan oleh pengguna setelah data hulu difinalisasi dan dibersihkan dll.
Paket ini melakukan operasi yang sangat istimewa termasuk membuat cadangan basis data pada awal proses (pasti, pasti), menjatuhkan dan membuat ulang tabel terhitung dll.
Saya telah menulis prosedur tersimpan untuk menjalankan pekerjaan ini melalui [SSISDB]. [Katalog]. [Create_execution] dan [SSISDB]. [Katalog]. [Start_execution] prosedur tersimpan .... ini berfungsi dengan baik ketika dijalankan di bawah akun saya (Saya seorang sysadmin).
Prosedur tersimpan gagal ketika dijalankan oleh pengguna normal karena tingkat izin yang lebih tinggi diperlukan dalam SSISDB dan MSDB untuk enqueue eksekusi, dan paket itu sendiri gagal karena berjalan di bawah konteks keamanan (rendah) mereka.
Apa yang saya coba :
Saya mencoba untuk menyelesaikan masalah menggunakan 'Jalankan Sebagai' dalam prosedur yang tersimpan, namun ini gagal karena masalah rantai-lintas chaining, bendera yang dapat dipercaya dll.
Saya juga telah mencoba untuk menyelesaikan masalah ini dengan meminta pekerjaan Agen untuk menjalankan paket, dan hanya menjalankan pekerjaan agen dari prosedur yang tersimpan, namun saya dengan cepat memasuki dunia kesakitan yang melibatkan:
- Ketidakmampuan untuk mengatur izin eksekusi berdasarkan per-pekerjaan
- Harapan untuk mengkonfigurasi akses ini melalui Peran Server pusat untuk melayani perubahan staf seiring waktu, dan pekerjaan hanya dapat memiliki satu pengguna sebagai pemilik
- Dunia gelap dari akun Proxy, Kredensial dalam kombinasi dengan login sql-auth dll
Paket C dan D
Satu-satunya pilihan yang dapat saya pikirkan untuk tetap ada pada saya adalah untuk membuat SQL Server Login khusus dengan izin tinggi, dan percaya pengguna untuk tidak melewati kredensial sekitar / kehilangan auditabilitas dari siapa yang menjadwalkan impor (bagaimana masalah ini diselesaikan di area lain dari organisasi), atau kustom membangun ujung depan web murni untuk memungkinkan pengguna untuk mengotentikasi sebagai akun 'Peran Server' mereka, dan kemudian membiarkan aplikasi web menjalankan prosedur tersimpan di bawah koneksi kedua (istimewa).
Begitu....
Apakah ada saran di luar sana tentang cara:
- memiliki paket SSIS melakukan operasi istimewa
- dieksekusi oleh pengguna dengan hak istimewa rendah (menggunakan akun windows AD)
- lebih disukai jika akses untuk menjalankan pekerjaan dikelola melalui Peran Server pusat (Saya tidak memiliki kemampuan mudah untuk membuat grup windows baru untuk mereka)
- dan di mana akun baru, perantara / proksi adalah akun SQL Server Auth (sekali lagi, kemampuan yang sangat terbatas untuk melakukan perubahan pada AD)
Saya mengerti ada banyak bagian yang bergerak di sini (dan beberapa terasa seperti pisau berputar) jadi beri tahu saya jika ada informasi lain yang Anda rasa saya lewatkan.
Cheers, Tim
Edit ....
Jadi hari ini saya membuat login SQL Server khusus dengan izin ssis_admin, menciptakan tiga pekerjaan SQL Server Agent yang dimiliki oleh pengguna tersebut, dan memperbarui prosedur tersimpan yang dipanggil oleh pengguna akhir saya ke execute aspengguna tersebut. Ini gagal karena ketidakmampuan untuk meneleponcreate execution sebagai login SQL Server, itu memerlukan akun windows.
Saya memperbarui prosedur yang disimpan pengguna ke execute asakun Windows SQL Server berjalan sebagai (akun layanan AD), memberikannya ssis_admindan gagal dengan kesalahan
Konteks keamanan saat ini tidak dapat dikembalikan. Silakan beralih ke database asli tempat 'Jalankan Sebagai' dipanggil dan coba lagi.
Ini tidak cepat :(
create_executionkarena saya harus melewati parameter (satu dari tiga nilai) dari sproc ke pekerjaan. Saya senang memiliki tiga sprocs / pekerjaan dll jika itu menyelesaikannya. 2) Jika ssis_admin adalah peran privilege terendah yang membuat saya di sana, saya terbuka untuk itu ... lebih baik daripada sysadmin setidaknya dan menyelesaikannya secara tidak sengaja menjatuhkan / nuking tabel gudang dalam penggunaan umum.
ssis_adminperan akan memungkinkan mereka untuk menjalankan paket SSIS (procs memeriksa keanggotaan dalam peran sysadmin atau ssis_admin) tapi saya pikir itu akan dijalankan sebagai mereka dan karena itu tidak dapat mengambil backup dan semacamnya. (Saya harus mengujinya dengan pasti, tidak akan pernah ingat apakah itu berjalan seperti mereka atau akun layanan SQL Server). Namun, menjadi anggota ssis_admin memungkinkan mereka menyebarkan paket dan mengatasi berbagai konfigurasi yang mungkin atau mungkin bukan hal yang baik. Tahun 2016 memberi kita lebih banyak peran granular tetapi jelas tidak banyak digunakan di sini
EXECUTE ASuntuk memungkinkan mereka untuk menjalankan pekerjaan tertentu melalui sp_start_job. Mengatakan orang internet acak yang mengerikan di keamanan
create_executionyaitu apakah mereka perlu menentukan parameter pada eksekusi untuk "skenario siap data mereka"? 2) Aman untuk berasumsi bahwa Anda tidak tertarik menempatkan mereka dalam peran ssis_admin?