Создание служебного субъекта и ключа

Завершено

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

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

Когда субъект-служба должен взаимодействовать с Azure, он входит в идентификатор Microsoft Entra. После проверки личности представителя службы, Microsoft Entra ID выдает токен , который клиентское приложение хранит и использует при выполнении запросов к Azure.

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

Заметка

Помните, что управляемые удостоверения — это специальные субъекты-службы, работающие в Azure. Они имеют другой тип процесса проверки подлинности, который не требует, чтобы вы знали или обрабатывали учетные данные вообще.

Ключи

Ключи похожи на пароли. Однако ключи гораздо длиннее и сложнее. Фактически, в большинстве случаев Microsoft Entra ID генерирует ключи самостоятельно, чтобы убедиться, что:

• Ключи криптографически случайные. То есть, их очень трудно угадать.
• Люди не случайно используют слабые пароли в качестве ключей.

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

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

Заметка

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

Сертификаты

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

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

Заметка

Сертификаты являются хорошим вариантом, когда их можно использовать. Они сложнее украсть злоумышленникам. Кроме того, труднее перехватывать и изменять запросы, использующие сертификаты. Однако сертификаты требуют больше инфраструктуры и имеют некоторые текущие затраты на обслуживание.

Работа с ключами для служебных субъектов

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

Заметка

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

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

Управление субъектами-службами для Azure Pipelines

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

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

Совет

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

Создание учетной записи службы и ключа

Azure CLI можно использовать для создания субъектов-служб и управления ими.

Заметка

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

Чтобы создать учетную запись службы и ключ, используйте команду az ad sp create-for-rbac. Эта команда принимает несколько аргументов и может при необходимости назначать роли субъекту-службе. Далее вы узнаете об этой теме в этом модуле. Ниже приведен пример создания субъекта-службы без назначений ролей Azure.

az ad sp create-for-rbac --name MyPipeline

При выполнении этой команды Azure CLI возвращает ответ JSON со свойством password. Это свойство является ключом субъекта-службы. Вы не можете снова получить этот ключ, поэтому не забудьте использовать его немедленно или сохранить его где-то безопасно.

Заметка

Команда az ad sp create-for-rbac создает регистрацию приложения в Microsoft Entra ID, добавляет основной объект службы в клиент Microsoft Entra и создает ключ для регистрации приложения. Другая команда, az ad sp create, создает только субъект-службу в клиенте (а не регистрацию приложения). При создании принципалов службы для конвейеров команда az ad sp create-for-rbac обычно является наилучшей.

Командлеты Azure PowerShell можно использовать для создания субъектов-служб и управления ими.

Заметка

Создание и изменение субъектов-служб требует наличия связанных разрешений в идентификаторе Microsoft Entra. В некоторых организациях может потребоваться администратор для выполнения этих действий.

Чтобы создать служебный принципал и ключ, используйте командлет New-AzADServicePrincipal. Этот командлет принимает несколько аргументов и может при необходимости назначать роли основному объекту службы. Далее вы узнаете об этой теме в этом модуле. На данный момент вот пример, иллюстрирующий создание учетной записи службы без присвоения ролей Azure.

$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline

При выполнении этой команды Azure PowerShell заполняет переменную servicePrincipal сведениями о субъекте-службе, включая ключ:

$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText

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

Заметка

Командлет New-AzADServicePrincipal создает регистрацию приложения в Microsoft Entra ID, добавляет основной сервис в учетную запись Microsoft Entra и создает ключ для этой регистрации приложения.

Определение основного сервиса

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

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

Совет

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

Осторожность

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

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

Обработка ключей с истекшим сроком действия

Срок действия субъектов-служб не истекает, но их ключи истекают. При создании ключа можно настроить его срок действия. По умолчанию срок действия равен одному году. После этого срока действия ключ перестаёт быть действительным, и конвейер не может войти в Microsoft Entra ID. Необходимо регулярно обновлять или сменять ключи.

Осторожность

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

Чтобы сбросить ключ для учетной записи служб, используйте команду az ad sp с идентификатором приложения, как в следующем примере:

az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"

Вы также можете удалить ключ сервисного принципала и создать его заново в двух отдельных шагах, используя команду az ad sp credential delete, а затем команду az ad sp credential reset --append.

Чтобы сбросить ключ для субъекта-службы, сначала используйте командлет Remove-AzADServicePrincipalCredential для удаления существующих учетных данных. Затем используйте командлет New-AzADServicePrincipalCredential для добавления новых учетных данных. Эти командлеты используют идентификатор объекта субъекта-службы для его идентификации. Прежде чем использовать командлеты, необходимо получить этот идентификатор из идентификатора приложения.

$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id

Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId

$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText

Совет

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

Управление жизненным циклом субъекта-службы

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

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

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

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

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