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

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

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

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

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

• Когда разработчик выполняет приложение во время локальной разработки: приложение проходит проверку подлинности в Azure с помощью субъекта-службы приложений для локальной разработки или учетных данных разработчика Azure. Эти параметры рассматриваются в разделе Аутентификация во время локальной разработки.
• Когда приложение размещено в Azure: приложение проходит проверку подлинности в ресурсах Azure с помощью управляемого удостоверения. Этот параметр рассматривается в разделе Аутентификации в серверных средах.
• Если приложение размещено и развернуто локально: приложение проходит проверку подлинности в ресурсах Azure с помощью служебной учетной записи приложения. Этот параметр рассматривается в разделе Аутентификации в серверных средах.

DefaultAzureCredential (учетные данные Azure по умолчанию)

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

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

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

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

Используйте проверку подлинности на основе маркеров вместо использования строк подключения при создании приложений для Azure. Аутентификация на основе токенов обеспечивает следующие преимущества по сравнению с аутентификацией с использованием строк подключения:

• Методы проверки подлинности на основе маркеров, описанные в этой статье, позволяют устанавливать определенные разрешения, необходимые приложению в ресурсе Azure. Эта практика следует принципу наименьшего привилегирования. В отличие от этого, строка подключения предоставляет полные права ресурсу Azure.
• Любой пользователь или любое приложение, имеющее строку подключения, может подключаться к ресурсу Azure. Однако методы аутентификации на основе маркеров ограничивают доступ к ресурсу только для тех приложений, которые предназначены для доступа к этому ресурсу.
• С управляемым удостоверением не требуется хранить секрет приложения. Приложение является более безопасным, так как нет строки подключения или секрета приложения, которые могут быть скомпрометированы.
• Пакет azure-identity получает токены Microsoft Entra и управляет ими, упрощая использование аутентификации на основе токенов так же просто, как строка подключения.

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

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

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

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

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

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

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

Чтобы использовать DefaultAzureCredential в приложении C++, добавьте пакет azure-identity-cpp в приложение с помощью vcpkg.

vcpkg add port azure-identity-cpp

Затем добавьте следующее в файл CMake:

find_package(azure-identity-cpp CONFIG REQUIRED)
target_link_libraries(<your project name> PRIVATE Azure::azure-identity)

Доступ к службам Azure осуществляется с помощью специализированных клиентских классов из различных клиентских библиотек Azure SDK. В следующем примере кода показано, как создать экземпляр DefaultAzureCredential объекта и использовать его с клиентским классом Azure SDK. В этом случае это объект, используемый SecretClient для доступа к секретам Azure KeyVault.

#include <azure/identity.hpp>
#include <azure/keyvault/secrets.hpp>

int main(){
  
  auto const keyVaultUrl = std::getenv("AZURE_KEYVAULT_URL");
  auto credential = std::make_shared<Azure::Identity::DefaultAzureCredential>();

  
  Azure::Security::KeyVault::Secrets::SecretClient secretClient(keyVaultUrl, credential);
}

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

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

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

• Клиентская библиотека идентификации Azure для C++ README на GitHub