Як заборонити доступ до SQL Server до певного входу через SSMS, але дозволити більше .Net SqlClient Provider Data

У нас ситуація, коли розробники не мають UPDATEдозволів, АЛЕ вони працюють з програмами та бачать рядки підключення -> вони знають паролі з деяких облікових записів SQL (приклад SQLLogin1), які мають дозволи на оновлення. Наші операції в даний час не є досконалими, а іноді виробничі дані потрібно змінювати (для цього ще немає графічного інтерфейсу).

Замість того, щоб звертатися до DBA і просити його змінити дані, розробник (неналежним чином) використовує обліковий запис SQL SQLLogin1(який має дозвіл на зміну даних) та підключиться через студію управління SQL Server для зміни самих даних.

DBA не може змінити пароль SQLLogin1без того, щоб розробник побачив новий рядок з'єднання та новий пароль, оскільки рядок підключення програми, яку використовує SQLLogin1, підтримує розробник.

Питання:

Чи є спосіб заборонити доступ до SQLLogin1входу в SQL, але тільки якщо він підключається через SSMS?

У той же час, якщо SQLLogin1підключення закінчується .Net SqlClient Data Provider( program_nameв sys.dm_exec_sessions), воно повинно бути дозволено ввійти.

Таким чином ми хочемо не дозволяти Developer підключатися через SSMS SQLLogin1, хоча програма, яка використовується SQLLogin1, все ще зможе підключитися.

Ви можете використовувати тригер входу в сервер, щоб зробити власні перевірки входу та відхилити їх, коли вважаєте за потрібне. Цей тригер ви побачите в списку "Об'єкти сервера" та "Тригери", якщо ви використовуєте SSMS.

Наприклад:

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

ROLLBACKУсередині тригера буде відкидати з'єднання (є неявна транзакція обгорткового виклик тригера на події входу в систему).

Будьте обережні при впровадженні тригерів для входу, якщо їх не закодовано належним чином, ви будете відхиляти входи, які повинні мати можливість увійти (включаючи свій власний!). Переконайтесь, що спершу перевірити тест / розробку.

Майте на увазі, що цей код виконується до створення сеансу , тому системні представлення, що спираються на ідентифікатор сеансу (SPID), не будуть містити перевірений в даний момент вхід, доки тригери не завершаться без відкату або недостатньо високого збою.

Я думаю, що немає надійного рішення для вашої проблеми, оскільки вона Application Nameможе змінюватися, parameterщоб камеру міняв будь-який користувач.

Ось як це змінити в межах SSMS:

У Connect to Database Objectдіалоговому вікні виберіть «Параметри», відкрийте Additional Connection Parametersта оберіть будь-яке ім’я Application Name:

Тепер sys.dm_exec_sessionsDMV та Program_name () покажуть вам, що ви передали в рядку з'єднання в Application Nameпараметрі:

Ви не можете відрізати конкретного клієнта, як уже детально описано в інших відповідях.

Рішення полягає у видаленні привілеїв доступу до виробничих систем із облікових записів розробника.

Будь-яка зміна має бути сценарієм, і сценарій запустить dba.

Розгортання виконується систематиком; devs виробляє пакет, який вони дарують комусь із належними привілеями, і devs ніколи не бачить конфігурації, які використовуються у виробничих системах.

Налагодження влаштовується в кожному конкретному випадку з копією виробничих даних у стадійному середовищі як бажане рішення або тимчасовий рахунок з обмеженими привілеями, якщо це необхідно.

1. В ідеальному розумінні це питання процесу / політики / управління. Навіть якщо хтось знає пароль, якщо він суперечить політиці компанії, щоб хтось, окрім DBA, підключався до виробництва (ну, можливо, у вас є команда Release Engineering та / або системні адміністратори тощо), і за порушення правил є штрафні санкції, то цього має бути достатньо (якщо припустити, що такі правила виконуються).

2. Намагатися запобігти підключенню конкретної програми неможливо. Як показав sepupic , змінити "назву програми" досить просто. Але навіть якщо розробник не може цього зрозуміти, існує багато інших програм, які можуть підключитися до SQL Server. Більшість людей матимуть доступ до SQLCMD.exe і навіть застарілого OSQL.exe . Розробник може з'єднатися з Visual Studio, і вони навіть можуть створити власний додаток для підключення через ".Net SqlClient Provider Data". О, і зараз у нас навіть є Studio Azure Data Studio. Просто занадто багато.

3. Але все-таки це може бути можливим, якщо ми підійдемо до нього з іншого напрямку: замість того, щоб не допускати з'єднання програми X, як щодо того, щоб дозволити додатку Y підключатися? Звичайно, ми знову потрапляємо в "ім'я програми", і навіть "ім'я хоста" можна підробляти, але НЕ я впевнений, що IP-адресу клієнта не можна підробляти (принаймні, не через ключові слова рядка з'єднання). Ви знаєте IP-адресу серверів додатків або можете їх легко знайти в sys.dm_exec_connectionsDMV (у client_net_addressполі).

   Починаючи з тригера входу, запропонованого EzLo , ми можемо змінити логіку, яка визначає, чи є з'єднання дійсним чи не таким:

   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;

   Єдиним способом в даний час було б або увійти на виробничу машину, або підключити їх робочу станцію до IP-сервера додатків. Сподіваємось, у розробників немає доступу для входу у Виробництво. А підробка існуючого IP-адреси в мережі спричиняє проблеми, які можуть негативно вплинути на виробництво, тому вони не будуть цього намагатися, правда? Правильно?

Раніше я працював у компанії, яка мала цю проблему з одним розробником. Його звільнили, але ми також застосували таблицю, в якій було ім’я для входу та AllowedMachine (сервер додатків) через тригер входу. Це вирішило наші проблеми. А може, це було через стрілянину.