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