Thực hiện thủ tục lưu trữ truy cập vào một cá thể SQL khác


8

Tôi xin lỗi nếu câu hỏi này lặp lại câu hỏi khác đã được hỏi. Tôi đã tìm kiếm trong nhiều giờ và không tìm thấy cái nào phù hợp với hoàn cảnh của tôi.

Kết quả mong muốn

Một người dùng sử dụng xác thực SQL đã thực thi quyền đối với Database1 trên Server1 (ví dụ mặc định) và đó là nó. Người dùng thực thi một thủ tục được lưu trữ, như một phần của quy trình, truy cập Cơ sở dữ liệu 2 trên Server1 \ Instance2. Tôi muốn nó được an toàn và đơn giản (cả hai đều quan trọng).

Thêm thông tin

Thông tin đăng nhập windows của tôi có quyền truy cập vào cả hai phiên bản (trên cùng một máy chủ). Do đó, tôi có thể thực hiện các thủ tục được lưu trữ dưới đăng nhập của mình mà không gặp khó khăn. Tuy nhiên, tôi không muốn cung cấp cho người dùng mức độ truy cập của mình. Tôi cũng cần sử dụng thông tin đăng nhập SQL vì người dùng sẽ không ở trên miền.

Những gì tôi muốn là cung cấp cho thủ tục được lưu trữ mức độ truy cập của tôi chỉ cho thủ tục đó. Vì tôi là một sysadmin, điều đó sẽ cung cấp cho người dùng mọi thứ họ cần cho thủ tục đó. Nếu tôi làm được điều đó, có lẽ tôi sẽ tạo một tài khoản chỉ với mục đích đó thay vì sử dụng tài khoản của tôi, nhưng bằng cách nào đó nó sẽ an toàn vì tôi kiểm soát những gì mà Proc lưu trữ làm.

Tôi đã thử đặt câu lệnh "VỚI EXECUTE AS" trong kho lưu trữ của mình nhưng tôi không thể lấy nó để lấy thông tin đăng nhập windows của mình. Khi tôi đặt nó vào, tôi sẽ gặp lỗi sau khi biên dịch Proc được lưu trữ:

Không thể thực thi dưới dạng 'domain \ jdoe' của người dùng, vì nó không tồn tại hoặc bạn không có quyền.

Người dùng là sysadmin trên cả hai máy chủ, như tôi đã nói, vì vậy tôi không chắc nó cần thêm gì nữa.

Tôi đã xem xét như sau:

  • TRUSTED - Tôi thà không để lộ cơ sở dữ liệu của mình và điều này có vẻ đáng sợ
  • Máy chủ được liên kết - Tôi không muốn cấp thêm quyền. Tôi không tin tưởng cơ sở dữ liệu khác có quyền truy cập vào cơ sở dữ liệu của mình và tôi không tin cơ sở dữ liệu của mình có quyền truy cập vào tất cả các cơ sở dữ liệu khác.
  • Chứng chỉ - Điều này có vẻ phức tạp và khó khăn. Trừ khi tôi có thể tìm ra một cách rất đơn giản để làm điều này và duy trì nó, tôi không chắc nó có giá trị rắc rối không.
  • Quyền sở hữu xích - Một lần nữa, đáng sợ. Có vẻ như điều này gây ra nhiều vấn đề bảo mật hơn khi mục tiêu của tôi là ngăn chặn các vấn đề bảo mật.
  • Người dùng được nhân đôi - Tôi thậm chí đã tạo cùng một người dùng (rõ ràng là SID khác nhau) trên phiên bản máy chủ khác và cung cấp cho nó cùng một mật khẩu. Không đi.

Tôi cảm thấy như tôi đang thiếu một cái gì đó rõ ràng nhưng tôi không chắc nó là gì. Vì tôi đã đập đầu vào tường cả ngày về điều này, có lẽ tôi đã quá gần để nhìn thấy nó. Tôi sẽ rất trân trọng điều đó nếu ai đó ở đây có thể giúp tôi hoặc chỉ cho tôi đi đúng hướng. Tôi sẽ nói rằng tôi đã đọc rất nhiều bài báo MSDN (cậu bé tôi ghét chúng - dường như chúng không bao giờ nói với tôi những gì tôi muốn biết). Những gì tôi thực sự muốn là một hướng dẫn đơn giản, dễ làm theo hướng dẫn tôi làm thế nào để làm điều này. Nói tóm lại, ngay cả một chỉ dẫn chung về hướng tôi cần đi cũng sẽ hữu ích.

Câu trả lời:


3

Thay vào đó, hãy thử sử dụng EXECUTE AS LOGIN = 'DOMAIN \ username' và xem điều đó có hiệu quả không.


Tôi đã thử điều đó nhưng rõ ràng lệnh đó không được thiết kế cho bên trong một thủ tục được lưu trữ.
IAmTimCorey

Nó sẽ hoạt động tốt trong một thủ tục được lưu trữ. Tài khoản của bạn đã được đăng nhập riêng hay bạn có được quyền của mình thông qua tư cách thành viên nhóm không?
mrdenny

Tài khoản của tôi có thông tin đăng nhập riêng, có quyền sysadmin. Nó cũng có quyền Quản trị viên tên miền thông qua thành viên nhóm, do đó sẽ cung cấp cho tôi mọi thứ tôi cần và nó sẽ hoạt động khi tôi đăng nhập bằng thông tin đăng nhập Windows của mình. Tuy nhiên, tôi phát hiện ra hai điều. Đầu tiên, nếu tôi sử dụng mã trên của bạn trong câu lệnh VỚI của một Proc được lưu trữ, nó sẽ cho tôi một lỗi cú pháp. Nếu tôi đặt nó trong một câu lệnh, nó sẽ hoạt động bên trong một thể hiện nhưng không phải là thể hiện chéo.
IAmTimCorey

3

Hãy xem sử dụng EXECUTE AS+ Đáng tin cậy. Bạn có thể thiết lập nó ở nơi nó có thể được gọi trong thủ tục được lưu trữ miễn là người dùng b đã được cấp quyền truy cập và hai cơ sở dữ liệu tin tưởng lẫn nhau.

Blog này nên trả lời hoặc cung cấp mọi thứ bạn cần. http://www.sommarskog.se/grantperm.html#EXECAScrossdb

việc sử dụng thuộc tính cơ sở dữ liệu TRUSTWORTHY để kiểm soát truy cập vào các tài nguyên ngoài phạm vi của cơ sở dữ liệu nguồn

http://msdn.microsoft.com/en-us/l Library / ms188304% 28v = sql.90% 29.aspx


Vấn đề tôi thấy với điều đó là Đáng tin cậy thiết lập mối quan hệ tin cậy giữa hai cơ sở dữ liệu. Điều này có thể được khai thác bởi sysadmin ở hai bên. Tôi không muốn điều này. Tôi đang cố gắng giới hạn quyền mà một người có. Nếu cuối cùng tôi cho người khác nhiều quyền hơn, đó sẽ không phải là điều tốt. Cảm ơn mặc dù.
IAmTimCorey

Lưu ý ở đây rằng các chủ sở hữu cá nhân không phải là người thật, nhưng đó có thể là thông tin đăng nhập chung cho mỗi cơ sở dữ liệu. Bạn không phải cấp toàn bộ cơ sở dữ liệu. Nếu bạn không tin tưởng các hệ thống trên cơ sở dữ liệu khác thì hãy nhấn vào việc ký chứng chỉ.
SoftwareCarpenter

Bạn đã đề cập rằng bạn đã xem qua liên kết sommarskog.se/grantperm.html trong câu trả lời của bạn dưới đây. Đó là cùng một blog tôi đã đăng trong câu trả lời tôi đề nghị. "Blog của những người này nên trả lời hoặc cung cấp mọi thứ bạn cần. Sommarskog.se/grantperm.html#EXECAScrossdb " Có lẽ bạn chỉ đang giới thiệu lại cho người khác. Tôi đồng ý nó là một blog tốt và đọc. Chúc may mắn!
Phần

Vâng, xin lỗi tôi quên nói rằng liên kết đến từ bạn. Đó là một nguồn tài nguyên tốt. Cảm ơn bạn đã giúp đỡ.
IAmTimCorey

2

Sau khi đọc nhiều về chủ đề và thực hiện một số thí nghiệm, tôi tin rằng tôi đã đi đến kết luận về vấn đề này. Câu lệnh EXECUTE AS không được thiết kế để hoạt động xuyên suốt mà không có ý nghĩa bảo mật chính. Điều tôi đã hy vọng là một cách để nói cho thủ tục của tôi biết danh tính Windows nào tôi muốn chạy, vì một danh tính Windows có thể có quyền truy cập vào nhiều tài nguyên trên nhiều máy chủ. Tuy nhiên, ngay cả sau khi chơi xung quanh với một loạt các cài đặt khác nhau, rõ ràng là tôi sẽ phải làm suy yếu các biện pháp bảo mật khác để cho phép một thủ tục được lưu trữ để mạo danh tôi.

Dường như không có nhiều thông tin về các thủ tục máy chủ chéo hoặc máy chủ chéo. Tôi sẽ tưởng tượng lý do cho điều này là vì ý nghĩa bảo mật và hiệu suất của việc làm này. Tuy nhiên, tôi tin rằng có những trường hợp quan trọng và có vẻ như các giải pháp để làm như vậy rất phức tạp và rất cụ thể theo kịch bản. Tôi đã xem qua một bài viết hay giúp tôi ít nhất hiểu một số lựa chọn của tôi. Nó không tập trung vào truy cập chéo, nhưng nó đã cho tôi manh mối mà tôi đang tìm kiếm. Tôi sẽ khuyến khích bạn kiểm tra xem nó:

http://www.sommarskog.se/grantperm.html

Tôi vẫn sẽ quan tâm đến các giải pháp khác cho vấn đề này, nhưng giải pháp của tôi ngay bây giờ là hai lần. Đầu tiên, nếu tôi thực sự cần truy cập hai cơ sở dữ liệu thông qua một thủ tục được lưu trữ, tôi phải sử dụng thông tin đăng nhập Windows. Tuy nhiên, tôi tránh điều này bất cứ khi nào có thể vì nó gây ra các vấn đề về hiệu năng (khóa đa máy chủ, biến chứng mạng, không thể tối ưu hóa truy vấn, v.v.) Thứ hai, tôi mang dữ liệu từ mỗi cơ sở dữ liệu thông qua các cuộc gọi riêng biệt, cơ sở dữ liệu. Điều đó có nghĩa là tôi mang dữ liệu trở lại máy khách trước khi hợp nhất nó. Nó không phải là hiệu suất hoặc sạch như tôi muốn, nhưng nó có vẻ là giải pháp an toàn nhất.


1

Nếu bạn cần truy cập các đối tượng cơ sở dữ liệu giữa hai Trường hợp máy chủ SQL, tôi sẽ đề xuất một trong các cách sau:

  1. Tạo và sử dụng Máy chủ được liên kết giữa hai phiên bản với quyền thích hợp để truy cập đối tượng trên đối tượng đích (từ xa).
  2. Sử dụng SSIS và gọi gói từ phiên bản nguồn của SQL Server. Tùy thuộc vào phiên bản SQL Server nào được sử dụng, bạn có thể có một công việc Tác nhân SQL (không lên lịch để chạy, nhưng được gọi bởi thủ tục được lưu trữ) hoặc sử dụng SSISDB để gọi gói SSIS sẽ truy cập đối tượng cơ sở dữ liệu trên cá thể từ xa.
  3. Di chuyển logic đến lớp giữa (hoặc phía ứng dụng khách)
  4. Tạo CLR để truy cập đối tượng cơ sở dữ liệu từ xa Trong số này có lẽ tôi sẽ sử dụng CLR để truy cập máy chủ cá thể từ xa và chạy thực thi thủ tục được lưu trữ. Bạn sẽ cần cấp tài khoản mà Sơ đồ máy chủ nguồn SQL chạy dưới quyền truy cập vào Trường hợp máy chủ SQL từ xa.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.