Чи є безпечний спосіб зберігання паролів, які використовуються для ssh скриптом?

Отже, спочатку я знаю, що я повинен використовувати ключ auth із SSH. Не потрібно мені це пояснювати.

Проблема тут полягає в тому, що у мене є (велика) купа серверів, і мені потрібно мати сценарій, щоб можна було з'єднати кожен із них.

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

Тож для деяких я просто зберігав паролі в db, і мій сценарій запускаю його, коли потрібно. Проблема полягає в тому, що це виглядає не дуже безпечно. Чи є спосіб зробити це трохи безпечнішим?

Як якийсь конкретний спосіб його зберігання?

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

Якщо сценарій потрібно запускати автономно, всі ставки виключаються. Відповідь тут - ні, немає абсолютно безпечного способу зберігання паролів у такому середовищі . Не існує абсолютно безпечного і практичного способу зробити що-небудь.

Замість того, щоб намагатися уникати неминучого, слід зосередитися на обороні глибоко .

По-перше, звичайно, ви повинні захистити паролі належним чином . Зазвичай це означає зберігати їх у файлі, окремо від сценарію, та налаштовувати обмежувальні права доступу до файлової системи . Це майже все, що ви можете зробити на цьому фронті, з точки зору безпеки.

Інші заходи, безумовно, можуть додати неясність процесу. Шифрування паролів змусить зловмисника шукати ключ розшифровки. Використання сховища, захищеного операційною системою, як правило, захищає від доступу інших користувачів до вашого ключа (тому воно не надає переваги перед дозволами файлової системи, крім складних для атаки та використання). Ці заходи затягнуть атаку, але, звичайно, не завадять їй проти визначеного нападника.

Тепер давайте на хвилину розглянемо паролі як загальнодоступні . Що ви можете зробити, щоб зменшити шкоду?

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

Можливо, ви також хочете розглянути можливість переміщення логіки сценарію на сервери . Таким чином, ви отримуєте менший інтерфейс, який простіше контролювати, а особливо ...

Монітор . Завжди контролюйте доступ до серверів. Переважно аутентифікацію журналу та команди, виконані для журналу додавання лише . Не забудьте відстежувати зміни файлів сценарію, використовуючи auditd, наприклад,.

Звичайно, багато з цих механізмів не є корисними, якщо у вас немає контролю над серверами, як видно з вашого питання. Якщо це так, я б радив вам зв’язатися з людьми, які адмініструють сервери, та повідомте їх про ваш сценарій та можливі помилки безпеки.

Коротка відповідь: Ні.

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

Іншими словами, вам потрібно довго поглянути на поглиблену безпеку як на сервері, з якого виконується сценарій, так і в мережі та на цільових серверах.

Ви можете зашифрувати паролі у своєму db другим паролем і зберегти цей пароль на окремому (3-му) автоматі та мати систему, де сценарій, який потребує паролів із db, спочатку з'єднує цю третю машину, щоб отримати пароль розшифровки. , розшифровує пароль в db з паролем, який він отримав від 3-ї машини і робить це спрацьованим.

Звичайно, це насправді не додає додаткової безпеки, зловмисник з достатніми привілеями також може просто вимагати пароль від 3-ї машини.

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

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