WEBVTT

00:00:00.120 --> 00:00:01.580
Уявіть собі таку ситуацію.

00:00:01.720 --> 00:00:04.860
Ви створюєте застосунок, і вам потрібен ключ АРІ для підключення до сервісу,

00:00:04.920 --> 00:00:07.280
пароль бази даних або ключ облікового запису зберігання.

00:00:07.440 --> 00:00:11.420
Отже, ви вставляєте його прямо в код, можливо, у файл конфігурації або змінну середовища.

00:00:11.560 --> 00:00:16.380
Усе працює чудово, доки ви не відправите цей код на GitHub або не поділитеся блокнотом із колегою.

00:00:16.540 --> 00:00:19.000
І в ту ж мить ваш секрет перестає бути секретом.

00:00:19.200 --> 00:00:22.880
Якщо цей код потрапить у чужі руки, вся ваша система опиниться під загрозою.

00:00:22.880 --> 00:00:25.900
Azure Key Vault – це інструмент, який вирішує цю проблему.

00:00:26.060 --> 00:00:29.680
Він надає безпечне місце для зберігання секретів, щоб вони ніколи не потрапляли у ваш код.

00:00:29.800 --> 00:00:31.680
Але ось у чому більшість людей помиляється.

00:00:31.840 --> 00:00:34.860
Просто мати Key Vault не означає автоматично гарантувати безпеку.

00:00:34.980 --> 00:00:39.080
Те, як ви його налаштовуєте, контролюєте доступ і призначаєте права, має не менше значення.

00:00:39.240 --> 00:00:41.700
До кінця цього епізоду ви дізнаєтеся, що таке Key Vault,

00:00:41.700 --> 00:00:46.660
що в ньому можна зберігати, як працює доступ і яка найбільша помилка може залишити ваші секрети відкритими.

00:00:46.660 --> 00:00:50.020
Все простою мовою, без складних термінів, тільки головне, що вам потрібно.

00:00:50.140 --> 00:00:51.980
Отже, що саме таке Azure Key Vault?

00:00:52.140 --> 00:00:53.420
Що таке Azure Key Vault?

00:00:53.620 --> 00:00:55.120
Ось найпростіше визначення.

00:00:55.260 --> 00:00:58.240
Azure Key Vault – це хмарний цифровий сейф для ваших секретів.

00:00:58.380 --> 00:01:01.720
Це керований сервіс від Microsoft для зберігання ключів ARRI, паролів баз даних,

00:01:01.800 --> 00:01:05.340
рядків підключення, ключів шифрування та сертифікатів в одному центральному місці.

00:01:05.340 --> 00:01:09.700
Вам не потрібно турбуватися про інфраструктуру, оскільки Azure бере на себе оновлення, працездатність і безпеку.

00:01:09.820 --> 00:01:11.180
Ви просто користуєтеся ним.

00:01:11.180 --> 00:01:12.840
Уявіть це як офісну будівлю.

00:01:13.020 --> 00:01:15.500
У вас є робочі місця, кімнати для нарад і шафи з документами,

00:01:15.600 --> 00:01:18.420
але десь у підвалі є надійно захищена кімната сейф для найважливішого.

00:01:18.560 --> 00:01:20.800
Майстер ключі, готівка, юридичні документи.

00:01:20.960 --> 00:01:23.120
Ніхто не заходить туди без дозволу та автентифікації.

00:01:23.280 --> 00:01:25.660
І кожен раз, коли хтось відчиняє двері, це фіксується в журналі.

00:01:25.760 --> 00:01:29.600
Це і є Key Vault – безпечна кімната у підвалі вашої архітектури Azure.

00:01:29.600 --> 00:01:31.760
Тепер порівняйте це зі старими методами.

00:01:31.760 --> 00:01:34.560
20 років тому, якщо вам був потрібен пароль до бази даних,

00:01:34.640 --> 00:01:37.760
ви прописували його в коді у файлі конфігурації, змінній середовища

00:01:37.760 --> 00:01:40.680
або, що ще гірше, залишали відкритим текстом у вихідному коді.

00:01:40.820 --> 00:01:43.340
Якщо хтось отримував доступ до сервера, він мав усе.

00:01:43.480 --> 00:01:46.700
А якщо вам потрібно було змінити пароль, доводилося оновлювати його всюди.

00:01:46.840 --> 00:01:49.560
У кожному файлі конфігурації, у кожному середовищі, у кожному розгортанні.

00:01:49.720 --> 00:01:50.940
Це був справжній кошмар.

00:01:50.940 --> 00:01:52.320
Key Vault змінює все це.

00:01:52.320 --> 00:01:55.160
Замість того, щоб розкидати секрети по коду та конфігураційних файлах,

00:01:55.220 --> 00:01:56.960
ви зберігаєте їх в одному центральному місці.

00:01:57.100 --> 00:02:00.260
Ваші програми запитують їх під час виконання, лише коли вони їм потрібні.

00:02:00.400 --> 00:02:03.480
А оскільки все централізовано, ви можете оновити секрет в одному місці,

00:02:03.600 --> 00:02:06.980
і кожна програма, що його використовує, автоматично отримає нове значення

00:02:06.980 --> 00:02:08.860
без змін у коді чи повторного розгортання.

00:02:09.020 --> 00:02:10.180
Але ось у чому річ Key Vault.

00:02:10.180 --> 00:02:12.200
Це не просто менеджер паролів для ваших програм.

00:02:12.440 --> 00:02:14.020
Це основна служба безпеки.

00:02:14.180 --> 00:02:16.460
Будь-яка служба Azure може інтегруватися з нею.

00:02:16.460 --> 00:02:20.880
AppService, Functions, AKS, Data Factory, Synapse, Logic Apps, Conveyori, DevOps –

00:02:20.880 --> 00:02:22.200
усі вони вміють працювати з Key Vault.

00:02:22.360 --> 00:02:25.000
Вона стає основою вашої безпечної хмарної архітектури.

00:02:25.120 --> 00:02:26.600
І як тільки ви правильно її налаштуєте,

00:02:26.680 --> 00:02:28.960
ви взагалі перестанете думати про керування обліковими даними.

00:02:29.160 --> 00:02:30.240
Що можна зберігати?

00:02:30.400 --> 00:02:32.060
Тепер, коли ви знаєте, що таке Key Vault,

00:02:32.200 --> 00:02:34.520
давайте поговоримо про те, що саме можна в ній розмістити.

00:02:34.520 --> 00:02:38.020
У вас є три основні категорії – секрети, ключі та сертифікати.

00:02:38.180 --> 00:02:39.760
Кожна з них виконує свою функцію,

00:02:39.760 --> 00:02:42.720
і розуміння різниці допоможе вам правильно використовувати Key Vault.

00:02:42.880 --> 00:02:43.960
Почнемо з секретів.

00:02:44.080 --> 00:02:46.100
Це те, що люди зберігають найчастіше.

00:02:46.280 --> 00:02:48.780
Секрети – це рядки підключення, ключі ARRI, паролі до баз даних,

00:02:48.860 --> 00:02:50.120
ключі облікових записів зберігання,

00:02:50.240 --> 00:02:51.620
фактично всі повсякденні облікові дані,

00:02:51.720 --> 00:02:53.840
необхідні вашим програмам для взаємодії з іншими службами.

00:02:54.000 --> 00:02:56.460
Замість того, щоб додавати їх у свій код чи конфігураційний файл,

00:02:56.520 --> 00:02:57.680
ви розміщуєте їх у Key Vault.

00:02:57.680 --> 00:02:59.480
Ваша програма отримує їх під час виконання,

00:02:59.480 --> 00:03:01.340
і ніхто ніколи не бачить їх у відкритому вигляді.

00:03:01.460 --> 00:03:04.240
Уявіть це, як замкнено шухлядо у вашій цифровій картотеці.

00:03:04.480 --> 00:03:05.460
Наступні – ключі.

00:03:05.580 --> 00:03:07.720
Це ключі шифрування для даних у стані спокою.

00:03:07.920 --> 00:03:09.980
Якщо ви використовуєте ключі, якими керує клієнт,

00:03:10.040 --> 00:03:11.500
для сховища ежур, баз даних SQL

00:03:11.500 --> 00:03:13.100
або шифрування дисків віртуальних машин,

00:03:13.180 --> 00:03:14.480
ці ключі можуть зберігатися в Key Vault.

00:03:14.600 --> 00:03:15.920
Це дає вам повний контроль над тим,

00:03:15.920 --> 00:03:17.540
хто і коли може ними користуватися.

00:03:17.660 --> 00:03:19.900
А якщо для дотримання вимог вам потрібні апаратні ключі,

00:03:19.900 --> 00:03:22.320
преміум-рівень забезпечить захист за допомогою HSM.

00:03:22.540 --> 00:03:23.680
Далі йдуть сертифікати.

00:03:23.860 --> 00:03:26.260
TLS та SSL – сертифікати для ваших веб-програм,

00:03:26.400 --> 00:03:27.620
ARRI та внутрішніх службових.

00:03:27.760 --> 00:03:29.800
Key Vault може зберігати їх, керувати їхнім життєвим циклом

00:03:29.800 --> 00:03:30.940
і навіть автоматично поновлювати,

00:03:31.040 --> 00:03:32.400
коли термін їхньої дії добігає кінця.

00:03:32.520 --> 00:03:33.780
Це справжній порятунок для тих,

00:03:33.780 --> 00:03:35.620
у кого сертифікат коли-небудь закінчувався

00:03:35.620 --> 00:03:36.960
о третій годині ночі в неділю.

00:03:37.100 --> 00:03:38.140
Ось реальний приклад.

00:03:38.300 --> 00:03:39.780
Уявіть, що у вас є веб-програма,

00:03:39.780 --> 00:03:41.660
який потрібен рядок підключення до бази даних

00:03:41.660 --> 00:03:43.060
і ключ ARRI для сторонньої служби.

00:03:43.200 --> 00:03:44.940
За старим способом, ви б записали обидва значення

00:03:44.940 --> 00:03:46.600
у свій JSON-файл налаштувань програми.

00:03:46.780 --> 00:03:49.080
Скоріше за все, якщо цей файл потрапить у ваш репозиторі,

00:03:49.180 --> 00:03:50.700
будь-хто з доступом до коду зможе побачити

00:03:50.700 --> 00:03:52.080
ваші облікові дані бази даних.

00:03:52.080 --> 00:03:54.580
З Key Vault ви зберігаєте обидва значення як секрети.

00:03:54.700 --> 00:03:56.140
Ваша програма отримує їх під час запуску

00:03:56.140 --> 00:03:57.920
і вони ніколи не з'являються у вашому вихідному коді.

00:03:58.020 --> 00:03:59.840
Потрібно оновити пароль до бази даних.

00:03:59.920 --> 00:04:00.880
Оновіть його в Key Vault.

00:04:00.880 --> 00:04:02.780
Програма автоматично отримає нове значення

00:04:02.780 --> 00:04:04.100
під час наступного перезапуску.

00:04:04.240 --> 00:04:06.120
Жодних змін у коді чи повторних розгортань.

00:04:06.300 --> 00:04:08.440
Декого дивує те, що версійність тут вбудована.

00:04:08.600 --> 00:04:11.360
Коли ви оновлюєте секрет, Key Vault не перезаписує старе значення.

00:04:11.540 --> 00:04:12.780
Він створює нову версію.

00:04:12.780 --> 00:04:15.180
Старі версії зберігаються, тому ви можете відкотитися назад,

00:04:15.300 --> 00:04:16.160
якщо щось піде не так.

00:04:16.300 --> 00:04:18.340
Це надзвичайно зручно під час інцидентів.

00:04:18.480 --> 00:04:20.820
Ви можете швидко повернутися до попереднього секрету,

00:04:20.920 --> 00:04:22.780
не згадуючи, яким було старе значення.

00:04:22.780 --> 00:04:26.180
Ви можете зберігати всі три типи – секрети, ключі та сертифікати –

00:04:26.180 --> 00:04:27.020
в одному сховищі.

00:04:27.140 --> 00:04:29.920
Але найкраща практика – розділяти їх за середовищами.

00:04:30.120 --> 00:04:33.380
Майте окреме сховище для розробки, для тестування та для продукту.

00:04:33.380 --> 00:04:35.960
Це запобігає випадковому використанню продуктового секрету

00:04:35.960 --> 00:04:38.200
в середовищі розробки та обмежує радіус ураження,

00:04:38.340 --> 00:04:40.100
якщо одне сховище буде скомпрометовано.

00:04:40.220 --> 00:04:42.520
Але зберігання секретів – це лише половина справи.

00:04:42.660 --> 00:04:44.820
Справжнє питання в тому, хто має до них доступ.

00:04:44.980 --> 00:04:46.440
Як працює контроль доступу?

00:04:46.440 --> 00:04:48.580
Тепер поговоримо про те, хто отримує доступ.

00:04:48.800 --> 00:04:51.560
У Key Vault є два різні способи контролю доступу до вмісту,

00:04:51.620 --> 00:04:52.960
і вибір має велике значення.

00:04:53.120 --> 00:04:55.420
Перша модель – це застарілі політики доступу.

00:04:55.580 --> 00:04:56.660
Це старий спосіб.

00:04:56.660 --> 00:04:58.920
Ви створюєте політики безпосередньо у сховищі

00:04:58.920 --> 00:05:00.940
і призначаєте дозволи конкретним користувачам

00:05:00.940 --> 00:05:04.240
або групам для певних типів даних, секретів, ключів або сертифікатів.

00:05:04.360 --> 00:05:07.300
Проблема в тому, що ці політики прив'язані безпосередньо до сховища.

00:05:07.440 --> 00:05:09.840
Якщо у вас декілька сховищ, вам доведеться керувати політиками

00:05:09.840 --> 00:05:10.740
в кожному з них окремо.

00:05:10.860 --> 00:05:12.120
Це погано масштабується.

00:05:12.300 --> 00:05:14.380
Microsoft тепер не рекомендує їх використовувати,

00:05:14.500 --> 00:05:16.360
оскільки вони мають відомі проблеми з безпекою.

00:05:16.520 --> 00:05:18.880
Вони не підтримують керування привілеєваними ідентичностями

00:05:18.880 --> 00:05:21.420
та можуть створювати неочікувані шляхи підвищення привілеїв.

00:05:21.540 --> 00:05:24.740
Друга модель – це Azure RBAC – керування доступом на основі ролей.

00:05:24.900 --> 00:05:26.060
Це сучасний спосіб.

00:05:26.280 --> 00:05:28.060
Він використовує ідентичності EntraID

00:05:28.060 --> 00:05:30.620
і узгоджується з тим, як ви керуєте дозволами врешті Azure.

00:05:30.760 --> 00:05:32.420
Якщо ви вже знаєте, як надати комусь доступ

00:05:32.420 --> 00:05:34.480
до облікового запису зберігання чи віртуальної машини,

00:05:34.580 --> 00:05:36.380
ви вже знаєте, як надати їм доступ до Key Vault.

00:05:36.560 --> 00:05:38.380
Та сама система – ті самі шаблони.

00:05:38.560 --> 00:05:40.640
Ось головне правило – мінімальні привілеї.

00:05:40.820 --> 00:05:42.380
Надавайте лише той мінімальний доступ,

00:05:42.540 --> 00:05:43.940
який потрібен людині, не більше.

00:05:44.100 --> 00:05:45.860
Якщо комусь потрібно лише читати секрети,

00:05:45.940 --> 00:05:47.760
не давайте дозвіл на їх створення чи видалення.

00:05:47.940 --> 00:05:49.940
Якщо комусь потрібно лише керувати сертифікатами,

00:05:50.060 --> 00:05:51.140
не давайте доступ до ключів.

00:05:51.300 --> 00:05:52.860
Дозвольте пройтися по ключових ролях.

00:05:52.860 --> 00:05:54.700
У вас є читач Key Vault, Key Vault Reader.

00:05:54.700 --> 00:05:56.060
Це дозволяє переглядати список секретів,

00:05:56.140 --> 00:05:57.020
але не читати їхні значення.

00:05:57.140 --> 00:05:58.940
Користувач секретів Key Vault – Key Vault Secrets User.

00:05:59.080 --> 00:06:01.020
Це дозволяє користувачеві читати значення секретів.

00:06:01.120 --> 00:06:03.100
І адміністратор секретів Key Vault – Key Vault Secrets Office.

00:06:03.320 --> 00:06:05.720
Це дозволяє створювати, оновлювати та видаляти секрети.

00:06:05.820 --> 00:06:07.080
Поміть та закономірність.

00:06:07.200 --> 00:06:09.400
Кожна роль стосується конкретних даних у сховищі,

00:06:09.480 --> 00:06:10.460
а не самого сховища.

00:06:10.580 --> 00:06:12.220
Тепер порівняйте це з загальними ролями

00:06:12.220 --> 00:06:13.720
власник, учасник чи тач.

00:06:13.720 --> 00:06:15.820
Вони застосовуються до сховища як ресурсу,

00:06:15.820 --> 00:06:16.680
а не до даних у ньому.

00:06:16.840 --> 00:06:18.820
Власник може видалити сховище повністю.

00:06:18.980 --> 00:06:21.280
Учасник може змінювати налаштування сховища.

00:06:21.400 --> 00:06:23.020
Але жодна з цих ролей сама по собі

00:06:23.020 --> 00:06:24.960
не дає доступу до секретів у середині.

00:06:25.120 --> 00:06:27.480
Це окремий рівень дозволів, і це найголовніше.

00:06:27.640 --> 00:06:29.940
Керування доступом – це багаторівнева структура.

00:06:30.140 --> 00:06:32.080
Вам потрібен доступ до самого сховища –

00:06:32.080 --> 00:06:32.780
це перший рівень,

00:06:32.860 --> 00:06:35.060
і доступ до даних у сховищі – це другий рівень.

00:06:35.060 --> 00:06:37.020
Обидва мають надаватися окремо.

00:06:37.140 --> 00:06:39.200
Більшість новачків думають лише про перший рівень

00:06:39.200 --> 00:06:40.280
і забувають про другий.

00:06:40.280 --> 00:06:42.040
Ось тут і починаються проблеми.

00:06:42.160 --> 00:06:43.520
Головна помилка безпеки.

00:06:43.700 --> 00:06:45.240
Річ у тім, що більшість людей бачать роль

00:06:45.240 --> 00:06:47.200
учасник Key Vault і вважають її безпечною.

00:06:47.380 --> 00:06:48.880
Вони бачать слово «учасник» і припускають,

00:06:49.000 --> 00:06:50.460
що можуть керувати налаштуваннями сховища,

00:06:50.540 --> 00:06:51.860
але не торкатися секретів усередині.

00:06:51.980 --> 00:06:54.720
Власна документація Microsoft спочатку стверджувала саме це.

00:06:54.880 --> 00:06:57.080
Ця роль не дозволяє отримувати доступ до секретів,

00:06:57.160 --> 00:06:58.380
ключів або сертифікатів.

00:06:58.380 --> 00:06:59.620
Але це не зовсім так.

00:06:59.860 --> 00:07:01.800
Користувач із ролью «учасник Key Vault»

00:07:01.800 --> 00:07:04.160
може змінювати політики доступу до сховища.

00:07:04.160 --> 00:07:05.960
І якщо це сховище все ще використовує

00:07:05.960 --> 00:07:08.020
застарілі політики доступу, що часто буває,

00:07:08.120 --> 00:07:09.760
вони можуть просто надати собі повний доступ

00:07:09.760 --> 00:07:12.160
для читання до кожного секрету, ключа та сертифіката.

00:07:12.320 --> 00:07:13.880
Не потрібен ніякий спеціальний експлойт,

00:07:13.980 --> 00:07:15.280
ніяка вразливість для виправлення.

00:07:15.400 --> 00:07:16.840
Так просто працюють дозволи.

00:07:16.960 --> 00:07:20.040
Дослідники безпеки з DataDog довели це у 2024 році.

00:07:20.220 --> 00:07:21.900
Вони показали, що учасник може отримати

00:07:21.900 --> 00:07:23.660
повний доступ до даних у будь-якому сховищі,

00:07:23.740 --> 00:07:25.540
що використовує застарілі політики доступу.

00:07:25.680 --> 00:07:27.520
Реакція Microsoft була цікавою.

00:07:27.520 --> 00:07:29.200
Вони заявили, що це невразливість,

00:07:29.280 --> 00:07:31.880
оскільки учасники призначені для керування політиками доступу,

00:07:31.960 --> 00:07:33.500
але вони також оновили документацію,

00:07:33.600 --> 00:07:34.480
щоб чітко попередити.

00:07:34.620 --> 00:07:36.640
Ця роль може надати собі доступ до площини даних.

00:07:36.760 --> 00:07:38.440
Отже, це не помилка в самому Key Vault,

00:07:38.580 --> 00:07:39.740
це пастка конфігурації.

00:07:39.980 --> 00:07:41.620
Вона ловить навіть досвідчені команди,

00:07:41.680 --> 00:07:43.260
тому що назва ролі звучить невинно.

00:07:43.420 --> 00:07:44.740
Учасник не звучить як хтось,

00:07:44.840 --> 00:07:46.640
хто може читати паролі вашої бази даних,

00:07:46.700 --> 00:07:47.880
але на практиці це саме так.

00:07:47.980 --> 00:07:49.020
Подумайте про ризик.

00:07:49.160 --> 00:07:50.900
Якщо зловмисник зламає обліковий запис

00:07:50.900 --> 00:07:53.020
із роллю учасника у вашому сховищі ключів,

00:07:53.140 --> 00:07:54.860
йому не потрібно зламувати саме сховище.

00:07:55.020 --> 00:07:56.880
Йому не потрібно зламувати шифрування.

00:07:57.060 --> 00:07:58.700
Він просто змінює політику доступу,

00:07:58.820 --> 00:08:00.080
надає собі права на читання

00:08:00.080 --> 00:08:02.400
та непамітно викрадає кожен збережений вами секрет,

00:08:02.520 --> 00:08:05.320
рядки підключення, ключі ARRI, сертифікати, усе це.

00:08:05.480 --> 00:08:06.880
І оскільки зміни політики доступу

00:08:06.880 --> 00:08:08.640
є звичайною адміністративною діяльністю,

00:08:08.720 --> 00:08:10.240
це може не викликати жодних сповіщень.

00:08:10.380 --> 00:08:11.420
Тож як це виправити?

00:08:11.560 --> 00:08:13.040
По-перше, використовуйте Azure RBAC

00:08:13.040 --> 00:08:14.080
для доступу до площини даних

00:08:14.080 --> 00:08:15.300
замість застарілих політик доступу.

00:08:15.420 --> 00:08:17.600
RBAC відокремлює керування сховищем від даних,

00:08:17.680 --> 00:08:18.540
що зберігаються в ньому.

00:08:18.700 --> 00:08:21.000
По-друге, ніколи не надавайте роль учасника Key Vault

00:08:21.000 --> 00:08:22.460
нікому, кому вона не потрібна.

00:08:22.600 --> 00:08:25.040
По-третє, якщо у вас уже є користувачі з цією ролью,

00:08:25.100 --> 00:08:26.080
перевірте їх сьогодні.

00:08:26.240 --> 00:08:28.040
Замініть учасника на більш конкретні ролі,

00:08:28.040 --> 00:08:29.600
як-от користувач секретів Key Vault

00:08:29.600 --> 00:08:31.120
або офіцер секретів Key Vault.

00:08:31.320 --> 00:08:33.280
Є друга помилка, яка погіршує першу

00:08:33.280 --> 00:08:35.440
зберігання всіх секретів в одному сховищі.

00:08:35.440 --> 00:08:37.240
Якщо у вас одне сховище для всього,

00:08:37.400 --> 00:08:39.600
розробки, тестування, проміжного середовища,

00:08:39.720 --> 00:08:41.200
виробництва, усіх ваших програм

00:08:41.200 --> 00:08:43.440
і його зламають, усе опиниться під загрозою.

00:08:43.620 --> 00:08:45.020
Це єдина точка відмови.

00:08:45.160 --> 00:08:46.900
Ми трохи згодом поговоримо про стратегію

00:08:46.900 --> 00:08:48.660
кількох сховищ, але принцип простий.

00:08:48.660 --> 00:08:50.320
Не тримайте всі яйця в одному кошику,

00:08:50.420 --> 00:08:51.980
особливо коли цей кошик містить ключі

00:08:51.980 --> 00:08:53.520
від усієї вашої інфраструктури.

00:08:53.640 --> 00:08:55.800
Керована ідентичність – це золотий стандарт.

00:08:55.940 --> 00:08:57.300
Отже, як зробити це правильно?

00:08:57.520 --> 00:08:59.620
Поговорімо про найкращий спосіб доступу до Key Vault.

00:08:59.620 --> 00:09:01.180
Існує фундаментальна проблема.

00:09:01.400 --> 00:09:02.800
Щоб отримати облікові дані з Key Vault,

00:09:02.940 --> 00:09:04.140
програма має автентифікуватися,

00:09:04.240 --> 00:09:06.180
але для автентифікації їй потрібні облікові дані.

00:09:06.300 --> 00:09:07.360
Де зберігати облікові дані,

00:09:07.480 --> 00:09:08.840
які програма використовує для отримання

00:09:08.840 --> 00:09:09.780
інших облікових даних?

00:09:09.900 --> 00:09:11.380
Це проблема курки та яйця.

00:09:11.580 --> 00:09:13.020
Стара відповідь – суб'єкт-служба

00:09:13.020 --> 00:09:14.000
з клієнтським секретом,

00:09:14.120 --> 00:09:15.700
але цей секрет має десь зберігатися

00:09:15.700 --> 00:09:17.980
у файлі конфігурації, змінних середовища

00:09:17.980 --> 00:09:19.160
чи конвоєрі розгортання.

00:09:19.160 --> 00:09:21.580
І ось ви знову стикаєтеся з тією самою проблемою.

00:09:21.740 --> 00:09:23.500
Ви просто перенесли секрет в інше місце.

00:09:23.620 --> 00:09:25.680
Керована ідентичність повністю вирішує це питання.

00:09:25.840 --> 00:09:26.840
Ось як це працює.

00:09:27.000 --> 00:09:28.160
Коли ви вмикаєте керовану ідентичність

00:09:28.680 --> 00:09:30.600
для ресурсу Azure, наприклад, веб-програми,

00:09:30.720 --> 00:09:32.080
функції чи віртуальної машини,

00:09:32.180 --> 00:09:34.000
Azure автоматично створює ідентичність

00:09:34.000 --> 00:09:35.400
для цього ресурсу в EntraID.

00:09:35.600 --> 00:09:37.780
Ця ідентичність повністю керується Azure.

00:09:37.960 --> 00:09:39.720
Не потрібно створювати облікові дані,

00:09:39.820 --> 00:09:41.700
оновлювати секрети чи щось зберігати.

00:09:41.700 --> 00:09:43.500
Ресурс просто має ідентичність,

00:09:43.600 --> 00:09:44.580
про яку знає Azure.

00:09:44.760 --> 00:09:45.800
Існує два типи.

00:09:45.940 --> 00:09:47.840
Керована ідентичність призначена системою,

00:09:47.940 --> 00:09:49.720
прив'язана до одного конкретного ресурсу.

00:09:49.840 --> 00:09:52.300
Якщо видалити ресурс, ідентичність також зникне.

00:09:52.460 --> 00:09:53.900
Вони мають спільний життєвий цикл,

00:09:54.020 --> 00:09:55.320
що спрощує адміністрування.

00:09:55.480 --> 00:09:57.540
Керована ідентичність, призначена користувачем,

00:09:57.640 --> 00:10:00.400
це окрема ідентичність, яку можна призначити кільком ресурсам.

00:10:00.560 --> 00:10:02.680
Вона не має спільного життєвого циклу з жодним із них,

00:10:02.780 --> 00:10:04.700
тому корисна, коли одна ідентичність потрібна

00:10:04.700 --> 00:10:05.600
для кількох службових.

00:10:05.720 --> 00:10:07.320
Ось як це виглядає на практиці.

00:10:07.480 --> 00:10:09.680
У вас є веб-програма, який потрібно считати рядок

00:10:09.680 --> 00:10:11.380
підключення до бази даних із Key Vault.

00:10:11.540 --> 00:10:13.720
Ви вмикаєте для веб-програми керовану ідентичність,

00:10:13.820 --> 00:10:14.740
призначену системою.

00:10:14.900 --> 00:10:16.480
Потім надаєте цій ідентичності роль

00:10:16.480 --> 00:10:18.840
користувач секретів Key Vault у вашому сховищі.

00:10:18.980 --> 00:10:19.460
Це все.

00:10:19.680 --> 00:10:20.980
Жодних рядків підключення в коді,

00:10:21.080 --> 00:10:23.080
жодних клієнтських секретів у файлах конфігурації.

00:10:23.080 --> 00:10:25.200
Веб-додаток проходить автентифікацію в Key Vault,

00:10:25.320 --> 00:10:26.860
використовуючи кероване посвідчення,

00:10:34.700 --> 00:10:36.320
використовує найпоширеніший вектор атаки

00:10:36.320 --> 00:10:37.860
викрадення облікових даних.

00:10:37.960 --> 00:10:39.860
Якщо немає облікових даних для викрадення,

00:10:39.980 --> 00:10:41.500
зловмиснику нічого компрометувати.

00:10:41.680 --> 00:10:43.680
Дозвольте навести приклад із реального життя.

00:10:43.840 --> 00:10:45.420
Уявіть конвейер обробки даних у Cynapse,

00:10:45.560 --> 00:10:47.600
якому потрібен доступ до облікового запису сховища.

00:10:47.740 --> 00:10:50.080
За старим підходом ви зберігали ключ доступу до сховища

00:10:50.080 --> 00:10:51.180
в конфігурації конвейера.

00:10:51.180 --> 00:10:53.180
Якщо хтось отримував доступ до цього конвейера,

00:10:53.280 --> 00:10:54.140
він отримував і ключ.

00:10:54.300 --> 00:10:56.540
Завдяки керованому посвідченню робоча область Cynapse

00:10:56.540 --> 00:10:57.620
має свою ідентичність.

00:10:57.760 --> 00:10:59.740
Цій ідентичності надається доступ до Key Vault,

00:10:59.880 --> 00:11:01.760
де зберігається ключ доступу до сховища.

00:11:01.880 --> 00:11:03.740
Конвейер отримує ключ під час виконання,

00:11:03.860 --> 00:11:05.680
використовує його і ніде не зберігає.

00:11:05.860 --> 00:11:06.860
Жодних ключів у коді,

00:11:06.980 --> 00:11:08.960
жодних секретів у конфігурації конвейера.

00:11:09.080 --> 00:11:10.680
Поєднуючи кероване посвідчення з RBAC

00:11:10.680 --> 00:11:11.900
та принципом найменших привілеїв,

00:11:11.900 --> 00:11:13.020
ви створюєте безпечну основу

00:11:13.020 --> 00:11:14.500
для будь-якого робочого навантаження Azure.

00:11:14.640 --> 00:11:16.960
Ваші програми проходять автентифікацію без паролів.

00:11:17.120 --> 00:11:18.220
Вони отримують доступ лише до того,

00:11:18.220 --> 00:11:18.860
що їм потрібно,

00:11:18.920 --> 00:11:20.620
і кожен такий доступ реєструється та перевіряється.

00:11:20.780 --> 00:11:22.440
Це шаблон, який Майкрософт рекомендує

00:11:22.440 --> 00:11:23.620
майже для кожного сценарію.

00:11:23.780 --> 00:11:25.240
Як тільки ви почнете його використовувати,

00:11:25.360 --> 00:11:27.040
ви здивуєтесь, чому раніше робили це інакше.

00:11:27.200 --> 00:11:29.220
Вартість та стратегія використання кількох сховищ.

00:11:29.380 --> 00:11:31.080
Отже, давайте поговоримо про вартість.

00:11:31.260 --> 00:11:32.780
Саме тут більшість людей дивуються.

00:11:33.000 --> 00:11:34.740
Скільки насправді коштує Azure Key Vault?

00:11:34.880 --> 00:11:36.180
Модель ціноутворення проста.

00:11:36.340 --> 00:11:38.040
Немає плати за зберігання кожного секрету.

00:11:38.160 --> 00:11:39.500
Ви не платите за кожен пароль або арі-ключ,

00:11:39.500 --> 00:11:40.300
який ви зберігаєте.

00:11:40.440 --> 00:11:41.940
Натомість ви платите за операцію.

00:11:42.100 --> 00:11:43.860
Для стандартного рівня це приблизно 3 центи

00:11:43.860 --> 00:11:45.140
за кожні 10 тисяч операцій.

00:11:45.300 --> 00:11:47.760
Виклик отримання секрету зараховується як одна операція,

00:11:47.880 --> 00:11:50.320
як і створення секрету або перегляд в місту сховища.

00:11:50.460 --> 00:11:52.360
Для типової програми малого чи середнього розміру

00:11:52.360 --> 00:11:53.840
це коштує кілька центів на місяць.

00:11:53.980 --> 00:11:55.160
Буквально кілька центів.

00:11:55.320 --> 00:11:57.500
Порівняйте це з AWS Secrets Manager.

00:11:57.740 --> 00:11:59.460
Вони стягують 40 центів за секрет на місяць

00:11:59.460 --> 00:12:00.380
лише за його зберігання,

00:12:00.380 --> 00:12:01.900
плюс додаткові збори за арі-виклики.

00:12:02.040 --> 00:12:03.980
Якщо у вас 100 секретів, це 40 доларів на місяць,

00:12:04.080 --> 00:12:05.620
перш ніж ви прочитаєте хоча б один із них.

00:12:05.780 --> 00:12:08.000
За журки Волт 100 секретів при помірному використанні

00:12:08.000 --> 00:12:09.600
можуть коштувати вам 15 центів.

00:12:09.740 --> 00:12:11.540
Різниця швидко зростає з масштабом.

00:12:11.680 --> 00:12:13.100
Також існує преміум-рівень.

00:12:13.280 --> 00:12:15.440
Він додає ключі на базі HSM для робочих навантажень,

00:12:15.440 --> 00:12:17.700
що потребують найвищого рівня криптографічного захисту.

00:12:17.820 --> 00:12:21.160
Це фінансові транзакції, дані охорони здоров'я, державні системи.

00:12:21.160 --> 00:12:22.860
Вартість за операцію там вища –

00:12:22.860 --> 00:12:26.580
близько 15 центів за 10 тисяч операцій для розширених типів ключів,

00:12:26.660 --> 00:12:28.560
плюс щомісячна плата за ключ HSM.

00:12:28.740 --> 00:12:31.820
Але для більшості програм стандартного рівня – більш ніж достатньо.

00:12:31.980 --> 00:12:34.800
Ось фінансовий сюрприз, який застає людей з ненацька.

00:12:34.800 --> 00:12:36.940
Для типового веб-додатка з кількома секретами

00:12:36.940 --> 00:12:40.120
та кількома тисячами операцій на місяцький Волт коштує менше долара.

00:12:40.280 --> 00:12:42.900
Ви витратите більше на каву, поки будете його налаштовувати.

00:12:43.080 --> 00:12:45.280
Але є стратегія, що важливіша за вартість –

00:12:45.280 --> 00:12:46.980
Кількість сховищ, які ви використовуєте.

00:12:47.120 --> 00:12:49.340
Розумний підхід – це стратегія з використанням кількох сховищ.

00:12:49.500 --> 00:12:50.920
Використовуйте окремі сховища для розробки,

00:12:51.000 --> 00:12:52.660
тестування, стейджингу та продуктивного середовища.

00:12:52.780 --> 00:12:54.600
Це запобігає найпоширенішій помилці.

00:12:54.760 --> 00:12:56.620
Хтось запускає тестовий скрипт, який випадково

00:12:56.620 --> 00:12:58.640
считує продуктивну базу даних, бо рядок підключення

00:12:58.640 --> 00:12:59.740
був у тому самому сховищі.

00:12:59.860 --> 00:13:02.520
Коли середовища розділені, така помилка стає неможливою.

00:13:02.660 --> 00:13:04.440
Вам також слід розділяти їх за бізнес-підрозділами

00:13:04.440 --> 00:13:05.820
або доменними зонами відповідності.

00:13:05.940 --> 00:13:07.760
Якщо ви працюєте з даними платіжних карток,

00:13:07.840 --> 00:13:09.460
помістіть ці секрети у власне сховище.

00:13:09.620 --> 00:13:11.380
Загальні бізнес-навантаження – в інше,

00:13:11.500 --> 00:13:12.640
медичні дані – у третє.

00:13:12.780 --> 00:13:15.540
Це не про ускладнення, це про обмеження радіуса ураження.

00:13:15.720 --> 00:13:17.380
Якщо одне сховище буде скомпрометовано,

00:13:17.480 --> 00:13:19.100
викриються лише секрети в цьому сховищі.

00:13:19.100 --> 00:13:21.380
Решта вашої інфраструктури залишиться в безпеці.

00:13:21.500 --> 00:13:23.840
І два вбудовані запобіжники, які варто завжди вмикати.

00:13:23.840 --> 00:13:26.460
М'яке видалення означає, що якщо хтось видалить секрет,

00:13:26.580 --> 00:13:27.500
він не зникне назавжди.

00:13:27.680 --> 00:13:30.120
Він переходить у відновлюваний стан на термін зберігання,

00:13:30.240 --> 00:13:32.100
який ви обираєте, до 90 днів.

00:13:32.300 --> 00:13:34.120
Захист від очищення йде ще далі.

00:13:34.300 --> 00:13:36.820
Ніхто не може остаточно видалити сховище або його вміст,

00:13:36.920 --> 00:13:38.480
доки не закінчиться термін зберігання.

00:13:38.480 --> 00:13:40.780
Разом вони запобігають випадковій втраті даних,

00:13:40.860 --> 00:13:42.880
через яку служби безпеки втрачають спокій.

00:13:43.020 --> 00:13:44.340
Як це все працює разом?

00:13:44.480 --> 00:13:47.360
Давайте об'єднаємо все це і побачимо, як пазл складається докупи.

00:13:47.360 --> 00:13:48.620
Key Vault – це не острів.

00:13:48.760 --> 00:13:51.980
Це центральна нервова система для секретів у вашій архітектурі Azure.

00:13:52.140 --> 00:13:54.060
Коли ви розумієте, як працює вся система,

00:13:54.240 --> 00:13:55.320
все стає на свої місця.

00:13:55.500 --> 00:13:57.780
Ось що відбувається, коли програмі потрібен секрет.

00:13:57.920 --> 00:14:00.280
Програма надсилає запит, використовуючи своє кероване посвідчення

00:14:00.280 --> 00:14:01.120
Managed Identity.

00:14:01.120 --> 00:14:03.440
Це посвідчення вже зареєстроване в EntraID.

00:14:03.640 --> 00:14:07.700
Azure створив його автоматично, коли ви ввімкнули кероване посвідчення для ресурсу.

00:14:07.860 --> 00:14:10.320
EntraID перевіряє справжність посвідчення,

00:14:10.440 --> 00:14:12.180
а потім передає запит до Key Vault.

00:14:12.180 --> 00:14:14.920
Key Vault перевіряє призначені вами дозволи RBAC.

00:14:15.160 --> 00:14:17.120
Якщо посвідчення має правильну роль, наприклад,

00:14:17.200 --> 00:14:19.120
Key Vault Secrets User, секрет повертається.

00:14:19.340 --> 00:14:20.940
Все це відбувається за мілісекунди.

00:14:21.100 --> 00:14:22.860
Програма ніколи не бачить облікових даних.

00:14:23.020 --> 00:14:24.240
Вона ніколи не зберігає пароль.

00:14:24.380 --> 00:14:26.100
Вона просто отримує значення, яке їй потрібне.

00:14:26.100 --> 00:14:28.780
А тепер подумайте, скільки сервісів Azure можуть до цього підключитися.

00:14:28.900 --> 00:14:33.220
App Service, Functions AKS, Data Factory, Synapse, Logic Apps, DevOps Pipelines –

00:14:33.220 --> 00:14:34.540
всі вони вміють працювати з Key Vault.

00:14:34.540 --> 00:14:38.860
Ви можете налаштувати веб-додаток так, щоб він брав секрет безпосередньо з параметрів програми.

00:14:39.020 --> 00:14:43.820
Ви можете налаштувати конвейер Data Factory на отримання ключа облікового запису зберігання з Key Vault під час виконання.

00:14:43.980 --> 00:14:48.360
Ви можете налаштувати кластер Kubernetes для отримання секретів за допомогою драйвера Key Vault CSI.

00:14:48.360 --> 00:14:54.380
Кожна служба інтегрується однаково, використовуючи ту саму систему ідентифікації, ролі RBAC та аудит журналів.

00:14:54.500 --> 00:14:56.880
Шаблон CI-CD є особливо ефективним.

00:14:57.040 --> 00:14:59.840
Ваші конвейери отримують секрети з Key Vault під час розгортання.

00:14:59.840 --> 00:15:03.200
Вони ніколи не зберігають їх у змінних конвейера чи секретах репозиторію.

00:15:03.320 --> 00:15:06.520
Якщо потрібно змінити пароль бази даних, ви оновлюєте його в Key Vault.

00:15:06.680 --> 00:15:09.880
Під час наступного запуску конвейер автоматично підтягне нове значення.

00:15:10.080 --> 00:15:12.660
Жодних змін у конвейері, коді чи повторних розгортань.

00:15:12.660 --> 00:15:14.620
Ось що робить цю систему такою вдалою.

00:15:14.780 --> 00:15:19.560
Як тільки ви налаштуєте Key Vault з керованою ідентичністю та RBAC, ви повністю забудете про керування обліковими даними.

00:15:19.700 --> 00:15:21.220
Ваші програми просто працюють.

00:15:21.400 --> 00:15:23.340
Секрети оновлюються непомітно для всіх.

00:15:23.340 --> 00:15:25.720
Сертифікати поновлюються без нічних екстрених ситуацій.

00:15:25.920 --> 00:15:27.740
Система виконує все це у фоновому режимі.

00:15:27.860 --> 00:15:29.700
Ось модель безпеки, яка має значення.

00:15:30.140 --> 00:15:31.840
Ідентифікація – це периметр, а не мережа.

00:15:32.000 --> 00:15:35.200
Немає значення, чи хтось знаходиться всередині вашої віртуальної мережі чи поза нею.

00:15:35.200 --> 00:15:38.580
Важливо лише те, чи має користувач дійсну ідентичність із потрібними дозволами.

00:15:38.720 --> 00:15:40.200
Key Vault забезпечує це за замовчуванням.

00:15:40.880 --> 00:15:46.160
Кожен запит на доступ проходить автентифікацію EntraID та авторизацію RBAC незалежно від джерела запиту.

00:15:46.300 --> 00:15:47.820
І все це реєструється в журналах.

00:15:47.900 --> 00:15:50.400
Кожне читання секрету, кожна операція з ключем, кожне отримання сертифіката.

00:15:50.540 --> 00:15:52.440
Ви можете бачити, хто і коли отримав доступ до чого.

00:15:52.600 --> 00:15:55.120
Якщо щось виглядає підозріло, у вас є дані для розслідування.

00:15:55.260 --> 00:15:57.460
Це критично важливо для відповідності вимогам, реагування на інциденти

00:15:57.460 --> 00:15:59.600
та просто для розуміння того, що відбувається у вашому середовищі.

00:15:59.600 --> 00:16:01.340
У цьому вся привабливість системи.

00:16:01.440 --> 00:16:06.360
Key Vault, EntraID, RBAC та керована ідентичність працюють разом як єдина структура безпеки.

00:16:06.360 --> 00:16:08.240
Кожен елемент підсилює інші.

00:16:08.360 --> 00:16:11.740
А коли вони налаштовані правильно, ви отримуєте систему керування даними,

00:16:11.920 --> 00:16:15.760
яка є безпечнішою та простішою в експлуатації, ніж будь-що створене власноруч.

00:16:16.040 --> 00:16:16.960
Практичні поради.

00:16:17.140 --> 00:16:19.100
Отже, що вам слід зробити прямо зараз?

00:16:19.260 --> 00:16:20.720
Перетворимо ці знання на дії.

00:16:20.720 --> 00:16:22.960
Ось справи, які ви можете вирішити цього тижня.

00:16:23.040 --> 00:16:24.560
Почніть зі своєї моделі дозволів.

00:16:24.680 --> 00:16:27.780
Відкрите свій кій Vault на порталі, перейдіть до налаштувань доступу та перевірте, що там вказано.

00:16:27.780 --> 00:16:30.700
Якщо ви бачите політику доступу до сховища Vault Access Policy, це старий методичний.

00:16:30.820 --> 00:16:33.580
Вам варто перейти на керування доступом на основі ролей Azure, Azure RBAC.

00:16:33.880 --> 00:16:35.060
Міграція є простою.

00:16:35.220 --> 00:16:39.780
Змініть модель дозволів і призначте ролі RBAC тим самим користувачам, які вже мали політики доступу.

00:16:39.960 --> 00:16:40.980
Зробіть це сьогодні.

00:16:41.140 --> 00:16:44.700
Microsoft рекомендує це і дослідження, про які ми говорили, чітко пояснили чому.

00:16:44.900 --> 00:16:48.320
Далі проведіть аудит усіх облікових записів, що мають роль співавтора Contributa у Key Vault.

00:16:48.320 --> 00:16:51.640
Відкрийте вкладку IAM у вашому сховищі та подивіться, хто має доступ співавтора.

00:16:51.780 --> 00:16:54.240
Кожна особа з цією ролью повинна мати на це вагому причину.

00:16:54.580 --> 00:16:55.340
Найчастіше – ні.

00:16:55.520 --> 00:16:57.760
Замініть роль учасника на щось більш конкретне.

00:16:57.900 --> 00:17:01.000
Якщо комусь потрібно лише читати секрети, надайте їм роль користувача секретів Key Vault.

00:17:01.140 --> 00:17:04.140
Якщо їм потрібно керувати секретами, використовуйте роль відповідального за секрети Key Vault.

00:17:04.360 --> 00:17:06.880
Мета полягає в тому, щоб повністю закрити цей шлях підвищення привілею.

00:17:07.020 --> 00:17:09.460
Далі скористайтеся керованими ідентифікаторами Managed Identity.

00:17:09.460 --> 00:17:12.700
Будь-яка служба Azure, який потрібен доступ до Key Vault, має використовувати їх.

00:17:12.820 --> 00:17:16.180
Якщо у вас є веб-програма, функція Data Factory або віртуальна машина,

00:17:16.320 --> 00:17:20.340
що досі використовують суб'єкт-сервіс із секретом клієнта, перейдіть на керований ідентифікатор.

00:17:20.480 --> 00:17:24.300
Це простіше, безпечніше і вирішує проблему курки та яйця, яку ми обговорювали.

00:17:24.460 --> 00:17:27.380
Azure бере на себе керування обліковими даними у фоновому режимі.

00:17:27.480 --> 00:17:31.080
І ще одне – увімкніть м'яке видалення та захист від очищення для кожного сховища.

00:17:31.080 --> 00:17:34.920
М'яке видалення увімкнено за замовчуванням для нових сховищ, а захист від очищення – ні.

00:17:35.140 --> 00:17:35.820
Увімкніть його.

00:17:36.020 --> 00:17:40.440
Це налаштування запобігає остаточному видаленню сховища або його вмісту протягом періоду зберігання.

00:17:40.660 --> 00:17:43.240
Воно врятувало не одну команду від катастрофічної помилки.

00:17:43.400 --> 00:17:44.520
Ось ваш заклик до дії.

00:17:44.820 --> 00:17:47.040
Проаналізуйте свій поточний підхід до керування секретами.

00:17:47.200 --> 00:17:51.100
Знайдіть один секрет, який досі знаходиться у файлі конфігурації, змінній оточення або жорстко прописаний у коді.

00:17:51.220 --> 00:17:52.820
Перенесіть його в Key Vault цього тижня.

00:17:52.820 --> 00:17:53.580
Лише один.

00:17:53.720 --> 00:17:55.920
Коли ви побачите, наскільки це просто, ви захочете перенести решту.

00:17:56.040 --> 00:17:57.580
Безпека – це неодноразове налаштування.

00:17:57.740 --> 00:17:58.780
Це постійна практика.

00:17:58.920 --> 00:18:01.520
Key Vault полегшує цю практику, але лише за умови правильного використання.

00:18:01.860 --> 00:18:02.620
Інструменти вже є.

00:18:02.780 --> 00:18:04.180
Паттерни перевірені на практиці.

00:18:04.320 --> 00:18:06.080
Тепер справа за вами – впровадити їх.

00:18:06.220 --> 00:18:07.140
Це і є система.

00:18:07.320 --> 00:18:11.120
Key Vault – ваш цифровий сейф, але він надійний лише настільки, наскільки надійні засоби керування доступом навколо нього.

00:18:11.280 --> 00:18:13.140
Почніть з аудиту, який я щойно описав.

00:18:13.260 --> 00:18:14.640
Перевірте свою модель дозволів.

00:18:14.640 --> 00:18:18.060
Перевірте призначення ролей учасників і перенесіть один секрет у сховище цього тижня.

00:18:18.160 --> 00:18:20.940
Підписуйтесь, щоб отримувати більше порад із хмарної безпеки простою мовою

00:18:20.940 --> 00:18:23.860
і поділіться цим із тими, хто досі зберігає секрети у файлах конфігурації.