Должен ли я зашифровать данные в базе данных?

16

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

Проблема в том, что это конфиденциальные данные, история болезни и тому подобное.

Клиент настаивает на шифровании данных на уровне базы данных, но я думаю, что это ухудшит производительность веб-приложения. (Но, может быть, я не должен беспокоиться об этом)

Я читал законы о защите данных по вопросам здравоохранения (Португалия), но не очень конкретно об этом (я только расспросил их об этом, я жду их ответа).

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

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

Даже добавление случайной соли в пароль пользователя не решит проблему, поскольку я всегда могу получить к ней доступ и, следовательно, расшифровать данные.

Тио
источник
1
Я в большей степени клиентский разработчик, но я подозреваю, что шифрование всего на самом деле сделает данные менее безопасными, если вы используете один и тот же ключ.
Эрик Реппен
4
Можете ли вы поместить всю базу данных на зашифрованный том и назвать это день. Конечно, чтение / запись будет медленнее, но вы сохраняете все преимущества RDMS (или того, что вы используете), пока данные на диске зашифрованы
DXM
2
Это также означает, что вы не сможете увидеть данные в MySQL Workbench? Все самое лучшее для отладки.
Маной Р
4
Медицина - строго регламентированная отрасль. Работающие там профессионалы привыкли к тому, что кто-то скажет им, каковы правила. Этот образ мышления перетек на ИТ-проекты. Это не совсем проблема безопасности. Это культурная проблема. Стоимость ведения бизнеса в медицинской сфере.
Reactgular
1
Британский госпиталь был оштрафован на 300 000 фунтов стерлингов за то, что дисководы сбились с незашифрованных баз данных. Информация о здоровье очень чувствительна.
MarkJ

Ответы:

9

Я бы лично проверил законы об этом. Если данные должны быть зашифрованы, то они должны быть зашифрованы.

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

Хотя кража этих медицинских данных без средств идентификации пациентов будет крайне затруднительной, вряд ли это будет чем-то большим. Существуют буквально онлайн-конкурсы, которые используют эти анонимные медицинские данные.

С отделением медицинских данных от личных данных пациента. Используйте надежный набор ролей, чтобы ограничить персонал только тем, что ему нужно. За исключением медицинского персонала, которому необходимо иметь дело с пациентом напрямую (медсестры и врачи на переднем крае), никто не должен иметь доступ к обоим. Регистраторам нужны только личные данные пациента, персоналу лаборатории нужна только медицинская карта и PatientID, хирургические медсестры только в настоящее время имеют состояние здоровья и имя.

Когда вы определили каждый набор ролей, стремитесь не только реализовать их в своем веб-приложении, но и в базе данных, а также на дополнительном уровне безопасности.

М Афифи
источник
1
IANAL, но неспециалисты IMO не должны «проверять законы», когда возможная ответственность велика. Они должны проконсультироваться с адвокатом.
Кевин Клайн
я рассматриваю этот подход как верный ответ. медицинские записи, которые не связаны ни с пациентами, ни с врачами, не имеют смысла и непригодны даже для статистического анализа, поскольку в нем нет ссылок и доказательств того, что они не составлены.
Zalaboza
13

Да, вы должны зашифровать базу данных.

Базовое шифрование хранимых данных («данные в состоянии покоя») является общепринятым принципом безопасности и, вероятно, предписано законом, если в вашей стране существуют законы, защищающие личную информацию или информацию о состоянии здоровья.

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

Если все сделано правильно, снижение производительности должно быть небольшим.

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

РЕДАКТИРОВАТЬ: вышеупомянутое шифрование будет шифровать том. Если бы кто-то украл жесткий диск, он нашел бы данные в зашифрованном виде. Однако, если бы кто-то запускал запросы к базе данных, он увидел бы незашифрованные данные (вот почему я упомянул разделение информации, хотя ОП не хотел это обсуждать).

Обратите внимание, что эта рекомендация подразумевает минимум, который вы должны сделать. Если вам нужна юридическая консультация, то, конечно, вам нужно искать в другом месте. Если вы хотите более подробно обсудить написание безопасного кода, я бы начал с книги « Написание безопасного кода» .

jdigital
источник
2
Я не уверен, если это так. Вопрос не в шифровании базы данных, а в шифровании данных в базе данных. Это означает, что данные в SQL-запросах будут зашифрованы.
Маной Р
1
Хит производительности должен быть маленьким? Поиск по данным будет медленным. Вся концепция индексации не работает, когда данные зашифрованы. Это потребует полного сканирования таблицы.
mike30
@mike Приведенный выше подход зашифрует том и не повлияет на индексацию и т. д.
jdigital
ИМО вам нужно больше опыта, чем вы можете получить здесь. IANAL, но я думаю, что ваш клиент будет довольно подвержен риску, если эти данные будут скомпрометированы.
Кевин Клайн
8

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

Теперь есть несколько вещей, которые вы можете беспокоиться в этом контексте:

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

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

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

В третьем сценарии все зависит от контекста, в котором происходит атака: если это, например, атака XSS или CSRF, то злоумышленник может сделать все, что может законный пользователь, и шифрование ваших данных совсем не помогает ,

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

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

tdammers
источник
2
+1: без модели угрозы вы, скорее всего, запираете входную дверь, но оставляете заднюю дверь широко открытой.
Кевин Клайн
8

На мгновение не обращая внимания на то, что просит клиент, и какими бы ни были законы ...

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

Очевидно, вы должны убедиться, что сервер надежно защищен, сетевое соединение защищено, а пользовательский интерфейс защищен должным образом (включая тайм-ауты сеансов, чтобы пользователи не могли уйти, оставляя доступ любому, кто использует их компьютер). Вы также можете зашифровать резервные копии базы данных. И физически защищать комнату, в которой находится сервер. Но я бы не стал шифровать живые данные.

Пояснение: это предполагает, что то, о чем спрашивал ОП, на самом деле шифрует данные в базе данных. Не файловая система, в которой находится база данных.

GrandmasterB
источник
полностью согласен, но ЗАКОНОВ нет :(
Zalaboza
1
Ну, вы могли бы, AES_DESCRYPT('') LIKE 'Smith%'хотя и невероятно медленно. Или вы можете получить интенсивный и сделать перевернутый индекс с солеными хэшами
foochow
1

Если вы тщательно разрабатываете веб-приложение, используя эффективную среду MVC, такую ​​как CakePHP. Zend или Rails, тогда вы сможете включить / отключить шифрование на модальном уровне данных.

CakePHP, например, имеет несколько примеров поведения для модалов, которые шифруют данные. Делая процесс прозрачным для контроллеров и представлений.

При этом игнорируются проблемы с индексированием и другие технические проблемы с базами данных. Должно быть возможно иметь это как настраиваемую опцию.

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

Reactgular
источник
1

Да, вы должны зашифровать базу данных.

Поскольку это личная и конфиденциальная информация, я определенно верю, что так и должно быть.

Из пароля вы можете получить ключ шифрования, который вы сохраняете только для сеанса. Таким образом, он нигде не хранится, и никто (включая администраторов баз данных) не может его знать, так как никто не может знать и пароль. Любой, кто пытается просмотреть БД напрямую, будет смотреть на тарабарщину. Единственный способ это исправить - перехват сеанса, но я предполагаю, что сеансы также безопасны.

dagnelies
источник
Люди очень часто забывают свои пароли ... тогда что?
любопытный парень
-1

Я спрашиваю себя, почему клиент просит вас зашифровать БД? Если бы он попросил вас защитить данные, я бы согласился, но он уже имеет в виду неявную реализацию. Поэтому, пока он точно не знает, о чем говорит, он просто излагает модные слова с моей точки зрения.

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

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

sschrass
источник
... каждая крупная СУБД принимает во внимание безопасность ... кроме случаев, когда они этого не делают .
Джей Элстон
Первый вопрос, который мне нужно задать, - как они это сделали и как можно предотвратить повреждение, зашифровав базу данных. Я просто быстро просмотрел эту статью, но у меня сложилось впечатление, что у них есть учетные данные.
sschrass
Точно - учетные данные БД могут и не быть скомпрометированы. Задача состоит в том, чтобы спроектировать систему так, чтобы даже когда неавторизованные пользователи получали доступ к учетным данным, им по-прежнему требовались дополнительные ключи шифрования для доступа к конфиденциальным данным. Для медицинской информации это еще сложнее. Не каждый, имеющий доступ к учетным данным БД, должен иметь доступ к конфиденциальным данным. Например, администратор базы данных не должен иметь возможность читать данные пациента в виде открытого текста. Единственные люди, которые должны иметь возможность прочитать эти данные, - это пациенты и их поставщики.
Джей Элстон