Налаштування Azure Key Vault: де витікають секрети та ключі
Майже кожен витік починається не зі зламу, а із зручності. Рядок підключення до бази осідає у файлі конфігурації застосунку, пароль — у змінній середовища на стенді, а ключ доступу до сховища секретів лежить прямо в скрипті розгортання.
Файл потрапляє в репозиторій, репозиторій — у зовнішню копію, і далі секрет живе в історії комітів, навіть після того як рядок видалили.
Окрема історія — ключі доступу, видані «тимчасово». Їх отримують агент збірки, аналітик для налагодження, підрядник на час проєкту. Через місяць ніхто не пам'ятає, які з них ще використовуються, тому ротація не виконується: страшно відкликати робочий ключ. Так один безстроковий доступ переживає кілька змін команди.
Сертифікати ламають сервіси не тому, що їх складно випустити, а тому що не вибудувана ротація.
Приватний ключ зберігається на одній машині, оновлення роблять вручну за чужим нагадуванням, а після закінчення строку відкат уже не допомагає — новий сертифікат нікуди покласти без зупинки сервісу.
І най дорожче за наслідками: доступ до секретів середовищ не розділений.
Тестовий стенд і продуктивний контур читають один і той самий набір паролів застосунків, розробник бачить продуктивні облікові дані, а під час розбору інциденту неможливо відповісти, хто і коли звертався до секрету. Розбираємо, як це закривається на рівні сховища, політик доступу та ротації.
Що дає кероване зберігання секретів і ключів
Секрети живуть довше, ніж їхні власники: рядки підключення осідають у файлах конфігурації на серверах, у змінних середовища агентів збірки та в листуванні. Коли інженер іде з проєкту, відкликання доступу перетворюється на пошук — де ще прописаний цей ключ і хто ним користується. Поки триває пошук, ключ залишається робочим.
Azure Key Vault прибирає локальні копії як клас: секрет зберігається в одному місці, а застосунок отримує його за своїм службовим обліковим записом, а не за спільним рядком у файлі.
Права надаються ролями на рівні окремого секрету, тому збирач читає лише те, що йому справді потрібно. Зміна значення не вимагає правок конфігурацій і перезапуску середовища — сервіс підхоплює актуальну версію під час наступного звернення.
Ротація секретів і керування життєвим циклом ключів переводяться в розклад: строк дії, сповіщення заздалегідь, перевипуск сертифіката без простою. У ключа зберігаються версії — якщо нова не підійшла, відкат на попередню займає хвилини й не потребує відновлення з резервної копії.
Аудит звернень до секретів відповідає на питання «хто це бачив»: журнал фіксує обліковий запис, час і об'єкт звернення. Відкликання доступу — одна операція, що набирає чинності одразу, бо відкликати на боці застосунку нічого.
Час ротації скорочується з годин ручної роботи до хвилин, а відмови через прострочені сертифікати й забуті ключі зникають разом із ручними правками конфігурацій.
Варіанти підключення застосунків до сховища
Способів підключити сервіс до сховища кілька, і вибирають між ними не за смаком, а за тим, чи вміє сервіс підтверджувати свою ідентичність сам.
Керована ідентичність — базовий варіант: платформа видає токен, і в коді не залишається ні пароля, ні рядка підключення, а доступ відкликається разом із ресурсом. Сервісне підключення потрібне там, де це неможливо — права видає окремий обліковий запис з урізаною роллю.
Мережеві обмеження не замінюють перевірку ідентичності, а звужують периметр, з якого сховище взагалі доступне.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Керована ідентичність | Сервіси всередині підписки: віртуальні машини, контейнери, функції | Лише для ресурсів, які вміють отримувати ідентичність; права надаються на рівні сховища |
| Сервісне підключення | Зовнішні системи та застарілі застосунки без підтримки ідентичностей | Облікові дані живуть довше й потребують ротації, потрібен окремий контроль доступу |
| Приватна точка входу | Трафік до сховища не повинен виходити в публічну мережу | Потребує приватної мережі та внутрішньої адресації, ускладнює налагодження з робочої машини |
| Мережева ізоляція сховища | Сховище потрібно закрити від зовнішніх звернень | Список дозволених підмереж доводиться підтримувати в актуальному стані |
На практиці режими комбінують: внутрішні сервіси ходять за ідентичностями, сховище закрито приватною точкою входу та списком підмереж, а облікові записи залишаються лише для зовнішніх споживачів.
Такий набір дає перевірювану картину — видно, хто звертається до секретів, і зрозуміло, що станеться під час відкликання доступу.
Порядок впровадження: від аудиту секретів до передачі
Порядок робіт будуємо так, щоб перенесення не узаконило наявний безлад: спочатку повна картина секретів та їхніх власників, потім схема доступу, і лише потім міграція.
Кожен етап завершується артефактом, який можна перевірити — картою секретів, матрицею ролей, результатами контрольних сценаріїв.
- Аудит секретів. Інвентаризуємо сховища паролів у репозиторіях, змінні конвеєрів, конфігурації застосунків і файли на серверах. Для кожного запису фіксуємо власника, критичність, строк життя та дублікати — без цього ротація й видалення неможливі.
- Схема розмежування доступу. Розводимо сховища за середовищами, видаємо ролі на конкретні секрети замість прав на весь контур. Робочі навантаження читають значення через керовані ідентичності, службові облікові записи з довгоживучими ключами виводимо з обігу, публічний доступ закриваємо.
- Міграція секретів. Переносимо поетапно, з версіюванням і звіркою значень з еталоном. Застосунки та конвеєри перемикаємо на читання зі сховища, старі копії позначаємо до видалення й знімаємо після контрольного періоду.
- Налаштування ротації. Задаємо строк життя та розклад зміни паролів і ключів, автоматизуємо оновлення й сповіщення власнику. Окремо перевіряємо, що сервіс підхоплює нову версію без перезапуску та ручного втручання.
- Перевірка відмов. Проганяємо сценарії: недоступність сховища, відкликаний доступ, забутий секрет, помилкове видалення. Вмикаємо захист від безповоротної втрати та відновлення з резервної копії.
- Приймання та передача. Перевіряємо права з кожного середовища за контрольними сценаріями, віддаємо карту сховищ, матрицю ролей, регламент ротації та порядок відновлення. Чергова команда отримує інструкції та розбір типових інцидентів.
Політики доступу, ролі та схеми зберігання ключів
Після введення в експлуатацію у вас залишається не набір налаштувань «як зробили — так і працює», а керований контур: рольова модель, розділені середовища, письмові регламенти.
Передаємо його у вигляді переліку, за яким новий інженер розбереться без історії листування, а ви приймете роботу за пунктами.
- Ролі та права доступу. Матриця «хто і що може»: адміністратор сховища, відповідальний за секрети, сервісний споживач лише на читання. Права мінімально необхідні, окремий суб'єкт на кожного, без спільних облікових записів.
- Розділення середовищ. Розробка, передпродакшн і продакшн живуть в окремих сховищах зі своїми правами: витік тестових значень не відкриває доступ до робочих.
- Політики сховища. М'яке видалення та захист від очищення, мережеві обмеження, журналювання звернень до секретів з вивантаженням у спільний моніторинг.
- Регламент ротації секретів. За кожним класом: строк життя, власник, порядок випуску нової версії та відкат на попередню без зупинки сервісу.
- Ротація сертифікатів. Схема автопродовження, календар сповіщень заздалегідь до закінчення та відповідальний за ручний випуск, якщо автопродовження недоступне.
- Документація щодо секретів. Карта сховища: ім'я, призначення, власник, споживач, строк ротації, порядок відновлення.
- Видача та відкликання доступу. Як запитується доступ і що знімається під час виходу співробітника або виведення сервісу з експлуатації.
Проходимо цей перелік разом з вашою командою перед здачею — розбіжності закриваємо до передачі, а не після.
Кейс: як секрети переїхали з конфігурацій у сховище
Замовник — продуктова команда з трьома середовищами та 30+ сервісами: рядки підключення до баз, ключі зовнішніх API та сертифікати лежали в змінних середовища й маніфестах репозиторію.
Ротація одного ключа означала ручний обхід сервісів, а вихід людини з доступами запускав зміну секретів у всьому контурі. Один забутий маніфест — і продакшн віддавав відмову авторизації при цілком живих екземплярах застосунку.
Що змінили
Секрети переїхали в Azure Key Vault з доступом за керованими ідентичностями: застосунок отримує значення за роллю, пароля й ключа в конфігурації більше немає. Сховища розділили за середовищами, права видали групами, а версіювання зберегло попередні значення для відкату.
Сертифікати перевели на автопродовження — актуальна версія забирається під час старту, без ручної заміни.
Показники до і після
Міграцію пройшли 34 сервіси. Відмови через прострочені сертифікати та неузгоджені ключі — 3-4 за квартал — зникли: продовження йде без участі людини.
Ротація ключа займає одну операцію замість планового вікна з обходом команд, а відновлення доступу після зміни співробітника — хвилини замість годин.
Сканер секретів перестав знаходити значення в репозиторіях, а журнал звернень до сховища показав реальні зв'язки сервісів: видно, хто і що читає, і зайві права знімаються за фактом, а не за пам'яттю.
Чим сховище секретів відрізняється від змінних середовища
Часта суперечка: якщо секрет вміщається у змінну середовища, навіщо окреме сховище? Різниця не в зручності, а в межі довіри.
Змінні середовища процес отримує під час старту, і далі вони видимі кожному, хто має доступ до хоста, до опису контейнера або до знімка процесу під час збою.
Файли конфігурації закривають іншу частину завдання: їх версіонують, перевіряють, відкочують. Але секрет у репозиторії живе довше, ніж доступ людини, яка його туди поклала, а шифрування файлу просто переносить питання на носій ключа.
| Спосіб | Коли підходить | Обмеження |
|---|---|---|
| Змінні середовища | Адреси сервісів, режими роботи, рівень логів | Немає історії версій, ротація потребує перезапуску, значення потрапляють у логи та описи контейнерів |
| Файли конфігурації | Налаштування, які мають проходити перевірку | Секрет залишається в репозиторії та на диску, доступ не відкликається точково |
| Кероване сховище | Ключі, паролі, рядки підключення, сертифікати | Потрібні права застосунку на сховище та зрозуміла схема ротації |
Кероване сховище розділяє доступ і значення: застосунок отримує секрет за своєю ідентичністю, права видаються роллю, а версії ключів і сертифікатів змінюються окремо від релізу. В Azure Key Vault це підтверджує журнал звернень — видно, хто і коли читав секрет.
Вибір способу зберігання зводиться до трьох питань: що буде, якщо значення потрапить у лог, хто і наскільки швидко зможе його змінити, як відкликати доступ у співробітника, що пішов. Якщо хоча б на одне «ніяк» — місце такого значення у сховищі.
Часті питання про інтеграцію сховища із сервісами
Сумніви стосуються не самого налаштування, а поведінки системи, коли щось ламається: сховище недоступне, сервіс живе поза хмарним контуром, секрет треба змінити без перезапуску, доступ — передати іншій команді. Нижче — відповіді на сценарії, які найчастіше спливають на архітектурному розборі.
Що буде, якщо сховище стане недоступним?
Застосунок не звертається до сховища на кожен запит: значення читаються під час старту й тримаються в пам'яті, повтор іде лише після відмови авторизації. На боці сервісу вмикаємо короткий кеш і роботу на останній валідній версії з повтором і зростаючою паузою.
Від випадкового видалення сховище захищає незворотне блокування — помилка не зносить ключі та сертифікати.
Як підключаються сервіси поза хмарою?
Зовнішній сервіс підключається через приватний канал або за списком дозволених адрес — відкритого доступу з інтернету не залишається. Кожному споживачу видаємо окрему ідентичність і мінімальну роль, тому один скомпрометований набір прав не відкриває решту секретів.
Як проходить ротація без простою?
Зміна секрету — це дві версії, що живуть одночасно: застосунки приймають і стару, і нову, потім стара вимикається. Для баз даних порядок такий: спочатку змінюємо пароль у самій системі, потім версію у сховищі. Перезапуск не потрібен — нова версія підхоплюється за подією або за таймером.
Що з доступом після передачі проєкту?
Права описані як код: власники, ролі та ідентичності лежать у репозиторії, тому передача команді — це зміна власника й відкликання зайвих ролей, а не ручний обхід консолі. В аварії працює окрема процедура: доступ за заявкою, на обмежений час, із записом у журнал.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою робіт і планом впровадження, нам потрібен не повний пакет документації, а зріз за кількома пунктами.
З цим набором вихідних даних ми за один прохід визначаємо обсяг робіт, схему розділення сховищ в Azure Key Vault і порядок перенесення — без уточнювальних кіл і листування на два тижні.
- Перелік сервісів і застосунків, яким потрібні секрети, ключі або сертифікати: назва, середовище (продуктивне, передпродуктивне, тестове), власник з боку замовника.
- Поточне місце зберігання: файли конфігурації в репозиторії, змінні середовища на серверах, саморобне рішення, розрізнені записи в адміністраторів — як є, без приведення до ладу.
- Вимоги до доступу: які команди та ролі читають секрети, хто випускає й відкликає, чи потрібна ізоляція за середовищами та заборона на читання продуктивних значень із тестового контуру.
- Вимоги до середовища: хмара або гібридна схема, наявність приватних точок входу, як сервіси підтверджують свою автентичність один перед одним, чи потрібні окремі контури під чутливі дані.
- Правила життєвого циклу: строк дії секретів і сертифікатів, періодичність зміни, порядок дій під час компрометації, куди складаються журнали доступу і на який строк зберігання.
- Обмеження за строками: вікна, коли допустимі перемикання, критичні періоди на кшталт закриття звітності, порядок погодження змін.
- Критерії приймання: що вважаємо результатом — сервіс отримує секрет автоматично, без ручного втручання, а відкат на попередню схему перевірено на тестовому контурі.
Описуйте картину як є, навіть якщо зараз ключі передають у листуванні: чим точніші вихідні дані, тим менше припущень в оцінці. У відповідь надішлемо план етапів, склад робіт, розподіл відповідальності та точку старту.
