Не будьте таким парнем: избегайте случайных удалений с помощью замков Microsoft Azure

Опубликовано: 2 Марта, 2023
Не будьте таким парнем: избегайте случайных удалений с помощью замков Microsoft Azure

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

Если в вашей организации используется процесс управления изменениями и есть запланированное совещание для обсуждения изменений, окно обслуживания для внесения таких изменений, и после этого никакие изменения не должны применяться в рабочей среде, то Azure ;ocks может хорошо работать в вашей организации. стратегия.

Функция есть везде в Azure — вы можете применить ее на уровне подписки, группы ресурсов и ресурсов, и существует иерархия. Они не привязаны к разрешениям RBAC, поэтому, даже если у вас есть все разрешения в мире Azure, вы не сможете обойти блокировки. Неплохо, а?

бывают двух видов: только для чтения и для удаления. Где блокировки только для чтения вообще не позволяют выполнять какие-либо изменения при их применении. Используя Удалить блокировки, мы можем выполнять изменения и даже добавлять ресурсы, на которые распространяются блокировки, однако операция удаления не разрешена.

Общие сведения о блокировках Azure

Как я уже сказал, функция есть везде. Возможно, вы не заметили, но он присутствует, когда вы открываете каждую колонку на портале Azure.

Допустим, вы зашли на виртуальный сетевой ресурс и проверили блокировки, вы увидите все существующие блокировки, выполненные на уровне родителя, и будет указан список всех блокировок, которые применяются к этим конкретным ресурсам. Если они неактивны, это означает, что они были определены на более высоком уровне, в нашем примере на уровне . На этом этапе верхнее меню становится решающим, потому что мы можем перейти на более высокие уровни для проверки блокировок, и в нашем случае мы можем проверить уровни и .

Еще один полезный ресурс при управлении блокировками — проверка на уровне подписки. Используя портал Azure, щелкните элемент Subscriptions, а затем Resource Locks. Будет показан список всех существующих . К сожалению, у нас нет такой же возможности перейти непосредственно к ресурсу, к которому применяется блокировка, а предоставленная информация говорит о и не дает нам дополнительных сведений. Было бы неплохо узнать, находится ли блокировка на уровне или .

Использование блокировок Azure в простом сценарии

Мы можем использовать простой сценарий, чтобы проиллюстрировать, как функция замков может помочь организации. Допустим, у нас есть группа ресурсов под названием RG-Network, и после развертывания мы во всем разобрались, все настройки на месте, и все остальные группы ресурсов нашей подписки используют эту группу ресурсов, чтобы полагаться на свою сетевую часть.

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

Как мы видели в первой части этой статьи, блокировки могут быть определены двух типов: и . С помощью Azure Portal нажмите на пункт Resource Groups, а затем нажмите на нужную группу ресурсов, в нашем случае RG-Network, а затем нажмите на locks.

Будет показан новый блейд со списком всех замков на этом уровне или выше. Чтобы создать новый, нажмите «Добавить».

В появившемся новом окне назовите замок, определите тип и добавьте некоторые примечания для дальнейшего использования. В этом сценарии мы блокируем эту группу ресурсов из-за управления изменениями 171, а затем нажимаем OK.

Теперь, когда у нас есть блокировка, пришло время внести изменения в любой ресурс, принадлежащий этой группе. Допустим, администратор решил, что создание подсети в рабочее время не помешает, и попытался изменить настройки. Сообщение об ошибке, которое он получит, будет похоже на это. Удивительно, а?

Использование монитора и оповещение с блокировками

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

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

Использование пользовательской роли RBAC

Если у вас есть делегирование в вашей среде Microsoft Azure и вы используете RBAC для контроля и применения принципа наименьших привилегий, вы можете создать роль RBAC для лица, ответственного за процесс управления изменениями, для создания и снятия , таким образом, вы будете знать, что ваша среда не быть измененным вне вашего процесса. Имейте в виду, что это всего лишь гипотетический сценарий для демонстрации некоторых возможностей блокировок и Microsoft Azure в целом — если он подходит для всего или части вашей организации, дерзайте!

Наш первый шаг — создать новую , и мы собираемся пометить ее как Lock Administrator, и вместо того, чтобы создавать с нуля, мы будем использовать существующую роль. По умолчанию только встроенные роли Владелец и Администратор доступа пользователей могут управлять блокировками.

Первый командлет PowerShell экспортирует встроенную роль администратора доступа пользователей в файл JSON, который мы назвали , а второй командлет просто показывает текущие действия, которые может выполнять эта роль (прочитайте все, что определено * /read, управлять авторизацией, определенной авторизацией/*, и иметь возможность играть с заявками в службу поддержки, определенными Microsoft.Support/*).

Get-AzureRMRoleDefinition -Name «Администратор доступа пользователей» | ConvertTo-Json | out-file LockAdmin.json Get-AzureRMRoleDefinition -Name «Администратор доступа пользователей» | фл

Мы хотим разрешить только видеть ресурсы и управлять блокировками. Мы собираемся открыть файл JSON и внести несколько изменений следующим образом:

  • Удалить строку идентификатора
  • Измените значение имени на имя, которое соответствует нашей новой настраиваемой роли.
  • Измените значение описания
  • Удалить из действий
  • Добавьте /subscriptions/<subscription-id> в раздел .
    Примечание. Вы можете получить эту информацию с помощью Get-AzureRMSubscription.

Сохраните файл и запустите следующий командлет, чтобы создать новую настраиваемую роль RBAC. (Файл JSON находился в той же папке, где я запускал командлет, вы всегда можете указать путь, например: C:Tempfile.json.)

New-AzureRmRoleDefinition -InputFile.LockAdmin.json

Следующим шагом является назначение пользователя на уровне подписки (вы можете ввести более строгие ограничения и добавить на уровне группы ресурсов или ресурса). В нашем примере мы добавим нашего пользователя в качестве роли (Да, Ночная Сова будет нашим администратором замков! Нам нужны силы супергероев для поддержания порядка в производственной среде?)

В последнем тесте мы вошли в систему как (элемент 01), мы видим, что мы не можем сделать одно единственное изменение в нашей среде, но можем управлять блокировками на всех уровнях. В приведенном ниже примере мы проверяем блокировки на уровне группы ресурсов (элемент 2), видим установленные блокировки (элемент 4) и можем создавать новые (элемент 3).

Изображение 365
Довольно аккуратно, правда?