Ограничить доступ BLOB-объектов Azure к WebApp

Question

Положение: У нас есть веб-приложение на Azure и хранилище больших двоичных объектов. Через наше веб-приложение мы записываем данные в большой двоичный объект и в настоящее время читаем эти данные обратно, возвращая их в виде ответов в веб-приложении.

Что мы пытаемся сделать: Попытка найти способ ограничить доступ к BLOB-объекту, чтобы только наше веб-приложение могло получить к нему доступ. В настоящее время настройка IP-адреса в настройках брандмауэра работает нормально, если у нас есть статический IP-адрес (мы часто тестируем локальный запуск веб-приложения из нашего офиса, и это позволяет нам нормально читать и записывать в большой двоичный объект). Однако, когда мы используем IP-адрес нашего веб-приложения (считанный со страницы междоменного веб-приложения), мы не получаем такой же доступ и получаем ошибки при попытке чтения / записи в BLOB-объект.

Вопрос: Есть ли способ ограничить доступ к BLOB-объекту веб-приложением, не настраивая VPN на Azure (слишком дорого)? Я видел, как люди говорили об использовании SAS для создания валидных по времени ссылок на контент BLOB-объектов, и это имеет смысл только для того, чтобы пользователи имели доступ к контенту через наше веб-приложение (которое затем предоставило бы им ссылку), но это не решает проблему. проблема в том, что наше веб-приложение не может писать в большой двоичный объект, когда он недоступен для общественности.

Мы просто пытаемся не использовать капли? или это правильный способ их использования, но вы должны сделать это с помощью подхода VPN?

Answer 1

Другой вариант - использовать аутентификацию Azure AD в сочетании с управляемой идентификацией в службе приложений. На момент написания этой функции все еще находится в предварительном просмотре.

Я написал статью о том, как это сделать: https://joonasw.net/view/azure-ad-authentication-with-azure-storage-and-managed-service-identity.

Ключевые части:

• Включить управляемую идентификацию
• Добавьте сгенерированному субъекту службы необходимую роль в контейнере учетной записи / BLOB-контейнера
• Измените код, чтобы использовать токены доступа AAD, полученные с помощью управляемого удостоверения, вместо ключа доступа / токена SAS

Получение токена с помощью https://www.nuget.org/packages/Microsoft.Azure.Services.AppAuthentication/1.1.0-preview:

private async Task<string> GetAccessTokenAsync()
{
    var tokenProvider = new AzureServiceTokenProvider();
    return await tokenProvider.GetAccessTokenAsync("https://storage.azure.com/");
}

Чтение BLOB-объекта с помощью токена:

private async Task<Stream> GetBlobWithSdk(string accessToken)
{
    var tokenCredential = new TokenCredential(accessToken);
    var storageCredentials = new StorageCredentials(tokenCredential);
    // Define the blob to read
    var blob = new CloudBlockBlob(new Uri($"https://{StorageAccountName}.blob.core.windows.net/{ContainerName}/{FileName}"), storageCredentials);
    // Open a data stream to the blob
    return await blob.OpenReadAsync();
}

Answer 2

Ключи SAS - это правильный способ защиты и предоставления доступа к хранилищу BLOB-объектов. Вопреки вашему убеждению, это будет работать с частным контейнером. Вот ресурс, который вы можете найти полезным:

http://www.siddharthpandey.net/use-shared-access-signature-to-share-private-blob-in-azure/

Ознакомьтесь также с рекомендациями Microsoft по обеспечению безопасности хранилища BLOB-объектов. Это решает многие из перечисленных проблем и является обязательным для прочтения для любого разработчика Azure PaaS.

https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide