Использование принципов безопасности служб и управляемых идентификаторов в Azure DevOps

Azure DevOps Services

учетные записи служб и управляемые удостоверения обеспечивают безопасную масштабируемую аутентификацию для рабочих процессов автоматизации Azure DevOps. Эти типы удостоверений Microsoft Entra обеспечивают повышенную безопасность по сравнению с традиционными личными маркерами доступа (PATs). Они используют автоматическое управление учетными данными, более короткие сроки существования маркеров и средства управления доступом корпоративного уровня.

Преимущества сервисных принципалов и управляемых идентичностей

Улучшенная безопасность

• Краткосрочные токены: срок действия токенов Microsoft Entra истекает каждый час, что снижает риск воздействия по сравнению с PATs (которые могут действовать до одного года).
• Автоматическая смена: управляемые удостоверения обрабатывают смену учетных данных автоматически.
• Нет сохраненных секретов: необходимость хранения долгосрочных учетных данных в коде или конфигурации устранена.

Эффективность работы

• Централизованное управление: управление доступом с помощью политик Microsoft Entra ID и разрешений Azure DevOps.
• Возможности аудита: отслеживание шаблонов проверки подлинности и доступа с помощью комплексного ведения журнала.
• Эффективное масштабирование: поддержка сценариев корпоративной автоматизации без отдельных зависимостей пользователей.

Современная проверка подлинности

• На основе стандартов: использует протоколы OAuth 2.0 и OpenID Connect.
• Поддержка многофакторной проверки подлинности: наследует политики безопасности организации.
• Условный доступ: применяет расширенные политики безопасности на основе контекста.

Общие сведения о субъектах-службах и управляемых удостоверениях

Сервисные принципы

Учётные записи службы Service principals — это объекты Microsoft Entra, представляющие приложения в арендаторе. Они определяют, что может делать приложение, к каким ресурсам оно может получить доступ и кто может его использовать. Субъекты-службы создаются автоматически при регистрации приложения в Microsoft Entra ID и обеспечивают безопасный способ проверки подлинности и доступа к ресурсам приложений.

Основные характеристики

• Создаются с помощью регистрации приложений в Microsoft Entra ID.
• Поддержка сценариев с несколькими арендаторами.
• Требовать явное управление учетными данными (сертификаты или секреты клиента).
• Идеально подходит для приложений, которые должны проходить проверку подлинности в разных средах.

Управляемые идентичности

Управляемые удостоверения — это особый тип учетной записи службы, которыми Azure управляет автоматически. Они устраняют необходимость для разработчиков управлять учетными данными, предоставляя автоматически управляемый идентификатор в Microsoft Entra ID для ресурсов Azure.

Типы управляемых удостоверений

Управляемое удостоверение, назначаемое системой:

• Автоматически создается и привязана к определенному ресурсу Azure.
• Жизненный цикл, управляемый Azure (удаляется при удалении ресурса).
• Связь "один к одному" с ресурсом Azure.
• Лучше всего подходит для приложений, развернутых в одном ресурсе Azure.

Управляемое удостоверение, назначаемое пользователем:

• Создан как автономный ресурс Azure.
• Можно назначить нескольким ресурсам Azure.
• Жизненный цикл управляется независимо от связанных ресурсов.
• Лучше всего подходит для приложений, работающих на нескольких ресурсах или требующих общего удостоверения.

Когда следует использовать каждый тип:

• Учетные записи служб: мультиоблачные развертывания, конвейеры непрерывной интеграции и непрерывной доставки (CI/CD), приложения за пределами Azure.
• Назначаемые системой управляемые удостоверения: приложения с одним ресурсом Azure (Azure Functions, Azure App Service).
• Назначаемые пользователем управляемые идентификации: приложения с несколькими ресурсами, сценарии совместного использования идентификаций.

Руководство по реализации

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

Шаг 1: Создайте свою личность

Выберите соответствующий тип удостоверения в зависимости от сценария развертывания.

Вариант A: Создание учетной записи службы (регистрация приложения)

Субъекты-службы хорошо работают для конвейеров CI/CD, сценариев между облаками и приложений, которым требуются гибкие варианты развертывания.

1. Зарегистрируйте приложение в центре администрирования Microsoft Entra.

2. Перейдите к App registrations>Новая регистрация.

3. Настройте приложение:

   • Имя: используйте описательное имя приложения.
   • Типы учетных записей: выберите соответствующую поддержку клиента.
   • URI перенаправления: Оставьте пустым для сценариев взаимодействия служб.

4. Создайте учетные данные проверки подлинности:

   • Рекомендуется отправить сертификат для повышения безопасности.
   • Альтернатива: Создание секрета клиента (требуется регулярная ротация).

Дополнительные сведения см. в следующих статьях:

• Объекты приложения и сервисного принципала в Microsoft Entra ID
• Создать учетную запись службы

Вариант B: Создание управляемого удостоверения

Управляемые удостоверения предоставляют самый простой опыт аутентификации для приложений, размещенных в Azure.

Для управляемого удостоверения, назначаемого системой:

1. Перейдите к ресурсу Azure, например Службе приложений или приложению Azure Functions.
2. Перейдите к Идентификации>Системное назначение.
3. Переключите состояние на Вкл.
4. Нажмите кнопку "Сохранить", чтобы сохранить конфигурацию.

Для назначаемого пользователем управляемого удостоверения:

1. Создайте управляемое удостоверение в портале Azure.
2. Перейдите к Создать ресурс>Управляемое удостоверение.
3. Настройте базовые параметры и создайте ресурс.
4. При необходимости назначьте ресурсы.

Дополнительные сведения см. в следующих статьях:

• Обзор управляемых идентификаторов
• Управление назначаемыми пользователем управляемыми идентичностями

Шаг 2. Добавление идентификации в Azure DevOps

После создания идентификатора в Microsoft Entra ID добавьте его в организацию Azure DevOps, чтобы предоставить доступ к ресурсам.

Предпосылки

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

Добавление идентификатора

Чтобы добавить удостоверение на портале Azure DevOps, выполните следующие действия.

1. Перейдите в Настройки организации>Пользователи.

2. Выберите "Добавить пользователей".

3. Введите отображаемое имя вашего сервисного принципала или управляемой идентичности.

4. Выберите соответствующий уровень доступа и доступ к проекту.

5. Отправьте приглашение.

   

Добавьте идентификатор программно.

Используйте REST API ServicePrincipalEntitlements для автоматизации процесса.

Другие соображения.

• Найдите правильный ID: Используйте идентификатор объекта учетной записи службы на панели Корпоративные приложения в центре администрирования Microsoft Entra, а не идентификатор объекта регистрации приложения.
• Тенантные ограничения: Вы можете добавлять удостоверения только из того же клиента, к которому подключена ваша организация Azure DevOps. Сведения о сценариях с несколькими клиентами см. в разделе Обходное решение - часто задаваемые вопросы.

Шаг 3. Настройка разрешений

Настройте детализированные разрешения для субъекта-службы или управляемого удостоверения в Azure DevOps. В отличие от других служб Azure, Azure DevOps использует собственную модель разрешений вместо разрешений приложений Microsoft Entra.

Параметры разрешений:

• Прямое назначение: предоставление разрешений непосредственно учетной записи.
• Членство в группе: Добавление в группы безопасности Azure DevOps или Microsoft Entra.
• уровни Access: назначьте соответствующий уровень лицензии (базовый, базовый и тестовый план или подписчик Visual Studio).

Рекомендации:

• Примените минимальные привилегии: предоставьте только необходимые минимальные разрешения.
• Использование групп. Управление разрешениями с помощью групп для упрощения обслуживания.
• Регулярные проверки: периодические разрешения аудита.

Параметры управления разрешениями:

• Azure DevOps портал: выберите параметры Организации>Разрешения.
• REST API: используйте API Графа субъекта-службы для программного управления.

Шаг 4: Получение токенов Microsoft Entra ID

Получите маркеры доступа для проверки подлинности приложений с помощью Azure DevOps API и служб.

Для субъектов-служб

Используйте поток учетных данных клиента:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://app.vssps.visualstudio.com/.default
&client_secret={client-secret}
&grant_type=client_credentials

Используйте проверку подлинности сертификата (рекомендуется):

using Microsoft.Identity.Client;

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithCertificate(certificate)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

var result = await app
    .AcquireTokenForClient(new[] { "https://app.vssps.visualstudio.com/.default" })
    .ExecuteAsync();

string accessToken = result.AccessToken;

Для управляемых удостоверений

Из Azure ресурсов:

using Azure.Identity;
using Azure.Core;

var credential = new ManagedIdentityCredential();
var tokenRequest = new TokenRequestContext(new[] { "https://app.vssps.visualstudio.com/.default" });
var token = await credential.GetTokenAsync(tokenRequest);

string accessToken = token.Token;

Используйте службу метаданных экземпляра Azure:

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-0801&resource=https://app.vssps.visualstudio.com/
Metadata: true

Azure CLI для нерегламентированных операций

Для одноразовых операций или тестирования используйте Azure CLI:

# For service principal
az login --service-principal --username {client-id} --password {client-secret} --tenant {tenant-id}
az account get-access-token --scope https://app.vssps.visualstudio.com/.default

# For managed identity (from Azure resource)
az login --identity
az account get-access-token --scope https://app.vssps.visualstudio.com/.default

Для получения дополнительной информации см. раздел Получение токенов Microsoft Entra.

Шаг 5. Использование маркеров с Azure DevOps

Используйте полученные маркеры для проверки подлинности вызовов REST API и других операций Azure DevOps.

Выполните вызовы API, прошедшие проверку подлинности:

using System.Net.Http;
using System.Net.Http.Headers;

var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = 
    new AuthenticationHeaderValue("Bearer", accessToken);

var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.2");

Примеры видео

Распространенные сценарии интеграции

• Источники NuGet: подключайтесь с помощью NuGet.exe или dotnet CLI.
• Публикация Marketplace: публикация расширений с помощью командной строки.
• Azure Pipelines: создание служебных подключений, поддерживаемых управляемыми идентификациями.
• Операции Git: клонирование репозиториев с помощью диспетчера учетных данных Git.

Полные примеры кода см. в примерах приложений.

Рекомендации по управлению

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

Лицензирование

• Для каждого удостоверения требуется лицензия в каждой организации, к которой оно присоединяется.
• Выставление счетов в нескольких организациях не применяется к субъектам-службам.
• Правила лицензирования на основе групп не применяются автоматически. Необходимо назначить лицензии напрямую.

Управление идентичностью

• Адреса электронной почты не используются, поэтому приглашения по электронной почте отсутствуют.
• Отображаемые имена или аватары не изменяются в Azure DevOps.
• Отображаемые имена наследуются от Microsoft Entra ID.

Членство в группах

• Можно добавить в группы Microsoft Entra и группы Azure DevOps.
• Имеет техническое ограничение, которое предотвращает отображение в списках членов группы Microsoft Entra (только ограничение пользовательского интерфейса).
• Может по-прежнему наследовать разрешения от групп Microsoft Entra, к которым принадлежат пользователи.

Материализация

• Необходимо явно добавлять в организацию (в отличие от автоматического создания в случае пользователей).
• Требуется, так как служебные учётные записи не могут войти в систему интерактивно.

Основные отличия от учетных записей пользователей

Служебные субъекты и управляемые идентификаторы имеют конкретные ограничения по сравнению с обычными пользователями.

Capabilities

• ✅ Генерация токенов Microsoft Entra для доступа к API.
• ✅ Осуществляйте доступ к ресурсам Azure DevOps с соответствующими разрешениями.
• ✅ Присоединяйтесь к группам безопасности и командам.
• ❌ Создание персональных токенов доступа или SSH-ключей.
• ❌ Войдите в интерактивном режиме или получите доступ через веб-интерфейс.
• ❌ Создание или владение организациями.
• ❌ Поддержка OAuth-потоков в Azure DevOps.

Выставление счетов

• Считается отдельной лицензией в каждой организации. (Скидки на несколько организаций нет.)
• Необходимо назначить уровень доступа напрямую. (Правила группы не применяются автоматически.)

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

Q. Почему стоит использовать сервисный принципал или управляемую идентификацию вместо патентного токена доступа (PAT)?

А. Субъекты-службы и управляемые удостоверения обеспечивают значительные преимущества безопасности по сравнению с личными токенами доступа (PAT).

Преимущества безопасности:

• Более короткий срок жизни: срок действия токенов Microsoft Entra истекает каждый час, по сравнению с личными токенами доступа (PAT), которые могут оставаться действительными до года.
• Автоматическая смена: управляемые удостоверения автоматически обновляют учетные данные.
• Нет общих секретов: риск хранения или случайного раскрытия долгосрочных токенов устраняется.
• Централизованное управление: осуществляется через Microsoft Entra ID с корпоративными политиками безопасности.

Операционные преимущества:

• Журнал аудита: полностью фиксирует события аутентификации и доступа.
• Условный доступ: применяет политики на основе расположения, устройства и факторов риска.
• Нет учетных записей служб. Устраняет зависимость от отдельных учетных записей пользователей для автоматизации.

Примеры миграции см. в разделе Замена персональных токенов доступа (PAT) на токены Microsoft Entra.

Q. Каковы лимиты скорости для служебных принципалов и управляемых удостоверений?

А. Субъекты-службы и управляемые удостоверения имеют те же пределы скорости, что и пользователи.

Q. Будет ли использовать эту функцию дороже?

А. Учетные записи службы и управляемые идентичности оцениваются как пользователи на основе уровня доступа. Основные различия:

• Нет скидки на выставление счетов в нескольких организациях: каждое удостоверение считается отдельной лицензией в каждой организации.
• Назначение лицензий. Уровни доступа должны быть назначены напрямую. (Правила группы не применяются автоматически.)
• Те же ценовые категории: Базовый, Базовый + тестовые планы и тарифы подписчиков Visual Studio применяются.

Q. Можно ли добавить управляемое удостоверение из другого арендатора в мою организацию?

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

Чтобы настроить управляемое удостоверение между клиентами, выполните приведенные действия.

1. Создайте управляемое удостоверение, назначаемое пользователем, в клиенте ресурсов.
2. Назначьте его ресурсу Azure, например виртуальной машине или приложению Функций).
3. Создайте хранилище ключей и создайте сертификат (формат, отличный от PEM).
4. Предоставьте управляемому удостоверению доступ к хранилищу ключей с разрешениями Чтение и Список секретов.
5. Скачайте сертификат в формате CER (только открытый ключ).
6. Зарегистрируйте приложение в целевом клиенте.
7. Загрузите сертификат на регистрацию приложения.
8. Добавьте субъект-службу в организацию Azure DevOps.
9. Настройте проверку подлинности с помощью сертификата из хранилища ключей.

// Example: Acquire token using managed identity certificate
public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
    var keyVaultUri = new Uri($"https://{keyVaultName}.vault.azure.net");
    var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
    var keyVaultSecret = await client.GetSecretAsync(secretName);
    return keyVaultSecret.Value.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(
    string applicationClientID, string appTenantId)
{
    byte[] privateKeyBytes = Convert.FromBase64String(await GetSecret(keyVaultName, secretName));
    var certificate = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

    var app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
        .WithCertificate(certificate)
        .WithAuthority(new Uri($"https://login.microsoftonline.com/{appTenantId}"))
        .Build();

    var result = await app.AcquireTokenForClient(
        new[] { "499b84ac-1321-427f-aa17-267ca6975798/.default" })
        .ExecuteAsync();

    return result;
}

Распространенные ошибки и способы их устранения

Репозиторий Git с именем или идентификатором не существует или у вас нет разрешений

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

Не удалось создать субъект-службу с идентификатором объекта

Решение: Убедитесь, что вы используете идентификатор объекта служебного принципала из раздела корпоративных приложений, а не идентификатор объекта регистрации приложения.

Чтобы найти правильный идентификатор, выполните следующие действия.

1. Перейдите в центр администрирования Microsoft Entra>Enterprise applications.
2. Найдите имя приложения.
3. Используйте идентификатор объекта на панели корпоративных приложений .

Доступ запрещен: требуются разрешения для добавления пользователей

Возможные причины и решения:

• Недостаточный уровень доступа: должен быть администратором коллекции проектов (PCA) или администратором проекта или команды с включенными разрешениями на приглашение.
• Ограничение политики: Проверьте, включена ли политика «Разрешить администраторам команды и проектов приглашать новых пользователей».
• Назначение лицензий: администраторы проектов не могут назначать лицензии во время приглашения. Обратитесь к PCA за изменениями лицензий.

API списка графов Azure DevOps возвращает пустой список

Решение: Используйте continuationToken для итерации по всем страницам. Субъекты-службы могут отображаться на последующих страницах из-за особенностей разбиения на страницы в API.

TF401444: ошибка: требуется вход

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

Использование ИИ для настройки принципала службы и управляемого удостоверения

Если у вас Azure DevOps MCP Server подключен к вашему ИИ в агентном режиме, вы можете использовать запросы на естественном языке для настройки и устранения неполадок аутентификации сервисного принципала и управляемого удостоверения.

Связанный контент

• Примеры приложений и примеров кода
• Справочник по API предоставления прав для служебных субъектов
• Справочник по Service Principal Graph API
• параметры проверки подлинности Microsoft Entra
• Руководство по аутентификации для Azure DevOps