Наслідки безпеки відновлення резервної копії з невідомого джерела?

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

Запитання 1 : Які можливі наслідки відновлення резервної копії, яка може бути шкідливою?

Питання 2 : Що ви можете зробити, щоб захистити ваш сервер / дані в інших базах даних від впливу відновлення потенційно-шкідливої ​​резервної копії? RESTORE VERIFYONLYздавалося б, хорошим першим кроком. Кінцева відповідь - це, мабуть, «відновити базу даних у VM з пісочницею, не маючи доступу до зовнішнього світу», але припустимо, що цей варіант відсутній. Що ще слід зробити в цій ситуації?

База даних може містити шкідливий код, можливо, процедуру, яка збирається змінити пароль для входу "sa" або видалити кожну базу даних. Однак єдиний спосіб я бачу, що викликає проблему, - це людина відновити базу даних, а потім виконати вручну будь-який код у цій базі даних. Він не виконується автоматизованим чином.

Немає параметрів, які можна застосувати в базі даних, щоб сервер SQL автоматично виконував деякий біт коду в базі даних після відновлення на сервері. Якби це було, я би сподівався, що Microsoft втратить сертифікацію спільних критеріїв для продукту. Це велика помилка, яка дозволила мені в СУБД.

Ви можете зробити кілька заходів щодо профілактики.

1. Переконайтесь, що ніхто, окрім одного системного адміністратора, не має доступу до відновленої бази даних.
2. Поверніть db в єдиний користувальницький режим після відновлення.
3. Перевірте код у всіх збережених процедурах та функціях та тригерах всередині цієї бази даних.
4. Виконайте dbcc checkdb, щоб переконатися, що немає проблем з цілісністю.
5. Перевірте користувачів, які раніше мали доступ до бази даних та видаліть їх.
6. Почніть дозволяти доступ, дуже обмежений певними перевіреними вами об'єктами.

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

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

Це само по собі нічого не зробить, звичайно - вірус не раптом стає чутливим - але якщо ваші користувачі спробують отримати доступ до файлу, вони можуть бути заражені. (Гей, я сказав, що я досягаю.) Я розглядаю сценарій, коли зовнішній хакер хоче отримати зловмисне програмне забезпечення у двері, а потім він надсилає електронному письмові Бобу в бухгалтерію, кажучи: "Ось файл: \ sqlserver \ filetableshare \ myvirus.exe "- в цей момент він пройшов повз ваших брандмауерів без виявлення, і ми тепер перейшли до ваших внутрішніх антивірусних та анти-шкідливих програм.

ВІДКЛЮЧЕННЯ ВЕРІФІОННО здавалося б хорошим першим кроком. Кінцева відповідь, ймовірно, "відновіть базу даних в VM з пісочницею, не маючи доступу до зовнішнього світу", але припустимо, що цей варіант не входить у таблицю. Що ще слід зробити в цій ситуації?

Відновити перевірити лише перевіряє цілісність бази даних, НЕ ВІДКАЄТЕ, чи включає в себе резервна копія шкідливий код чи ні, RESTORE VERIFYONLY не намагається перевірити структуру даних, що містяться в резервних томах. Вкрай малоймовірно, що якщо резервне копіювання зсередини фірми, де ви працюєте, може бути шкідливою, але якщо вона надходить від якоїсь третьої сторони, вам потрібно бути обережним, як вказував Шон.

Документація Microsoft Online говорить про це

• В цілях безпеки рекомендуємо не приєднувати та не відновлювати бази даних з невідомих або недовірених джерел. Такі бази даних можуть містити шкідливий код, який може виконувати ненавмисний код Transact-SQL або викликати помилки, змінюючи схему або фізичну структуру бази даних. Перш ніж використовувати базу даних з невідомого або недовіреного джерела, запустіть DBCC CHECKDB на базі даних на непродукційному сервері, а також вивчіть код, такий як збережені процедури або інший визначений користувачем код, у базі даних.

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

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

Який ризик є відновлення невідомої бази даних з невідомого джерела? Немає.

Який ризик є в тому, щоб дозволити невідомому додатку підключитися за допомогою облікового запису sysadmin для підключення до цієї бази даних та запуску коду? ЛОТИ! Якщо обліковий запис програми має права лише в межах бази даних і немає доступу на рівні сервера, то нічого, що дійсно не може зробити поза межами бази даних. Це, в основному, зводиться до того, щоб на сервері встановити належну настройку системи безпеки.

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

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

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

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

Отримайте старий ноутбук / робочий стіл та оціночну версію програмного забезпечення Бази даних (SQLExpress), якщо проблема з ліцензуванням. Скопіюйте файл резервного копіювання на апарат, відключіть мережу / бездротовий зв'язок і виконайте відновлення. Потім починайте копати. Знайдіть весь час, який вам потрібен, тому що є багато місць, які речі можуть приховати, більшість із них уже охоплені іншими публікаціями в цій темі.

Ваша цілісність DBA та доброзичливість вашого виробничого середовища важливіші, ніж будь-яке замовлення, яке дав начальник.