Есть ли безопасный способ хранения паролей, используемых для ssh скриптом?

Итак, во-первых, я знаю, что я должен использовать ключ аутентификации с SSH. Не надо мне это объяснять.

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

Я использую аутентификацию по ключу всякий раз, когда могу, но это не возможно на каждом сервере (я не контролирую это). Так что SSH с логином или иногда телнетом.

Так что для некоторых я просто храню пароли в БД, и мой сценарий беру их при необходимости. Проблема в том, что это не выглядит безопасным. Есть ли способ сделать его немного безопаснее?

Как какой-то конкретный способ хранения?

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

Если скрипт должен работать автономно, все ставки отключены. Ответ здесь - нет, в такой среде нет абсолютно безопасного способа хранения паролей . Нет абсолютно безопасного и практичного способа что-либо сделать.

Вместо того, чтобы избегать неизбежного, вы должны сосредоточиться на глубокой защите .

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

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

Теперь давайте на время обработать пароли как общедоступные . Что вы можете сделать, чтобы уменьшить ущерб?

Старое и проверенное решение - ограничить возможности этих учетных данных. В системе UNIX хороший способ сделать это - настроить отдельного пользователя для вашего сценария и ограничить возможности этого пользователя как на обращающемся, так и на доступном сервере. Вы можете ограничить возможности пользователя на уровне SSH , на уровне оболочки или, возможно, с помощью механизма обязательного контроля доступа, такого как SELinux .

Что-то, что вы также можете рассмотреть, это переместить логику скрипта на серверы . Таким образом, вы получаете меньший интерфейс, которым легче управлять, и особенно ...

Монитор . Всегда следите за доступом к серверам. Желательно, чтобы протокол аутентификации и команды выполнялись только для добавления в журнал . Не забудьте, например, следить за изменениями файла скрипта auditd.

Конечно, многие из этих механизмов бесполезны, если у вас нет контроля над серверами, как кажется из вашего вопроса. Если это так, я бы посоветовал вам связаться с людьми, управляющими серверами, и сообщить им о вашем сценарии и потенциальных проблемах безопасности.

Короткий ответ - нет.

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

Другими словами, вам необходимо тщательно изучить всестороннюю безопасность как на сервере, с которого запускается скрипт, так и в сети и на целевых серверах.

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

Конечно, это не добавляет дополнительной безопасности, злоумышленник с достаточными правами может также просто запросить пароль с 3-го компьютера.

Но дело в том, что третье лицо может контролировать третье устройство, например, ваш босс или сотрудник службы безопасности, или третье лицо, контролирующее серверы, которые вы не контролируете.

Таким образом, вы можете сказать им, что если у них когда-нибудь возникнут проблемы, если вы бросите свою работу и они не доверяют заменяющему вас парню или просто хотят, чтобы ваши скрипты прекратили доступ к своим машинам, они могут отключить 3-ю машина, и ваши скрипты больше не будут иметь доступа к паролям.