Risiko keamanan atau kinerja menggunakan SQL CLR [ditutup]

Apakah ada risiko keamanan atau kinerja tertentu dalam menggunakan CLR di SQL Server?

Pertanyaannya, seperti yang ditunjukkan oleh Remus, terlalu umum untuk mendapatkan jawaban karena jawabannya tergantung pada konteks fungsionalitas apa yang akan digunakan dan bagaimana akan digunakan.

Mengenai "Keamanan":

Jika Anda bertanya tentang apa pun yang dapat dilakukan dalam sebuah majelis bertanda PERMISSION_SET = SAFE, maka tidak ada masalah yang pernah saya temukan. Dan SQLCLR adalah "lebih aman" daripada menggunakan xp_cmdshellatau sp_OA*procs indah (itu sarkasme) (atau bahkan Extended Stored Procedures, tapi mudah-mudahan tidak ada yang membuat itu lagi).

Jika Anda ingin mengetahui apa arti "AMAN" dalam istilah praktis, silakan lihat artikel ini: Stairway to SQLCLR Level 3: Keamanan (Umum dan Majelis AMAN) (diperlukan pendaftaran gratis).

Jika Anda bertanya tentang apa pun yang dapat dilakukan dalam suatu rakitan yang ditandai dengan PERMISSION_SET = EXTERNAL_ACCESS, maka tentu saja ada risiko, sekali lagi, tergantung pada fungsi apa yang digunakan. Jika Anda menulis rutin untuk membaca direktori dan nama file (yaitu read-only), maka itu hanya masalah apa yang harus dilihat dan tidak terlihat. Jika Anda menulis kode yang memungkinkan untuk menghapus file, risikonya meningkat. Tetapi apa yang dapat dilakukan dengan sumber daya eksternal tersebut dikendalikan oleh:

• apakah Anda menggunakan Peniruan:
  • tanpa peniruan berarti mengakses sumber daya eksternal dilakukan melalui akun "Masuk sebagai" dari layanan SQL Server. Apa pun yang memiliki akses ke akun itu, fungsi SQLCLR Anda akan dapat melakukannya.
  • menggunakan Peniruan berarti bahwa Login di SQL Server yang menjalankan fungsi, jika Login itu sesuai dengan Login Windows, dapat melakukan apa pun yang diperbolehkan untuk Login Windows tertentu. Jika Login di SQL Server adalah Login SQL Server, maka upaya untuk menggunakan Peniruan identitas akan mendapat kesalahan.
• Izin apa yang diatur pada sumber daya eksternal. Untuk akses sistem file, ini dikontrol melalui ACL pada drive NTFS.

Jika Anda bertanya tentang apa pun yang dapat dilakukan di majelis bertanda PERMISSION_SET = UNSAFE, itu cukup terbuka. Banyak fungsi dianggap hanya dapat digunakan dalam majelis UNSAFE karena mereka adalah masalah stabilitas dan / atau perilaku yang konsisten lebih dari keamanan atau kinerja. Misalnya, dalam majelis UNSAFE dimungkinkan untuk memiliki variabel statis yang dapat ditulis. Ini biasanya bukan hal yang baik untuk dilakukan karena kelas SQLCLR dibagikan di semua sesi. Jika niat Anda adalah untuk membagikan data dalam memori di semua sesi dan telah merencanakan kondisi balapan (dan melakukan banyak pengujian), maka Anda harus baik-baik saja karena Anda mengharapkan perilaku ini. Tetapi jika Anda hanya ingin variabel statis yang dapat ditulis untuk menyimpan nilai untuk sesi tertentu agar tidak perlu mencarinya lagi atau menghitungnya lagi, dan tidak menyadari bahwa sesi lain membaca nilai itu dan mungkin menulisnya secara berlebihan, yah, itu akan menjadi masalah.

Tetapi jika Anda khawatir tentang seseorang yang menulis ke Registry, tetapi belum memiliki kode yang benar-benar menulis ke Registry, maka Anda mungkin tidak perlu khawatir tentang ini ;-).

Jika Anda ingin melihat bagaimana EXTERNAL_ACCESS dan UNSAFE bekerja secara praktis, dan perbedaan antara pengaturan TRUSTWORTHY ON(tidak disukai) vs menggunakan Login Asimetris atau Berbasis Sertifikat, silakan lihat artikel ini: Stairway to SQLCLR Level 4: Keamanan (Sidang EKSTERNAL dan UNSAFE) (diperlukan pendaftaran gratis).

Mengenai "Kinerja":

Ini semua adalah masalah apa yang Anda coba lakukan dan bagaimana Anda melakukannya. Ada beberapa hal yang jauh lebih cepat di SQLCLR, dan beberapa hal yang lebih lambat. Tetapi seperti halnya dengan T-SQL, dimungkinkan untuk mengambil tugas yang agak sederhana dan / atau efisien dan membuatnya rumit dan / atau tidak efisien dengan melakukan hal-hal yang salah. Tetapi menggunakan SQL CLR secara inheren, pada dasarnya, lebih lambat.

Rakitan SQLCLR dapat diinstal dengan tiga tingkat keamanan akses: SAFE | EXTERNAL_ACCESS | UNSAFE. Ini banyak didokumentasikan, merujuk CREATE ASSEMBLYdan Merancang Majelis :

Mengelola Keamanan Majelis
Anda dapat mengontrol seberapa banyak majelis dapat mengakses sumber daya yang dilindungi oleh .NET Code Access Security ketika menjalankan kode yang dikelola. Anda melakukan ini dengan menentukan satu dari tiga set izin ketika Anda membuat atau memodifikasi sebuah perakitan: SAFE, EXTERNAL_ACCESS, atau UNSAFE.

SAFE
SAFE adalah perizinan standar yang ditetapkan dan itu yang paling membatasi. Kode dijalankan oleh majelis dengan izin AMAN tidak dapat mengakses sumber daya sistem eksternal seperti file, jaringan, variabel lingkungan, atau registri. Kode SAFE dapat mengakses data dari database SQL Server lokal atau melakukan perhitungan dan logika bisnis yang tidak melibatkan mengakses sumber daya di luar database lokal.
Sebagian besar majelis melakukan tugas komputasi dan manajemen data tanpa harus mengakses sumber daya di luar SQL Server. Karena itu, kami merekomendasikan SAFE sebagai izin perakitan yang ditetapkan.

EXTERNAL_ACCESS
EXTERNAL_ACCESS memungkinkan majelis untuk mengakses sumber daya sistem eksternal tertentu seperti file, jaringan, layanan Web, variabel lingkungan, dan registri. Hanya login SQL Server dengan izin ACCESS EKSTERNAL yang dapat membuat rakitan EXTERNAL_ACCESS. Rakitan SAFE dan EXTERNAL_ACCESS hanya dapat berisi kode yang aman untuk diverifikasi. Ini berarti bahwa rakitan ini hanya dapat mengakses kelas melalui titik masuk yang terdefinisi dengan baik yang valid untuk definisi jenis. Oleh karena itu, mereka tidak dapat secara sewenang-wenang mengakses buffer memori yang tidak dimiliki oleh kode. Selain itu, mereka tidak dapat melakukan operasi yang mungkin memiliki efek buruk pada ketahanan proses SQL Server.

UNSAFE
UNSAFE memberi majelis akses tak terbatas ke sumber daya, baik di dalam maupun di luar SQL Server. Kode yang dijalankan dari dalam majelis UNSAFE dapat memanggil kode yang tidak dikelola. Juga, menentukan UNSAFE memungkinkan kode dalam perakitan untuk melakukan operasi yang dianggap tidak aman oleh verifikator CLR. Operasi ini berpotensi mengakses buffer memori di ruang proses SQL Server secara tidak terkendali. Majelis UNSAFE juga berpotensi menumbangkan sistem keamanan SQL Server atau runtime bahasa umum. Izin UNSAFE harus diberikan hanya kepada majelis yang sangat tepercaya oleh pengembang atau administrator berpengalaman. Hanya anggota peran server tetap sysadmin yang dapat membuat perangkat UNSAFE.

Ada pembatasan lebih lanjut pada atribut CLR yang diizinkan dan hanya sebagian dari .Net Framework Assemblies yang didukung. Sekali lagi, lihat dokumentasi yang ditautkan.

Adapun kinerja, pemikiran paling penting adalah untuk mengingat bahwa SQL Server adalah lingkungan multi-tasking kooperatif, sedangkan CLR tidak. Kode SQLCLR harus memanggil Thread.BeginThreadAffinity()kapan saja ia memakan CPU untuk jangka waktu berapa pun (termasuk pemblokiran). Adam Machanic memiliki presentasi yang sangat baik tentang topik, lihat Data, Lebih Cepat: Teknik Kinerja Microsoft SQL Server dengan SQLCLR .

Topiknya luas dan pertanyaannya tidak jelas. SQLCLR dapat melakukan beberapa tugas unik yang tidak cocok dengan fitur lain. Dan SQLCLR hanyalah senjata lain dalam gudang SQL Server yang dapat Anda tembak sendiri, kinerja atau keamanan. Baca dokumentasinya.