Что такое канонический способ управления криптографическими ключами, связанными с определенным исходным кодом? (например, пары ключей SSH или RSA, сильно связанные с конкретной программой).Хороший способ управления криптографическими ключами?
Я неохотно проверяю это на контроль версий по очевидным причинам, но я не хочу, чтобы они находились только на локальных жестких дисках нескольких людей.
Вы можете поместить их в управление версиями зашифрованными, и пусть только несколько человек знают пароль. Это имеет то преимущество, что они хранятся вместе с кодом и что вы можете легко их обновлять, но файлы бесполезны для злоумышленника (при условии, что вы используете надежный пароль).
Ответ на промышленную прочность заключается в использовании Hardware Security Module (HSM).
Несколько менее причудливый ответ заключается в том, чтобы сохранить печатную и/или электронную копию в компании в безопасности.
Когда я отвечал за управление ключами подписи программного обеспечения, я сохранил ключ GPG на двух хостах в нашей сети с отличной защитой хоста и хорошими брандмауэрами. Я сжег две копии CD: один для нашего технического директора и один для нашего генерального директора. (Я просто сказал ему: «Не теряйте этот диск. Не откладывайте его». Проще говоря. :)
кодовая фраза для ключа была другая. Я вспомнил это. Сотрудник, который заполнил бы меня, если бы я отсутствовал, знал кодовую фразу. Я попросил нашего генерального директора и технического директора держать ключевую фразу от компакт-диска с ключом.
Конечно, это было для ключей, которые мы будем использовать не чаще одного раза в день, и часто не в течение нескольких дней или недель, когда мы выпустили обновления для системы безопасности. Если ваши потребности отличаются от наших, вам может понадобиться сделать что-то еще.
Очень хороший вопрос и нет абсолютного правильного ответа ИМО.
Вопросы спросить себя:
1) Каково влияние ключа становится известной
2) Каков уровень доверия в компании
3) Насколько важно для инженеров, чтобы иметь возможность производить выпуск строит
Идеи я использовал на протяжении многих лет включают в себя:
Хранится в хранилище управления версиями, но с ограниченным «secure_group» доступа
Pros
Cons
Ключи, введенные системой сборки Стандартная сборка содержит фиктивный ключ (ключи).
Release сборок генерируется сервер сборки, который не заменяет или впрыскивает ключи производства
Pros
Против
- Все данные/системы должны поддерживать фиктивный ключ
- Построить сервер становится узкое место/критически важный компонент
Пользовательского DRM пакет
Создайте свой собственный пакет ключей RSA, т.е. зашифрован заголовок с сеансом генерируется симметричный ключ для шифрования данных ключа. DRM подход также позволяет делать такие вещи, как набор пакетов истечения времени или максимального количество использований
Pros
Cons
- много пользовательского кода
- Все построения системы должны быть реорганизованы, чтобы прочитать основные данные пакета - Key Package необходимо Lib/API для извлечения и поэтому инженер может читать ключевые данные
Есть другие варианты таких как защищенный сервер шифрования или веб-сайты аутентификации с двумя проходами для извлечения ключевых данных.
В моем опыте нет идеального решения, хотя я был бы очень интересно услышать предложения или мнения от сообщества
Надежда, что помогает