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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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