Як я можу перевірити параметри безпеки кінцевої точки SQL Server?

Я зараз створюю TEST-середовище для наших співробітників із розробки SQL Server.

У виробництві у нас є 3 сервери SQL, SQL01містить кілька баз даних, до яких відображено дзеркальне відображення SQL02. SQL03виступає свідком у "високій безпеці з автоматичним відмовою" або синхронною конфігурацією.

Я використовував VMWare P2V для віртуалізації всіх трьох машин на окремому апаратному забезпеченні, переконфігурувавши SID-машини машин та обробляв IP-адреси наших виробничих серверів з цих нових машин.

Я спочатку забув скрутити виробничу машину свідків, тому бази даних на машинах TEST все ще використовували цю SQL03машину як свідка. Помітивши проблему, я вирішив переналаштувати бази даних на TEST, щоб вказати на щойно віртуалізованого свідка TEST, викликати його TEST03.

Щоб перенастроїти базу даних для використання нового свідка, я ввів таку команду на первинному сервері TEST01:

ALTER DATABASE [TestDB] SET WITNESS = 'TCP://TEST03.domain.inet:5022';

Відповідь була несподіваною:

The ALTER DATABASE command could not be sent to the remote server instance
'TCP://TEST03.domain.inet:5022'.  The database mirroring configuration was
not changed.  Verify that the server is connected, and try again.

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

Для того, щоб це спрацювало, мені потрібно було створити LOGINтест-свідка:

CREATE LOGIN [DOMAIN\SQLServiceAccount] FOR WINDOWS WITH DEFAULT_DATABASE [Master];

і GRANTвоно має CONNECTправо на кінцеву точку, про яку йдеться:

GRANT CONNECT ON ENDPOINT::Mirroring TO [DOMAIN\SQLServiceAccount];

Тоді мені вдалося успішно вказати дзеркальні бази даних на середовищі TEST до нового свідка випробувань.

Як я можу перевірити кінцеву точку свідка виробництва, щоб побачити, яка безпека пов'язана з нею?

Я припускаю, що має бути якийсь системний каталог, який я можу перевірити, однак у "Книг он-лайн", здається, немає нічого конкретного для Кінцевих точок, і Bing добре, Bingless ...

Додаткова інформація:

SELECT ep.endpoint_id, p.class_desc, p.permission_name, ep.name, sp.name 
FROM sys.server_permissions p
    INNER JOIN sys.endpoints ep ON p.major_id = ep.endpoint_id
    INNER JOIN sys.server_principals sp ON p.grantee_principal_id = sp.principal_id
WHERE class = '105';

повертає:

endpoint_id class_desc  permission_name endpoint_name   principal_name
2           ENDPOINT    CONNECT TSQL    Local Machine   public
3           ENDPOINT    CONNECT TSQL    Named Pipes     public
4           ENDPOINT    CONNECT TSQL    Default TCP     public
5           ENDPOINT    CONNECT TSQL    Default VIA     public

І:

SELECT name, endpoint_id, protocol_desc, type_desc, role_desc 
FROM sys.database_mirroring_endpoints;

Повернення:

name        endpoint_id  protocol_desc  type_desc           role_desc 
Mirroring   65536        TCP            DATABASE_MIRRORING  WITNESS

Здається, що для sys.server_permissionsоб'єкта кінцевої точки дзеркального відображення немає запису . Ні major_idта немає minor_id65536. Також жодна із системних баз даних не містить посилань на кінцеву точку.

Я в збитку.

Провівши частину дня, займаючись переміщенням дзеркальних баз даних з сервера на сервер у нашому середовищі DEV, готуючись до нашого переходу на SQL Server 2012, я натрапив на цей документ MSDN, який пояснює, що безпека ENDPOINT визначається виключно залежно від типу облікового запису SQL Server працює під. Якщо SQL Server використовує доменний обліковий запис, він автоматично отримує доступ до кінцевої точки. Якщо SQL Server використовує вбудований акаунт, такий як [Мережева служба] або [Локальна система] тощо, то кінцева точка повинна бути налаштована сертифікатом безпеки, і лише власники сертифікату можуть отримати доступ до кінцевої точки.

Відповідний розділ документа:

Визначення типу аутентифікації для кінцевої точки дзеркального відображення бази даних

Важливо розуміти, що облікові записи служб SQL Server екземплярів вашого сервера визначають, який тип автентифікації ви можете використовувати для кінцевих точок дзеркального відображення вашої бази даних:

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

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

Якщо екземпляри вашого сервера використовують автентифікацію Windows, ви можете створити кінцеві точки дзеркального відображення в базі даних за допомогою Transact-SQL, PowerShell або майстра нової групи доступності.

Примітка:

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

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

Не існує автоматизованого методу налаштування захисту дзеркального відображення бази даних за допомогою сертифікатів. Вам потрібно буде використовувати або CREATE ENDPOINT Transact-SQL, або командлет New-SqlHadrEndpoint PowerShell. Для отримання додаткової інформації див. CREATE ENDPOINT (Transact-SQL).

Рем Русану (у своїй відповіді) правильно визначив, як визначити захист на місці, що відповідає дзеркальній кінцевій точці; як і в:

SELECT ep.name, sp2.name AS Grantee, sp.name AS Grantor, p.permission_name, ep.state_desc
FROM sys.server_permissions p 
    INNER JOIN sys.endpoints ep ON p.major_id = ep.endpoint_id
    INNER JOIN sys.server_principals sp ON p.grantor_principal_id = sp.principal_id
    INNER JOIN sys.server_principals sp2 ON p.grantee_principal_id = sp2.principal_id
WHERE p.class_desc = 'ENDPOINT' AND ep.type_desc = 'DATABASE_MIRRORING'

Однак у моєму випадку на SQL Server 2005 вихідні кінцеві точки дзеркального відображення не відображаються в результатах цього запиту - я припускаю, що це відбувається тому, що безпека за замовчуванням дозволяє CONNECT доступу до облікового запису, на якому працює SQL Server (як пояснено вище).

Отже, канонічна відповідь на запитання, як ви знаєте, хто має CONNECT доступ до ENDPOINT, - це сума запиту, наведеного вище, і використовує обліковий запис SQL Server разом з усіма можливими сертифікатами, які ви налаштували з доступом до кінцевої точки .

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

sys.dm_db_mirroring_connectionsповинні надати вам бажане. Він містить principal_name:

Ім'я логіна, підтвердженого для дозволів на з'єднання. Для автентифікації Windows це значення - ім'я віддаленого користувача. Для автентифікації сертифікатів це значення є власником сертифіката.

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

Дивіться документацію щодо Книг онлайн sys.database_mirroring_endpoints

Для дозволів об'єкта сервера ви дивитеся на звичайному місці, sys.server_permissions. Як і у будь-якому випадку, коли задіяна безпека Windows, все складніше через членство в групах Windows, і ви також повинні враховувати ієрархію дозволів .