Яка хороша практика безпеки для зберігання критичної бази даних на ноутбуках розробника?

У нас є кілька подарунків:

1. Розробникам потрібна репліка виробничої бази на своїх машинах.
2. Розробники мають пароль до зазначеної бази даних у файлах App.config.
3. Ми не хочемо, щоб дані у зазначеній базі даних були порушені.

Кілька запропонованих рішень та їх недоліки:

1. Повне диск-шифрування. Це вирішує всі проблеми, але погіршує продуктивність ноутбука, і ми починаємо роботу, тому не майте грошей на власні коні.
2. Створення ВМ із зашифрованим жорстким диском та збереження на ньому бази даних. Він працює добре, але це не дуже допомагає, оскільки в Web.Config є пароль.
3. Рішення №2 + вимагає від розробника вводити пароль бази даних кожного разу, коли він що-небудь запускає. Це вирішує всі проблеми, але це дійсно громіздко для розробників, які іноді запускають додаток кілька разів на хвилину. Також у нас є кілька додатків, які підключаються до однієї бази даних, і реалізація екрана паролів повинна відрізнятися в кожному.

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

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

Якщо вам потрібні дані масштабу виробництва для тестування, у вас є кілька варіантів:

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

Для варіанту №2

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

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

По можливості змініть свій спосіб роботи.

Як вказували інші:

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

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

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

Якщо це дійсно необхідно, потрібно просто зашифрувати повний диск.

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

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

Відповідь Корбіна Марта досить гарна, я просто додам додаткову деталь, що у вашій виробничій базі зазвичай є два класи даних: метадані системи / програми; дані клієнта / дані транзакцій. Останнє НІКОЛИ не слід застосовувати в середовищі розвитку "як є".

Дійсно дуже рідко, що вам потрібна актуальна інформація про клієнта для розвитку.

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

Ви не вказуєте, яка база даних та яке середовище.

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

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

Чи є спосіб зберегти пароль у пам'яті при першому його введенні та прочитанні всіма. Знову ви не заявляєте про навколишнє середовище. Файли з пам'яттю

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

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