Sử dụng vai trò sysadmin với EXECUTE AS


7

Theo hiểu biết của tôi, tôi có thể sử dụng EXECUTE AS OWNERmệnh đề như một phần của thủ tục mà tôi tạo để làm cho phần thân của thủ tục đó chạy như một người dùng khác. Mục tiêu của tôi là thực thi một lệnh yêu cầu sysadminvai trò ( DBCC TRACEON(1224)). Thủ tục này được cho là được gọi bởi một người dùng không có đặc quyền.

Tôi đã chạy đoạn script sau dưới sangười dùng:

SELECT USER_NAME(), USER_ID(), IsSysAdmin = IS_SRVROLEMEMBER('sysadmin')
-- dbo  1   1

IF EXISTS(SELECT * FROM sys.procedures WHERE name = 'MyProc')
    DROP PROCEDURE MyProc

GO
CREATE PROCEDURE MyProc
WITH EXECUTE AS OWNER
AS 
    SELECT USER_NAME(), USER_ID(), IsSysAdmin = IS_SRVROLEMEMBER('sysadmin');
-- dbo  1   0

    DBCC TRACEON(1224)
--Msg 2571, Level 14, State 3, Procedure MyProc, Line 7
--User 'dbo' does not have permission to run DBCC TRACEON.

RETURN
GO

EXEC MyProc

Đầu ra là nội tuyến trong ý kiến. Hóa ra bên ngoài thủ tục tôi dường như có sysadmintư cách thành viên, nhưng không phải bên trong thủ tục.

Thủ tục thuộc sở hữu của dbongười dùng. Tôi hiểu rằng không thể cấp sysadminvai trò cho người dùng cơ sở dữ liệu (ít nhất GUI không cung cấp khả năng này). Vì vậy, tôi không thấy làm thế nào tôi có thể làm cho người dùng cơ sở dữ liệu có vai trò máy chủ.

Tôi cũng đã thử EXECUTE AS 'sa'kết quả trong Cannot execute as the user 'sa', because it does not exist or you do not have permission.. Các tài liệu nói rằng tôi chỉ có thể chỉ định một tên người dùng, không phải là một tên đăng nhập. Vì vậy, tôi hiểu tại sao điều đó không làm việc.

Làm thế nào tôi có thể chạy thủ tục của tôi với sysadminvai trò thành viên?

Câu trả lời:


5

Nó có thể được thực hiện nhưng nó thường được coi là khá nguy hiểm. Ở mức rất cơ bản, bạn đặt trustworthycờ trên cơ sở dữ liệu và sau đó khi sử dụng bạn execute astrên sp, nó có thể tận dụng quyền truy cập bảo mật của máy chủ cấp độ máy chủ.

Vì điều này nguy hiểm đến mức nào nên tôi không muốn đi sâu vào chi tiết nào ở đây. Tuy nhiên tôi đã viết blog về nó ở đây với các hướng dẫn cụ thể về cách thực hiện.

Tất cả những gì đang được nói chắc chắn rằng bạn hoàn toàn NEEDlàm theo cách này. Bạn đang mở một lỗ hổng bảo mật lớn. Nếu bạn quyết định làm điều đó, hãy đặt SP của bạn vào cơ sở dữ liệu của chính nó và chỉ cấp cho người dùng kết nối và thực thi quyền truy cập vào sp.


Bài viết của bạn mô tả một cách để có thủ tục trong cơ sở dữ liệu mới. Rằng sẽ làm việc. Nó vẫn còn "nguy hiểm" khi làm điều đó? Dường như nhận được cấu hình đúng với một cơ sở dữ liệu riêng biệt không phải là liên quan.
usr

1
Đưa sp vào DB mới chắc chắn là ít nguy hiểm nhất. Điều nguy hiểm ở đây thực sự là đến một lúc nào đó, ai đó sẽ gây rối và cấp cho ai đó db_owner của cơ sở dữ liệu đó. Điều đó sẽ mang lại cho họ sysadmin một cách hiệu quả nếu họ biết cách làm điều đó. Tôi nghĩ (chưa được thử nghiệm) bạn thậm chí có thể làm điều đó với CREATE PROCEDUREvà mạo danh quyền. Bây giờ nó không có quá nhiều rủi ro nhưng rủi ro sau khi mọi người đã quên tại sao bạn lại tạo một db riêng biệt ngay từ đầu.
Kenneth Fisher

6

Mục tiêu của tôi là thực thi một lệnh yêu cầu vai trò sysadmin (DBCC TRACEON (1224))

Bạn đang đục một lỗ hổng trong bảo mật của mình bằng cách cho phép người dùng không có đặc quyền chạy như vai trò sysadmin.

Nếu bạn đang cố gắng thiết lập dấu 1224vết, điều này vô hiệu hóa việc leo thang khóa dựa trên số lượng khóa, bạn có thể thực hiện ở cấp độ bảng bằng cách sử dụngALTER TABLE

ví dụ: Dưới đây cho phép khóa leo thang đến mức phân vùng trên bảng được phân vùng. Nếu bảng không được phân vùng, khóa thang được đặt ở mức BẢNG.

ALTER TABLE dbo.T1 SET (LOCK_ESCALATION = AUTO); - các tùy chọn hợp lệ là AUTO, TABLE và DISABLE

Bây giờ bạn chỉ có thể cung cấp cho người dùng unpreviledge thay đổi quyền bảng.

HTH


Đây là một mẹo hay cho cờ theo dõi cụ thể này , nhưng không phải cho cờ theo dõi nói chung. Ngoài ra, nếu bạn muốn ngăn người dùng thực hiện các hoạt động thay đổi bảng khác, bạn có thể có trình kích hoạt DDL để nắm bắt ALTER_TABLEvà kiểm tra chính xác những gì họ đang làm trước khi cho phép nó xảy ra (tốt hơn, chính xác hơn, trước khi không quay lại).
Aaron Bertrand

Đây là một giải pháp khả thi đối với tôi vì thực tế là có vẻ rủi ro khi thực hiện quyền bảo mật. Có lẽ tôi sẽ sử dụng cái này. Cảm ơn! Điều đó nói rằng, tôi sẽ chấp nhận câu trả lời trả lời tốt nhất phần bảo mật của câu hỏi này.
usr

@AaronBertrand đồng ý rằng điều này chỉ dành cho cờ 1224 theo dõi này vì cờ theo dõi này hoạt động ở cấp độ bảng. Tôi đã viết câu trả lời này khi nhìn vào định nghĩa cờ theo dõi, nó có thể được kích hoạt thay thế bằng Bảng thay đổi .
Kin Shah

0

Tạo một công việc SQL Server Agent (thuộc sở hữu của một thành viên sysadmin) sẽ thực hiện thủ thuật này, mặc dù tôi nhận ra rằng đây không phải là một giải pháp rất hay.

Người dùng có thể bắt đầu công việc (không đồng bộ) bằng msdb.dbo.sp_start_job. Tuy nhiên, việc chạy một tác nhân Tác nhân đồng bộ đòi hỏi một vài dòng mã nếu đây là một yêu cầu. Ngoài ra, rõ ràng, bạn cần phải có dịch vụ SQL Server Agent hoạt động.


Tôi yêu cầu cờ theo dõi được đặt trong phiên hiện tại trên một kết nối cụ thể. Tôi không muốn kích hoạt nó trên toàn cầu.
usr

Xin lỗi, đã không nhận ra nó là phiên cụ thể.
Daniel Hutmacher
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.