Как защититься от сис.админа и программиста, храня секретные данные в БД?
Есть web-приложение по управлению ресурсами (назначение персонала на проекты), построенная на базе PostgreSQL и Java.
Возникла необходимость хранить в БД высокосекретные данные (контрактные ставки и зарплаты людей). Понятно, что эти данные ни при каких изменениях в системе не должны быть доступны системному администратору БД и программисту, даже если они скопировали эксплуатационную БД и пытаются с ней "играться", чтоб эти данные оттуда достать. Но в то же время, эти данные должны быть доступны нескольким группам пользователей. Кому-то на чтение, кому-то на чтение-запись. В идеале даже и эти группы пользователей не должны читать данные друг-друга, если они не входят в группу особо привилегированных, которые могут читать все.
Система уже имеет разветвленную схему привилегий, но защиты от администратора никакой не делалось, т.к. возможно прямое добавление привилегии через БД.
Очевидно, что эти секретные данные (секретные поля) должны как минимум шифроваться на уровне БД для предотвращения прямого чтения. Но как защититься от перехвата паролей или ключей шифрования программистами и сис.админами?
Посоветуйте статьи или примеры (непроприетарных) архитектурных решений на Java, чтоб достичь вышеописанного.
Можно попробовать такой вариант:
1) В web-приложении сделать шифрование данных симметричным алгоритмом на стороне клиента
2) Админ и программист не должны участвовать в генерации ключей шифрования для алгоритма
3) Пользователям раздаются ключи для доступа к информации.
Итого:
1) Данные в базе хранятся в зашифрованном виде
2) Данные между БД и приложением ходят в зашифрованном виде
3) Ключи хранятся у пользователей и никуда не передаются
Секретные данные не будут индексироваться. По ним не будет производиться поиск.
Про "тыкву" - да. Но с этим приходится мириться. Тут уж или высокий уровень секретности без возможностей восстановления через бэкдоры или такого рода данные вообще не храним.
Данные о зарплате заводятся в проект наверное не только для того, чтобы там храниться, но и как-то участвуют в вычислениях.
Поэтому если у Вас трехзвенка, то защититься от админа сервера приложений невозможно - данные должны быть там в дешифрованном виде.
Если же есть возможность работу над этими "высокосекретными" данными всю производить по двухзвенной схеме - в клиентском браузере, то тогда - да, шифрование с должными предосторожностями (с рандомизацией и защитой от replay attack) Вас в принципе спасет. Хотя задача всё равно будет нетривиальной.
P.S. Кстати, Вы уверены, что ставку нельзя будет "вычислить обратно", зная сумму оплаты за этап и его трудозатраты в часах ?
Не совсем ответ на Ваш вопрос, но всё же. Называть сведения о ЗП "высокосекретными", мягко говоря, неверно. Они не секретны, а конфиденциальны, и обычно защищаются пунктами трудового договора. Мне кажется, что у вас сейчас проблема в том, что поставлена задача, оторванная от реальности. Вы пытаетесь потратить уйму времени на разработку, породив при этом кучу проблем в последующей поддержке - на фикцию. Даже при успешной реализации, подумайте, что улучшится на предприятии? Сотрудники перестанут общаться между собой (в т.ч. тихонько интересуясь кто сколько "получает")? Компания при публикации резюме перестанет указывать вилку ЗП? Я бы порекомендовал серьезно задуматься над постановкой задачи, очень похоже на стрельбу из пушки по воробьям...
Мной озвученная постановка - сухая техническая выжимка полной постановки задачи от руководства нашего головного офиса. Требуется для точного рассчета эффективности и нижней планки ставок по контрактам с клиентами. Ориентировочные з/п вилки персоналу естественно известны, но точные суммы (кроме собственной) - нет.
Вы слегка сгущаете краски про необщение сотрудников и пр. Как-то же существуем на рынке более 15 лет...
To sim3x: Я примерно такую схему и предполагаю, что программисты все делают, код ревьюируется на отсутствие секретных данных в логах системы или серверов (пока проблема с логами БД), админы готовят процедуру развертывания (и возможно даже развертывают) я cам генерю ключи и сам обучаю пользователей. Но все еще непобедима проблема перехвата или ключа или пароля к ключу.
To m0rd: Вот этот вариант возможно и нужно реализовывать. Только пока неясно как (хотелось бы пример микроархитектуры).
Т.е. все получается открытым образом с UI уровня (работа по SSL с сервером) и назад тоже, и шифруется на бэкэнде. До момента шифрования нужно все очень внимательно ревьюить, чтоб никакие перехваты в коде не произошли и никакие внедрения чужеродного кода были невозможны (особенно на UI). Шифровать можно как симметричным, так и асиметричным ключем (тогда область кэширования ключей на страницах может быть разной). А на сторону БД уйдут уже стразу зашифрованные данные. Тем самым мы защищаемся от пока непобедимых нижнеуровневых логов БД. Т.е. ключи шифрования каждый раз предоставляются самим пользователем.
Но это все теория. Конечно. хотелось бы увидеть примерчик. А то я подозреваю в большом количестве невидимых "граблей", на которые заранее не хотелось бы наступать.
Средний
