Як я можу запобігти випадковому злому з виробничою базою даних?


31

Зовсім недавно у мене був розробник випадково спробував відновити базу даних у виробництві, коли він мав би відновитись до поетапної копії. Це легко зробити, враховуючи, що імена db схожі, тобто, CustomerName_Staging порівняно з CustomerName_Production.

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

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

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


25
Розробники не повинні мати доступ для запису до виробничих баз даних, або, бажано, будь-якого доступу.
Майкл Хемптон

12
@MichaelHampton - Це я і він. Я також розробник. Що ти пропонуєш?
Кріс Б. Беренс

10
Окремі облікові записи користувачів для кожної ролі (dev vs ops / DBA). І достаток обережності.
Майкл Хемптон

2
Я б настійно радив, щоб у вас було виробниче середовище на окремому ящику. В іншому випадку інсценізація та виробництво мають ділитися ресурсами - диском, процесором тощо, - і якщо інсценізація монополізує ресурс, ваше виробниче середовище може постраждати.
Thorbjørn Ravn Andersen

1
Просто майте окремі користувачі / паролі для цих баз даних.
нейтрин

Відповіді:


32

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

  • Переконайтеся, що ви відновляєте на правильному сервері (тобто не відновлюється dev -> prod)
  • Переконайтеся, що це правильний "тип" бази даних (у вашому випадку "постановка" та "виробництво")
  • З’ясуйте, які резервні копії (файли) для відновлення автоматично, переглянувши таблиці резервного копіювання в msdb

Et cetera. Ви обмежені лише вашою фантазією.


1
Це цікава ідея ... у нас уже є код, який управляє відновленням db (для автоматизованого тестування). Ми могли б поставити між собою прошарок абстракції, який лише вказував на постановку, так що відновлення виробництва було зовсім іншим процесом ...
Кріс Б. Беренс

11
Тепер ви думаєте з порталами. :)
Бен Тул

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

2
Я вважаю, що ніхто не повинен мати доступ до виробництва за замовчуванням. Ви повинні мати спеціальний процес для отримання пароля пропозиції. Це незручно, але насправді мінімум.
ОліверС

1
@BenThul Додавання іншого облікового запису для доступу продукту та зробити його ще одним кроком незручним для мене все-таки правильним рішенням. Ділова потреба полягає не в тому, щоб DEV економив 2 хвилини, а відновлювати БД, який можна ідеально перемістити до облікового запису продукту.
Оліверс

32

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

Ви не повинні мати можливість випадково щось робити з виробництвом!

Це включає випадкові випадки автоматизованих речей.

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

Почати потрібно з сортування робочого процесу.

  • Ваші облікові записи розробників повинні мати можливість записувати у власні копії, контроль версій і, можливо, переходити з контролю версій у тестувальне середовище.

  • Користувачі резервних копій повинні мати змогу читати лише з виробництва та писати у ваш резервний магазин (який повинен бути належним чином захищений).

  • Будь-яке інше читання / запис на виробництві повинно вимагати спеціального та незручної автентифікації. Ви не повинні мати можливість проскочити в нього або забути, що ви ввійшли в систему. Фізичний контроль доступу тут корисний. Смарт-карти, фліп-перемикачі для "озброєння" облікового запису, одночасний поворот з двома ключами.

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

Автоматизація є частиною рішення.

Я не сліпий від того, що повний поворот (завантаження у VCS, перевірка покриття, витяг на тестовий сервер, запуск автоматизованих тестів, повторна автентифікація, створення резервної копії, витяг з VCS) - тривалий процес.

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

Але поодинці автоматизація гірша, ніж марна. Це просто допоможе вам зробити більші помилки з меншою думкою.

Підходить для команд усіх розмірів.

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


2
Крім того, одна річ, яку я люблю робити, це використовувати два названі облікові записи на користувача. Один призначений для звичайного входу користувача, роботи, щоденної роботи тощо, тоді як другий обліковий запис (як правило, з таким суфіксом, як + або підкреслення) має повні права на prod та dev, необхідні користувачеві. Таким чином, користувач повинен приймати активне рішення, щоб натиснути, щоб продати, на відміну від dev. Це схоже на описану вище кулю 3, але не потребує значної додаткової інфраструктури або витрат для демонстрації цінності.
user24313

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

Де я можу взяти один із цих контрацепцій з подвійним ключем одночасного повороту і чи постачається він із USB?
Ліліенталь

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

1
@Lilienthal Це була метафора для театру підвищеної безпеки, але ви можете наслідувати, що дешево атакує USB-накопичувач до кожного розробника, а потім мати вашу автоматику перевірити щонайменше два їхні серійні номери при запуску небезпечних речей. У більших колективах ви зможете ввійти, щоб побачити, хто втручається у виробництво, і нести відповідальних людей, коли все піде не так.
Олі

12

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

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


2
Я також використовую великий червоний колір фону на терміналах / db-з'єднаннях із виробничими серверами, а також яскраво-червоні шпалери для адмін-акаундів на ПК ...
Falco

Так, я думав про це. Зробіть виробничу пожежну машину червоною ...
Кріс Б. Беренс

Кольорове кодування допомагає. Так само, як і в IDE.
Thorbjørn Ravn Andersen

1

Розробники не повинні знати пароль до виробничої бази. Пароль продукту повинен бути випадковим і не запам'ятовуватися - щось на кшталт результату зчитування клавіатури ( Z^kC83N*(#$Hx). Ваш DEV пароль може бути $YourDog'sNameабо correct horse battery stapleабо будь-який інший .

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

(Як завжди, у вас повинні бути резервні копії для вашої виробничої бази даних. Наприклад, за допомогою MySQL архівуйте бінарні журнали як додаткові резервні копії. Для PostgreSQL архівуйте журнали попереднього запису. Це ваш крайній захист для будь-яке стихійне лихо, самонанесене чи інше.)


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

1
@Falco Саме це я і пропоную. Незручно, але можливо.
200_успіх

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

2
@Falco Оскільки середовища prod повинні тісно відображати середовища розробки, файл конфігурації знаходитиметься в аналогічному місці на сервері prod, як і на машинах розробників. Будь-який компетентний розробник повинен знати, куди їх шукати, а якщо вони не знають, де його шукати, то вам потрібно це затримка - саме для запобігання пошкодженню типу, зазначеного у питанні.
200_успіх

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

0

Коротка відповідь - RBAC - рольовий контроль доступу.

Ваші дозволи для будь-якого середовища повинні бути різними - і настільки прикро, як такі речі, як UAC, вони вам потрібні: особливо для PROD середовищ.

Там немає НІКОЛИ причини девів , щоб мати прямий доступ до Prod - незалежно від того, наскільки мала організації / команда. Ваш "Dev" може також носити капелюхи "Stage" і "Prod", але йому потрібно мати різні облікові дані та процеси, щоб потрапити в різні середовища.

Це дратує? Абсолютно. Але чи допомагає це [запобігти] занурювати ваше середовище? Абсолютно.


0

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

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


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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.