Как я могу автоматизировать расшифровку gpg, которая использует парольную фразу, сохраняя ее в секрете?


13

Мне поручено автоматизировать расшифровку gpg с помощью cron (или любого Ubuntu Server-совместимого инструмента планирования заданий). Поскольку он должен быть автоматизирован, я использовал --passphraseего, но он попадает в историю оболочки, поэтому он виден в списке процессов.

Как я могу автоматизировать дешифрование, поддерживая при этом хорошие (желательно отличные) стандарты безопасности?

Пример будет высоко оценен.


Аргументы, подобные этому, видны в и psт. Д., Если вы не hidepidвключили /proc, но оболочка, выполняющая скрипт (из cron или иным способом), не является интерактивной и не должна записывать историю, если не настроена неправильно.
dave_thompson_085

Ответы:


23

Сохраните парольную фразу в файле, который доступен для чтения только пользователю задания cron, и используйте --passphrase-fileопцию сказать, gpgчтобы прочитать парольную фразу там.

Это гарантирует, что пароль не будет виден в информации о процессе в памяти. Уровень безопасности будет определяться уровнем доступа к файлу, в котором хранится фраза-пароль (а также уровнем доступа к файлу, содержащему ключ), в том числе в любом месте, где копируется его содержимое (поэтому будьте осторожны с резервными копиями), и автономная доступность (извлечение диска из сервера). Будет ли этот уровень безопасности достаточным, будет зависеть от ваших средств управления доступом к серверу, на котором хранится файл, физически и программно, а также от сценариев, которые вы пытаетесь смягчить.

Если вам нужны высокие стандарты безопасности, вам нужно использовать аппаратный модуль безопасности вместо того, чтобы хранить ваш ключ (и фразу-пароль) локально. Это не предотвратит использование ключа на месте , но предотвратит его копирование и использование в другом месте.


+1 за упоминание модуля аппаратной безопасности, единственное решение, действительно, этой загадки.
MariusMatutiae

Стивен, спасибо за упоминание модуля аппаратной безопасности, я проведу некоторые исследования. Спасибо, что указал мне правильное направление.
Zakk Coetzee

@StephenKitt Аппаратные ключи хороши, когда работают. Когда они этого не делают, ну ...
Satō

@ SatōKatsura верно, хотя я бы отметил, что Yubikey не HSM. (Что не означает, что HSM не уязвимы, конечно .)
Стивен Китт,

«Если вам нужны высокие стандарты безопасности», то вы не можете автоматически расшифровать или подписать задание.
JimmyB

5

Автоматическая расшифровка означает, что вы должны хранить парольную фразу где-то или не использовать парольную фразу (если вы не используете дополнительные опции, как указано в другом ответе, представленном Стивеном, когда я печатал свой)! Ни один из них не соответствует вашим требованиям к хорошим или высоким стандартам безопасности.

То есть ваше требование не совместимо с безопасностью.

Вы можете полагаться на такие вещи, как - вы должны быть пользователем root, я дал файлу, в котором хранится моя парольная фраза, действительно запутанное имя, я зашифровал базовые файловые системы и т. Д., И т. Д., Но они все слои которые тривиальны, чтобы обойти, если вы являетесь корнем в первую очередь.

Опция, которая не позволяет парольной фразе появляться в списке процессов --passphrase-file <file-name>.

Однако это не более безопасно, чем просто удалить фразу-пароль.


Спасибо, что объяснили Тони, вы дали лучшее представление по этому вопросу. Модуль аппаратного обеспечения безопасности, упомянутый Стивеном, будет главной целью.
Zakk Coetzee

@ZakkCoetzee: Как я сказал в другом ответе, что мешает злоумышленнику использовать HSM, если они root?
Мартин Боннер поддерживает Монику

@MartinBonner Как сказал выше Стивен Китт, он мешает им получить ключ, который определенно лучше, чем получить ключ.
Закк

Это, но не намного лучше. Спросите Diginotar (у которого был ключ в HSM, но он оставил HSM подключенным и с соответствующей смарт-картой в слоте, чтобы злоумышленник мог подписать несколько сертификатов атакующего.)
Мартин Боннер поддерживает Monica
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.