Уявіть собі таку ситуацію. Ви створюєте застосунок, і вам потрібен ключ АРІ для підключення до сервісу, пароль бази даних або ключ облікового запису зберігання. Отже, ви вставляєте його прямо в код, можливо, у файл конфігурації або змінну середовища. Усе працює чудово, доки ви не відправите цей код на GitHub або не поділитеся блокнотом із колегою. І в ту ж мить ваш секрет перестає бути секретом. Якщо цей код потрапить у чужі руки, вся ваша система опиниться під загрозою. Azure Key Vault – це інструмент, який вирішує цю проблему. Він надає безпечне місце для зберігання секретів, щоб вони ніколи не потрапляли у ваш код. Але ось у чому більшість людей помиляється. Просто мати Key Vault не означає автоматично гарантувати безпеку. Те, як ви його налаштовуєте, контролюєте доступ і призначаєте права, має не менше значення. До кінця цього епізоду ви дізнаєтеся, що таке Key Vault, що в ньому можна зберігати, як працює доступ і яка найбільша помилка може залишити ваші секрети відкритими.

Все простою мовою, без складних термінів, тільки головне, що вам потрібно. Отже, що саме таке Azure Key Vault? Що таке Azure Key Vault? Ось найпростіше визначення. Azure Key Vault – це хмарний цифровий сейф для ваших секретів. Це керований сервіс від Microsoft для зберігання ключів ARRI, паролів баз даних, рядків підключення, ключів шифрування та сертифікатів в одному центральному місці. Вам не потрібно турбуватися про інфраструктуру, оскільки Azure бере на себе оновлення, працездатність і безпеку. Ви просто користуєтеся ним. Уявіть це як офісну будівлю. У вас є робочі місця, кімнати для нарад і шафи з документами, але десь у підвалі є надійно захищена кімната сейф для найважливішого. Майстер ключі, готівка, юридичні документи. Ніхто не заходить туди без дозволу та автентифікації. І кожен раз, коли хтось відчиняє двері, це фіксується в журналі. Це і є Key Vault – безпечна кімната у підвалі вашої архітектури Azure.

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

Це основна служба безпеки. Будь-яка служба Azure може інтегруватися з нею. AppService, Functions, AKS, Data Factory, Synapse, Logic Apps, Conveyori, DevOps – усі вони вміють працювати з Key Vault. Вона стає основою вашої безпечної хмарної архітектури. І як тільки ви правильно її налаштуєте, ви взагалі перестанете думати про керування обліковими даними. Що можна зберігати? Тепер, коли ви знаєте, що таке Key Vault, давайте поговоримо про те, що саме можна в ній розмістити. У вас є три основні категорії – секрети, ключі та сертифікати. Кожна з них виконує свою функцію, і розуміння різниці допоможе вам правильно використовувати Key Vault. Почнемо з секретів. Це те, що люди зберігають найчастіше. Секрети – це рядки підключення, ключі ARRI, паролі до баз даних, ключі облікових записів зберігання, фактично всі повсякденні облікові дані, необхідні вашим програмам для взаємодії з іншими службами.

Замість того, щоб додавати їх у свій код чи конфігураційний файл, ви розміщуєте їх у Key Vault. Ваша програма отримує їх під час виконання, і ніхто ніколи не бачить їх у відкритому вигляді. Уявіть це, як замкнено шухлядо у вашій цифровій картотеці. Наступні – ключі. Це ключі шифрування для даних у стані спокою. Якщо ви використовуєте ключі, якими керує клієнт, для сховища ежур, баз даних SQL або шифрування дисків віртуальних машин, ці ключі можуть зберігатися в Key Vault. Це дає вам повний контроль над тим, хто і коли може ними користуватися. А якщо для дотримання вимог вам потрібні апаратні ключі, преміум-рівень забезпечить захист за допомогою HSM. Далі йдуть сертифікати. TLS та SSL – сертифікати для ваших веб-програм, ARRI та внутрішніх службових. Key Vault може зберігати їх, керувати їхнім життєвим циклом і навіть автоматично поновлювати, коли термін їхньої дії добігає кінця. Це справжній порятунок для тих, у кого сертифікат коли-небудь закінчувався о третій годині ночі в неділю.

Ось реальний приклад. Уявіть, що у вас є веб-програма, який потрібен рядок підключення до бази даних і ключ ARRI для сторонньої служби. За старим способом, ви б записали обидва значення у свій JSON-файл налаштувань програми. Скоріше за все, якщо цей файл потрапить у ваш репозиторі, будь-хто з доступом до коду зможе побачити ваші облікові дані бази даних. З Key Vault ви зберігаєте обидва значення як секрети. Ваша програма отримує їх під час запуску і вони ніколи не з'являються у вашому вихідному коді. Потрібно оновити пароль до бази даних. Оновіть його в Key Vault. Програма автоматично отримає нове значення під час наступного перезапуску. Жодних змін у коді чи повторних розгортань. Декого дивує те, що версійність тут вбудована. Коли ви оновлюєте секрет, Key Vault не перезаписує старе значення. Він створює нову версію. Старі версії зберігаються, тому ви можете відкотитися назад, якщо щось піде не так.

Це надзвичайно зручно під час інцидентів. Ви можете швидко повернутися до попереднього секрету, не згадуючи, яким було старе значення. Ви можете зберігати всі три типи – секрети, ключі та сертифікати – в одному сховищі. Але найкраща практика – розділяти їх за середовищами. Майте окреме сховище для розробки, для тестування та для продукту. Це запобігає випадковому використанню продуктового секрету в середовищі розробки та обмежує радіус ураження, якщо одне сховище буде скомпрометовано. Але зберігання секретів – це лише половина справи. Справжнє питання в тому, хто має до них доступ. Як працює контроль доступу? Тепер поговоримо про те, хто отримує доступ. У Key Vault є два різні способи контролю доступу до вмісту, і вибір має велике значення. Перша модель – це застарілі політики доступу. Це старий спосіб. Ви створюєте політики безпосередньо у сховищі і призначаєте дозволи конкретним користувачам або групам для певних типів даних, секретів, ключів або сертифікатів.

Проблема в тому, що ці політики прив'язані безпосередньо до сховища. Якщо у вас декілька сховищ, вам доведеться керувати політиками в кожному з них окремо. Це погано масштабується. Microsoft тепер не рекомендує їх використовувати, оскільки вони мають відомі проблеми з безпекою. Вони не підтримують керування привілеєваними ідентичностями та можуть створювати неочікувані шляхи підвищення привілеїв. Друга модель – це Azure RBAC – керування доступом на основі ролей. Це сучасний спосіб. Він використовує ідентичності EntraID і узгоджується з тим, як ви керуєте дозволами врешті Azure. Якщо ви вже знаєте, як надати комусь доступ до облікового запису зберігання чи віртуальної машини, ви вже знаєте, як надати їм доступ до Key Vault. Та сама система – ті самі шаблони. Ось головне правило – мінімальні привілеї. Надавайте лише той мінімальний доступ, який потрібен людині, не більше. Якщо комусь потрібно лише читати секрети, не давайте дозвіл на їх створення чи видалення.

Якщо комусь потрібно лише керувати сертифікатами, не давайте доступ до ключів. Дозвольте пройтися по ключових ролях. У вас є читач Key Vault, Key Vault Reader. Це дозволяє переглядати список секретів, але не читати їхні значення. Користувач секретів Key Vault – Key Vault Secrets User. Це дозволяє користувачеві читати значення секретів. І адміністратор секретів Key Vault – Key Vault Secrets Office. Це дозволяє створювати, оновлювати та видаляти секрети. Поміть та закономірність. Кожна роль стосується конкретних даних у сховищі, а не самого сховища. Тепер порівняйте це з загальними ролями власник, учасник чи тач. Вони застосовуються до сховища як ресурсу, а не до даних у ньому. Власник може видалити сховище повністю. Учасник може змінювати налаштування сховища. Але жодна з цих ролей сама по собі не дає доступу до секретів у середині. Це окремий рівень дозволів, і це найголовніше. Керування доступом – це багаторівнева структура.

Вам потрібен доступ до самого сховища – це перший рівень, і доступ до даних у сховищі – це другий рівень. Обидва мають надаватися окремо. Більшість новачків думають лише про перший рівень і забувають про другий. Ось тут і починаються проблеми. Головна помилка безпеки. Річ у тім, що більшість людей бачать роль учасник Key Vault і вважають її безпечною. Вони бачать слово «учасник» і припускають, що можуть керувати налаштуваннями сховища, але не торкатися секретів усередині. Власна документація Microsoft спочатку стверджувала саме це. Ця роль не дозволяє отримувати доступ до секретів, ключів або сертифікатів. Але це не зовсім так. Користувач із ролью «учасник Key Vault» може змінювати політики доступу до сховища. І якщо це сховище все ще використовує застарілі політики доступу, що часто буває, вони можуть просто надати собі повний доступ для читання до кожного секрету, ключа та сертифіката.

Не потрібен ніякий спеціальний експлойт, ніяка вразливість для виправлення. Так просто працюють дозволи. Дослідники безпеки з DataDog довели це у 2024 році. Вони показали, що учасник може отримати повний доступ до даних у будь-якому сховищі, що використовує застарілі політики доступу. Реакція Microsoft була цікавою. Вони заявили, що це невразливість, оскільки учасники призначені для керування політиками доступу, але вони також оновили документацію, щоб чітко попередити. Ця роль може надати собі доступ до площини даних. Отже, це не помилка в самому Key Vault, це пастка конфігурації. Вона ловить навіть досвідчені команди, тому що назва ролі звучить невинно. Учасник не звучить як хтось, хто може читати паролі вашої бази даних, але на практиці це саме так. Подумайте про ризик. Якщо зловмисник зламає обліковий запис із роллю учасника у вашому сховищі ключів, йому не потрібно зламувати саме сховище.

Йому не потрібно зламувати шифрування. Він просто змінює політику доступу, надає собі права на читання та непамітно викрадає кожен збережений вами секрет, рядки підключення, ключі ARRI, сертифікати, усе це. І оскільки зміни політики доступу є звичайною адміністративною діяльністю, це може не викликати жодних сповіщень. Тож як це виправити? По-перше, використовуйте Azure RBAC для доступу до площини даних замість застарілих політик доступу. RBAC відокремлює керування сховищем від даних, що зберігаються в ньому. По-друге, ніколи не надавайте роль учасника Key Vault нікому, кому вона не потрібна. По-третє, якщо у вас уже є користувачі з цією ролью, перевірте їх сьогодні. Замініть учасника на більш конкретні ролі, як-от користувач секретів Key Vault або офіцер секретів Key Vault. Є друга помилка, яка погіршує першу зберігання всіх секретів в одному сховищі. Якщо у вас одне сховище для всього, розробки, тестування, проміжного середовища, виробництва, усіх ваших програм і його зламають, усе опиниться під загрозою.

Це єдина точка відмови. Ми трохи згодом поговоримо про стратегію кількох сховищ, але принцип простий. Не тримайте всі яйця в одному кошику, особливо коли цей кошик містить ключі від усієї вашої інфраструктури. Керована ідентичність – це золотий стандарт. Отже, як зробити це правильно? Поговорімо про найкращий спосіб доступу до Key Vault. Існує фундаментальна проблема. Щоб отримати облікові дані з Key Vault, програма має автентифікуватися, але для автентифікації їй потрібні облікові дані. Де зберігати облікові дані, які програма використовує для отримання інших облікових даних? Це проблема курки та яйця. Стара відповідь – суб'єкт-служба з клієнтським секретом, але цей секрет має десь зберігатися у файлі конфігурації, змінних середовища чи конвоєрі розгортання. І ось ви знову стикаєтеся з тією самою проблемою. Ви просто перенесли секрет в інше місце. Керована ідентичність повністю вирішує це питання.

Ось як це працює. Коли ви вмикаєте керовану ідентичність для ресурсу Azure, наприклад, веб-програми, функції чи віртуальної машини, Azure автоматично створює ідентичність для цього ресурсу в EntraID. Ця ідентичність повністю керується Azure. Не потрібно створювати облікові дані, оновлювати секрети чи щось зберігати. Ресурс просто має ідентичність, про яку знає Azure. Існує два типи. Керована ідентичність призначена системою, прив'язана до одного конкретного ресурсу. Якщо видалити ресурс, ідентичність також зникне. Вони мають спільний життєвий цикл, що спрощує адміністрування. Керована ідентичність, призначена користувачем, це окрема ідентичність, яку можна призначити кільком ресурсам. Вона не має спільного життєвого циклу з жодним із них, тому корисна, коли одна ідентичність потрібна для кількох службових. Ось як це виглядає на практиці. У вас є веб-програма, який потрібно считати рядок підключення до бази даних із Key Vault.

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

використовує найпоширеніший вектор атаки викрадення облікових даних. Якщо немає облікових даних для викрадення, зловмиснику нічого компрометувати. Дозвольте навести приклад із реального життя. Уявіть конвейер обробки даних у Cynapse, якому потрібен доступ до облікового запису сховища. За старим підходом ви зберігали ключ доступу до сховища в конфігурації конвейера. Якщо хтось отримував доступ до цього конвейера, він отримував і ключ. Завдяки керованому посвідченню робоча область Cynapse має свою ідентичність. Цій ідентичності надається доступ до Key Vault, де зберігається ключ доступу до сховища. Конвейер отримує ключ під час виконання, використовує його і ніде не зберігає. Жодних ключів у коді, жодних секретів у конфігурації конвейера. Поєднуючи кероване посвідчення з RBAC та принципом найменших привілеїв, ви створюєте безпечну основу для будь-якого робочого навантаження Azure. Ваші програми проходять автентифікацію без паролів.

Вони отримують доступ лише до того, що їм потрібно, і кожен такий доступ реєструється та перевіряється. Це шаблон, який Майкрософт рекомендує майже для кожного сценарію. Як тільки ви почнете його використовувати, ви здивуєтесь, чому раніше робили це інакше. Вартість та стратегія використання кількох сховищ. Отже, давайте поговоримо про вартість. Саме тут більшість людей дивуються. Скільки насправді коштує Azure Key Vault? Модель ціноутворення проста. Немає плати за зберігання кожного секрету. Ви не платите за кожен пароль або арі-ключ, який ви зберігаєте. Натомість ви платите за операцію. Для стандартного рівня це приблизно 3 центи за кожні 10 тисяч операцій. Виклик отримання секрету зараховується як одна операція, як і створення секрету або перегляд в місту сховища. Для типової програми малого чи середнього розміру це коштує кілька центів на місяць. Буквально кілька центів. Порівняйте це з AWS Secrets Manager.

Вони стягують 40 центів за секрет на місяць лише за його зберігання, плюс додаткові збори за арі-виклики. Якщо у вас 100 секретів, це 40 доларів на місяць, перш ніж ви прочитаєте хоча б один із них. За журки Волт 100 секретів при помірному використанні можуть коштувати вам 15 центів. Різниця швидко зростає з масштабом. Також існує преміум-рівень. Він додає ключі на базі HSM для робочих навантажень, що потребують найвищого рівня криптографічного захисту. Це фінансові транзакції, дані охорони здоров'я, державні системи. Вартість за операцію там вища – близько 15 центів за 10 тисяч операцій для розширених типів ключів, плюс щомісячна плата за ключ HSM. Але для більшості програм стандартного рівня – більш ніж достатньо. Ось фінансовий сюрприз, який застає людей з ненацька. Для типового веб-додатка з кількома секретами та кількома тисячами операцій на місяцький Волт коштує менше долара. Ви витратите більше на каву, поки будете його налаштовувати.

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

М'яке видалення означає, що якщо хтось видалить секрет, він не зникне назавжди. Він переходить у відновлюваний стан на термін зберігання, який ви обираєте, до 90 днів. Захист від очищення йде ще далі. Ніхто не може остаточно видалити сховище або його вміст, доки не закінчиться термін зберігання. Разом вони запобігають випадковій втраті даних, через яку служби безпеки втрачають спокій. Як це все працює разом? Давайте об'єднаємо все це і побачимо, як пазл складається докупи. Key Vault – це не острів. Це центральна нервова система для секретів у вашій архітектурі Azure. Коли ви розумієте, як працює вся система, все стає на свої місця. Ось що відбувається, коли програмі потрібен секрет. Програма надсилає запит, використовуючи своє кероване посвідчення Managed Identity. Це посвідчення вже зареєстроване в EntraID. Azure створив його автоматично, коли ви ввімкнули кероване посвідчення для ресурсу.

EntraID перевіряє справжність посвідчення, а потім передає запит до Key Vault. Key Vault перевіряє призначені вами дозволи RBAC. Якщо посвідчення має правильну роль, наприклад, Key Vault Secrets User, секрет повертається. Все це відбувається за мілісекунди. Програма ніколи не бачить облікових даних. Вона ніколи не зберігає пароль. Вона просто отримує значення, яке їй потрібне. А тепер подумайте, скільки сервісів Azure можуть до цього підключитися. App Service, Functions AKS, Data Factory, Synapse, Logic Apps, DevOps Pipelines – всі вони вміють працювати з Key Vault. Ви можете налаштувати веб-додаток так, щоб він брав секрет безпосередньо з параметрів програми. Ви можете налаштувати конвейер Data Factory на отримання ключа облікового запису зберігання з Key Vault під час виконання. Ви можете налаштувати кластер Kubernetes для отримання секретів за допомогою драйвера Key Vault CSI. Кожна служба інтегрується однаково, використовуючи ту саму систему ідентифікації, ролі RBAC та аудит журналів.

Шаблон CI-CD є особливо ефективним. Ваші конвейери отримують секрети з Key Vault під час розгортання. Вони ніколи не зберігають їх у змінних конвейера чи секретах репозиторію. Якщо потрібно змінити пароль бази даних, ви оновлюєте його в Key Vault. Під час наступного запуску конвейер автоматично підтягне нове значення. Жодних змін у конвейері, коді чи повторних розгортань. Ось що робить цю систему такою вдалою. Як тільки ви налаштуєте Key Vault з керованою ідентичністю та RBAC, ви повністю забудете про керування обліковими даними. Ваші програми просто працюють. Секрети оновлюються непомітно для всіх. Сертифікати поновлюються без нічних екстрених ситуацій. Система виконує все це у фоновому режимі. Ось модель безпеки, яка має значення. Ідентифікація – це периметр, а не мережа. Немає значення, чи хтось знаходиться всередині вашої віртуальної мережі чи поза нею. Важливо лише те, чи має користувач дійсну ідентичність із потрібними дозволами.

Key Vault забезпечує це за замовчуванням. Кожен запит на доступ проходить автентифікацію EntraID та авторизацію RBAC незалежно від джерела запиту. І все це реєструється в журналах. Кожне читання секрету, кожна операція з ключем, кожне отримання сертифіката. Ви можете бачити, хто і коли отримав доступ до чого. Якщо щось виглядає підозріло, у вас є дані для розслідування. Це критично важливо для відповідності вимогам, реагування на інциденти та просто для розуміння того, що відбувається у вашому середовищі. У цьому вся привабливість системи. Key Vault, EntraID, RBAC та керована ідентичність працюють разом як єдина структура безпеки. Кожен елемент підсилює інші. А коли вони налаштовані правильно, ви отримуєте систему керування даними, яка є безпечнішою та простішою в експлуатації, ніж будь-що створене власноруч. Практичні поради. Отже, що вам слід зробити прямо зараз? Перетворимо ці знання на дії.

Ось справи, які ви можете вирішити цього тижня. Почніть зі своєї моделі дозволів. Відкрите свій кій Vault на порталі, перейдіть до налаштувань доступу та перевірте, що там вказано. Якщо ви бачите політику доступу до сховища Vault Access Policy, це старий методичний. Вам варто перейти на керування доступом на основі ролей Azure, Azure RBAC. Міграція є простою. Змініть модель дозволів і призначте ролі RBAC тим самим користувачам, які вже мали політики доступу. Зробіть це сьогодні. Microsoft рекомендує це і дослідження, про які ми говорили, чітко пояснили чому. Далі проведіть аудит усіх облікових записів, що мають роль співавтора Contributa у Key Vault. Відкрийте вкладку IAM у вашому сховищі та подивіться, хто має доступ співавтора. Кожна особа з цією ролью повинна мати на це вагому причину. Найчастіше – ні. Замініть роль учасника на щось більш конкретне. Якщо комусь потрібно лише читати секрети, надайте їм роль користувача секретів Key Vault.

Якщо їм потрібно керувати секретами, використовуйте роль відповідального за секрети Key Vault. Мета полягає в тому, щоб повністю закрити цей шлях підвищення привілею. Далі скористайтеся керованими ідентифікаторами Managed Identity. Будь-яка служба Azure, який потрібен доступ до Key Vault, має використовувати їх. Якщо у вас є веб-програма, функція Data Factory або віртуальна машина, що досі використовують суб'єкт-сервіс із секретом клієнта, перейдіть на керований ідентифікатор. Це простіше, безпечніше і вирішує проблему курки та яйця, яку ми обговорювали. Azure бере на себе керування обліковими даними у фоновому режимі. І ще одне – увімкніть м'яке видалення та захист від очищення для кожного сховища. М'яке видалення увімкнено за замовчуванням для нових сховищ, а захист від очищення – ні. Увімкніть його. Це налаштування запобігає остаточному видаленню сховища або його вмісту протягом періоду зберігання.

Воно врятувало не одну команду від катастрофічної помилки. Ось ваш заклик до дії. Проаналізуйте свій поточний підхід до керування секретами. Знайдіть один секрет, який досі знаходиться у файлі конфігурації, змінній оточення або жорстко прописаний у коді. Перенесіть його в Key Vault цього тижня. Лише один. Коли ви побачите, наскільки це просто, ви захочете перенести решту. Безпека – це неодноразове налаштування. Це постійна практика. Key Vault полегшує цю практику, але лише за умови правильного використання. Інструменти вже є. Паттерни перевірені на практиці. Тепер справа за вами – впровадити їх. Це і є система. Key Vault – ваш цифровий сейф, але він надійний лише настільки, наскільки надійні засоби керування доступом навколо нього. Почніть з аудиту, який я щойно описав. Перевірте свою модель дозволів. Перевірте призначення ролей учасників і перенесіть один секрет у сховище цього тижня. Підписуйтесь, щоб отримувати більше порад із хмарної безпеки простою мовою і поділіться цим із тими, хто досі зберігає секрети у файлах конфігурації.