Полупрозрачные базы данных

Question

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

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

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

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

Мой вопрос: должен ли я реализовать этот метод в своем приложении? Существуют ли другие приложения с открытым исходным кодом, которые пошли по этому пути, с которыми я могу сравнить проекты баз данных (особенно с использованием php / MySQL)? Кто-нибудь еще, ищущий действительно безопасный, но неудобный набор функций? Есть ли другая модель безопасности базы данных, которая более популярна и современна, которую я пропустил? Было ли полупрозрачность базы данных причудой или законным методом проектирования баз данных, который я должен принять? Хотя я всегда ценю обсуждение, я бы предпочел объективные ответы, которые я могу использовать в своем дизайне.

Answer 1

Итак, я недавно посмотрел на нечто похожее на это и столкнулся с той же проблемой. Решение, которое я рассматриваю, заключается в следующем:

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

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

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

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

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

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

Answer 2

Должен ли я реализовать этот метод в моем приложении? Ну, как и в других вещах в жизни, есть компромисс :) Возможно, он более безопасен, но сложнее построить.

Существуют ли другие приложения с открытым исходным кодом, которые пошли по этому пути, с которыми я могу сравнить проекты баз данных (особенно с использованием php / MySQL)?

Не знаю, я думаю, инструменты для этого есть сами:)

Кто-нибудь еще использует такие по-настоящему безопасные, но действительно неудобные наборы функций?

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

Есть ли другая модель безопасности базы данных, которая более популярна и современна, которую я пропустил?

Обычно существует два вида соединений с базой данных. Один вариант дает пользователям реальную учетную запись базы данных, другой - использовать единый вход в базу данных. До появления Интернета в мире клиент-сервер были сторонники обеих моделей, но среди веб-разработчиков метод единого входа является ведущим.

Было ли полупрозрачность базы данных причудой или законным методом проектирования баз данных, который я должен принять?

Не думаю, что база данных паролей UNIX, например, является отличным примером базовой полупрозрачной базы данных;)

здесь что-то почитать текст ссылки

Answer 3

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

Ознакомьтесь с HIPAA , особенно когда речь идет о технологиях. Помните, что ни одна система не является действительно безопасной, кроме Skynet *, и посмотрите, что случилось с этим! Люди несут ответственность. Когда вы работаете в медицинской компании, вы подписываете соглашение о неразглашении, указывающее, что вы не будете разглашать какую-либо информацию, которую вы узнаете, в рамках ваших обязанностей, поскольку она является конфиденциальной. Там будет кто-то, чтобы сбросить пароли людей. Так оно и есть, потому что не все технологически компетентны, и так оно и есть сейчас. Вам нужно только реализовать безопасность, как говорит HIPAA.

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

Answer 4

Немного другое решение, вы можете проверить cryptdb:

http://css.csail.mit.edu/cryptdb/