Разрешения RBAC Azure AD для восстановления субъектов-служб

Ваша настраиваемая роль отсутствует конкретное разрешение, необходимое для восстановления удаленных субъектов-служб. Хотя у вас есть разрешение на восстановление удаленных приложений (microsoft.directory/deletedItems.applications/restore), вам требуется эквивалентное разрешение для субъектов-служб.

Конкретное разрешение, которое вам нужно добавить, — microsoft.directory/deletedItems.servicePrincipals/restore. Вот исправленный код PowerShell:

$params = @{
    description = "delete/restore applications and service principals."
    displayName = "Test role"
    isEnabled = $true
    assignableScopes = @("/")
    rolePermissions = @(
        @{
            allowedResourceActions = @(
                "microsoft.directory/applications/standard/read",
                "microsoft.directory/applications/delete",
                "microsoft.directory/servicePrincipals/standard/read",
                "microsoft.directory/servicePrincipals/delete",
                "microsoft.directory/deletedItems.applications/restore",
                # Добавьте это разрешение для восстановления субъекта-службы
                "microsoft.directory/deletedItems.servicePrincipals/restore"
            )
        }
    )
}

New-MgRoleManagementDirectoryRoleDefinition -BodyParameter $params

Содержание

• Понимание RBAC Azure AD для управления субъектами-службами
• Необходимые разрешения для восстановления субъектов-служб
• Полная настройка настраиваемой роли
• Проверка разрешений роли
• Лучшие практики для ролей управления субъектами-службами

Понимание RBAC Azure AD для управления субъектами-службами

Azure AD использует управление доступом на основе ролей (RBAC) для управления разрешениями для объектов каталога. При работе с субъектами-службами и приложениями важно понимать, что они рассматриваются как отдельные объекты со своими собственными областями разрешений.

Ключевые концепции:

• Субъекты-службы представляют приложения в Azure AD и имеют собственный жизненный цикл управления
• Приложения в этом контексте относятся к объектам регистрации приложений
• Удаленные элементы для обоих объектов хранятся отдельно и требуют разных разрешений на восстановление
• Роль “Администратор приложений” имеет встроенные разрешения для обеих операций восстановления, поэтому она работает

Когда вы удаляете субъект-службу, он перемещается в контейнер удаленных элементов для субъектов-служб, а не для приложений. Именно поэтому вам требуется конкретное разрешение на восстановление субъекта-службы.

Необходимые разрешения для восстановления субъектов-служб

Отсутствующее разрешение — microsoft.directory/deletedItems.servicePrincipals/restore. Это разрешение специально позволяет пользователям восстанавливать удаленные субъекты-службы из контейнера удаленных элементов Azure AD.

Разбор разрешений:

• microsoft.directory/deletedItems.applications/restore - Восстанавливает удаленные регистрации приложений
• microsoft.directory/deletedItems.servicePrincipals/restore - Восстанавливает удаленные субъекты-службы

Почему это важно:

• Субъекты-службы и приложения хранятся в разных каталогах внутри Azure AD
• Удаленные субъекты-службы управляются отдельно от удаленных приложений
• Без разрешения на восстановление субъекта-службы API Azure AD возвращает ошибку “доступ запрещен” при попытке восстановления

Важно: Операция восстановления для субъектов-служб требует как разрешения на чтение удаленных элементов (microsoft.directory/deletedItems.servicePrincipals/standard/read), так и разрешения на восстановление. Однако в большинстве случаев стандартное разрешение на чтение родительского ресурса (microsoft.directory/servicePrincipals/standard/read) неявно включает доступ на чтение к удаленным элементам.

Полная настройка настраиваемой роли

Вот комплексная настройка настраиваемой роли, которая включает все необходимые разрешения для управления приложениями и субъектами-службами, включая операции восстановления:

$params = @{
    description = "Полная роль управления для приложений и субъектов-служб включая операции удаления и восстановления"
    displayName = "Менеджер приложений и субъектов-служб"
    isEnabled = $true
    assignableScopes = @("/")
    rolePermissions = @(
        @{
            allowedResourceActions = @(
                # Разрешения для приложений
                "microsoft.directory/applications/standard/read",
                "microsoft.directory/applications/basic/read",
                "microsoft.directory/applications/create",
                "microsoft.directory/applications/update",
                "microsoft.directory/applications/delete",
                "microsoft.directory/deletedItems.applications/restore",
                
                # Разрешения для субъектов-служб
                "microsoft.directory/servicePrincipals/standard/read",
                "microsoft.directory/servicePrincipals/basic/read",
                "microsoft.directory/servicePrincipals/create",
                "microsoft.directory/servicePrincipals/update",
                "microsoft.directory/servicePrincipals/delete",
                "microsoft.directory/deletedItems.servicePrincipals/restore"
            )
        }
    )
}

New-MgRoleManagementDirectoryRoleDefinition -BodyParameter $params

Включенные категории разрешений:

• Разрешения на чтение - Стандартный и базовый доступ на чтение как к приложениям, так и к субъектам-служб
• Управление жизненным циклом - Операции создания, обновления и удаления
• Операции восстановления - Возможности восстановления как приложений, так и субъектов-служб

Проверка разрешений роли

После создания роли вы должны проверить, что у нее есть правильные разрешения, используя Microsoft Graph API или PowerShell:

Использование PowerShell для проверки разрешений роли:

# Получение определения роли
$role = Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Менеджер приложений и субъектов-служб'"

# Отображение разрешений роли
$role.rolePermissions.allowedResourceActions

Использование Microsoft Graph API для проверки:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions?$filter=displayName eq 'Менеджер приложений и субъектов-служб'

Тестирование операции восстановления:

# Тестирование восстановления удаленного субъекта-службы
Restore-MgDirectoryDeletedServicePrincipal -DeletedServicePrincipalId "идентификатор-объекта-удаленного-субъекта-службы"

Если роль настроена правильно, эта команда должна выполниться успешно. Если вы получаете ошибку “доступ запрещен”, дважды проверьте, что разрешение microsoft.directory/deletedItems.servicePrincipals/restore включено.

Лучшие практики для ролей управления субъектами-службами

При создании настраиваемых ролей для управления субъектами-службами учитывайте эти лучшие практики:

Принцип наименьших привилегий:

• Предоставляйте только конкретные разрешения, необходимые для каждой операции
• Избегайте использования области назначения “/” (все каталоги), если это абсолютно необходимо
• Рассмотрите возможность ограничения области для конкретных регистраций приложений или субъектов-служб, когда это возможно

Распространенные комбинации разрешений:

Мониторинг и аудит:

• Включите ведение журнала аудита Azure AD для назначений ролей и использования разрешений
• Регулярно проверяйте назначения ролей, чтобы убедиться, что они все еще необходимы
• Рассмотрите возможность использования Azure AD Privileged Identity Management для своевременного доступа (just-in-time)

Обработка ошибок:

• При сбое восстановления субъекта-службы проверьте конкретное сообщение об ошибке
• Распространенные ошибки включают:
  • Доступ запрещен (отсутствуют разрешения)
  • Объект не найден (субъект-служба уже окончательно удален)
  • Конфликт (субъект-служба уже восстановлен или существует)

Заключение

1. Ключевое разрешение, которого вам не хватало, — microsoft.directory/deletedItems.servicePrincipals/restore, которое специально позволяет восстанавливать удаленные субъекты-службы.

2. Субъекты-службы и приложения требуют отдельных разрешений на восстановление, поскольку они управляются как разные типы объектов в Azure AD.

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

4. Всегда проверяйте разрешения вашей роли после создания и тестируйте операции перед назначением роли пользователям.

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

Добавив отсутствующее разрешение на восстановление субъекта-службы в вашу настраиваемую роль, вы сможете успешно восстанавливать удаленные субъекты-службы так же, как это можно делать с помощью встроенной роли “Администратор приложений”.