У цій статті ми розглянемо засоби SQL Server для забезпечення безпеки і кращі практики, пов'язані з налаштуванням і забезпеченням безпеки в цій СУБД.
зміст:
- Аутентифікація в SQL Server
- Авторизація в SQL Server
- ролі додатків
- Фільтрація даних в SQL Server
- Схеми в SQL Server
- Шифрування даних засобами SQL Server
- Використання Group Managed Service Accounts для SQL Server
- Оцінка вразливостей SQL Server через SSMS
- Аудит активності в SQL Server
- Загальні рекомендації з безпеки SQL Server
Для початку згадаємо базові концепції безпеки SQL Server. MSSQL управляє доступом до об'єктів через аутентифікацію і авторизацію.
- аутентифікація - це процес входу в SQL Server, коли користувач відправляє свої дані на сервер. Аутентифікація встановлює особу користувача, який проходить аутентифікацію;
- авторизація - це процес визначення того, до яких захищених об'єктів може звертатися користувач, і які операції дозволені для цих ресурсів.
Багато об'єктів SQL Server мають свої дозволи, які можуть успадковуватися від вищого об'єкта. Дозволи можуть бути надані окремому користувачеві, групі або ролі.
Аутентифікація в SQL Server
Аккаунт SQL Server можна розділити на 2 частини: ім'я входу і Користувач.
- ім'я входу - це глобальний логін для всього примірника SQL Server. За допомогою нього ви проходите процес аутентифікації;
- Користувач - це учасник бази даних, прив'язаний до певного Імені Входу.
Наприклад, ваше ім'я входу на сервер може бути domain \ username, а користувач в базі даних, прив'язаний до цього імені входу може називатися domain_databaseUser. Практично завжди ім'я входу і користувач в базі даних збігаються за назвою, але потрібно мати на увазі що вони можуть і різнитися, мати різні імена.
SQL Server підтримує 2 режиму аутентифікації:
- аутентифікація Windows (Windows Authentication) - аутентифікація здійснюється за допомогою системи безпеки Windows. Користувачам, які вже автентифіковано в Windows і мають права на SQL Server не потрібно надавати додаткові облікові дані.
- Змішаний режим аутентифікації (Mixed Mode Authentication) - в цьому режимі крім аутентифікації Windows підтримується аутентифікація самого SQL Server через логін і пароль.
Microsoft рекомендує використовувати аутентифікацію Windows, якщо є така можливість. Для аутентифікації за допомогою логіна і пароля, дані (логін і пароль) передаються по мережі, хоч і в зашифрованому вигляді. При Windows аутентифікації по мережі передається серія зашифрованих повідомлень, в яких не бере пароль користувача.
Але деякі програми, особливо старі, не підтримують аутентифікацію Windows, тому при установці режиму аутентифікації варто враховувати які програми будуть підключатися до сервера.
SQL Server підтримує три типи Login Name (Імен входу):
- Локальна обліковий запис користувача Windows або обліковий запис домену/ Довіреної домену.
- Група Windows. Надання доступу локальної групі Windows або групі з AD домену. Дозволяє надати доступ до всіх користувачів, які є членами групи.
- Логін SQL Server (SQL Server authentication). SQL Server зберігає ім'я користувача та хеш пароля в базі даних master, використовуючи методи внутрішньої аутентифікації для перевірки входу в систему.
SQL Server автоматично інтегрується з Active Directory. Якщо ви хочете роздати права доменної облікового запису, вам потрібно використовувати NetBios ім'я домену та логін облікового запису. Наприклад для користувача username в домені domain.local буде вірним "domain \ username".
Авторизація в SQL Server
Для авторизації SQL Server використовує безпеку на основі ролей, яка дозволяє призначати дозволу для ролі або групи Windows / домену, а не окремим користувачам. У SQL Server є вбудовані ролі сервера і баз даних, у яких є визначений набір дозволів.
У SQL Server є 3 рівня безпеки, їх можна уявити, як ієрархію від вищого до нижчого:
- рівень сервера - на цьому рівні можна роздати права на бази даних, облікові записи, ролі сервера і групи доступності;
- Рівень бази даних включають в себе схеми, користувачі бази даних, ролі бази даних і повнотекстові каталоги;
- рівень схеми включають такі об'єкти, як таблиці, уявлення, функції і процедури.
Вбудовані ролі сервера
| роль | опис |
| sysadmin | Учасник ролі має повні права до всіх ресурсів SQL Server. |
| serveradmin | Учасники ролі можуть змінювати параметри конфігурації на рівні сервера і вимикати сервер. |
| securityadmin | Учасники ролі керують логінами і їх властивостями. Вони можуть надавати права доступу GRANT, DENY і REVOKE на рівні сервера і на рівні бази даних, якщо мають до неї доступ. securityadmin мало чим відрізняється від ролі sysadmin, тому що учасники цієї ролі потенційно можуть отримати доступ до всіх ресурсів SQL Server. |
| processadmin | Учасники ролі можуть завершувати процеси, запущені в SQL Server. |
| setupadmin | Учасники ролі можуть додавати і видаляти пов'язані сервери за допомогою TSQL. |
| bulkadmin | Учасники ролі можуть запускати BULK INSERT операції. |
| diskadmin | Учасники ролі можуть управляти пристроями резервного копіювання. На практиці ця роль практично не застосовується. |
| dbcreator | Учасники ролі можуть створювати, змінювати, видаляти і відновлювати бази даних. |
| public | Кожен логін SQL Server знаходиться в цій ролі. Змінити членство public не можна. Коли у користувача немає дозволу для об'єкта, до якого він отримує доступ, користувач успадковує дозволи public ролі для цього об'єкту. |
Схема ролей SQL Server:
На практиці використання серверних ролей не особливо поширене, тому що часто користувачеві потрібен унікальний набір дозволів. Винятком можуть бути роль sysadmin для системних адміністраторів і роль public.
Вбудовані ролі бази даних
| роль | опис |
| db_owner | Учасники ролі можуть виконувати всі дії по налаштуванню і обслуговуванню бази даних, включаючи видалення. |
| db_securityadmin | Учасники ролі можуть змінювати членство інших ролей. Учасники цієї групи потенційно можуть збільшити свої права до db_owner, тому варто вважати цю роль еквівалентної db_owner. |
| db_accessadmin | Учасники ролі можуть управляти доступом до бази даних для існуючих на сервері логінів. |
| db_backupoperator | Учасники ролі можуть виконувати резервне копіювання бази даних. |
| db_ddladmin | Учасники ролі можуть виконувати будь-яку DDL команду в базі даних. |
| db_datawriter | Учасники ролі можуть створювати / змінювати / видаляти дані у всіх призначених для користувача таблицях в базі даних. |
| db_datareader | Учасники ролі можуть зчитувати дані з усіх призначених для користувача таблиць. |
| db_denydatawriter | |
| db_denydatareader | Учасникам ролі заборонений доступ до призначених для користувача таблиць бази даних. |
Так само варто окремо виділити спеціальні ролі в базі даних msdb.
| db_ssisadmin db_ssisoperator db_ssisltduser | Учасники цих ролей можуть адмініструвати і використовувати SSIS (SQL Server Integration Services). |
| dc_admin dc_operator dc_proxy | Учасники цих ролей можуть адмініструвати і використовувати збирач даних. |
| PolicyAdministratorRole | Учасники цієї ролі мають повний доступ до політиків SQL Server |
| ServerGroupAdministratorRole ServerGroupReaderRole | Учасники цих ролей мають повний доступ до зареєстрованих групам серверів. |
| SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole | Учасники цих ролей мають повний доступ завданням агента SQL Server |
Схема по вбудованим ролям баз даних в SQL Server:
ролі додатків
Роль додатки - це об'єкт бази даних (такий же, як і звичайна роль бази даних), який дозволяє за допомогою аутентифікації через пароль міняти контекст безпеки в базі даних. На відміну від ролей баз даних, ролі додатків за замовчуванням знаходяться в неактивному стані і активуються, коли програма процедуру sp_setapprole і вводить відповідний пароль.
На відміну від звичайних ролей, ролі додатків практично ніколи не використовуються. Як виняток, їх застосування можна знайти в multi-layer додатках.
Фільтрація даних в SQL Server
Фільтрація даних в SQL Server через збережені процедур / подання / функції можна віднести до реалізації принципу найменших привілеїв, так як ви надаєте доступ не до всіх даних в таблиці, а лише до деякої їх частини.
Наприклад, можна надати користувачеві права тільки на SELECT з уявлення і заборонити прямий доступ до таблиць, які використовуються в поданні. Таким чином ви надасте доступ тільки до частини даних з таблиці, задавши фільтр where в поданні.
Фільтрація даних через Row-Level Security
Безпека на рівні рядків або Row-Level Security (RLS) Дозволяє фільтрувати дані таблиці для різних користувачів по настроюється фільтру. Це здійснюється через SECURITY POLICY в T-SQL
На даному скріншоті політика налаштовується таким чином, що користувач Sales1 буде бачити рядки таблиці, в яких значення стовпця Sales дорівнює імені користувача (Sales1), а користувач Manager буде бачити все рядки.
Схеми в SQL Server
У деяких об'єктів SQL Server (таблиці, процедури, подання, функції) є схема. Схеми можна уявити, як контейнери для різних об'єктів (або простір імен / namespace, якщо ви знайомі з програмуванням).
Наприклад, якщо у користувача є права на select зі схеми, то користувач так само може робити select з усіх об'єктів цієї схеми. Тобто об'єкти, що належать схемою, успадковують її дозволу. Коли користувачі створюють об'єкти в схемі, об'єкти належать власнику схеми, а не користувачеві. Дозволи не успадковуються від схеми користувачами. Тобто у користувачів зі схемою dbo за замовчуванням, немає дозволів які надані цій схемі - вони повинні бути чітко зазначених у них.
Головна відмінність схем від ролей в тому, що дозволу на схеми можуть бути надані ролям. Наприклад, у ролі testrole можуть бути дозволу select зі схеми schema1 і дозволу на select / update на схемі schema2. Об'єкт може належати всього однією схемою, але права на нього можуть бути у кількох ролей.
вбудовані схеми
У SQL Server є вбудовані системні схеми:
- dbo
- guest
- sys
- INFORMATION_SCHEMA
Схема dbo є схемою за замовчуванням для нових баз даних, а користувач dbo є власником схеми dbo. За замовчуванням, нові користувачі в базі даних мають схему dbo як схеми за замовчуванням. Інші вбудовані схеми потрібні для системних об'єктів SQL Server.
Шифрування даних засобами SQL Server
SQL Server може шифрувати дані, процедури і з'єднання з сервером. Шифрування можливо з використанням сертифіката, асиметричного або симетричного ключа. У SQL Server використовується ієрархічна модель шифрування, тобто кожен шар ієрархії шифрує шар під ним. Підтримуються всі відомі і популярні алгоритми шифрування. Для реалізації алгоритмів шифрування використовується Windows Crypto API.
Найпоширенішими типами шифрування є TDE (Прозоре шифрування даних) і Always Encrypted.
Прозоре шифрування даних
Прозоре шифрування даних або Transparent Data Encryption шифрує всю базу цілком. При крадіжці фізичного носія або .mdf / .ldf файлу, зловмисник не зможе отримати доступ до інформації в базі даних.
Діаграма, для того щоб представити весь процес
Базове шифрування бази даних через T-SQL:
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password';
go
CREATE CERTIFICATE ServerCert WITH SUBJECT = 'DEK Certificate';
go
USE AdventureWorks2012;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE ServerCert;
GO
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
GO
Always Encrypted
Ця технологія дозволяє зберігати шифровані дані в SQL Server без передачі ключів шифрування самому SQL Server. Always Encrypted так само як і TDE шифрує дані в базі даних, але не на рівні бази, а на рівні стовпця.
Для шифрування Always Encrypted використовує 2 ключа:
- Column Encryption Key (CEK)
- Column Master Key (CMK)
Всі процеси шифрування і дешифрування даних відбуваються на клієнті, в базі даних зберігаються тільки зашифроване значення ключа шифрування (CEK).
Always Encrypted так само дозволяє обмежити доступ до даних навіть для DBA, таким чином даючи можливість не турбуватися про те, що адміністратор отримає доступ до даних, до яких не повинен.
Коли варто використовувати шифрування SQL Server?
Шифрування даних це одна з важливих заходів забезпечення безпеки, але шифрування може бути вимогливо до ресурсів сервера і іноді може бути зайвим.
Якщо користувачі звертаються до даних через загальнодоступну мережу, то для забезпечення безпеки може знадобитися шифрування, але якщо дані передаються по захищеної локальної мережі або ВПН, то необхідності в шифруванні даних немає. Так само варто розглянути можливість шифрування даних, якщо є загроза крадіжки фізичного носія з базами даних.
Впровадження шифрування має бути добре сплановано: потрібно врахувати додаткове навантаження на сервер, чи можуть додатки, які працюють з вашим сервером впровадити підтримку шифрування даного типу на своєму боці і багато інших нюансів.
Використання Group Managed Service Accounts для SQL Server
Групові керовані облікові записи служби або gMSA - це спеціальна обліковий запис, який автоматично управляється Active Directory. gMSA це розвиток технології MSA, так як MSA було неможливо використовувати в кластерних сценаріях.
gMSA виключає необхідність вручну міняти паролі для облікового запису. При налаштуванні gMSA ви вказуєте на яких серверах буде працювати gMSA аккаунт, як часто Active Directory буде міняти пароль, і хто має право на перегляд пароля. На серверах, на яких буде встановлено gMSA не потрібно вказувати пароль при вказівці відповідної облікового запису gMSA.
Майте на увазі, що версія Windows Server для роботи з gMSA повинна бути не нижче 2012.
Оцінка вразливостей SQL Server через SSMS
У SQL Server Management Studio є функція оцінки вразливостей для бази даних.
Виберіть базу даних -> Tasks -> Vulnerability Assessment -> Scan For Vulnerabilities.
Сканер оцінить базу даних на предмет популярних помилок в конфігурації безпеки і дасть відповідні рекомендації.
Обов'язково варто пройтися цим сканером по вашим баз даних. Він може виявити приховані проблеми, яких не видно на перший погляд.
Аудит активності в SQL Server
SQL Server надає можливість вести аудит будь-якої користувальницької активності в екземплярі сервера.
Це дуже потужний інструмент, який дозволяє повністю контролювати дії ваших користувачів / розробників.
Розглянемо базову настройку аудиту:
У SSMS, у вкладці Security -> Audits створіть новий аудит.
Потім, для аудиту потрібно створити Специфікацію (Audit Specification), для вказівки подій, які будуть відстежуватися.
Після того як ви створите і активуєте аудит, в журналі аудиту можна буде подивитися події, які зафіксовані процедурою аудиту.
Загальні рекомендації з безпеки SQL Server
Завжди дотримуйтесь принципу найменших привілеїв. У тому числі налаштуйте обліковий запис служби SQL Server за допомогою gMSA. Ні в якому разі не використовуйте доменний обліковий запис з привілеями адміністратора домену.
Принцип найменших привілеїв
Коли ви заводите нових користувачів, рекомендується використовувати принцип LUA (Least-privileged User Account або Аккаунт з Найменшими Правами). Цей принцип є важливою частиною безпеки сервера і даних.
Для користувачів з адміністративними правами рекомендується видавати дозволи лише на ті операції, які їм буде необхідні. Вбудовані серверні ролі варто використовувати тільки тоді, коли набір їх дозволів повністю збігається із завданнями користувача.
Надання прав ролям, а не користувачам
Коли користувачів стає багато, управляти їх дозволами стає складніше, і також стає складніше не допустити помилки в наданні прав.
Рекомендується надавати дозволи ролям, а користувачів додавати в ролі. Таким чином ви досягнете більшої прозорості, так як всі користувачі тій чи іншій ролі матимуть однакові права. Додати або видалити користувачів з ролі простіше, ніж відтворити окремі набори дозволів для окремих користувачів. Ролі можуть бути вкладеними, але так робити не рекомендується, через меншу прозорості і потенційного погіршення продуктивності (якщо вкладених ролей стане занадто багато).
Можна надати права користувачеві на схему. У цьому випадку користувачі відразу зможуть працювати з новоствореними об'єктами в цій схемі, на відміну від ролей, коли при створенні нового об'єкта, ролі потрібно буде роздати на нього права.
