Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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