Хранилище Azure: возможно ли истечь для токена SAS до истечения срока его действия?

#azure #azure-functions #azure-storage #azure-blob-storage

#azure #azure-функции #azure-хранилище #azure-blob-хранилище

Вопрос:

Я создаю токены SAS на сервере по требованию и отправляю их пользователям, чтобы они могли загружать большие двоичные объекты. По умолчанию срок действия каждого токена истекает через час. Я также использую Azure Functions для обработки на стороне сервера.

 var cloudStorageAccount = // create a new CloudStorageAccount
var sharedAccessAccountPolicy = new SharedAccessAccountPolicy
{
    Permissions = SharedAccessAccountPermissions.Read | SharedAccessAccountPermissions.Write,
    Services = SharedAccessAccountServices.Blob,
    ResourceTypes = SharedAccessAccountResourceTypes.Object,
    SharedAccessExpiryTime = DateTime.UtcNow.AddHours(1),
    Protocols = SharedAccessProtocol.HttpsOnly
};

var token = cloudStorageAccount.GetSharedAccessSignature(sharedAccessAccountPolicy);
 

Что я хотел бы сделать, так это истечь токен SAS после его успешного использования один раз, прослушивая изменения больших двоичных объектов через EventGridTrigger . Например, если пользователю потребовалось 10 минут, чтобы загрузить файл, этот токен больше нельзя использовать. Это делается для предотвращения злоупотреблений, поскольку API, который генерирует токены SAS, ограничен по скорости. Если я хочу, чтобы пользователь загружал только один файл в час, мне нужен способ обеспечить это. Кто-то с быстрым подключением к Интернету теоретически может загрузить десятки файлов, если токен истекает через час.

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

Комментарии:

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

Ответ №1:

Я полагаю, что для этого вы можете использовать делегирование пользователей SAS. Делегирование пользователя SAS может быть создано и отозвано программно.

https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas

Отозвать ключ делегирования пользователя

Вы можете отозвать ключ делегирования пользователя, вызвав операцию Отзыв ключей делегирования пользователя. Когда вы отзываете ключ делегирования пользователя, все подписи общего доступа, основанные на этом ключе, становятся недействительными. Затем вы можете снова вызвать операцию получения ключа делегирования пользователя и использовать ключ для создания новых подписей общего доступа. Этот подход является самым быстрым способом отозвать делегирование SAS пользователем.

Ответ №2:

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

Официальное объяснение см. В разделе Отзыв на этой странице: https://docs.microsoft.com/en-us/azure/storage/blobs/security-recommendations#revocation

«Служба SAS, которая не связана с политикой сохраненного доступа, не может быть отозвана».

Кроме того, не существует одноразовых токенов SAS, и, согласно этому запросу обратной связи, Microsoft не планирует внедрять эту функцию: https://feedback.azure.com/forums/217298-storage/suggestions/6070592-one-time-use-sas-tokens

Лучше всего просто сократить время истечения срока действия для вашего варианта использования. Если вам абсолютно необходимо ограничить загрузку для определенного пользователя, тогда вы рассматриваете возможность перехода пользователя через отдельное контролируемое приложение вместо прямого доступа к хранилищу (например, веб-API), которое можно использовать в качестве привратника (проверка предыдущих загрузок и реализация логики ограничения).

Комментарии:

1. Жаль, что за 6 лет не было никакого прогресса в этом запросе. Кстати, я создавал токены на уровне учетной записи. Я изменил реализацию так, чтобы они создавались для каждого большого двоичного объекта. Это должно, по крайней мере, ограничить подверженность риску для одного большого двоичного объекта.