Rủi ro bảo mật hoặc hiệu suất khi sử dụng SQL CLR [đã đóng]

Có bất kỳ rủi ro bảo mật hoặc hiệu suất cụ thể nào khi sử dụng CLR trong SQL Server không?

Câu hỏi, như Remus đã chỉ ra, quá chung chung để có câu trả lời vì câu trả lời phụ thuộc vào ngữ cảnh của chức năng nào sẽ được sử dụng và cách sử dụng nó.

Về "Bảo mật":

Nếu bạn đang hỏi về bất cứ điều gì có thể được thực hiện trong một hội đồng được đánh dấu PERMISSION_SET = SAFE, thì sẽ không có bất kỳ vấn đề nào tôi có thể tìm thấy. Và SQLCLR "an toàn" hơn so với việc sử dụng xp_cmdshellhoặc các sp_OA*procs tuyệt vời (đó là châm biếm) (hoặc thậm chí là Thủ tục lưu trữ mở rộng, nhưng hy vọng không ai tạo ra bất kỳ quy trình nào nữa).

Nếu bạn muốn xem qua "SAFE" nghĩa là gì trong thực tế, vui lòng xem bài viết này: Nấc thang lên SQLCLR Cấp 3: Bảo mật (Lắp ráp chung và SAFE) (yêu cầu đăng ký miễn phí).

Nếu bạn đang hỏi về bất cứ điều gì có thể được thực hiện trong một hội đồng được đánh dấu PERMISSION_SET = EXTERNAL_ACCESS, thì chắc chắn sẽ có rủi ro, một lần nữa, tùy thuộc vào chức năng nào đang được sử dụng. Nếu bạn viết một thói quen để đọc các thư mục và tên tệp (tức là chỉ đọc), thì đó chỉ là vấn đề cần xem và không nhìn thấy. Nếu bạn đang viết mã cho phép xóa một tập tin, rủi ro sẽ tăng lên. Nhưng những gì có thể được thực hiện với những tài nguyên bên ngoài đó được kiểm soát bởi:

• cho dù bạn có đang sử dụng Mạo danh hay không:
  • không mạo danh nghĩa là truy cập tài nguyên bên ngoài được thực hiện thông qua tài khoản "Đăng nhập dưới dạng" của dịch vụ SQL Server. Bất cứ tài khoản nào có quyền truy cập, chức năng SQLCLR của bạn sẽ có thể thực hiện.
  • sử dụng Mạo danh có nghĩa là Đăng nhập trong SQL Server đang chạy chức năng, nếu Đăng nhập đó tương ứng với Đăng nhập Windows, có thể làm bất cứ điều gì mà Đăng nhập Windows cụ thể được phép làm. Nếu Đăng nhập trong SQL Server là Đăng nhập máy chủ SQL, thì khi thử sử dụng Mạo danh sẽ gặp lỗi.
• Những quyền nào được thiết lập trên tài nguyên bên ngoài. Để truy cập hệ thống tập tin, điều này được kiểm soát thông qua ACL trên các ổ đĩa NTFS.

Nếu bạn đang hỏi về bất cứ điều gì có thể được thực hiện trong một hội đồng được đánh dấu bằng PERMISSION_SET = UNSAFE, đó là kết thúc khá mở. Rất nhiều chức năng được coi là chỉ có thể sử dụng được trong các hội đồng UNSAFE vì chúng là các vấn đề về tính ổn định và / hoặc hành vi nhất quán hơn là bảo mật hoặc hiệu suất. Ví dụ, trong một hội đồng UNSAFE có thể có một biến tĩnh có thể ghi. Điều này thường không phải là một điều tốt để làm vì các lớp SQLCLR được chia sẻ trên tất cả các phiên. Nếu ý định của bạn là chia sẻ dữ liệu trong bộ nhớ trong tất cả các phiên và đã lên kế hoạch cho các điều kiện cuộc đua (và thực hiện nhiều thử nghiệm), thì bạn sẽ ổn vì bạn đang mong đợi hành vi này. Nhưng nếu bạn chỉ đơn giản muốn một biến tĩnh có thể ghi để lưu một giá trị cho một phiên cụ thể để không phải tìm kiếm lại hoặc tính toán lại, và không biết rằng các phiên khác đang đọc giá trị đó và có thể ghi đè lên nó, tốt, đó sẽ là một vấn đề

Nhưng nếu bạn lo lắng về việc ai đó viết thư cho Cơ quan đăng ký, nhưng chưa có bất kỳ mã nào thực sự ghi vào Cơ quan đăng ký, thì có lẽ bạn không cần phải lo lắng về điều này ;-).

Nếu bạn muốn tìm hiểu về cách EXTERNAL_ACCESS và UNSAFE hoạt động theo các thuật ngữ thực tế và sự khác biệt giữa cài đặt TRUSTWORTHY ON(không được ưa thích) so với sử dụng Đăng nhập dựa trên khóa hoặc chứng chỉ không đối xứng, vui lòng xem bài viết này: Stairway to SQLCLR Cấp 4: Bảo mật (EXTERNAL và UNSAFE Assemblies) (yêu cầu đăng ký miễn phí).

Về "Hiệu suất":

Đây là tất cả vấn đề về những gì bạn đang cố gắng làm và cách bạn thực hiện nó. Có một số thứ nhanh hơn nhiều trong SQLCLR và một số thứ chậm hơn. Nhưng cũng giống như với T-SQL, có thể thực hiện một nhiệm vụ hơi đơn giản và / hoặc hiệu quả và làm cho nó trở nên phức tạp và / hoặc không hiệu quả bằng cách thực hiện mọi thứ không chính xác. Nhưng việc sử dụng SQL CLR không phải là bản chất, chậm hơn.

Các hội đồng SQLCLR có thể được cài đặt với ba cấp độ truy cập bảo mật : SAFE | EXTERNAL_ACCESS | UNSAFE. Đây là tài liệu amply, tham khảo CREATE ASSEMBLYvà thiết kế các hội đồng :

Quản lý bảo mật hội
Bạn có thể kiểm soát bao nhiêu hội đồng có thể truy cập các tài nguyên được bảo vệ bởi .NET Code Access Security khi nó chạy mã được quản lý. Bạn làm điều này bằng cách chỉ định một trong ba bộ quyền khi bạn tạo hoặc sửa đổi một hội đồng: SAFE, EXTERNAL_ACCESS hoặc UNSAFE.

SAFE
SAFE là bộ quyền mặc định và nó là hạn chế nhất. Mã được chạy bởi một hội đồng có quyền SAFE không thể truy cập tài nguyên hệ thống bên ngoài như tệp, mạng, biến môi trường hoặc sổ đăng ký. Mã SAFE có thể truy cập dữ liệu từ cơ sở dữ liệu SQL Server cục bộ hoặc thực hiện tính toán và logic nghiệp vụ không liên quan đến việc truy cập tài nguyên bên ngoài cơ sở dữ liệu cục bộ.
Hầu hết các hội đồng thực hiện các nhiệm vụ quản lý dữ liệu và tính toán mà không phải truy cập tài nguyên bên ngoài SQL Server. Do đó, chúng tôi khuyên bạn nên SAFE làm bộ cấp phép lắp ráp.

EXTERNAL_ACCESS
EXTERNAL_ACCESS cho phép các hội đồng truy cập một số tài nguyên hệ thống bên ngoài nhất định như tệp, mạng, dịch vụ web, biến môi trường và sổ đăng ký. Chỉ các thông tin đăng nhập Máy chủ SQL có quyền EXTERNAL ACCESS mới có thể tạo các cụm EXTERNAL_ACCESS. Các hội đồng SAFE và EXTERNAL_ACCESS chỉ có thể chứa mã có thể kiểm chứng loại an toàn. Điều này có nghĩa là các hội đồng này chỉ có thể truy cập các lớp thông qua các điểm nhập được xác định rõ là hợp lệ cho định nghĩa kiểu. Do đó, họ không thể tùy ý truy cập bộ đệm bộ nhớ không thuộc sở hữu của mã. Ngoài ra, họ không thể thực hiện các hoạt động có thể có ảnh hưởng xấu đến sự mạnh mẽ của quy trình SQL Server.

UNSAFE
UNSAFE cung cấp cho các hội đồng quyền truy cập không hạn chế vào các tài nguyên, cả trong và ngoài SQL Server. Mã đang chạy từ bên trong một hội đồng UNSAFE có thể gọi mã không được quản lý. Ngoài ra, việc chỉ định UNSAFE cho phép mã trong tổ hợp thực hiện các hoạt động được coi là không an toàn kiểu bởi trình xác minh CLR. Các hoạt động này có khả năng có thể truy cập bộ đệm bộ nhớ trong không gian xử lý SQL Server theo cách không được kiểm soát. Các hội đồng UNSAFE cũng có khả năng phá hủy hệ thống bảo mật của SQL Server hoặc thời gian chạy ngôn ngữ chung. Quyền UNSAFE chỉ nên được cấp cho các hội đồng có độ tin cậy cao bởi các nhà phát triển hoặc quản trị viên có kinh nghiệm. Chỉ các thành viên của vai trò máy chủ cố định sysadmin mới có thể tạo các hội đồng UNSAFE.

Có nhiều hạn chế hơn đối với các thuộc tính CLR được phép và chỉ một tập hợp con của .Net Framework Assemblies được hỗ trợ. Một lần nữa, tham khảo các tài liệu liên kết.

Về hiệu năng, suy nghĩ quan trọng nhất là phải nhớ rằng SQL Server là một môi trường đa tác vụ hợp tác, trong khi CLR thì không. Mã SQLCLR phải gọi Thread.BeginThreadAffinity()bất cứ lúc nào nó chiếm CPU trong bất kỳ khoảng thời gian nào (bao gồm cả chặn). Adam Machanic có một bài thuyết trình tuyệt vời về chủ đề này, xem Dữ liệu, Nhanh hơn: Kỹ thuật Hiệu suất Máy chủ Microsoft SQL với SQLCLR .

Chủ đề rộng lớn và câu hỏi mơ hồ. SQLCLR có thể thực hiện một số tác vụ duy nhất mà không tính năng nào khác có thể sánh được. Và SQLCLR chỉ là một vũ khí khác trong kho vũ khí của SQL Server, bạn có thể tự bắn vào chân mình bằng hiệu suất hoặc bảo mật. Đọc tài liệu.