Безопасность для служб ИИ Azure
Безопасность должна рассматриваться как главный приоритет в разработке всех приложений, и при росте приложений с поддержкой искусственного интеллекта безопасность еще более важна. В этой статье описаны различные функции безопасности, доступные для служб ИИ Azure. Каждая функция отвечает за определенный аспект, поэтому в одном рабочем процессе можно использовать несколько функций.
Полный список рекомендаций по обеспечению безопасности служб Azure см. в статье о базовой базе безопасности служб ИИ Azure.
Функции безопасности
Возможность | Description |
---|---|
Протокол TLS | Все конечные точки служб ИИ Azure, предоставляемые по протоколу HTTP, применяют протокол TLS 1.2. При применении протокола безопасности потребители, пытающиеся вызвать конечную точку служб искусственного интеллекта Azure, должны соблюдать следующие рекомендации:
|
Параметры аутентификации | Проверка подлинности позволяет подтвердить, что удостоверение принадлежит пользователю. В отличие от этого, в рамках авторизации пользователь предоставляет свои разрешения и права доступа для работы с ресурсами по данному удостоверению. Удостоверение представляет собой коллекцию сведений о субъекте, а субъект может быть отдельным пользователем или службой. По умолчанию вы выполняете проверку подлинности собственных вызовов к службам ИИ Azure с помощью предоставленных ключей подписки; это самый простой метод, но не самый безопасный. Самый безопасный метод проверки подлинности — использовать управляемые роли в идентификаторе Microsoft Entra. Дополнительные сведения об этом и других вариантах проверки подлинности см. в статье "Проверка подлинности запросов к службам ИИ Azure". |
Смена клавиш | Каждый ресурс служб ИИ Azure имеет два ключа API для включения смены секретов. Это мера предосторожности, которая позволяет регулярно изменять ключи, которые могут получить доступ к вашей службе, защищая конфиденциальность вашей службы при утечке ключа. Дополнительные сведения об этом и других параметрах проверки подлинности см. в разделе "Смена ключей". |
Переменные среды | Переменные среды — это пары имя-значение, хранящиеся в определенной среде разработки. Переменные среды являются более безопасными, чем использование жестко закодированных значений в коде. Инструкции по использованию переменных среды в коде см. в руководстве по переменным среды. Однако если среда скомпрометирована, переменные среды также скомпрометируются, поэтому это не самый безопасный подход. Самый безопасный метод проверки подлинности — использовать управляемые роли в идентификаторе Microsoft Entra. Дополнительные сведения об этом и других вариантах проверки подлинности см. в статье "Проверка подлинности запросов к службам ИИ Azure". |
Управляемые клиентом ключи (CMK) | Эта функция предназначена для служб, в которых хранятся неактивные данные клиента (дольше 48 часов). Хотя эти данные уже дважды шифруются на серверах Azure, пользователи могут повысить безопасность, добавив еще один уровень шифрования с помощью ключей, которыми они управляют сами. Вы можете связать свою службу с Azure Key Vault для управления ключами шифрования данных. Проверьте, поддерживается ли CMK службой, которую вы хотите использовать в документации по ключам , управляемым клиентом. |
Виртуальные сети | Виртуальные сети позволяют определить, какие именно конечные точки могут совершать вызовы API к определенному ресурсу. Служба Azure отклоняет вызовы API от устройств за пределами сети. Вы можете задать определение разрешенной сети на основе формул или задать полный список разрешенных конечных точек. Это дополнительный уровень безопасности, который можно использовать в сочетании с другими. |
Защита от потери данных | Функция защиты от потери данных позволяет администратору решить, какие типы URI ресурс Azure может принимать в качестве входных данных (для вызовов API, которые принимают URI в качестве входных данных). Это позволяет предотвратить возможную кражу конфиденциальных данных компании: если компания хранит конфиденциальную информацию (например, частные данные клиента) в параметрах URL-адреса, злоумышленник изнутри компании может отправлять конфиденциальные URL-адреса в службу Azure, которая передает их за пределы компании. Защита от потери данных позволяет настроить службу для отклонения определенных форм URI при их получении. |
Защищенное хранилище | Функция "Защищенное хранилище" предлагает клиентам интерфейс для просмотра и утверждения или отклонения запросов на доступ к данным. Этот интерфейс позволяет специалисту Майкрософт получить доступ к данным клиента в рамках процессов поддержки. Сведения о том, как инициируются, отслеживаются и хранятся запросы на блокировку клиента, а также хранятся для последующих проверок и аудита, см. в руководстве по блокировке клиента. Блокировка клиента доступна для следующих служб:
|
Использование собственного хранилища (BYOS) | Служба "Речь" в настоящее время не поддерживает защищенное хранилище. Однако вы можете организовать хранение ваших данных для определенной службы в вашем собственном ресурсе с использованием вашего собственного хранилища (BYOS). Подход BYOS позволяет управлять данными аналогично защищенному хранилищу. Помните, что данные службы "Речь" хранятся и обрабатываются в регионе Azure, где был создан речевой ресурс. Это относится к любым неактивным данным и передаче данных. При использовании функций персонализации, таких как "Пользовательское распознавание речи" и "Пользовательский голос", все данные клиентов передаются, хранятся и обрабатываются в том же регионе, где находятся ресурс службы "Речь" и ваше хранилище BYOS (если оно используется). Чтобы использовать BYOS с речью, следуйте инструкциям по шифрованию неактивных данных. Корпорация Майкрософт не использует данные клиентов для улучшения моделей распознавания речи. Кроме того, если ведение журнала конечной точки отключено и никакая персонализация не используется, служба "Речь" не сохраняет данные о клиентах. |
Следующие шаги
- Изучите службы ИИ Azure и выберите службу для начала работы.