Комментарии 15
Нв Хабре была эпидемия "курсовых" по криптографии. Теперь нам стоит ожидать такой же эпидемии дипломных проектов?
Обычно они хранятся в специальных файлах конфигурации проекта (appsettings.json) либо прямо в коде.
Я думал, так только индусы с Ютуба делают. Для чувствительных данных есть секреты.
"Недавно защитил свой диплом по разработке системы для управления корпоративными секретами. В честь этого хотел представить небольшую выжимку из моей работы."
Теперь понятно, почему в статье столько "воды" в начале.
“Сервер создаёт сейф и генерирует два ключа (приватный и публичный). Перед сохранением в БД приватный ключ шифруется с помощью AES”
Что за повальная мода генерировать приватный ключ на сервере? А потом его еже и АЕS шифровать. А ключи АЕS шифрования вы где хранить будете?
если говорить о безопасности, то хранение ключей должно быть распределённым- т.е. каждый сервис имеет свой приватный и публичный ключ.
Публичные ключи храниться на центральном сервере для простоты поиска/обновления,
Далее каждые сервис знает публичные ключи клиентов которые авторизированный на нем.
Как раздавать авторизацию( регистрировать публичные ключи- дело десятое, хоть в app.settings” храните.
поздравляю вы переизбрали OpenPGP :)
С понятием OpenPGP почему то во время поиска не сталкивался, спасибо, буду знать.
А ключи АЕS шифрования вы где хранить будете?
В моей реализации ключ храниться в appsettings.json. Для компрометации секретов потребуется: знать ключ от приложения из (appsettings.json\env) + шифр из БД.
если говорить о безопасности, то хранение ключей должно быть распределённым- т.е. каждый сервис имеет свой приватный и публичный ключ
Да вы правы, но требуется еще и удобство. Так или иначе что бы делиться секретами между разными клиентами, нужно либо уметь расшифровать секрет на стороне сервера, либо же заставлять всех клиентов обмениваться приватными ключами через сторонние каналы связи.
PS: Кстати, во время защиты комиссия также отметила этот момент :) посоветовала рассмотреть возможность распределённого хранения данных вместо централизации
Подключили ldap к passwork в свое время, админа переназначить не смогли - пароль его почему-то не проходил. Подключились к монге на тачке и поменяли ему айдишник на админовский. После этого компания отказалась от дальнейшего использования пассворка, но при этом подготовили все для переезда из 1pass. И ладно бы он развивался..дизайн придумали другой, либо полей накинули..
В Пассворке есть режим с шифрованием данных на клиенте, тогда у всех пользователей будет дополнительно свой мастер пароль и смена айдишника в базе не поможет получить доступ к данным.
Клиента еще поставить надо..а учитывая как народ такими вещами пользуется - смысл стремится к нулю. Я с пасворком работаю около 1,5 лет, кучу раз его перевозили, обновляли, переподнимали..ну сырая и страшная штука, как внутри, так и по дизайну, ну и способ установки...
Управление секретами IT-инфраструктуры