Защита среды Azure
Теперь, когда вы понимаете, как управлять средами и защищать конвейеры развертывания, можно отключить доступ человека к управляемым средам. В этом уроке вы узнаете, как структурировать разрешения пользователей в средах Azure. В том числе, как разрешить доступ в чрезвычайных ситуациях и как проверить любые изменения, происходящие в вашем активе Azure.
Блокировка доступа человека
Блокируя доступ человека к управляемым средам, вы гарантируете, что случайные или вредоносные изменения не могут обойти процессы проверки и автоматического развертывания вашей команды. Если вы не блокируете доступ человека, кто-то может случайно обойти элементы управления, на планирование и реализацию которых в репозитории и конвейерах вы потратили так много времени.
Без блокировки элементов управления также возможны случайные повреждения. Например, предположим, что у пользователя есть две копии открытого портала Azure. Одна — для тестовой среды, а другая — для рабочей среды. Когда пользователь переключается между вкладками браузера, легко случайно внести изменения, которые были предназначены для тестовой среды, в рабочую.
Чтобы заблокировать доступ к человеку, можно использовать управление доступом на основе ролей Azure (RBAC). В RBAC вы создаете назначения ролей для определения:
- Пользователи, группы или субъекты-службы могут получать доступ к определенному набору ресурсов Azure (область).
- Действия этих пользователей, групп или субъектов-служб при доступе к ресурсам (роль).
Azure RBAC предоставляет множество встроенных типов ролей, в том числе:
- Читатель, имеющий доступ только для чтения к среде.
- Участник, который может изменять ресурсы.
- Владелец, который может изменять ресурсы и предоставлять доступ другим пользователям.
Важно предоставить доступ в соответствующей области. Если ваша организация придерживается рекомендуемой практики использования выделенных подписок Azure для каждой среды, рассмотрите возможность использования групп управления Azure, чтобы упростить область назначения ролей. Если ваша организация использует одну подписку Azure для всех сред, избегайте предоставления пользователям доступа ко всей подписке, так как все ресурсы, включая управляемые среды, наследуют это разрешение.
Совет
Назначения ролей — это ресурсы Azure Resource Manager (ARM). Это означает, что вы можете настроить назначения ролей Azure RBAC в коде, например с помощью Bicep.
При планировании назначений ролей необходимо решить, что подходит для вашей организации. Предположим, что ваша организация создает отдельные подписки для каждой среды. Вы можете предоставить администраторам и разработчикам доступ Читателя к управляемым средам. С помощью этой роли они могут получить доступ к рабочей среде на портале Azure для просмотра конфигурации ресурсов, просмотра метрик и журналов, а также изучения проблем или ошибок без внесения изменений в среду.
Следующим образом можно настроить назначения ролей для сред вашей компании по производству игрушек, как для администраторов Azure, так и для разработчиков, которые пишут код и скрипты:
| Имя среды | Уровень управления | Разрешение администратора | Разрешение разработчика |
|---|---|---|---|
| Разработка | Управляется | Читатель | Читатель |
| Тест | Управляется | Читатель | Читатель |
| Промежуточная | Управляется | Читатель | Читатель |
| Производственный экземпляр | Управляется | Читатель | Читатель |
| Демонстрация | Неуправляемые | Владелец | Участник |
| Тестирование производительности | Неуправляемые | Владелец | нет |
| тест на проникновение; | Неуправляемые | Владелец | нет |
| Проверки на запросов на вытягивание | Неуправляемые | Владелец | Владелец |
| Песочницы для разработки | Неуправляемые | Владелец | Владелец |
При планировании назначений ролей убедитесь, что вы тщательно их протестировали. Иногда для операций управления могут потребоваться разрешения, которые не являются очевидными. Предоставьте участникам вашей команды возможность протестировать все свои повседневные работы с разрешениями, которые вы планируете использовать. Просмотрите все проблемы, с которыми они сталкиваются.
Регулярно проверяйте назначения ролей. Убедитесь, что вы случайно не предоставили доступ не тем людям или предоставили слишком широкий доступ.
Доступ к плоскости данных
В Azure поддерживаются операции двух типов:
- Для управления ресурсами в подписке используются операции уровня управления.
- Для доступа к функциям, предоставляемым ресурсом, используются операции плоскости данных.
Например, для создания учетной записи хранения можно использовать операцию плоскости управления. Операцию плоскости данных можно использовать для подключения к учетной записи хранения и доступа к данным, содержащимся в ней.
При блокировке прямого доступа пользователей к ресурсам Azure также следует учитывать, как это ограничение применяется к операциям плоскости данных. Например, процесс развертывания может хранить ключ для учетной записи хранения в месте, к которому может получить доступ администратор. Этот администратор может использовать ключ для обхода элементов управления и доступа к плоскости данных учетной записи хранения напрямую.
Увеличение числа ресурсов Azure поддерживает настройку управления доступом на уровне данных с помощью идентификатора Microsoft Entra. Эта поддержка снижает вероятность утечки ключей или предоставления доступа к плоскости данных непреднамеренно. Рекомендуется использовать идентификатор Microsoft Entra для доступа к плоскости данных везде, где вы можете.
Аварийный доступ
Иногда возникают чрезвычайные ситуации, и кто-то должен быстро получить доступ к рабочей среде для расследования или устранения проблемы. Важно планировать и репетировать, как вы хотите реагировать на эти чрезвычайные ситуации, прежде чем они происходят. Избегайте необходимости поспешно находить решения в сам момент сбоя.
Одним из подходов является «экстренная» учетная запись, специальная учетная запись пользователя, с более высоким уровнем разрешений, чем обычно есть у пользователей. Это называется брейк-стеклянной учетной записью, потому что требуется что-то необычное для получения доступа к своим учетным данным, как и разбиение стекла на панели пожарной сигнализации. Вы можете предоставить оператору безопасный способ получения доступа к учетным данным для экстренной учетной записи. Затем операторы могут войти в систему с этой учетной записью для внесения экстренных изменений.
Последовательность шагов для использования экстренной учетной записи выполняется следующим образом:
- Пользователь пытается выполнить экстренное изменение с помощью обычной учетной записи, но операция заблокирована, так как обычная учетная запись пользователя имеет недостаточный уровень разрешений.
- Пользователь обращается к учетным данным экстренной учетной записи и выполняет вход от имени этого пользователя.
- Пользователю (действующему через экстренную учетную запись) разрешено выполнить операцию.
Для использования экстренных учетных записей требуется высокий уровень дисциплины. Их использование должно быть зарезервировано для в полной мере чрезвычайных ситуаций. Внимательно управляйте своими учетными данными и защищайте их, так как учетная запись имеет высокий уровень привилегий. Рекомендуется часто изменять учетные данные экстренных учетных записей, чтобы свести к минимуму вероятность того, что они будут скомпрометированы.
Экстренные учетные записи часто используются командой, поэтому трудно проследить, кто их использовал и что сделали эти пользователи. Альтернативный подход к учетным записям разбиения заключается в внедрении функции Microsoft Entra управление привилегированными пользователями (PIM). Оно позволяет временно предоставить пользователю доступ к более высокому уровню разрешений.
Последовательность шагов для использования PIM:
Пользователь пытается выполнить экстренное изменение с помощью обычной учетной записи, но операция заблокирована, так как обычная учетная запись пользователя имеет недостаточный уровень разрешений.
Пользователь обращается к PIM и запрашивает временное повышение разрешений.
PIM может выполнять дополнительную проверку удостоверения пользователя или запрашивать утверждение от кого-либо, в зависимости от того, как оно настроено для организации.
Если запрос авторизован, PIM временно обновляет разрешения пользователя.
Пользователю разрешено выполнять операцию.
После истечения определенного периода времени PIM отменяет повышенные разрешения, предоставленные пользователю.
PIM и Azure записывают полные журналы аудита, чтобы понять, кто запрашивал повышенные разрешения и почему. Журналы также отслеживают, что они сделали в вашей среде при предоставлении разрешений.
Примечание.
Для PIM требуется лицензия premium для идентификатора Microsoft Entra.
После завершения чрезвычайной ситуации
После завершения чрезвычайной ситуации важно выполнить утвержденный процесс возврата к нормальной работе. Вы должны следовать этому процессу, прежде чем истекло слишком много времени, или вы рискуете забыть важные сведения или оставить конфигурации в небезопасном состоянии.
Внимательно изучите журналы аудита Azure и PIM, чтобы понять изменения, которые были выполнены в управляемых средах, и особенно в рабочей среде.
Внимание
У того, кто использует PIM или экстренную учетную запись, может быть возможность предоставить себе более широкие права в сравнении со стандартной учетной записью пользователя. Они также могут использовать временные разрешения для получения доступа к ключам плоскости данных, которые они могут продолжать использовать после отзыва разрешений.
Тщательно проанализируйте все случаи использования экстренных учетных записей или PIM. Отмените или смените все ключи, которые могли быть предоставлены во время чрезвычайной ситуации.
Вскоре после чрезвычайной ситуации повторно выполните синхронизацию ресурсов инфраструктуры как кода с любыми изменениями, внесенными во время чрезвычайной ситуации. Например, предположим, что в рамках решения срочной проблемы администратор вручную увеличил номер SKU Плана Службы приложений Azure App. Обновите шаблоны развертывания, чтобы включить новый номер SKU в конфигурацию ресурса. В противном случае во время следующего регулярного развертывания из конвейера номер SKU может быть сброшен на предыдущее значение и вызвать другой сбой.
Аудит изменений в среде Azure
Также рекомендуется настроить аудит и ведение журнала во всей среде Azure и отслеживать определенные события или угрозы.
Рекомендуется использовать средство управления сведениями о безопасности и событиями (SIEM), например Microsoft Sentinel. Это средство можно использовать для сбора и анализа журналов из вашего имущества Azure, а также даже из Azure DevOps, GitHub и других систем. Sentinel можно использовать для отслеживания непредвиденных или несанкционированных изменений в ресурсах Azure. Вы также можете импортировать журналы аудита конвейера и активировать оповещения при возникновении событий, например, когда администратор изменяет политику защиты ветви в репозитории.