Шифрование в базе данных на сервере?

Question

[melervand]

Подскажите как решить задачу.

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


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


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

Comments

[xmoonlight]

Вопросы есть:
1.По зашифрованным данным поиск и выборка из базы не предполагается?
2.Где планируете расшифроввывать данные: на промежуточном сервере или на клиенте (в браузере)?
3.Цель непонятна: защита от копирования/кражи хостером или ещё какая? (если есть доступ к скриптам работы с базой — украдут 100%)
Пока не вижу способа защиты, кроме хостинга подобного сервиса в доверенной зоне физического доступа и отдельный настроенный firewall. (ИМХО)

[melervand]

1. поиск и выборка только по id пользователя
2. на клиенте
3. имеете ввиду слить пароли дебагом?

Answer 1

[ntkt]

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

Если же менеджеры могут добавляться по ходу игры, то несколько сложнее:
Вариант №0: нагенерируем 100 ключей заранее. Избыточно, и со сменой паролей придется попариться, зато просто.
Вариант №1: один закрытый ключ для всех менеджеров и промежуточный код, который может получать доступ к паролю этого закрытого ключа, и который сам расшифровывает данные и отдает их на веб-интерфейс.

Answer 2

[smoked]

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

Comments

[melervand]

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

Answer 3

[melervand]

Кажется я придумал, правда есть избыточность.

Итак:
1. У каждого пользователя на основе его пароля(ЗК) генерируется открытый ключ
2. У группы менеджеров на основе мастер-пароля(ЗК) также генерируется открытый ключ
3. Пользователь шифрует данные своим и менежерским открытым ключом. Оба варианта сохраняются в базу
4. Теперь когда пользователю надо прочитать данные — он вводит свой пароль(ЗК) и дешифрует свою половину.
5. Также и менеджер вводит свой мастер-пароль(ЗК) и дешифрует свою половину.
6. Ну и менеджер изменяя данные шифрует их своим и пользовательским открытым ключом.

Ничего не упустил? Не упадет ли криптостойкость из-за дублирования данных зашифрованных двумя открытыми ключами?

Comments

[ntkt]

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

[melervand]

ntkt это — гениально! спасибо огромное! а по поводу добавления менеджеров, то скорее всего будет просто общий пароль для группы.

[ntkt]

Т.е. блок зашифрованных данных состоит из, грубо говоря, зашифрованных 1 раз под 1 ключом «сессионный_ключ» данных, и набора из N пар (открытый_ключ_#N, сессионный_ключ_под_открытым_ключом_#N). Если надо подпись — аналогично добавляются подписи: M пар вида (открытый ключ подписи, зашифрованный на нем хэш данных). Нельзя умолчать о том, что ключ подписи не может быть равен ключу для шифрования, т.к. у них разглашаются (публикуются) разные части из ключевой пары.

[melervand]

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

Но и новый менеджер устроившись на работу мог получить доступ к данным. Неужели придеться каждый раз пересчитывать все пары открытый_ключ_#N, сессионный_ключ_под_открытым_ключом_#N?

[melervand]

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

[ntkt]

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

[melervand]

ntkt а если украдут код?

[ntkt]

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

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

[ntkt]

В самом коде никаких ключей не должно быть, это правило.
Желательно сделать отдельный сервер аутентификации и шифрования, на котором никаких веб-интерфейсов не будет и который зафаерволлен нафиг. А доступные из веб-морды сервисы аутентификации и шифрования на этом криптосервере только и умеют, что по максимально простым протоколам принимать пароли и данные, и отдавать флаг да/нет, данные зашифрованные/расшифрованные, и т.д.
К серверу аутентификации, в зависимости от масштабов задачи, можно подключать железные криптоускорители и токены/смарткарты с ключами к ним. На нем можно поднять полнодисковое шифрование, а ходить на него только по полужелезной консоли через IP-KVM от провайдера. Тогда угнать БД у Вас сможет только тот, кто имеет физический доступ к серверу (надеюсь, что удаленно эксплуатируемых через веб-морду уязвимостей в самих службах шифрования на выделенном криптосервере не будет).

Answer 4

[ComodoHacker]

Не понял, зачем шифровать. Настроить контроль доступа в приложении не достаточно?

Answer 5

[StepEv]

Вставлю свои 5 копеек.

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

100% решения тут нет и быть не может, но можно максимально снизить риски. Рецепт:
— разделение доступа, предоставление доступа не ко всему массиву информации, а только к той части, которая нужна непосредственно в данный момент (НИКАКИХ общих паролей)
— журналирование — любой доступ к чувствительным данным должен быть запротоколирован
— мониторинг — любая подозрительная активность должна «включать сирену»
— аудит — анализ журналов

Плюс юридическое сопровождение — менеджеры должны подписать NDA.

На случай если утечка таки произойдёт, нужна возможность идентифицировать источник утечки по утёкшим данным. Как именно — консультируйтесь со специалистами по ИБ.

P.S. Если для вас вышеописанное дорого/сложно — не парьтесь и с шифрованием.

И ещё, вам надо понимать, что шифруя данные в БД, вы, не предприняв специальных мер, теряете возможность поиска, сортировки по хранимым данным. Нужна ли в этом случае именно БД?

Answer 6

[Iliapan]

здесь, очевидно, нужно смотреть в сторону шифрования с открытым ключом

Answer 7

[ntkt]

del