Приватный объект в S3-бакете по умолчанию недоступен по прямой ссылке: любое обращение требует AWS-учётных данных — access key и secret key — с правами на bucket или конкретный объект. Отправить файл кому-то напрямую нельзя, если заранее не открыть к нему публичный доступ, а это риск другого рода.
Presigned URL решает задачу иначе. Это обычная HTTP-ссылка со встроенной криптографической подписью, которая на ограниченное время даёт держателю доступ к конкретному объекту — без передачи самих ключей. Подпись формируется от имени владельца учётных данных заранее, а получатель просто переходит по ссылке или отправляет по ней запрос.
Главное отличие от публичного bucket или открытых ACL: доступ ограничен по времени, по конкретному объекту и по HTTP-методу, а не открыт всем и навсегда.
Счёт, архив, медиафайл, доступный по ссылке ограниченное время.
Presigned PUT-запрос принимает файл напрямую в bucket, без прокладки трафика через backend-сервер.
Presigned URL строится по алгоритму AWS Signature Version 4. В ссылку встраиваются параметры X-Amz-Algorithm, X-Amz-Credential, X-Amz-Date, X-Amz-Expires и X-Amz-Signature — они превращают обычный HTTP-запрос в подписанный и проверяемый.
Срок действия задаётся параметром expiration при генерации и ограничен сверху: при использовании временных учётных данных через SigV4 максимум составляет 7 дней (168 часов). После этого ссылка перестаёт работать независимо от того, использовалась она или нет.
Секретный ключ при этом никогда не покидает среду генерации и не передаётся получателю. Раскрывается только сама подпись, действующая ограниченное время и только для конкретного запроса.
Presigned URL наследует права того пользователя или роли, чьими ключами он подписан. Если у подписавшего нет доступа к объекту, ссылка тоже не сработает: она не создаёт новые права, а передаёт часть уже существующих на ограниченное время.
Собирать подпись SigV4 вручную не нужно: официальные AWS SDK предоставляют готовый метод. В boto3 для Python это generate_presigned_url; аналогичные методы есть в AWS SDK for JS и Java.
Минимальный набор параметров для генерации:
Presigned URL для PUT-запроса открывает удобный паттерн: клиентское приложение — браузер или мобильное приложение — загружает файл напрямую в объектное хранилище, минуя backend-сервер. Это снижает нагрузку на сервер и упрощает архитектуру загрузки файлов.
Для точечного ограничения прав presigned URL комбинируют с IAM-политикой подписывающего принципала: например, доступ только к определённому префиксу bucket или только на чтение. Даже если подпись создаётся с широкими правами роли, конкретная ссылка не может выйти за границы, заданные политикой.
Долгоживущие статические ключи, встроенные в код фронтенда или мобильного приложения и переданные третьей стороне, — постоянный источник риска. Их можно извлечь из кода, скопировать и использовать бессрочно, пока кто-то вручную не проведёт ротацию.
Presigned URL заменяет передачу постоянных ключей ограниченной по времени подписью. При утечке ссылки — через лог, случайную публикацию, кэш браузера — злоумышленник получает доступ только до истечения TTL и только к тому объекту и методу, для которых она была выписана.
Цена вопроса высокая. По данным Google Cloud Threat Horizons за первую половину 2025 года, слабые или отсутствующие учётные данные — главный вектор первичного доступа в облачные среды: 47,1% инцидентов; далее ошибки конфигурации (29,4%) и компрометация API или UI (11,8%). ENISA Threat Landscape 2025 фиксирует, что эксплуатация уязвимостей даёт 21,3% векторов первичного доступа в ЕС, а периметровые сервисы компрометируются массово в течение часов после раскрытия уязвимости: около 68% таких инцидентов заканчиваются развёртыванием вредоносного кода.
При такой статистике архитектура, где постоянные ключи не покидают серверную среду, а наружу выходят только ограниченные по времени подписи, — прямое сокращение поверхности атаки.
Чем короче срок действия ссылки, тем меньше окно риска при её утечке — через логирование, случайную публикацию или кэширование в истории браузера.
Подпись в URL эквивалентна временному ключу доступа к объекту: полный URL не должен попадать в общие логи, аналитику или поисковую индексацию.
Ограничения задаются для подписывающего принципала, а не только через TTL. Короткий срок действия не спасёт, если подпись выдана с избыточными правами.
Отслеживание аномальных обращений по presigned URL — стандартная точка контроля, которая встраивается в общие практики AppSec и DevSecOps — например, платформа VK Security Gate объединяет SAST, SCA, DAST, поиск секретов и сканирование контейнеров и внутри VK покрывает более 40 000 репозиториев и свыше 10 000 сканирований в день.
Presigned URL — не единственный инструмент временного доступа к объектам. Среди альтернатив:
Presigned URL предпочтителен, когда нужен прямой, кратковременный и точечный доступ к одному объекту без развёртывания дополнительной инфраструктуры вроде CDN или прокси.
Масштаб вопроса растёт вместе с облачной разработкой. По данным State of Cloud Native Development за Q1 2026, 71% backend-разработчиков в мире используют хотя бы одну cloud-native технологию, а 52% применяют три и более одновременно. При таком распространении объектных хранилищ и связанных с ними паттернов доступа presigned URL — рабочий инструмент, о механике и ограничениях которого стоит знать любой команде, работающей с S3-совместимым хранилищем.
Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.
Будем держать в курсе новостей и облачных трендов
