Cách từ chối quyền truy cập vào SQL Server để đăng nhập nhất định qua SSMS, nhưng cho phép qua Nhà cung cấp dữ liệu .Net SqlClient

Chúng tôi có một tình huống mà Nhà phát triển không có bất kỳ UPDATEquyền nào , NHƯNG họ làm việc với các ứng dụng và xem các chuỗi kết nối -> họ biết mật khẩu từ một số tài khoản SQL (ví dụ SQLLogin1) có quyền CẬP NHẬT. Hoạt động của chúng tôi hiện không hoàn hảo và đôi khi dữ liệu sản xuất cần được sửa đổi (chưa có GUI cho điều đó).

Thay vì liên hệ với DBA và yêu cầu anh ta sửa đổi dữ liệu, Nhà phát triển sẽ (sử dụng không đúng cách) sử dụng tài khoản SQL SQLLogin1(có quyền sửa đổi dữ liệu) và kết nối qua SQL Server Management Studio để tự sửa đổi dữ liệu.

DBA không thể thay đổi mật khẩu SQLLogin1mà không có Nhà phát triển thấy chuỗi kết nối mới và mật khẩu mới, vì chuỗi kết nối ứng dụng SQLLogin1được Nhà phát triển duy trì.

Câu hỏi:

Có cách nào để từ chối quyền truy cập vào SQLLogin1đăng nhập SQL, nhưng chỉ khi nó được kết nối qua SSMS?

Đồng thời nếu SQLLogin1kết nối qua .Net SqlClient Data Provider( program_nametrong sys.dm_exec_sessions), nó phải được phép đăng nhập.

Bằng cách này, chúng tôi muốn không cho Nhà phát triển kết nối qua SSMS bằng cách sử dụng SQLLogin1, trong khi ứng dụng đang sử dụng SQLLogin1, vẫn có thể kết nối.

Bạn có thể sử dụng trình kích hoạt đăng nhập máy chủ để xác thực đăng nhập tùy chỉnh và từ chối chúng bất cứ khi nào bạn thấy phù hợp. Bạn sẽ thấy trình kích hoạt này được liệt kê bên dưới "Đối tượng máy chủ" và bên trong "Kích hoạt" nếu bạn đang sử dụng SSMS.

Ví dụ:

CREATE TRIGGER strRejectSSMSConnectionForSQLLogin1
ON ALL SERVER FOR LOGON
AS
BEGIN

    IF ORIGINAL_LOGIN() = N'SQLLogin1' AND PROGRAM_NAME() LIKE N'Microsoft SQL Server Management Studio%'
    BEGIN
        RAISERROR('Direct connection by SSMS refused.', 16, 1)
        ROLLBACK
    END

END

Trình ROLLBACKkích hoạt bên trong sẽ từ chối kết nối (có một giao dịch ngầm bao trùm cuộc gọi đến trình kích hoạt trong sự kiện đăng nhập).

Hãy cẩn thận khi thực hiện các kích hoạt đăng nhập, nếu không được mã hóa đúng cách, bạn sẽ từ chối các thông tin đăng nhập có thể đăng nhập (bao gồm cả thông tin của riêng bạn!). Hãy chắc chắn để kiểm tra trên môi trường test / dev trước.

Hãy nhớ rằng mã này được thực thi trước khi phiên được tạo , do đó, các chế độ xem hệ thống dựa trên id phiên (SPID) sẽ không chứa thông tin đăng nhập được kiểm tra hiện tại cho đến khi kích hoạt kết thúc mà không quay trở lại hoặc thất bại đủ cao.

Tôi nghĩ rằng không có giải pháp đáng tin cậy cho vấn đề của bạn vì Application Namecó thể thay đổi parameterrằng cam được thay đổi bởi bất kỳ người dùng nào.

Đây là cách thay đổi nó trong SSMS:

Trong Connect to Database Objecthộp thoại chọn Tùy chọn, mở Additional Connection Parametersvà chọn bất kỳ tên nào Application Namenhư thế này:

Bây giờ sys.dm_exec_sessionsDMV và Program_name () sẽ hiển thị cho bạn những gì bạn đã truyền trong chuỗi kết nối của mình trong Application Nametham số:

Bạn không thể cắt đứt một khách hàng cụ thể, như đã được nêu chi tiết trong các câu trả lời khác.

Giải pháp là loại bỏ các đặc quyền truy cập vào các hệ thống sản xuất khỏi tài khoản của nhà phát triển.

Mọi thay đổi phải được viết kịch bản và một dba sẽ chạy kịch bản.

Triển khai được thực hiện bởi một sysadmin; nhà phát triển sản xuất một gói họ cung cấp cho người có đặc quyền phù hợp và nhà phát triển không bao giờ thấy các cấu hình được sử dụng trên các hệ thống sản xuất.

Gỡ lỗi được sắp xếp theo từng trường hợp với một bản sao của dữ liệu sản xuất trong môi trường dàn dựng như một giải pháp ưa thích hoặc một tài khoản tạm thời với các đặc quyền hạn chế nếu cần.

1. Theo nghĩa lý tưởng, đây là một vấn đề quy trình / chính sách / quản lý. Ngay cả khi ai đó biết mật khẩu, nếu đó là trái với chính sách của công ty đối với bất kỳ ai trừ DBA để kết nối với Sản xuất (tốt, bạn có thể có một nhóm Kỹ thuật phát hành và / hoặc quản trị viên hệ thống, v.v.), và có các hình phạt cho việc vi phạm quy tắc, thì đó nên là đủ (giả định rằng quy định như vậy được thực thi).

2. Cố gắng ngăn chặn một ứng dụng cụ thể kết nối là không thể. Như sepupic đã chứng minh , khá dễ dàng để thay đổi "tên chương trình". Nhưng ngay cả khi nhà phát triển không thể tìm ra điều đó, có rất nhiều chương trình khác có thể kết nối với SQL Server. Hầu hết mọi người sẽ có quyền truy cập vào SQLCMD.exe và thậm chí cả OSQL.exe không dùng nữa . Nhà phát triển có thể kết nối từ bên trong Visual Studio và thậm chí họ có thể tạo ứng dụng của riêng mình để kết nối thông qua ".Net SqlClient Data Carrier". Ồ, và bây giờ chúng tôi thậm chí còn có Azure Data Studio. Nó quá nhiều.

3. Tuy nhiên, điều này vẫn có thể xảy ra nếu chúng ta tiếp cận nó từ hướng khác: thay vì ngăn ứng dụng X kết nối, làm thế nào chỉ cho phép ứng dụng Y kết nối? Chắc chắn, chúng ta lại vào "tên chương trình" và thậm chí "tên máy chủ" có thể bị giả mạo, NHƯNG, tôi khá chắc chắn rằng Địa chỉ IP của khách hàng không thể bị giả mạo (ít nhất là không thông qua các từ khóa chuỗi kết nối). Bạn biết Địa chỉ IP của (các) máy chủ ứng dụng hoặc có thể dễ dàng tìm thấy nó từ sys.dm_exec_connectionsDMV (trong client_net_addresstrường).

   Bắt đầu với Trình kích hoạt đăng nhập do EzLo đề xuất , chúng tôi có thể sửa đổi logic xác định xem kết nối có hợp lệ hay không như sau:

   IF (ORIGINAL_LOGIN() = N'SQLLogin1'
       AND (
                CONVERT(VARCHAR(10), CONNECTIONPROPERTY('net_transport')) <> 'TCP'
             OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address')) <> '10.10.10.10'
    -- uncomment below (and comment-out line above) if app uses multiple IP addresses
    --       OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address'))
    --                   NOT IN ( '10.10.10.10', '10.10.10.11', ...)
           ))
   BEGIN
       RAISERROR('Non-application connection refused.', 16, 1);
       ROLLBACK;
   END;

   Cách duy nhất bây giờ là đăng nhập vào máy Sản xuất hoặc để máy trạm của họ giả mạo IP của máy chủ ứng dụng. Hy vọng các nhà phát triển không có quyền truy cập để đăng nhập vào Sản xuất. Và việc giả mạo một IP hiện có trên mạng gây ra các vấn đề có thể ảnh hưởng xấu đến Sản xuất, vì vậy họ sẽ không thử điều đó, phải không? Đúng?

Trước đây tôi đã làm việc cho một công ty có vấn đề này với một nhà phát triển. Anh ta đã bị sa thải, nhưng chúng tôi cũng đã triển khai một bảng có Tên đăng nhập và allowMachine (Máy chủ ứng dụng) thông qua Trình kích hoạt đăng nhập. Điều này giải quyết vấn đề của chúng tôi. Hoặc có thể đó là do vụ nổ súng.