Открыть список
Как стать автором
Обновить

Комментарии 10

Я правильно понял, что в базе документ шифруется симметричным ключом (один на документ?), и этот ключ передается клиенту (в зашифрованном виде) для последующей работы с документом?

Один ключ генерируется под одну метку. А метка выставляется на множество документов, т.е. все эти документы будут зашифрованы одним ключом.
т.е. компрометация сервера приведет к компрометации всех документов? Ловко придумано.
А вот раньше было по-другому: хранили документ в тяжелом сейфе, ключики в кармане. А если надо было его перевезти — вызывали фельдегеря. Он клал его в свою сумку, закрывал, опечатывал и вез куда надо. А там из сумки опять в тяжелый сейф, с другими ключиками. Вот как-то так и жили. А тут революция, новая архитектура, возим прямо в сейфе. А копии всех ключей в гардеробе на первом этаже.
В нашем случае компрометация сервера не учитывается, получается что если сервер будет скомпрометирован сразу — то документы еще не зашифрованы и можно делать будет с ними что хочешь. В случае же если сервер будет скомпрометирован в ходе работы — то уже зашифрованные документы будет невозможно расшифровать без доступа к исходному ключу.
«чтобы зашифровать сгенерированный ранее ключ и отправить пользователю. »
Из этого можно сделать вывод, что ключи хранятся на сервере. Все ключи. И они могут быть скомпрометированы при компрометации сервера.

Тут можно рассмотреть все под таким углом зрения, что "документы" физически представлены сервером а "сейф" — серверной комнатой. Ключи от сейфа можно по прежнему в кармане хранить. При перевозке сервера — вызываем фельдегеря, он кладет его в свою сумку, закрывает, опечатывает и везет, куда надо. Все как в старые добрые времена.

Если изначально документ у пользователя был расшифрован то да, скомпрометированный сервер отправит клиенту нужный ему ключ и в дальнейшем уже можно будет расшифровать документ используя этот ключ. А если компрометация сервера произошла после зашифровки документов — то нельзя будет расшифровать документ, так как «другой сервер» не будет же знать о ключах которые хранятся на «хорошем сервере».

Алексей, то что вы описали очень похоже на стандартные роли windows server AD RMS + FCI + ADFS, или уже современное решение все в одном Azure AIP. Последнее кстати самое понятное для конечного пользователя из тех что я видел

То есть я имел ввиду, рассматривали эти решения?

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

Информация

Дата основания
Местоположение
Россия
Сайт
crosstech.su
Численность
51–100 человек
Дата регистрации

Блог на Хабре