Чи слід зашифровувати дані в базі даних?

У мене є клієнт, для якого я збираюся зробити веб-додаток про догляд за пацієнтами, ведення пацієнтів, консультації, історію, календарі, в основному про це.

Проблема полягає в тому, що це конфіденційні дані, історія хворого тощо.

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

Я читав закони про захист даних з питань охорони здоров’я (Португалія), але не дуже конкретний з цього приводу (я просто допитав їх про це, чекаю їх відповіді).

Я прочитав наступне посилання , але питання у мене інше, чи потрібно шифрувати дані в базі даних, чи ні.

Одна з проблем, яку я передбачаю в шифруванні даних, полягає в тому, що мені знадобиться ключ, це може бути пароль користувача, але всі ми знаємо, як користувальницькі паролі (12345 і т. Д. І т. Д.), І генеруючи ключ, я повинен був би зберігати це десь, це означає, що програміст, dba, що б не мав до нього доступ, якісь думки з цього приводу?

Навіть додавання випадкової солі до пароля користувача не вирішить проблему, оскільки я завжди можу отримати доступ до неї, а тому розшифрувати дані.

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

Якщо ви не отримаєте жодних вказівок, я б намагався захистити зв’язок між пацієнтом та його даними. Тобто у вас, швидше за все PatientID, використовується таблиця в базі даних. PatientIDне ідентифікує пацієнта, лише історію хвороби пацієнта тощо. Однак, щоб визначити PatientIDДжо Блоггса, який проживає в Лісабоні Руа де Сан-Бернардо, я б зберігав це в окремій БД, якщо зможу. Використовуйте TDE для особистих даних пацієнта та роздумуйте про їх шифрування поверх того, що використовується ключі у вашому веб-додатку.

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

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

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

Так, слід зашифрувати базу даних.

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

Ми використовуємо SQL Server 2008, тому ми використовуємо TDE Microsoft; може бути якесь сторонне рішення для MySQL або, можливо, просто загальний підхід до шифрування томів (наприклад, TrueCrypt) буде працювати (хоча я хотів би мати те, що було сертифіковане для використання з базою даних).

Якщо виконано правильно, показник ефективності повинен бути невеликим.

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

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

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

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

Тепер у цьому контексті можна потурбуватися про кілька:

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

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

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

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

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

Додатковим питанням є те, де ви зберігаєте ключі та фрази, особливо якщо ви використовуєте платформу з моделлю виконання без стану, наприклад PHP. В ідеалі клієнт вводить його пропускну фразу, коли це потрібно, і зберігайте її лише в пам'яті, а ще краще, виконайте розшифровку на стороні клієнта (але це не часто можливо). На платформі без стану стан зазвичай виконується за допомогою сеансів, пам'яті, баз даних або плоских файлів; але все це набагато вразливіше, ніж зберігати стан у власній пам'яті веб-програми. Уникнути цього - проблема з курячими яйцями, адже якщо ви зашифруєте стан перед тим, як зберегти його, ви просто створили ще один секрет, який ви повинні безпечно пам’ятати. Запам’ятовування парольної фрази клієнта та відправлення його разом з кожним запитом, який потребує цього, може бути найменш жахливим рішенням;

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

Ні, ви, мабуть, не повинні шифрувати дані. Якщо ви зробите це, ви не зможете легко знайти його. Наприклад, як би ви шукали прізвище, like 'Smith%'якщо кожен запис імені шифрується? Як би ви склали графік артеріального тиску пацієнта з часом, якщо не можете select .... from.... where patient_id = N?

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

Роз'яснення: Це припущення, про що запитувала ОП - це фактично шифрування даних у базі даних. Не файлова система, на якій базується база даних.

Якщо ви ретельно розробляєте веб-додаток, використовуючи таку ефективну структуру MVC, як CakePHP. Зенд або Rails, тоді ви повинні мати можливість увімкнути / вимкнути шифрування на рівні даних Modal.

Наприклад, CakePHP містить кілька прикладів поведінки для модалів, які шифрують дані. Зробити процес прозорим для контролерів та переглядів.

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

Крім того, я б увімкнув шифрування або пізніше, або лише на виробничому сервері. Зашифровані дані важко налагоджувати та працювати з ними під час розробки, і це можна зробити лише на певних стовпцях.

Так, слід зашифрувати базу даних.

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

З пароля ви можете отримати ключ шифрування, який ви зберігаєте лише для сеансу. Таким чином, він ніде не зберігається, і ніхто (в тому числі DBA) не може його знати, оскільки ніхто також не може знати пароль. Кожен, хто намагається переглядати БД безпосередньо, буде дивитись на хитрість. Єдиний спосіб пошкодити це через викрадення сеансу, але я припускаю, що сеанси також безпечні.

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

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

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