У меня есть клиент, который теперь требует, чтобы мы меняли все пароли каждые 90 дней из-за их интерпретации GDPR. Это нормально для веб-системы, которую мы разрабатываем для них, потому что мы можем просто реализовать эти правила. Но они также требуют, чтобы мы изменили пароли на наших ключах SSH, используемых для доступа к серверам, что, в общем, не нормально.
Если нет, есть ли какие-нибудь инструменты, которые мы можем использовать, чтобы справиться с этим? Я думаю:
а. Создайте новые ключи.
б. Распространите все открытые ключи на существующие серверы.
c. Удалите существующие открытые ключи.
d. Архивируйте старые приватные ключи.
Я читал здесь несколько сообщений о Puppet, но, насколько я понимаю, они стремятся только решить проблему с распределением открытых ключей между серверами, а не создавать новые ключи каждый энный день? Стоит ли мне продолжить исследование Puppet?
Каков стандарт сообщества, когда речь идет о сохранении пароля и ssh-ключах? Как ты это делаешь?
Заказчик здесь неправ и не понимает, о чем говорит. Изменение ключевой фразы на закрытом ключе - это очень плохо идея, потому что она имеет очень нелогичные свойства безопасности.
Обычно пользователи считают измененные пароли «уже не секретными». Они могут стать одноразовыми паролями для малоценных сайтов, онлайновыми именами / псевдонимами, анекдотами и т. Д., А любая бумага, на которой они написаны, может стать разоблаченным мусором.
Для парольной фразы, используемой для шифрования закрытого ключа, это не так! Пароль должен храниться в секрете навсегда если все привилегии, связанные с ключом, не были отозваны (и следующее не относится к ssh-ключам, но если кодовая фраза предназначена для ключа, используемого не только для подписи, но и для получения личных сообщений, тогда навсегда действительно означает навсегда). Это связано с возможностью того, что зашифрованный файл закрытого ключа был получен злоумышленником или где-то хранится (например, в резервной копии), где он может быть получен злоумышленником в будущем. Если кодовая фраза когда-либо раскрывается, она взламывается.
В некотором смысле закрытый ключ, который прошел через N парольных фраз за время своего существования, является 1 / N как безопасный, поскольку знание любой из прошлых парольных фраз достаточно для компрометации ключа, если злоумышленник имел доступ к зашифрованному файлу закрытого ключа.
А теперь вернемся к вашей проблеме.
Если бы заказчик не ухватился за это заблуждение, касающееся паролей ssh, и не вник в него, правильным решением было бы просто никогда не сообщать им об этом и следовать лучшим методам работы с ключами самостоятельно. Но теперь, когда они есть, вам, вероятно, придется что-то делать, чтобы их удовлетворить. Вы можете попытаться объяснить, как парольные фразы, шифрующие закрытые ключи, имеют свойства безопасности, отличные от паролей, но, учитывая, насколько ошибается клиент во многих вещах (истечение срока действия пароля в целом - плохая идея), я сомневаюсь, что это сработает.
Это оставляет вам задачу автоматизации системы распределения новых ключей. я буду сильно отговаривать вы от автоматизации системы генерации новых ключей централизованно, поскольку закрытые ключи никогда не должны перемещаться между машинами. Вместо этого у вас должны быть процессы / напоминания / сценарии, чтобы упростить работу сотрудников / подрядчиков на вашей стороне, которым необходим доступ для создания новых закрытых ключей и публикации соответствующих открытых ключей, а также иметь систему распределения открытых ключей (марионеточную или другую), которая вы используете их для отправки в системы, к которым они должны получить доступ.
К тому же: Одна вещь, которая может убедить клиента отказаться от этого, - это упоминание о том, что принципиально нет способа заставить новый закрытый ключ иметь парольную фразу, отличную от старой, или даже что у него вообще есть парольная фраза.
Ответ на ваш первый вопрос: "Можно ли изменить пароль на существующем ключе SSH?" Да. С openssh это так же просто, как ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
Проблема в том, что пароль находится в / в файле закрытого ключа, который представляет собой простой формат, который не поддерживает дату истечения срока действия. Кроме того, большая часть концепции аутентификации на основе ключей в ssh заключается в том, что закрытый ключ не управляется централизованно, он должен существовать только на рабочей станции пользователя, что делает практически невозможным применение политики истечения срока действия пароля для закрытого ключа.
Вместо этого: в каждой среде, в которой я был, до того, как политика паролей относилась к объекту учетной записи пользователя, а не к методу, используемому для доступа к указанной учетной записи. Когда срок действия пароля истек или учетная запись заблокирована, все методы доступа блокируются, включая ключ ssh.
Добавьте многофакторную аутентификацию, если вам нужна дополнительная безопасность для учетной записи.
Но мне любопытно, что сделали другие люди, чтобы решить ваши серьезные проблемы.
С помощью AuthorizedKeysCommand некоторый механизм истечения срока может быть реализован на стороне сервера. От простой проверки метки времени файла до чего-то более сложного.
Одна из возможностей, которая может быть или не быть достаточной, - это использование пользовательского CA SSH, который позволяет вам установить время жизни для подписанного ключа. Независимо от того, какую автоматизацию вы используете для подписания ключей, вы можете отказаться от подписи в течение более 90 дней. Затем добавьте открытый ключ для вашего пользовательского ЦС в TrustedUserCAKeys в / etc / ssh / sshd_config и установите для AuthorizedKeysFile значение none.
Вы можете использовать такой инструмент, как Хранилище Hashicorp для создания недолговечных подписанных ключей SSH. Каждый пользователь будет получать новый ключ каждый день (или около того). Вы должны пройти аутентификацию в Vault, чтобы получить сертификат, используя все, что вы используете сегодня, например, сервер LDAP.
Усилия по настройке этого не огромны, но, по моему опыту, больше, чем то, на что @Mark ссылался в своем комментарии. Вы в основном заменяете одну проблему (требования невежественного клиента) другой (управление шардом).
Но он позволяет использовать несколько других сценариев, таких как простое создание внутренних сертификатов X509 и управление паролями базы данных, секретами приложений в текстовом файле. Вы судите об усилиях и рентабельности инвестиций.
Также обратите внимание, что версия с открытым исходным кодом не имеет возможностей аварийного восстановления (в ней есть все остальное).
Вы можете использовать ключевой агент, который включает временные одноразовые пароли (TOTP). Теперь ваш «пароль» меняется каждую минуту.
Однако все здесь правы: это глупо.