Защита Функций Azure с помощью Центров событий
При настройке доступа к ресурсам в Azure необходимо применять точный контроль над разрешениями к ресурсам. Доступ к этим ресурсам должен быть основан на необходимости знать и принципы безопасности с наименьшими привилегиями , чтобы убедиться, что клиенты могут выполнять только ограниченный набор действий, предоставленных им.
Авторизация доступа к центрам событий
Авторизация доступа к ресурсам Центры событий Azure можно сделать с помощью следующих конструкций безопасности:
Идентификатор Microsoft Entra: Идентификатор Microsoft Entra предоставляет управление доступом на основе ролей (RBAC) для детального управления доступом клиента к ресурсам Центров событий. В зависимости от ролей и разрешений, идентификатор Microsoft Entra будет авторизовать запросы с помощью маркера доступа OAuth 2.0.
Подписанный URL-адрес: подписанный URL-адрес (SAS) обеспечивает возможность защиты ресурсов Центров событий на основе правил авторизации. Политики авторизации определяются путем выбора одного или нескольких правил политики, таких как возможность отправлять сообщения, прослушивать сообщения и управлять сущностями в пространстве имен.
Рекомендации по подписанным URL-адресам
При использовании подписанного URL-адреса с Функции Azure и Центрами событий следует рассмотреть следующие рекомендации.
Избегайте права управления. Помимо возможности управления сущностями в пространстве имен Центров событий, право "Управление" включает как права отправки, так и прослушивания. В идеале приложение-функция должно быть предоставлено только сочетание прав отправки и прослушивания на основе выполняемых действий.
Не используйте правило управления по умолчанию: не используйте правило политики по умолчанию с именем RootManageSharedAccessKey , если оно не требуется приложению-функции, что должно быть необычным сценарием. Еще одна предостережение к этому правилу по умолчанию заключается в том, что она создана на уровне пространства имен и предоставляет разрешения всем базовым центрам событий.
Просмотрите области политики общего доступа: политики общего доступа можно создавать на уровне пространства имен и на каждом концентраторе событий. Рекомендуется создавать детализированные политики доступа, адаптированные для каждого клиента, чтобы ограничить их диапазон и разрешения.
Управляемое удостоверение
Удостоверение Active Directory можно назначить управляемому ресурсу в Azure, например приложению-функции или веб-приложению. После назначения удостоверения у него есть возможности для работы с другими ресурсами, которые используют идентификатор Microsoft Entra для авторизации, как и субъект-служба.
Приложения-функции можно назначить управляемое удостоверение и воспользоваться преимуществами подключений на основе удостоверений для подмножества служб, включая Центры событий. Подключения на основе удостоверений обеспечивают поддержку расширений триггера и выходных привязок и должны использовать расширение Центров событий 5.x и выше для поддержки.
Network
По умолчанию пространства имен Центров событий доступны из Интернета, пока запрос поставляется с допустимой проверкой подлинности и авторизацией. Существует три варианта ограничения сетевого доступа к пространствам имен Центров событий:
- Разрешить доступ с определенных IP-адресов
- Разрешить доступ из определенных виртуальных сетей (конечные точки службы)
- Разрешить доступ через частные конечные точки
Во всех случаях важно отметить, что указывается хотя бы одно правило брандмауэра IP-адресов или правило виртуальной сети для пространства имен. В противном случае, если ip-адрес или правило виртуальной сети не указано, пространство имен доступно через общедоступный Интернет (с помощью ключа доступа).
Функции Azure можно настроить для использования событий из концентраторов событий или публикации событий, настроенных с помощью конечных точек службы или частных конечных точек. Интеграция региональной виртуальной сети необходима для подключения приложения-функции к концентратору событий с помощью конечной точки службы или частной конечной точки.
При интеграции Функций с виртуальной сетью и включении vnetRouteAllEnabled
весь исходящий трафик из приложения-функции принудительно выполняется через виртуальную сеть. Это особенно важно для сценариев, когда вы хотите защитить приложение-функцию, обеспечивая весь трафик, включая трафик в службы Azure, проходит через виртуальную сеть для проверки и контроля. Если вы хотите полностью заблокировать приложение-функцию, необходимо также ограничить учетную запись хранения.
Чтобы активировать (использовать) события в среде виртуальной сети, приложение-функция должна размещаться в плане Premium, выделенном (Служба приложений) плане или Среда службы приложений (ASE).
Кроме того, выполнение в плане Функции Azure Premium и использование событий из концентратора событий с ограниченным доступом к виртуальной сети требует поддержки триггера виртуальной сети, также называемого мониторингом масштабирования среды выполнения. Мониторинг масштабирования среды выполнения можно настроить с помощью портал Azure, Azure CLI или других решений развертывания. Мониторинг масштабирования среды выполнения недоступен, если функция выполняется в плане выделенного (Служба приложений) или ASE.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Дэвид Баркол | Главный специалист по решению GBB
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Прежде чем продолжить, ознакомьтесь со следующими статьями:
- Авторизация доступа с помощью идентификатора Microsoft Entra
- Авторизация доступа с помощью подписанного URL-адреса в Центры событий Azure
- Настройка ресурса на основе удостоверений
Связанные материалы
Обработка бессерверных событий представляет собой эталонную архитектуру, деталисируя типичную архитектуру этого типа, с примерами кода и обсуждением важных аспектов.