Методы проверки подлинности, поддерживаемые Azure OpenAI

Azure OpenAI поддерживает несколько методов проверки подлинности, чтобы обеспечить безопасный и контролируемый доступ к своим ресурсам. Основными методами являются:

• Ключи API: Azure OpenAI также поддерживает проверку подлинности на основе ключей API. Ключи API создаются в портал Azure и могут использоваться для проверки подлинности запросов к службе Azure OpenAI. Этот метод проверки подлинности не рекомендуется с точки зрения безопасности и должен использоваться только в качестве последнего способа. Если этот метод проверки подлинности необходимо использовать, важно безопасно обрабатывать ключи API и периодически поворачивать их, чтобы снизить риск несанкционированного доступа.
• Идентификатор Microsoft Entra: этот метод использует надежные возможности управления удостоверениями и доступом Microsoft Entra. Пользователи и приложения проходят проверку подлинности с помощью удостоверений Microsoft Entra, которые могут быть традиционными учетными записями пользователей или управляемыми удостоверениями. Этот метод гарантирует, что только прошедшие проверку подлинности и авторизованные пользователи могут получить доступ к ресурсам Azure OpenAI.
• Записи управляемых удостоверений. Управляемые удостоверения для ресурсов Azure предоставляют автоматическое управляемое удостоверение в Microsoft Entra для приложений, используемых при подключении к ресурсам, поддерживающим проверку подлинности Microsoft Entra. Эти удостоверения можно назначить системой, то есть они привязаны к определенному ресурсу Azure или назначаемому пользователем идентификатору, что позволяет совместно использовать одно удостоверение для нескольких ресурсов. Управляемые удостоверения упрощают управление учетными данными и повышают безопасность, устраняя необходимость жестко закодированных учетных данных в коде приложения.

Почему управляемые удостоверения являются более безопасными, чем ключи API

Управляемые удостоверения в Microsoft Azure предлагают более безопасную альтернативу ключам API по нескольким причинам:

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

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

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

Корпорация Майкрософт рекомендует использовать управляемое удостоверение для ключей API при проверке подлинности в Azure OpenAI или любой другой службе Azure, поддерживающей управляемое удостоверение.

Различия между использованием ключей API и управляемых удостоверений в Azure OpenAI

Давайте рассмотрим влияние утечки идентификатора клиента по сравнению с утечкой ключа API.

Ключ API работает аналогично обычному паролю. Если он скомпрометирован, любой пользователь с ключом может получить доступ к ресурсу. Для Azure OpenAI это означает неограниченное использование моделей искусственного интеллекта, таких как GPT-4. Если сеть общедоступна, влияние безопасности может быть еще больше.

И наоборот, если идентификатор клиента утечка, риски минимальны. Это связано с тем, что идентификатор клиента не может установить подключение к Azure OpenAI. Чтобы использовать управляемое удостоверение, служба должна работать в Azure и даже если Azure OpenAI является общедоступной, вы не можете подключиться из локальной среды или через сеть с помощью приложения.

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

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

Системные и назначенные пользователем удостоверения

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

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

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