В настоящее время мы пытаемся создать решение, которое обрабатывает конфиденциальные данные в Azure с помощью приложений-функций (v2), скомпилированных на C#. Поскольку среда службы приложений была бы слишком дорогой для решения, которое нам нужно, мы попытались защитить связь между нашей функцией и очередью и таблицей хранилища BLOB-объектов общего назначения (v1), сначала используя интеграцию vnet, а затем ограничения IP. К сожалению, попытка ограничить доступ к хранилищу BLOB-объектов из функции по IP-адресу не работает — кажется, что всегда происходит сбой с «Запрещено», когда мы пытаемся подключиться, даже если полный список внешних IP-адресов функции добавлен к разрешенным IP-адресам хранилища BLOB-объектов. список. И хранилище BLOB-объектов не позволит добавить внутренний IP-адрес функции (LOCAL_ADDR в Kudu) в список «разрешенных IP-адресов», поскольку это внутренний IP-адрес, и даже добавление IP-адресов всего региона Azure в хранилище BLOB-объектов по-прежнему не кажется, позволяют функции для подключения. Единственное, что работает, — это полностью отключить ограничения IP, что ставит все решение в шаткое положение с точки зрения безопасности (например, GDPR).
Кому-нибудь удалось найти решение этой проблемы? Возможно ли это на самом деле, и есть ли идеи, где мы могли бы пойти не так, если бы это было так?


Самое близкое возможное решение, которое я нашел, — это подключить приложение «Функции» к виртуальной сети, затем подключить свою учетную запись хранения к той же виртуальной сети, после чего вы сможете настроить ограничения на основе этой виртуальной сети. Хранилище не поддерживает и не поддерживает безопасность исключений конкретно для Функций, поскольку поиск в разделе «Разрешить доверенные службы Azure» не включает продукты Функций.
Я бы рекомендовал проверить вторую часть этот документ, чтобы помочь настроить приложение «Функции» для виртуальной сети, затем Вот этот, чтобы настроить учетную запись хранения с той же виртуальной сетью, а затем добавить ограничения в брандмауэре хранилища.