Проверка подлинности приложений JavaScript в службах Azure с помощью библиотеки удостоверений Azure

Статья
12/18/2024

Если приложению требуется доступ к ресурсу Azure, например хранилищу, Key Vault или Cognitive Services, приложение должно пройти проверку подлинности в Azure. Это верно для всех приложений, развернутых в Azure, развернутых локально или в процессе разработки на локальной рабочей станции разработчика. В этой статье описаны рекомендуемые подходы к проверке подлинности приложения в Azure при использовании пакета SDK Azure для JavaScript.

Рекомендуемый подход к проверке подлинности приложений

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

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

Окружающая среда	Аутентификация
локальный	При разработке и запуске приложения приложение может проходить проверку подлинности в Azure с помощью служебного принципала приложения для локальной разработки или с использованием учетных данных Azure самого разработчика. Каждый из этих вариантов подробно рассматривается в разделе аутентификации во время локальной разработки.
лазурный	Если приложение размещено в Azure. Приложение должно пройти проверку подлинности в ресурсах Azure с помощью управляемого удостоверения. Этот параметр более подробно описан в разделе "Аутентификация в серверных средах".
локальных	Когда приложение размещено и развернуто локально, оно должно проходить проверку подлинности в ресурсах Azure с помощью учетной записи службы приложения. Этот параметр более подробно описан в разделе аутентификации в серверных средах.

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

Преимущества проверки подлинности на основе токенов

При создании приложений для Azure настоятельно рекомендуется использовать аутентификацию на основе токенов вместо секретных данных (строк подключения или ключей). Аутентификация на основе токенов осуществляется с помощью DefaultAzureCredential.

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

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

Используйте следующую библиотеку:

@azure/identity

DefaultAzureCredential

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

Сведения об использовании DefaultAzureCredential рассматриваются в разделе Use DefaultAzureCredential в приложении.

Проверка подлинности в средах сервера

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

Проверка подлинности во время локальной разработки

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

Использование DefaultAzureCredential в приложении

DefaultAzureCredential — это упорядоченная последовательность механизмов проверки подлинности в идентификаторе Microsoft Entra ID. Каждый механизм проверки подлинности является классом, производным от класса TokenCredential и называется учетной записью. Во время выполнения DefaultAzureCredential пытается пройти проверку подлинности с помощью первых учетных данных. Если учетные данные не удается получить маркер доступа, проверяются следующие учетные данные в последовательности, пока маркер доступа не будет успешно получен. Таким образом, приложение может использовать разные учетные данные в разных средах без написания кода для конкретной среды.

Чтобы использовать DefaultAzureCredential, добавьте пакет @azure/identity в приложение.

npm install @azure/identity

Затем в следующем примере кода показано, как создать экземпляр объекта DefaultAzureCredential и использовать его с клиентским классом службы Azure SDK, в этом случае BlobServiceClient, используемый для доступа к хранилищу BLOB-объектов Azure.

import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config';

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  new DefaultAzureCredential()
);

DefaultAzureCredential автоматически обнаруживает механизм проверки подлинности, настроенный для приложения, и получает необходимые маркеры для проверки подлинности приложения в Azure. Если приложение использует несколько клиентов ПАКЕТА SDK, то один и тот же объект учетных данных можно использовать с каждым клиентским объектом пакета SDK.

Поделиться через