Безопасность и разрешения 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 упрощает соблюдение этого принципа, привязывая разрешения к группам безопасности, субъектам-службам и учётным записям автоматизации, а не к отдельным пользователям.

Например, поставщик управляемых услуг может разделить доступ своей команды на несколько уровней:

• Служба поддержки: получает роль Reader, чтобы проверять состояние виртуальных машин и журналы диагностики без внесения изменений.
• Инженеры по миграции: получают роль Contributor для конкретных групп ресурсов, чтобы развёртывать рабочие нагрузки и применять обновления.
• Сценарии автоматизации: получают ограниченные по области действия пользовательские служебные учётные записи для выполнения ночного резервного копирования и сбора телеметрии.

Такой детальный подход гарантирует, что человеческая ошибка или скомпрометированные учётные данные на стороне поставщика не смогут привести к катастрофическим последствиям во всех управляемых средах клиентов.

Ограничения встроенных ролей как защитные барьеры

Чтобы защитить организации от избыточных разрешений, Azure Lighthouse устанавливает строгие ограничения на то, что можно и нельзя делегировать. Прежде всего, роль верхнего уровня Owner полностью не поддерживается в делегировании Lighthouse. Поставщик никогда не может получить возможность назначать разрешения другим или принимать на себя полное владение подпиской клиента.

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

Журналы аудита и отслеживание соответствия требованиям

Специалисты по соблюдению требований часто впадают в панику при мысли о том, что внешние поставщики получают доступ к ключевой облачной инфраструктуре предприятия. Azure Lighthouse снимает это беспокойство, ведя тщательный, защищённый от подделки журнал событий на стороне клиента.

Каждое действие пользователя поставщика — будь то перезагрузка виртуальной машины, изменение правила брандмауэра или обновление сетевых параметров — записывается непосредственно в журнал действий Azure (Azure Activity Log) клиента. Поскольку эти журналы находятся в клиенте, внешний поставщик не может их изменить или удалить. ИT-администраторы могут проводить регулярные аудиты, чтобы ответить на ключевые вопросы безопасности: кто обращался к этому ресурсу? Когда он был изменён? Какая именно команда была выполнена?

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

Заключение

Azure Lighthouse решает давнее противоречие между надёжной облачной безопасностью и эффективным управлением несколькими клиентами. Заменяя обмен паролями криптографически проверяемым делегированным управлением ресурсами, которым управляет клиент, ИТ-руководители могут масштабировать свою работу без ущерба для безопасности. Чтобы разобраться в базовых концепциях этой архитектуры, обязательно послушайте полный выпуск подкаста M365 FM, где без лишнего жаргона разбираются современные подходы к облачному управлению.

Часто задаваемые вопросы

Может ли поставщик Azure Lighthouse просматривать пароли моей организации?

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

Что произойдёт с доступом Azure Lighthouse, если поставщик подвергнется взлому?

Поскольку доступ строго ограничен конкретными встроенными ролями и ресурсами, заданными в назначении регистрации, и роль Owner исключена, зона возможного ущерба надёжно изолирована. Кроме того, клиент может мгновенно отозвать доступ, удалив назначение регистрации в своём портале.

Поддерживает ли Azure Lighthouse пользовательские роли RBAC?

Нет. Azure Lighthouse поддерживает только встроенные роли Azure, предоставляемые Microsoft. Пользовательские роли, созданные в клиенте поставщика или клиента, нельзя использовать в определениях регистрации.

Кто имеет право настраивать Azure Lighthouse в клиенте?

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