Зміцнюємо захист sql server, windows it pro
Функціональність таких програм SQL Server залежить від даних, і ніколи раніше захист цих даних не була настільки актуальна. SQL Server - улюблена мішень хакерів, крім того, існує ризик випадкового псування даних. Ризик можна знизити, зміцнивши SQL Server через скорочення зони атаки і управління доступом до неї
ІТ-інфраструктура для вашого підприємства
Зменшення зони атаки
Зоною атаки називають шляхи, через які можна отримати доступ або підвищити повноваження в SQL Server. Щоб скоротити зону атаки SQL Server, прийміть до відома наступні рекомендації.
Встановлюйте лише необхідні компоненти SQL Server. Установку SQL Server часто розглядають як рутинну завдання, але саме на даному етапі починають застосовувати заходи по зміцненню безпеки. При установці SQL Server не слід включати служби SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS), а також компонент Full-Text Engine і його засіб Filter Daemon Launcher. При необхідності їх можна легко додати пізніше.
Не встановлюйте служби SQL Server Reporting Services (SSRS) на одному сервері з ядром системи управління базою даних. Якщо встановити служби SSRS на одному сервері з ядром бази даних, веб-служби створюють пробіл в шарі безпеки. Історично в IIS і веб-службах було багато вразливих місць, через які хакери проникали в сервер. В результаті всі об'єкти, розміщені на сервері, наражалися на небезпеку. Цього можна уникнути, якщо відмовитися від установки служби SSRS на сервері бази даних.
Вимкніть служби SQL Server, в яких немає гострої необхідності. Зокрема, рекомендується зробити наступне.
Не використовуйте порти TCP / IP, які обираються за замовчуванням. Після установки слід налаштувати SQL Server на використання портів, відмінних від обираних за замовчуванням. Порти за замовчуванням - відомі точки входу в SQL Server; в минулому вони використовувалися хакерами. Гострота проблеми не настільки велика, якщо сервер недоступний з Інтернету, але у вірусів, «троянських коней» і зломщиків є інші способи використовувати ці вразливі місця. Такий підхід не усуває шлях атаки, а лише приховує його. Тому даний спосіб відомий як «захист невідомістю».
Вимкніть необов'язкові мережеві протоколи. Слід відключити (або не включати) мережеві протоколи, в яких немає необхідності. У більшості випадків для підключення до SQL Server не потрібні одночасно Named Pipes і TCP / IP, тому оберіть оптимальний протокол для підключення до SQL Server і відключіть інший. Наприклад, на екрані 1 показані відключений протокол Named Pipes і включений TCP / IP, налаштований для прослуховування порту, відмінного від обраного за замовчуванням.
Екран 1. Відключення необов'язкових мережевих протоколів
Зверніть увагу, на стан протоколів Shared Memory і Virtual Interface Adapter (VIA) на екрані 1. Зазвичай можна залишити Shared Memory включеним, так як цей протокол використовується сервером тільки для локальних підключень. Але протокол VIA потрібно відключити, якщо тільки не застосовується обладнання VIA.
Переконайтеся, що своєчасно оновлені і правильно налаштовані антивірусна програма і брандмауер. Для надійного захисту на сервері повинні бути встановлені новітні версії антивірусної програми і брандмауера. Крім того, повинні бути закриті всі порти, залишені відкритими за замовчуванням. Зокрема, обов'язково впевніться, що в брандмауері Не залишено відкритим порт, який обирається за замовчуванням для SQL Server.
На екрані 2 показані приклади політик зони атаки, що використовуються системою управління. Кожна політика містить умову і цільовий об'єкт, до якого застосовується ця умова. Система відстежує цільовий об'єкт, перевіряючи його відповідність умові. Можна навіть скасувати зміни, що порушують умова.
Екран 2. Використання системи управління на основі політик для управління настройками зони атаки
управління доступом
Управління доступом в SQL Server не обмежується наданням дозволів користувачам. Управління доступом охоплює наступні завдання.
Налаштування перевірки автентичності. По можливості слід використовувати тільки перевірку автентичності Windows.
Налаштування адміністративних облікових записів. Потрібно видалити обліковий запис \ BUILTIN \
Administrators і відключити обліковий запис з правами системного адміністратора (sa). Зазвичай слід строго обмежити коло користувачів, наділених повноваженнями системного адміністратора, і задіяти серверні ролі для привілейованих користувачів, яким потрібно вирішувати певні завдання на рівні сервера, наприклад операторів резервного копіювання або адміністраторів безпеки. Поки неможливо обмежити дозволу користувачів з правами системного адміністратора, але їх можна контролювати за допомогою засобів аудиту SQL Server.
Потрібно також обмежити членство в групі локальних адміністраторів. Локальний адміністратор може отримати доступ до комп'ютера SQL Server і надати права системного адміністратора самому собі. Зробити це непомітно важко, але можна. Для захисту сервера, на якому розміщується SQL Server, повинні застосовуватися настільки ж суворі заходи, як для безпеки самого екземпляра SQL Server.
Призначення облікових записів служб. Найпоширеніша помилка, що стосується облікових записів служб SQL Server, - надання їм зайвих дозволів. Перш ніж пояснити, як уникнути цієї помилки, згадаємо про кращий спосіб створення облікових записів.
Не слід використовувати вбудовані системні облікові записи Windows (наприклад, LocalService, LocalSystem) в якості облікових записів служб SQL Server, так як вбудовані системні облікові записи успадковують певні підвищені повноваження в Active Directory (AD), які не потрібні для SQL Server. Наприклад, облікового запису Network Service дозволено проходити перевірку автентичності в мережі з використанням облікового запису комп'ютера, а облікового запису LocalSystem дозволено створювати і видаляти власні імена учасника-служби (SPN).
При призначенні дозволів облікових записів служб SQL Server слід завжди керуватися правилом найменших привілеїв. У загальному випадку слід додати обліковий запис служби до підходящої локальної групи, створеної спеціально для кожного компонента SQL Server. Це дозволяє облікового запису служби успадковувати будь-які необхідні дозволи на рівні Windows. Призначення дозволів групі замість облікового запису служби гарантує, що дозволу не будуть втрачені у разі зміни ідентифікації служби. Крім того, у старій облікового запису служби не будуть збережені дозволу, які їй більше не потрібні.
У Windows або NTFS для облікових записів служб SQL Server не потрібно ніяких додаткових дозволів, крім успадкованих через членство у відповідній групі. Ніколи не вводьте облікові записи служб в групу локальних адміністраторів.
Створення груп безпеки. Не слід надавати доступ до SQL Server окремим користувачам. Замість цього створіть в AD групи безпеки для конкретних серверів і наборів дозволів, а потім вводите індивідуальних користувачів до відповідних груп по мірі необхідності. Керувати групами безпеки повинні адміністратор бази даних або група експлуатації. Часто в компаніях використовується інструмент, за допомогою якого члени групи експлуатації можуть вносити зміни (наприклад, додати користувача) в групу безпеки, але власник групи повинен схвалити зміну або скасувати його. Неприпустимо вирішувати додавання в одну з груп безпеки об'єктів, що знаходяться поза контролем оперативної групи, так як в цьому випадку втрачається можливість побачити членів групи і управляти додаванням і видаленням користувачів.
Призначення схем і володіння об'єктами. Якщо користувачам без прав системного адміністратора потрібно безпосередньо керувати певними частинами виробничої бази даних, слід відокремити відповідні об'єкти від всіх інших об'єктів. Кращий спосіб це зробити - помістити керовані користувачами об'єкти в спеціальну схему і надати дозволи на рівні схеми. Окремі користувачі та групи не повинні володіти схемою dbo або об'єктами в ній.
Не слід включати межбазовие ланцюжка володіння. Якщо вони включені, можуть виникнути ситуації, при яких користувач ненавмисно отримає дозволу для об'єктів, що перебувають у базі даних, відмінною від поточної.
Окремі користувачі не повинні володіти базами даних. Користувач, якому дозволено бути власником бази даних, автоматично зіставляється dbo, що призводить до обходу перевірки дозволів в базі даних. Цей рівень повноважень не можна відкликати або скасувати, якщо не змінити власника бази даних. Крім того, якщо володілець бази даних - нелегітимний користувач, можна отримати несподівані і важко піддаються діагностиці збої дозволів в базі даних. Якщо відключити обліковий запис системного адміністратора і межбазовие ланцюжка володіння, обліковий запис системного адміністратора можна призначити власником всіх баз даних, без жодного ризику.
Один з варіантів - завжди відключати параметр Trustworthy. Цей параметр часто використовується, щоб спростити запуск коду CLR з дозволами EXTERNAL_ACCESS або UNSAFE в базі даних. Він також дозволяє процедури і функції, в яких використовується передача повноважень для виконання функцій серверного рівня. По суті, параметр Trustworthy повідомляє примірнику сервера, що системний адміністратор довіряє володільцю бази даних. Цього можна досягти, не включаючи параметр Trustworthy, якщо підписати програмний код або модуль з використанням сертифіката.
Вищий пріоритет
Першочергове завдання адміністратора бази даних - захист примірників SQL Server і містяться в них даних. Зміцнення SQL Server шляхом зменшення зони атаки і управління доступом - важливий елемент захисту сервера. Прийоми, описані в даній статті, допоможуть захистити екземпляр SQL Server і ваші дані.
Поділіться матеріалом з колегами і друзями