CLR nghiêm ngặt bảo mật trên SQL Server 2017

Làm cách nào để hợp ngữ CLR được tạo bằng PERMISSION_SET =SAFE có thể truy cập tài nguyên hệ thống bên ngoài, gọi mã không được quản lý và có được đặc quyền sysadmin?

Điều này là do các thay đổi bảo mật được thực hiện trong .NET Framework, bắt đầu từ phiên bản 4.5 (tôi tin rằng).

Tài liệu MSDN về Kiến thức Cơ bản về Bảo mật Truy cập Mã nêu rõ:

.NET Framework cung cấp cơ chế thực thi các mức độ tin cậy khác nhau trên các mã khác nhau chạy trong cùng một ứng dụng được gọi là Bảo mật truy cập mã (CAS). Code Access Security trong .NET Framework không nên được sử dụng như một cơ chế để thực thi các ranh giới bảo mật dựa trên nguồn gốc mã hoặc các khía cạnh nhận dạng khác. Chúng tôi đang cập nhật hướng dẫn của mình để phản ánh rằng Mã bảo mật truy cập mã và Mã minh bạch bảo mật sẽ không được hỗ trợ làm ranh giới bảo mật với mã đáng tin cậy một phần, đặc biệt là mã không rõ nguồn gốc. Chúng tôi khuyên bạn không nên tải và thực thi mã không rõ nguồn gốc mà không áp dụng các biện pháp bảo mật thay thế.

Và sau đó trỏ đến trang Thay đổi bảo mật trong .NET Framework cho biết:

Thay đổi quan trọng nhất đối với bảo mật trong .NET Framework 4.5 nằm ở cách đặt tên mạnh.

Sau đó, điều này trỏ đến tài liệu về Đặt tên mạnh nâng cao nêu rõ:

Khóa tên mạnh bao gồm khóa chữ ký và khóa nhận dạng. Hợp ngữ được ký bằng khóa chữ ký và được xác định bằng khóa nhận dạng. Trước .NET Framework 4.5, hai khóa này giống hệt nhau. Bắt đầu với .NET Framework 4.5, khóa nhận dạng vẫn giống như trong các phiên bản .NET Framework trước đó, nhưng khóa chữ ký được cải tiến với thuật toán băm mạnh hơn. Ngoài ra, khóa chữ ký được ký bằng khóa nhận dạng để tạo chữ ký phản đối.

CŨNG CÓ, tài liệu về Nguyên tắc Mã hóa An toàn cho biết:

Mã bảo mật truy cập mã và mã bảo mật minh bạch sẽ không được hỗ trợ làm ranh giới bảo mật với mã tin cậy một phần. Chúng tôi khuyên bạn không nên tải và thực thi mã không rõ nguồn gốc mà không áp dụng các biện pháp bảo mật thay thế ...

Vì vậy, mô hình bảo mật cho .NET đã thay đổi nhiều năm trước, nhưng SQL Server (cho đến SQL Server 2017) vẫn được phép tiếp tục sử dụng mô hình bảo mật cũ. Có vẻ như, bắt đầu từ SQL Server 2017, chúng tôi đã đưa ra quyết định không hỗ trợ mô hình bảo mật cũ nữa.

Tôi nghi ngờ rằng việc cho phép mô hình bảo mật cũ là:

ngăn SQL Server (ít nhất là chức năng / thành phần liên quan đến CLR) dựa trên các phiên bản .NET Framework mới hơn và
chịu trách nhiệm về việc đột ngột xóa SQLCLR là một tính năng được hỗ trợ khỏi Cơ sở dữ liệu Azure SQL (hỗ trợ đã được thêm vào cuối năm 2014 với sự ra mắt của v12, nhưng sau đó bị xóa hoàn toàn kể từ ngày 15 tháng 4 năm 2016).

Vì vậy, có, loại này thật tệ. Điều đó có nghĩa là gì (ít nhất là vào lúc này) là người ta cần đầu tiên tạo Chứng chỉ hoặc Khóa không đối xứng (đã được sử dụng để ký bất kỳ Tập hợp nào sẽ được tải) vào [master] sau đó tạo Đăng nhập từ đó cấp UNSAFE ASSEMBLY vào Đăng nhập đó. Đây là chuỗi sự kiện tương tự mà người ta cần thực hiện khi tải EXTERNAL_ACCESS và UNSAFE Tuy nhiên, thật không may, bây giờ cần phải thực hiện lắp ráp để SAFE Lắp ráp.

Hiện tại không có cơ chế nào để xử lý điều này theo kiểu hoàn toàn di động (tức là không dựa vào các tệp bên ngoài) và Visual Studio / SSDT không thể xử lý được nếu không có sự can thiệp thủ công. Đây là trường hợp đã xảy ra, nhưng ít nhất có thể tạo một thiết lập để xử lý việc này theo kiểu hoàn toàn di động (tức là hoàn toàn nằm trong tập lệnh .sql):vui lòng xem Nấc thang lên SQLCLR Cấp 7:Phát triển và Bảo mật để biết chi tiết (đây là một bài báo mà tôi đã viết).

Có thể tạo Chứng chỉ từ các byte hex (tức là FROM BINARY = 0x... ) nhưng điều đó không hoạt động với Visual Studio (dựa trên MSBuild) / SSDT vì việc sử dụng Chứng chỉ yêu cầu sử dụng signtool và MSBuild sử dụng sn .

Để điều này có thể thực hiện được sao cho quá trình xuất bản Visual Studio / MSBuild / SSDT hoạt động (điều này có nghĩa là bất kỳ ai cũng có thể tạo một tập lệnh .sql hoàn toàn độc lập có khả năng tạo Khóa bất đối xứng mà không cần dựa vào một tệp bên ngoài), CREATE ASYMMETRIC KEY lệnh cần được nâng cao để cho phép được tạo từ một chuỗi nhị phân. Tôi đã đưa ra đề xuất này trên Microsoft Connect - Cho phép tạo Khóa bất đối xứng từ chuỗi hex byte nhị phân giống như TẠO CHỨNG NHẬN - vì vậy hãy hỗ trợ nó :-).

Ngoài ra (hiện tại, cho đến khi MS hy vọng tạo ra một phương pháp tốt hơn, chẳng hạn như đề xuất Khóa bất đối xứng của tôi), bạn có thể thử một trong hai kỹ thuật mà tôi mô tả trong các bài đăng blog sau (cả hai đều hoạt động hoàn toàn với SSDT):

SQLCLR so với SQL Server 2017, Phần 2:“Bảo mật nghiêm ngặt CLR” - Giải pháp 1
SQLCLR so với SQL Server 2017, Phần 3:“Bảo mật nghiêm ngặt CLR” - Giải pháp 2

Như một cuối cùng khu nghỉ mát, bạn có thể xem xét cách tiếp cận sau:

TẠM THỜI đặt [master] Cơ sở dữ liệu đến TRUSTWORTHY ON

Đối với bước tiếp theo (tức là CREATE ASSEMBLY ) để thực thi thành công, Đăng nhập là chủ sở hữu cơ sở dữ liệu (tức là cùng một SID được sử dụng bởi [dbo] Người dùng của [master] ) cần phải có UNSAFE ASSEMBLY sự cho phép. Nếu [master] thuộc sở hữu của sa hoặc bất kỳ sysadmin nào khác, thì nó có tất cả các quyền và yêu cầu này đã được đáp ứng. Nhưng, nếu [master] được sở hữu bởi thông tin đăng nhập có đặc quyền thấp ("phương pháp hay nhất"), khi đó bạn sẽ cần thực hiện câu lệnh sau để CREATE ASSEMBLY hoạt động khi TRUSTWORTHY ON :
```
EXEC (N'USE [master]; GRANT UNSAFE ASSEMBLY TO [{DB_Owner_Login}];');
```
Tạo Assembly trong [master]
Tạo Khóa không đối xứng từ Assembly
Bỏ hội
đặt [master] Cơ sở dữ liệu thành TRUSTWORTHY OFF
Tạo thông tin đăng nhập từ Khóa không đối xứng
Cấp UNSAFE ASSEMBLY vào Đăng nhập đó (điều này thay thế nhu cầu về DB nơi Assembly được tải phải được đặt thành TRUSTWORTHY ON và cho chủ sở hữu của nó Đăng nhập để có UNSAFE ASSEMBLY cho phép).

Xin lưu ý rằng tôi đã không bao gồm tính năng "Hội đồng đáng tin cậy" mới như một tùy chọn tại đây. Lý do nó không được đề cập là do nó có nhiều sai sót hơn là lợi ích, chưa kể nó hoàn toàn không cần thiết ngay từ đầu vì chức năng hiện có đã xử lý tình huống "Trusted Assemblies" được dùng để giải quyết. Để biết chi tiết đầy đủ về điều đó và bản trình diễn về cách thích hợp để xử lý các tập hợp hiện có, chưa được chỉ định, vui lòng xem:SQLCLR so với SQL Server 2017, Phần 4:“Tập hợp đáng tin cậy” - Sự thất vọng.