Які переваги розміщення секретних значень веб-сайту як змінних середовища?

Вказівки щодо девепсів за адресою https://12factor.net/config пропонують розмістити секрети веб-сайту (паролі бази даних, ключі api тощо) у змінні середовища. Які переваги має те, що замість використання текстових файлів (JSON, XML, YAML, INI чи подібних) ігнорується з контролю версій?

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

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

Враховуючи мій власний досвід, ви, по суті, отримали три варіанти із суміжними перевагами та недоліками:

Зберігання даних у конфігураційних файлах.

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

Переваги:

• Дуже просто ізолювати та контролювати доступ, особливо якщо ви використовуєте такі речі, як SELinux або AppArmor для покращення загальної безпеки системи.
• Зазвичай їх легко змінити для користувачів, які не є технічними (це перевага для опублікованого програмного забезпечення, але не обов'язково для програмного забезпечення, специфічного для вашої організації).
• Легко керувати на великих групах серверів. Там є всілякі інструменти для розгортання конфігурації.
• Розумно легко перевірити, яка саме конфігурація використовується.
• Для добре написаного додатку, як правило, ви можете змінити конфігурацію, не припиняючи обслуговування, оновивши конфігураційний файл, а потім надіслати певний сигнал додатку (як правило, SIGHUP).

Недоліки:

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

Зберігання даних у змінних середовища.

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

Переваги:

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

Недоліки

• У більшості UNIX систем отримати доступ до змінних оточуючих процесів досить просто. Деякі системи пропонують способи пом'якшити це (наприклад, параметр hidepidмонтажу для /procLInux), але вони не включені за замовчуванням і не захищають від атак користувача, якому належить процес.
• Не точно бачити точні налаштування, якими ви користуєтесь, якщо правильно вирішувати вищезазначені проблеми безпеки.
• Ви повинні довіряти додатку, щоб очистити навколишнє середовище, коли він породжує дочірні процеси, інакше він просочиться інформацією.
• Ви не можете легко змінити конфігурацію без повного перезавантаження програми.

Використовуйте аргументи командного рядка для передачі даних.

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

Переваги:

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

Недоліки:

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

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

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

Навіть якщо є якісь компроміси, пов’язані із безпекою, які слід здійснити, коли мова йде про змінні середовища чи файли, я не думаю, що безпека була основною рушійною силою цієї рекомендації. Пам’ятайте, автори 12factor.net також є (або також були?) Розробниками Heroku PaaS. Отримати всіх бажаючих використовувати змінні середовища, ймовірно, трохи спростило їх розвиток. Існує велика кількість різноманітних форматів та місць конфігураційних файлів, і їх було б важко підтримувати. Змінні середовища легко порівняно.

Не потрібно багато фантазії, щоб відгадати деякі розмови, які були у нього.

Розробник A: "А цей інтерфейс секретного файлу конфігурації занадто захаращений! Чи насправді нам потрібно мати спадне меню, яке перемикається між json, xml та csv?"

Розробник B: "О, життя було б таким грандіозним, якби тільки кожен використовував змінні середовища для конфігурації програми".

Розробник A: "Насправді для цього є певні причини, пов'язані з безпекою. Змінні середовища, ймовірно, не будуть випадково перевірені в контролі джерел."

Розробник B: "Чи не встановлюєте змінні середовища за допомогою сценарію, який запускає демон, або файл конфігурації?"

Розробник A: "Не в Heroku! Ми змусимо їх ввести їх в інтерфейс користувача".

Розробник B: "О, дивіться, попередження про моє доменне ім’я для 12factor.net тільки що вимкнулося." ¹

¹ : джерело: складено.

TL; DR

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

Конфігурація поза діапазону: відокремлення секретів від вихідного коду

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

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

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

Удосконаліть розділення: сервери, програми та ролі

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

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

Роздуми про безпеку

Хоча ретельне вивчення безпеки ядра / пам’яті / файлів не підходить для цієї відповіді, варто зазначити, що змінні середовища, що належним чином реалізовані, не менш безпечні, ніж «зашифровані» секрети. У будь-якому випадку цільова система все ж має зберігати розшифровану таємницю в пам'яті в якийсь момент, щоб використовувати її.

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

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

Особисто я б не рекомендував встановлювати змінні середовища, .bashrcоскільки вони стають видимими для всіх процесів, запущених оболонкою, але встановлювати їх на рівні демон / супервайзера (сценарій init / rc, systemd config), щоб їх область була обмежена, де потрібно .

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

Інший розгляд - це трубопроводи CI / CD - оскільки код проходить через різні середовища(наприклад, dev, test / qa, постановка, виробництво) характеристики навколишнього середовища (зони розгортання, деталі підключення до бази даних, облікові дані, IP-адреси, доменні імена тощо, тощо) найкраще встановлюються спеціальними інструментами / рамками управління конфігурацією та споживаються додатком процеси з навколишнього середовища (в DRY, пишіть один раз, виконайте будь-де моди). Традиційно, коли розробники прагнуть керувати цими операційними проблемами, вони, як правило, перевіряють файли конфігурації або шаблони, окрім коду, - а потім додають обхідні шляхи та інші складності, коли змінюються експлуатаційні вимоги (напр., Нові середовища / розгортання / сайти збираються, масштабованість / безпека зважити,

• Env-vars спрощує конфігурацію / складність в масштабі.
• Env-vars розміщує операційну конфігурацію прямо з командою, відповідальною за аспекти програми, що не стосуються коду, єдиним (якщо не стандартним) не обов'язковим чином.
• Env-vars підтримують заміну процесів master / supervisor (наприклад, god, monit, supervisord, sysvinit, systemd тощо), які підтримують додаток - і, звичайно, навіть систему розгортання (ОС, зображення контейнерів тощо) або інше як оперативні вимоги еволюціонувати / змінюватися. Незважаючи на те, що кожен мовний фреймворк в даний час має певний час виконання технологічних процесів, вони, як правило, є неповноцінними, більше підходять для середовищ розробників та / або збільшують складність у виробничих середовищах, що складаються з декількох мов.

Для виробництва я віддаю перевагу встановленню програм додатків у середовищі EnvironmentFile, такому, /etc/default/myapplication.confяке розгортається управлінням конфігурацією та встановлюється читабельним лише rootтаким чином, що systemd(або що-небудь інше з цього питання) може породжувати додаток у спеціально захищеного користувачем системи в приватному режимі групи . Оснащені спеціальними групами користувачів для opsта sudo- ці файли не читаються за замовчуванням у світі. Це сумісність з 12 факторами, що підтримує всі блага Dev + Ops plus, має всі переваги пристойної безпеки, в той же час дозволяючи розробникам / тестерам запускати власні EnvironmentFiles у середовищі dev / qa / test.

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

Веб-додатки Azure надають можливість використовувати цей шаблон, і він працює дуже добре.

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