ความเสี่ยงด้านความปลอดภัยหรือประสิทธิภาพการใช้ SQL CLR [ปิด]

มีความเสี่ยงด้านความปลอดภัยหรือประสิทธิภาพโดยเฉพาะอย่างยิ่งในการใช้ CLR ใน SQL Server หรือไม่?

คำถามดังที่รีมัสชี้ให้เห็นเป็นคำที่กว้างเกินไปที่จะได้รับคำตอบเนื่องจากคำตอบนั้นขึ้นอยู่กับบริบทของการใช้ฟังก์ชันการทำงานและวิธีการใช้งาน

เกี่ยวกับ "ความปลอดภัย":

หากคุณกำลังถามเกี่ยวกับสิ่งใดก็ตามที่สามารถทำได้ในชุดประกอบที่มีเครื่องหมายแสดงPERMISSION_SET = SAFEว่าไม่มีปัญหาใด ๆ ที่ฉันเคยพบ และ SQLCLR นั้น "ปลอดภัย" มากกว่าการใช้xp_cmdshellหรือsp_OA*procs (นั่นคือการเสียดสี) ที่ยอดเยี่ยม ( หรือแม้แต่ขั้นตอนการจัดเก็บเพิ่มเติม แต่หวังว่าจะไม่มีใครสร้างอีกต่อไป)

หากคุณต้องการคำแนะนำแบบ "SAFE" ในแง่ปฏิบัติโปรดดูบทความนี้: Stairway to SQLCLR ระดับ 3: ความปลอดภัย (ชุดประกอบทั่วไปและ SAFE) (ต้องลงทะเบียนฟรี)

หากคุณกำลังถามเกี่ยวกับสิ่งใดก็ตามที่สามารถทำได้ในชุดประกอบที่มีเครื่องหมายแสดงว่าPERMISSION_SET = EXTERNAL_ACCESSมีความเสี่ยงอย่างแน่นอนอีกครั้งทั้งนี้ขึ้นอยู่กับฟังก์ชันที่ใช้งานอยู่ หากคุณเขียนรูทีนเพื่ออ่านไดเร็กทอรีและชื่อไฟล์ (เช่นอ่านอย่างเดียว) แสดงว่าเป็นเรื่องของสิ่งที่ควรเห็นและไม่เห็น หากคุณกำลังเขียนรหัสที่อนุญาตให้ลบไฟล์ความเสี่ยงจะเพิ่มขึ้น แต่สิ่งที่สามารถทำได้กับทรัพยากรภายนอกเหล่านั้นถูกควบคุมโดย:

• ไม่ว่าคุณจะใช้การรับบทบาท:
  • ไม่มีการเลียนแบบหมายถึงการเข้าถึงทรัพยากรภายนอกทำได้ผ่านบัญชี "เข้าสู่ระบบในฐานะ" ของบริการ SQL Server ไม่ว่าบัญชีนั้นจะมีสิทธิ์เข้าถึงฟังก์ชัน SQLCLR ของคุณจะสามารถทำได้
  • การใช้การเลียนแบบหมายความว่าการเข้าสู่ระบบใน SQL Server ที่ใช้งานฟังก์ชั่นนั้นหากการล็อกอินนั้นสอดคล้องกับการเข้าสู่ระบบ Windows สามารถทำสิ่งใดก็ตามที่การเข้าสู่ระบบ Windows เฉพาะนั้นได้รับอนุญาตให้ทำได้ หากการเข้าสู่ระบบใน SQL Server เป็นการเข้าสู่ระบบเซิร์ฟเวอร์ SQL การพยายามใช้การเลียนแบบจะได้รับข้อผิดพลาด
• มีการตั้งค่าการอนุญาตใดในทรัพยากรภายนอก สำหรับการเข้าถึงระบบไฟล์สิ่งนี้ถูกควบคุมผ่าน ACLs บนไดรฟ์ NTFS

หากคุณกำลังถามเกี่ยวกับสิ่งที่สามารถทำได้ในการชุมนุมที่มีเครื่องหมาย PERMISSION_SET = UNSAFEที่ค่อนข้างปลายเปิด ฟังก์ชั่นจำนวนมากนั้นใช้งานได้ในแอสเซมบลี UNSAFE เท่านั้นเนื่องจากปัญหาด้านความเสถียรและ / หรือพฤติกรรมที่สอดคล้องกันมากกว่าความปลอดภัยหรือประสิทธิภาพ ตัวอย่างเช่นในแอสเซมบลี UNSAFE เป็นไปได้ที่จะมีตัวแปรสแตติกที่เขียนได้ โดยทั่วไปจะไม่เป็นการดีเนื่องจากคลาส SQLCLR ถูกแบ่งใช้ในทุกเซสชัน หากความตั้งใจของคุณคือการแบ่งปันข้อมูลในหน่วยความจำในทุกช่วงเวลาและวางแผนสำหรับสภาพการแข่งขัน (และทำการทดสอบมากมาย) คุณควรจะทำได้ดีตามที่คุณคาดหวังว่าจะเกิดพฤติกรรมนี้ แต่ถ้าคุณเพียงต้องการให้ตัวแปรแบบสแตติกเขียนได้เพื่อแคชค่าสำหรับเซสชันเฉพาะไม่ต้องค้นหาอีกครั้งหรือคำนวณอีกครั้งและไม่ทราบว่าเซสชันอื่นกำลังอ่านค่านั้นและอาจเขียนทับได้ดี นั่นจะเป็นปัญหา

แต่ถ้าคุณกังวลเกี่ยวกับคนที่เขียนถึง Registry แต่ยังไม่มีรหัสที่เขียนไปยัง Registry จริง ๆ แล้วคุณอาจไม่ต้องกังวลเกี่ยวกับเรื่องนี้ ;-)

หากคุณต้องการทราบวิธีการทำงานของ EXTERNAL_ACCESS และ UNSAFE ในแง่ปฏิบัติและความแตกต่างระหว่างการตั้งค่าTRUSTWORTHY ON(ไม่ต้องการ) กับการใช้ Asymmetric Key- หรือการลงชื่อเข้าใช้ที่ใช้ใบรับรองโปรดดูบทความนี้: Stairway to SQLCLR ระดับ 4: ความปลอดภัย (ส่วนประกอบภายนอกและ UNSAFE) (ต้องลงทะเบียนฟรี)

เกี่ยวกับ "ประสิทธิภาพ":

ทั้งหมดนี้เป็นเรื่องของสิ่งที่คุณพยายามทำและวิธีการทำ มีบางสิ่งที่เร็วกว่ามากใน SQLCLR และบางสิ่งที่ช้ากว่า แต่เช่นเดียวกับ T-SQL มันเป็นไปได้ที่จะใช้งานที่ค่อนข้างเรียบง่ายและ / หรือมีประสิทธิภาพและทำให้มันซับซ้อนและ / หรือไม่มีประสิทธิภาพโดยการทำสิ่งที่ไม่ถูกต้อง แต่การใช้ SQL CLR นั้นไม่ได้เกิดจากธรรมชาติ

ชุดประกอบ SQLCLR สามารถติดตั้งได้ด้วยการเข้าถึงความปลอดภัยสามระดับ: SAFE | EXTERNAL_ACCESS | UNSAFE. เอกสารนี้เพียงพอให้อ้างถึงCREATE ASSEMBLYและออกแบบชุดประกอบ :

การจัดการความปลอดภัยของชุดประกอบ
คุณสามารถควบคุมจำนวนชุดประกอบที่สามารถเข้าถึงทรัพยากรที่ได้รับการป้องกันโดย. NET Code Access Security เมื่อเรียกใช้รหัสที่ได้รับการจัดการ คุณทำได้โดยระบุหนึ่งในสามชุดสิทธิ์เมื่อคุณสร้างหรือแก้ไขชุดประกอบ: SAFE, EXTERNAL_ACCESS หรือ UNSAFE

SAFE
SAFE เป็นชุดการอนุญาตเริ่มต้นและเป็นข้อ จำกัด มากที่สุด รหัสที่ดำเนินการโดยชุดประกอบที่มีสิทธิ์ SAFE ไม่สามารถเข้าถึงทรัพยากรระบบภายนอกเช่นไฟล์เครือข่ายตัวแปรสภาพแวดล้อมหรือรีจิสทรี รหัส SAFE สามารถเข้าถึงข้อมูลจากฐานข้อมูล SQL Server ในพื้นที่หรือทำการคำนวณและตรรกะทางธุรกิจที่ไม่เกี่ยวข้องกับการเข้าถึงทรัพยากรนอกฐานข้อมูลท้องถิ่น
แอสเซมบลีส่วนใหญ่ทำการคำนวณและการจัดการข้อมูลโดยไม่ต้องเข้าถึงทรัพยากรภายนอก SQL Server ดังนั้นเราขอแนะนำให้ SAFE เป็นชุดสิทธิ์ในการประกอบ

EXTERNAL_ACCESS
EXTERNAL_ACCESS อนุญาตให้แอสเซมบลีเข้าถึงทรัพยากรระบบภายนอกบางอย่างเช่นไฟล์เครือข่ายบริการบนเว็บตัวแปรด้านสิ่งแวดล้อมและรีจิสตรี เฉพาะการเข้าสู่ระบบของเซิร์ฟเวอร์ SQL ที่มีสิทธิ์การเข้าถึงภายนอกสามารถสร้างแอสเซมบลี EXTERNAL_ACCESS แอสเซมบลี SAFE และ EXTERNAL_ACCESS สามารถประกอบด้วยรหัสเท่านั้นที่ปลอดภัยชนิด verifiably ซึ่งหมายความว่าแอสเซมบลีเหล่านี้สามารถเข้าถึงคลาสผ่านจุดเข้าใช้ที่กำหนดอย่างดีเท่านั้นที่ถูกต้องสำหรับการกำหนดชนิด ดังนั้นพวกเขาไม่สามารถเข้าถึงบัฟเฟอร์หน่วยความจำที่ไม่ได้เป็นเจ้าของโดยรหัส นอกจากนี้พวกเขาไม่สามารถดำเนินการที่อาจมีผลกระทบต่อความทนทานของกระบวนการเซิร์ฟเวอร์ SQL

UNSAFE
UNSAFE ให้แอสเซมบลีที่ไม่ จำกัด การเข้าถึงทรัพยากรทั้งภายในและภายนอก SQL Server รหัสที่กำลังเรียกใช้จากภายในแอสเซมบลี UNSAFE สามารถเรียกใช้รหัสที่ไม่มีการจัดการ นอกจากนี้การระบุ UNSAFE อนุญาตให้ใช้รหัสในแอสเซมบลีเพื่อดำเนินการที่ถือว่าไม่ปลอดภัยโดย CLR verifier การดำเนินการเหล่านี้สามารถเข้าถึงบัฟเฟอร์หน่วยความจำในพื้นที่กระบวนการ SQL Server ในลักษณะที่ไม่สามารถควบคุมได้ แอสเซมบลี UNSAFE ยังสามารถ subvert ระบบความปลอดภัยของ SQL Server หรือรันไทม์ภาษาทั่วไป ควรให้สิทธิ์ UNSAFE กับชุดประกอบที่เชื่อถือได้สูงเท่านั้นโดยนักพัฒนาหรือผู้ดูแลระบบที่มีประสบการณ์ เฉพาะสมาชิกของบทบาทเซิร์ฟเวอร์ถาวร sysadmin เท่านั้นที่สามารถสร้างชุดประกอบ UNSAFE ได้

มีข้อ จำกัด เพิ่มเติมเกี่ยวกับแอตทริบิวต์ CLR ที่อนุญาตและสนับสนุนชุดย่อยของ. Net Framework Assemblies เท่านั้น อีกครั้งโปรดดูเอกสารประกอบที่เชื่อมโยง

สำหรับประสิทธิภาพการทำงานสิ่งที่สำคัญที่สุดคือการจำไว้ว่า SQL Server เป็นสภาพแวดล้อมแบบมัลติทาสกิ้งแบบมีส่วนร่วมขณะที่ CLR ไม่ใช่ รหัส SQLCLR ต้องเรียกใช้Thread.BeginThreadAffinity()ทุกครั้งที่มันทำให้ซีพียูไม่ว่าจะในระยะเวลาใดก็ตาม (รวมถึงการบล็อค) อดัม Machanic มีการนำเสนอที่ดีเยี่ยมในหัวข้อดูข้อมูลได้เร็วขึ้น: เทคนิคประสิทธิภาพของเซิร์ฟเวอร์ Microsoft SQL กับ SQLCLR

หัวข้อกว้างใหญ่และคำถามคลุมเครือ SQLCLR สามารถทำงานบางอย่างที่ไม่เหมือนใครซึ่งคุณสมบัติอื่นไม่สามารถจับคู่ได้ และ SQLCLR เป็นเพียงอาวุธในคลังข้อมูล SQL Server ที่คุณสามารถยิงด้วยตัวคุณเองด้วยประสิทธิภาพหรือความปลอดภัย อ่านเอกสาร