Как отделить конфиденциальные данные в базе данных (MySql)

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

Каким может быть подход для реализации столбцов таблиц БД: шифровать информацию, разделять данные в двух разных БД, одну для конфиденциальных данных и другую для не конфиденциальных данных, или оба, или другой подход?

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

DBA не должен иметь возможность просматривать информацию о заболевании пользователя базы данных.

Что касается использования для разделения баз данных, я не думаю, что это необходимо. Вы храните данные в зашифрованном виде и используете разрешения базы данных пользователем, таблицы (если это даже необходимо) будет более чем достаточно. Я думаю, что дополнительная БД добавляет слой сложности без всего остального. Если он не находится в другом месте, он может иметь МАЛЕНЬКОЕ улучшение по сравнению с одной системой баз данных.

Ответ Ominus отвечает на ваш первый вопрос. Ответ на второй вопрос может потребовать более подробной информации о вашем заявлении.

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

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

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

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

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

Чтобы предотвратить просмотр данных администратором базы данных, вам необходимо зашифровать его с помощью кода, к которому у администратора нет доступа.

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

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

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

• имя
• Дата рождения
• Адрес электронной почты
• секс
• адрес