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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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