Microsoft AZ-204: Аутентификация, авторизация и безопасность Azure — Руководство по подготовке

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Часть Microsoft Azure Developer Associate AZ-204 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Аутентификация и авторизация в Azure основаны на платформе Microsoft Identity Platform, которая выдает токены удостоверениям (пользователям, приложениям, рабочим нагрузкам) и контролирует доступ к API и ресурсам. Приложения интегрируются через OAuth 2.0 и OpenID Connect, получают токены с помощью MSAL и запрашивают разрешения, объявленные в регистрациях приложений Azure AD. Рабочие нагрузки, выполняемые в Azure, могут полностью отказаться от учетных данных, используя управляемые удостоверения, и полагаться на Azure RBAC для доступа к таким службам, как Key Vault, Storage и Microsoft Graph. Управление секретами сосредоточено в Azure Key Vault, с четким разделением между доступом к данным хранилища (data plane) и контролем на уровне управления (management plane), а также с надежными гарантиями восстановления благодаря обратимому удалению и защите от очистки. Для хранилища подписи общего доступа (SAS) обеспечивают делегирование клиентам ограниченного по области и времени доступа без раскрытия ключей учетной записи.

Платформа Microsoft Identity Platform, OAuth 2.0, MSAL и регистрации приложений

Платформа Microsoft Identity Platform поддерживает несколько потоков OAuth 2.0, оптимизированных для различных типов приложений:

• Поток кода авторизации (Authorization code flow): Стандарт для веб-приложений, одностраничных приложений (SPA) и нативных приложений. Публичные клиенты должны использовать PKCE для защиты кода авторизации. Приложения перенаправляют пользователей на конечную точку авторизации, получают код авторизации на URI перенаправления, а затем обменивают его на конечной точке токенов на токен доступа (и, опционально, на токен обновления). Для SPA поток кода авторизации + PKCE заменяет устаревший неявный поток и снижает риск утечки токенов.
• Поток учетных данных клиента (Client credentials flow): Используется демонами и межсервисными службами без участия пользователя. Приложение запрашивает токены, используя утверждение клиента (сертификат) или секрет клиента. Здесь доступны только разрешения приложения (роли приложения), и большинство из них требуют согласия администратора. Этот поток использует scope /.default для запроса набора статически настроенных разрешений приложения.
• Поток кода устройства (Device code flow): Предназначен для устройств или сред без встроенного браузера. Приложение получает код пользователя и URL для верификации от платформы идентификации, пользователь аутентифицируется на другом устройстве, а приложение опрашивает конечную точку токенов. Применяются делегированные разрешения, так как пользователь выполняет вход.
• Поток неявного предоставления (Implicit grant flow): Исторически использовался SPA для получения токенов непосредственно с конечной точки авторизации. Сейчас его использование не рекомендуется в пользу потока кода авторизации с PKCE. Если он все же используется, при регистрации приложения по-прежнему требуется URI перенаправления.

MSAL (Microsoft Authentication Library) обеспечивает единообразное получение токенов на разных языках и платформах. Публичные клиентские приложения (десктопные, мобильные, SPA) используют AcquireTokenInteractive и AcquireTokenSilent для получения и кэширования токенов; нативные приложения также будут использовать AcquireTokenByDeviceCode для потока кода устройства и AcquireTokenByAuthorizationCode для обмена кода авторизации в контексте конфиденциальных клиентов. Конфиденциальные клиенты (веб-приложения/API/демоны) получают токены с помощью AcquireTokenForClient при использовании учетных данных клиента и AcquireTokenOnBehalfOf для сценариев OBO, когда API вызывает нижестоящие API с делегированным контекстом пользователя.

Кэширование токенов — неотъемлемая часть MSAL: библиотека хранит токены доступа и обновления, индексируя их по учетной записи, клиенту и области (scope), что позволяет AcquireTokenSilent избегать ненужных интерактивных запросов. Веб-приложения и API, работающие в нескольких экземплярах, должны сохранять и защищать кэш токенов, используя общее зашифрованное хранилище (например, распределенный кэш с надлежащим шифрованием при хранении и передаче). Хуки сериализации кэша в MSAL обеспечивают безопасное сохранение. Области (scopes) определяют разрешения, которые запрашивает приложение. Для делегированных разрешений запрашивайте минимальные, специфичные для ресурса области (например, https://graph.microsoft.com/User.Read). Для учетных данных клиента запрашивайте /.default на основе ресурса, что соответствует статически предоставленным приложению разрешениям (например, scope = https://graph.microsoft.com/.default). Используйте инкрементное согласие, чтобы запрашивать области постепенно и упростить взаимодействие с пользователем.

Регистрации приложений в Azure AD определяют удостоверение приложения, учетные данные, URI перенаправления и разрешения. Делегированные разрешения требуют вошедшего в систему пользователя и часто могут быть одобрены самими пользователями для доступа к их данным; разрешения приложения предоставляются самому приложению и почти всегда требуют согласия администратора, поскольку они применяются ко всему тенанту или имеют широкий охват. Приложения, предоставляющие API, объявляют области (scopes) (для делегированных разрешений) и роли приложения (app roles) (для разрешений приложения) в разделе “Expose an API”. Настройте однотенантный или мультитенантный доступ в зависимости от границ доверия и используйте сертификаты вместо секретов клиента для более надежных учетных данных и упрощенной ротации.

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

• GET https://graph.microsoft.com/v1.0/me для получения профиля пользователя с делегированными токенами (например, User.Read)
• GET https://graph.microsoft.com/v1.0/users и /groups для объектов каталога (требуются соответствующие делегированные разрешения или разрешения приложения, такие как User.Read.All или Group.Read.All)
• GET https://graph.microsoft.com/v1.0/sites или /drives для операций с SharePoint/OneDrive При использовании учетных данных клиента запрашивайте scope /.default и убедитесь, что для требуемых разрешений приложения имеется согласие администратора. Выбирайте правильный центр (authority) (специфичный для тенанта по сравнению с common/organizations), чтобы контролировать, где пользователи могут входить в систему и где могут выпускаться токены.

Управляемые удостоверения и безопасный доступ к ресурсам Azure, а также ссылки на Key Vault

Управляемые удостоверения для ресурсов Azure устраняют необходимость в секретах, позволяя Azure управлять учетными данными субъекта-службы. Управляемые удостоверения, назначаемые системой, привязаны к ресурсу (App Service, Function App, VM, VMSS, Logic App и т. д.) в соотношении 1:1 и разделяют его жизненный цикл; при удалении ресурса удаляется и удостоверение. Управляемые удостоверения, назначаемые пользователем, создаются как самостоятельные ресурсы Azure, которые можно привязать к нескольким вычислительным ресурсам, и существуют независимо от жизненного цикла какой-либо одной рабочей нагрузки. Эта модель поддерживает повторное использование удостоверений и разделение обязанностей.

Чтобы получить доступ к ресурсам Azure с помощью управляемого удостоверения, предоставьте ему соответствующую роль Azure RBAC в правильной области действия:

• Для плоскости данных Azure Storage с Azure AD назначьте роли, такие как Storage Blob Data Reader/Contributor, в области действия учетной записи хранения, контейнера или группы ресурсов/подписки.
• Для Key Vault (модель плоскости данных RBAC) назначьте роли, такие как Key Vault Secrets User или Key Vault Crypto Officer.
• Для Microsoft Graph через разрешения приложения управляемые удостоверения могут вызывать нижестоящие API только после связывания с регистрацией приложения. Используйте федерацию удостоверений рабочей нагрузки или настройте разрешения корпоративного приложения и согласие администратора по мере необходимости.

Во время выполнения используйте службу метаданных экземпляра (IMDS) на виртуальных машинах или управляемую конечную точку App Service для получения токенов; SDK, такие как DefaultAzureCredential из Azure Identity, будут автоматически использовать конечную точку управляемого удостоверения, когда она доступна. Это избавляет от необходимости хранить секреты и поддерживает их ротацию платформой.

Ссылки на Key Vault в App Service и Azure Functions позволяют безопасно извлекать секреты в параметры приложения без изменения кода. В значении параметра приложения используйте синтаксис ссылки @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version}). Платформа разрешает ссылку, используя управляемое удостоверение приложения при запуске, и периодически обновляет ее. Убедитесь, что у управляемого удостоверения есть разрешение Get для секретов через политики доступа Key Vault или роль Key Vault Secrets User при использовании модели плоскости данных RBAC. Ссылки на Key Vault идеально подходят для конфигурационных значений, которые никогда не должны храниться в виде открытого текста в хранилище конфигурации приложения, и убирают логику обработки секретов из кода приложения.

Azure Key Vault: Секреты, ключи, сертификаты и контроль доступа

Azure Key Vault хранит три типа объектов:

• Секреты: Непрозрачные строки, такие как пароли, строки подключения или ключи API. Имеют версии; клиенты обычно выполняют операции Get и Set.
• Ключи: Криптографические ключи (RSA, EC), используемые для операций подписи/проверки, шифрования/расшифровки и упаковки/распаковки ключей. Материал ключа защищен службой на базе HSM; клиенты вызывают криптографические операции через службу, а не экспортируют материал закрытого ключа.
• Сертификаты: Объекты X.509 с управлением жизненным циклом, опционально интегрированные с партнерскими центрами сертификации (CA). Сертификаты материализуются как сертификат плюс соответствующий секрет (PFX) и, опционально, управляемый ключ.

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

Контроль доступа может использовать устаревшие политики доступа к хранилищу или Azure RBAC для плоскости данных. Политики доступа настраиваются для каждого хранилища и явно предоставляют разрешения (Get, List, Set, Sign, Wrap) субъектам; они не наследуются и могут стать тяжелыми в эксплуатации при масштабировании. Модель плоскости данных RBAC использует роли Azure (например, Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) и поддерживает определение области действия на уровне подписки, группы ресурсов или хранилища с аудитом, интегрированным в Azure RBAC. Выберите одну модель; если для плоскости данных включен RBAC, политики доступа игнорируются. Операции на плоскости управления (создание/обновление хранилища) всегда используют Azure RBAC.

Интегрируйте Key Vault с приложениями, используя Azure SDK (например, SecretClient, KeyClient, CertificateClient) и DefaultAzureCredential. Предпочитайте управляемые удостоверения для аутентификации, избегайте встраивания учетных данных и реализуйте политики повторных попыток и регулирования при вызове API хранилища.

SAS для Azure Storage и сохраненные политики доступа

Подписи общего доступа (Shared Access Signatures, SAS) делегируют гранулированный, ограниченный по времени доступ к Azure Storage, не раскрывая ключи учетной записи:

• SAS делегирования пользователя (только для Blob): Основан на Azure AD. Приложение получает ключ делегирования пользователя от службы Blob, используя учетные данные Azure AD, а затем создает SAS-токены для клиентов. Это самый безопасный подход для сценариев, ориентированных на пользователя, поскольку он позволяет избежать использования ключей учетной записи и соответствует авторизации на основе ролей.
• SAS службы: Ограничен конкретным ресурсом (blob, контейнер, сообщение в очереди, сущность таблицы, файл). Подписывается ключом учетной записи. Поддерживает разрешения, такие как чтение, запись, добавление, создание, удаление, перечисление, установка неизменяемости и теги, в зависимости от службы.
• SAS учетной записи: Имеет самую широкую область действия, охватывающую несколько служб (Blob, Queue, Table, File) и типов ресурсов. Используйте с осторожностью из-за большого радиуса последствий.

SAS-токены включают ограничения, такие как время истечения срока действия (se), время начала (st), разрешения (sp), диапазоны IP-адресов (sip), разрешенные протоколы (spr), подписываемый ресурс (sr) и, при привязке к сохраненной политике доступа, подписанный идентификатор (si). Следуйте принципу наименьших привилегий, предоставляя только необходимые разрешения, устанавливая короткие сроки действия и требуя использования HTTPS (spr=https). По возможности отдавайте предпочтение SAS делегирования пользователя; в противном случае используйте SAS службы с сохраненной политикой доступа для возможности отзыва.

Сохраненные политики доступа размещаются на контейнерах, файловых ресурсах, очередях или таблицах и определяют многократно используемый набор ограничений (разрешения, время начала, время истечения). При создании SAS ссылайтесь на политику по ее идентификатору. Это позволяет централизованно отзывать или ужесточать область действия без необходимости перевыпускать все SAS-токены; обновление или удаление политики немедленно влияет на все связанные с ней SAS-токены. Регулярно ротируйте ключи учетной записи, если используются SAS службы или учетной записи, и отслеживайте использование через диагностические настройки и журналы Azure Monitor.

Практический сценарий

Компания Adobe развертывает мультитенантный портал для обработки медиафайлов на Azure. Клиенты входят в систему, используя свои собственные тенанты Microsoft Entra ID, загружают большие медиафайлы напрямую в Blob storage и отслеживают статус обработки. Решение должно избегать хранения секретов, централизовать управление разрешениями и обеспечивать возможность восстановления секретов в течение не менее 90 дней.

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

   • Создайте SPA для пользовательского интерфейса портала и конфиденциальный клиент для бэкенд-API. Предоставьте области API для делегированного доступа и определите роли приложений для фоновых заданий. Настройте SPA на использование кода авторизации + PKCE с точными URI перенаправления. Это приводит каждого клиента в соответствие с правильным потоком OAuth и обеспечивает границы согласия на основе принципа наименьших привилегий.

2. Внедрите MSAL в SPA и бэкенд:

   • SPA получает токены для бэкенд-API с помощью AcquireTokenInteractive/AcquireTokenSilent с инкрементным согласием. Бэкенд использует AcquireTokenOnBehalfOf для вызова Microsoft Graph, чтобы прочитать основной профиль вошедшего пользователя. Это сохраняет контекст пользователя сквозь все компоненты системы и минимизирует запросы на авторизацию благодаря кэшированию токенов.

3. Включите управляемые удостоверения, назначаемые системой, для App Service (API) и Azure Functions (обработчики медиа):

   • Назначьте роли Storage Blob Data Contributor для контейнера с медиафайлами и Key Vault Secrets User для хранилища. Управляемые удостоверения устраняют проблему распространения секретов и позволяют платформе автоматически ротировать учетные данные, обеспечивая безопасный доступ к Storage и Key Vault через Azure RBAC.

4. Настройте Azure Key Vault с использованием RBAC на уровне данных, обратимого удаления и защиты от очистки:

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

5. Используйте ссылки на Key Vault для конфигурации:

   • Ссылайтесь на секреты в настройках приложений App Service и Functions, используя @Microsoft.KeyVault(SecretUri=…). Платформа разрешает и обновляет значения с помощью управляемого удостоверения, что исключает необходимость вносить изменения в код и предотвращает хранение секретов в конфигурации в виде открытого текста.

6. Делегируйте прямые загрузки из браузера с помощью SAS:

   • Бэкенд выдает SAS-токены делегирования пользователя для кратковременного доступа только на запись к определенному пути в blob, с ограничением по IP и HTTPS. Для операционных пакетных инструментов создайте SAS службы, привязанный к сохраненной политике доступа на контейнере, чтобы токены можно было централизованно отозвать путем обновления или удаления политики. Это обеспечивает высокопроизводительную загрузку файлов клиентами без раскрытия ключей учетной записи и поддерживает возможность экстренного отзыва.

7. Минимально интегрируйте Microsoft Graph:

   • Запрашивайте https://graph.microsoft.com/User.Read в SPA для отображения профиля и используйте https://graph.microsoft.com/.default в бэкенде, если требуются какие-либо разрешения приложения (с предварительного согласия администратора). Использование /.default гарантирует, что бэкенд будет учитывать централизованно предоставленные разрешения приложения и избежит запроса избыточных областей в среде выполнения.

Эта архитектура использует код авторизации + PKCE для защиты SPA, поток OBO для сохранения контекста пользователя, управляемые удостоверения и RBAC для устранения секретов, Key Vault с надежными гарантиями восстановления, ссылки на Key Vault для гигиены конфигурации, Graph с минимально необходимыми разрешениями и SAS с сохраненными политиками доступа для безопасной и отзываемой загрузки файлов клиентами.

← Контейнерные решения Azure · Все домены · Azure API Management →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →