Чи безпечно зберігати критичні паролі в змінній середовищі сервера?

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

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

Це справді найкращий спосіб уникнути паролів у текстових файлах конфігурації чи є кращий спосіб?

Якщо ви працюєте в системі Linux, перегляньте / proc / * / environment і вирішіть, чи змінні середовища є хорошим місцем для зберігання конфіденційної інформації чи ні. / proc / self - це поточний процес:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

Не забувайте, що річ, що встановлює змінну оточення, ймовірно, читає файл десь.

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

Правильний спосіб зробити це - запустити програму як обліковий запис з обмеженими можливостями та зберігати пароль у файлі, захищеному дозволами на рівні файлової системи. Сподіваємось, ви можете "включити" файл або подібний файл, щоб уникнути пароля від системи контролю версій (якщо припустимо, що VCS не контролює безпеку). Щоб захиститись від ненавмисного розкриття інформації, затемніть пароль, проте який ви хочете - base64 кодує його, використовуйте pgp для шифрування, що б не мало сенсу в наборі параметрів вашої серверної програми. Якщо ви пишете програму для цього, найкраще, що ви можете зробити, - це запросити користувача на пароль лише тоді, коли це необхідно, а потім очистіть цей пароль із пам'яті, як тільки він буде використаний.

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

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

Що б я зробив, якби справді хотів захистити деяку інформацію в критичній для місії системі:

1. Використовуйте повне шифрування диска, щоб вміст усього постійного сховища було зашифровано.

2. Обмежити фізичний доступ до машин. Заблокуйте корпус машини захищеним механізмом блокування та контролюйте фізичний доступ до клавіш. Наймайте м'язів (озброєних охоронців), щоб бути воротарями для доступу.

3. Закріпити дрібнозернистий обов'язковий контроль доступу (MAC) в операційній системі пристрою. Ви можете почати щось із типу SELinux в GNU / Linux і встановити його на Enforcing, а потім налаштувати політику під точні потреби виробничого програмного забезпечення, дозволяючи цим обліковим записам точно (і тільки) потрібні їм дозволи до потрібних файлів.

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

5. Переконайтеся, що у вас є підключення до мережевих спеціалістів, щоб подбати про дозволи брандмауера, щоб мінімізувати витримку атаки по мережі. Аудит (тест на проникнення, а також тест коду на білому дошці) будь-яке програмне забезпечення, яке взаємодіє із зовнішніми системами, особливо з публічним Інтернетом. "Інтерфейси" включають не тільки прямі мережеві з'єднання, але також читання або запис "ненадійних" даних (дані, байти яких походять з-за оперативної пам'яті / диска / процесора захищеного сервера).

Це не повний перелік, але особливо пункт 4, ймовірно, має відношення до вас, хоча якщо ви не виконаєте принаймні кроки з 1 по 3, розгляд пунктів 4 і пункту 5 не дуже допоможе вам, оскільки ваш Система не захищена на досить фундаментальному рівні.

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

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

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

Недоліком у вашому сценарії є "створити відповідну змінну середовища, коли серверна система налаштована". Змінна середовища є динамічною властивістю процесу. Ви не можете створити її під час налаштування системи, якщо ви, маючи на увазі, маєте на увазі щось, що переживе перезавантаження. Ви маєте на увазі, що, мабуть, адміністратор організував присутність цієї змінної у середовищі, коли певний користувач входить у систему. Це робиться через файл конфігурації (як правило, ~/.pam_environmentабо ~/.profileфайл, прочитаний з ~/.profile). Таким чином, це рішення насправді не висуває пароль із файлів конфігурації.

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

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