Как защититься от сис.админа и программиста, храня секретные данные в БД?

Есть web-приложение по управлению ресурсами (назначение персонала на проекты), построенная на базе PostgreSQL и Java.

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

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

Очевидно, что эти секретные данные (секретные поля) должны как минимум шифроваться на уровне БД для предотвращения прямого чтения. Но как защититься от перехвата паролей или ключей шифрования программистами и сис.админами?
Посоветуйте статьи или примеры (непроприетарных) архитектурных решений на Java, чтоб достичь вышеописанного.
  • Вопрос задан
  • 5008 просмотров
Решения вопроса 1
@m0rd
Можно попробовать такой вариант:
1) В web-приложении сделать шифрование данных симметричным алгоритмом на стороне клиента
2) Админ и программист не должны участвовать в генерации ключей шифрования для алгоритма
3) Пользователям раздаются ключи для доступа к информации.
Итого:
1) Данные в базе хранятся в зашифрованном виде
2) Данные между БД и приложением ходят в зашифрованном виде
3) Ключи хранятся у пользователей и никуда не передаются
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
Данные о зарплате заводятся в проект наверное не только для того, чтобы там храниться, но и как-то участвуют в вычислениях.
Поэтому если у Вас трехзвенка, то защититься от админа сервера приложений невозможно - данные должны быть там в дешифрованном виде.
Если же есть возможность работу над этими "высокосекретными" данными всю производить по двухзвенной схеме - в клиентском браузере, то тогда - да, шифрование с должными предосторожностями (с рандомизацией и защитой от replay attack) Вас в принципе спасет. Хотя задача всё равно будет нетривиальной.

P.S. Кстати, Вы уверены, что ставку нельзя будет "вычислить обратно", зная сумму оплаты за этап и его трудозатраты в часах ?
Ответ написан
Комментировать
@bobzer
Java EE Developer
Не совсем ответ на Ваш вопрос, но всё же. Называть сведения о ЗП "высокосекретными", мягко говоря, неверно. Они не секретны, а конфиденциальны, и обычно защищаются пунктами трудового договора. Мне кажется, что у вас сейчас проблема в том, что поставлена задача, оторванная от реальности. Вы пытаетесь потратить уйму времени на разработку, породив при этом кучу проблем в последующей поддержке - на фикцию. Даже при успешной реализации, подумайте, что улучшится на предприятии? Сотрудники перестанут общаться между собой (в т.ч. тихонько интересуясь кто сколько "получает")? Компания при публикации резюме перестанет указывать вилку ЗП? Я бы порекомендовал серьезно задуматься над постановкой задачи, очень похоже на стрельбу из пушки по воробьям...
Ответ написан
@Khanover Автор вопроса
To sim3x: Я примерно такую схему и предполагаю, что программисты все делают, код ревьюируется на отсутствие секретных данных в логах системы или серверов (пока проблема с логами БД), админы готовят процедуру развертывания (и возможно даже развертывают) я cам генерю ключи и сам обучаю пользователей. Но все еще непобедима проблема перехвата или ключа или пароля к ключу.

To m0rd: Вот этот вариант возможно и нужно реализовывать. Только пока неясно как (хотелось бы пример микроархитектуры).

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

Но это все теория. Конечно. хотелось бы увидеть примерчик. А то я подозреваю в большом количестве невидимых "граблей", на которые заранее не хотелось бы наступать.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы