Безпека Azure Lighthouse і дозволи: як безпечно керувати доступом до хмари з кількох клієнтів

By Mirko Peters · 2026-10-21

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

Automatically translated with AI from the original post. Read the English original

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

Головне

• Клієнти зберігають повну владу над своїми клієнтами Azure, визначаючи точні області дії та вбудовані ролі.
• Визначення реєстрації та призначення працюють як постійне рукостискання, яке Azure перевіряє під час кожної дії.
• Повні ролі Owner і доступ до рівня даних повністю не підтримуються в делегуваннях Azure Lighthouse.
• Постачальники працюють через логічні проєкції у власному порталі, не передаючи паролі користувачів чи облікові дані.
• Журнали активності фіксують кожну зміну в клієнті клієнта, забезпечуючи прозорий журнал аудиту.

Архітектура безпеки Azure Lighthouse

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

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

Рукостискання з двох частин

Безпека в Azure Lighthouse ґрунтується не на сліпій довірі, а на двох незмінних конфігураційних файлах JSON, які розгортає безпосередньо адміністратор верхнього рівня клієнта.

Перша частина — визначення реєстрації. Цей документ зберігається в обліковому записі клієнта і прямо вказує, якій зовнішній організації довіряють і які конкретні вбудовані ролі їй надано. Друга частина — призначення реєстрації, яке працює як адреса і вказує це визначення на конкретну передплату або групу ресурсів.

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

Впровадження принципу найменших привілеїв у середовищах для кількох клієнтів

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

Наприклад, постачальник керованих послуг може розподілити доступ своєї команди на окремі рівні:

• Команда підтримки: отримує роль Читач, щоб перевіряти стан віртуальних машин і журнали діагностики без внесення змін.
• Інженери з міграції: отримують роль Учасник для конкретних груп ресурсів, щоб розгортати робочі навантаження та застосовувати оновлення.
• Скрипти автоматизації: отримують спеціальні облікові записи служб з обмеженим доступом для виконання щоденних резервних копій і збору телеметрії.

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

Обмеження вбудованих ролей як захисні бар’єри

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

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

Журнали аудиту та відстеження відповідності

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

Кожна окрема дія, яку виконує користувач постачальника, будь то перезавантаження віртуальної машини, зміна правила брандмауера чи оновлення мережевих налаштувань, записується безпосередньо в журнал активності Azure клієнта. Оскільки ці журнали зберігаються в клієнті, зовнішній постачальник не може ні змінити їх, ні видалити. ІТ-адміністратори можуть регулярно проводити аудит, щоб відповісти на ключові питання безпеки: хто звертався до цього ресурсу? Коли його змінили? Яку саме команду було виконано?

Крім того, організації можуть поєднати Azure Lighthouse з Privileged Identity Management (PIM), щоб вимагати підвищення привілеїв лише за потреби. Замість постійних прав учасника інженери постачальника можуть запитувати доступ лише тоді, коли виникає інцидент. Схвалення фіксуються в журналі, а часові обмеження застосовуються автоматично.

Висновок

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

Поширені запитання

Чи може постачальник Azure Lighthouse переглядати паролі моєї організації?

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

Що відбувається з доступом Azure Lighthouse, якщо постачальник зазнає зламу?

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

Чи підтримує Azure Lighthouse власні ролі RBAC?

Ні. Azure Lighthouse підтримує лише вбудовані ролі Azure, які надає Microsoft. Власні ролі, створені в клієнті постачальника або в клієнті замовника, не можна використовувати у визначеннях реєстрації.

Хто має повноваження налаштовувати Azure Lighthouse у клієнті?

Розгорнути шаблон реєстрації та налаштувати підключення може лише користувач із привілейованим доступом, а саме обліковий запис із дозволами на призначення ролей на рівні підписки або групи ресурсів, наприклад User Access Administrator або Owner.