S3 для маркетплейса: как хранить данные продавцам

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

Интернет-магазин и маркетплейс предъявляют разные требования к файловому хранилищу. Например, в интернет-магазине большая часть файлов загружается внутренней командой, поэтому уровень доверия к контенту выше, а структура хранения проще и обычно привязана к товарам и категориям. В маркетплейсе файлы поступают от множества независимых продавцов и пользователей, поэтому каждый объект должен считаться недоверенным до проверки.

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

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

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

1. Продавец авторизуется в кабинете и выбирает тип файла.
2. Backend проверяет продавца, товар, допустимый размер и формат.
3. Приложение формирует разрешенный ключ объекта и создает короткоживущую подписанную ссылку.
4. Браузер загружает файл напрямую в закрытую область PC-Storage.
5. Система фиксирует объект в базе и запускает проверки.
6. После успешной модерации создаются производные версии, а публичный объект помещается в область публикации.
7. Покупатель получает файл через CDN или контролируемую точку доступа.

Access Key и Secret Key являются учетными данными сервисного уровня. Если передать их продавцу или встроить в клиентское приложение, ключи можно извлечь, переиспользовать и применить за пределами предусмотренного сценария:

• появляется риск чтения или удаления чужих объектов;
• сложно ограничить размер и тип конкретной загрузки;
• отзыв ключа затрагивает все операции, использующие эту учетную запись;
• невозможно безопасно различать одну сессию продавца и другую;
• постоянный секрет может попасть в журналы, расширения браузера или исходный код приложения.

Правильная модель: постоянные ключи хранятся только на серверной стороне. Backend создает presigned URL (временную ссылку) на один объект и на короткий срок. Такая ссылка наследует ограничения учетной записи, которая ее выпустила, поэтому сервисная роль также должна иметь минимальные права.

Загрузка файлов через подписанные ссылки

Подписанная ссылка – это URL с временной криптографической подписью, позволяющий выполнить конкретную операцию с объектом без передачи постоянных учетных данных. Для маркетплейса это основной механизм прямых загрузок из браузера или мобильного приложения.

Presigned URL ограничивает доступ к объекту, но не проверяет содержимое файла. После загрузки обязательны контроль MIME-типа, фактического формата, размера, безопасности и принадлежности объекта.

Как проектировать бакеты и префиксы

В S3 нет традиционных папок. Структура, похожая на каталоги, формируется из ключей объектов с разделителями. Архитектор выбирает между несколькими бакетами и одним бакетом с префиксами.

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

Пример структуры:

mp-pending/sellers/452/products/91835/images/2026/07/upload-8f35.jpg

mp-public/products/91835/images/card/v4/main.webp

mp-private/sellers/452/documents/certificate/2026/cert-91a2.pdf

mp-system/feeds/seller-452/2026/07/29/catalog.xml

Правила построения ключей объектов

Ключ должен быть предсказуемым для системы, но не зависеть только от исходного имени файла. Имена image.jpg, photo1.png и document.pdf неизбежно повторяются, а пользовательские символы усложняют интеграции и миграцию.

Не используйте
Ключи вида sellers/452/image.jpg или исходное имя как единственный идентификатор. Они приводят к перезаписи, коллизиям и затрудняют аудит.

Метаданные и каталог объектов

S3-хранилище не заменяет PIM, базу товаров или поисковый индекс. В PC-Storage можно хранить пользовательские метаданные, однако сведения, необходимые для быстрого поиска и бизнес-логики, лучше дублировать в базе маркетплейса.

Конвейер проверки и модерации

Файл не должен становиться публичным сразу после загрузки. Он помещается в закрытый контур pending или quarantine, где проходит автоматические и, при необходимости, ручные проверки.

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

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

При скачивании приватного документа приложение сначала проверяет пользователя и бизнес-право: принадлежность продавцу, связь с заказом, роль сотрудника или срок действия документа. Только затем создается временная ссылка на один объект.

Модель доступа и минимальные привилегии

Модель, кто и что может делать:

• Продавец – загрузить только разрешенный объект.
• Backend – создать URL, записать метаданные.
• Модератор – смена статуса, редактирование.
• CDN – чтение только публичных объектов.
• Поддержка – просмотр логов без возможности удаления файлов.

Каждый сервис получает только те действия, которые необходимы ему для работы. CDN не требуется запись, сервису ресайза не нужно менять политику бакета, а оператору поддержки не следует выдавать право массового удаления.

Защита от удаления, перезаписи и ошибок

Большинство инцидентов с файлами связано не со сложной атакой, а с неверной политикой, ошибкой интеграции или массовой операцией. PC-Storage поддерживает версионирование и Object Lock, которые можно использовать для сценариев, где необходимо восстановление или защита от изменения. Вы можете:

• включать версионирование для критичных бакетов или классов объектов;
• разделять права на запись и удаление;
• использовать новые версионные ключи для опубликованных изображений;
• вводить отложенное удаление на уровне приложения;
• применять Object Lock только после определения режима и срока неизменяемости;
• вести журнал административных и массовых операций;
• проверять резервное восстановление, а не только факт создания копий.

Осторожно с Object Lock!
Неизменяемость защищает объект от удаления и перезаписи, но ошибочно заданный срок может усложнить законное удаление или исправление данных. Политику следует согласовать с требованиями бизнеса и комплаенса.

Маркетплейс быстро накапливает незавершенные загрузки, отклоненные материалы, старые версии и файлы удаленных товаров. Без правил жизненного цикла объем растет даже при стабильном ассортименте.

Автоматическая очистка не должна опираться только на дату последнего обращения. Объект может редко скачиваться, но оставаться юридически или операционно значимым. Источником решения должен быть статус в бизнес-системе, дополненный возрастом, префиксом и тегами.

Поставщики часто передают большие архивы, изображения высокого разрешения и пакетные выгрузки. Multipart upload делит файл на части, позволяет повторно передать только неудавшийся фрагмент и продолжить загрузку после разрыва связи. PC-Storage поддерживает этот механизм через S3 API.

Для маркетплейса важно дополнить multipart upload прикладными ограничениями: максимальный общий размер, число частей, срок завершения, допустимый тип архива и автоматическое прекращение зависших сессий.

CDN не заменяет объектное хранилище. CDN лишь кэширует публичные файлы ближе к пользователям и снижает повторную нагрузку на origin. Таким образом:

• публичные изображения следует разделять;
• для обновлений удобнее использовать версионные ключи, а не перезапись по старому URL;
• Cache-Control должен соответствовать частоте изменения объекта;
• прямой обход CDN к origin можно ограничить, если это поддерживает выбранная схема;
• защиту от хотлинков нужно проверять с учетом мобильных приложений и партнерских витрин.

Пример версионного адреса: products/91835/images/card/v7/main.webp. Новая версия получает новый URL, поэтому не требует рискованной очистки всех промежуточных кэшей.

1. Составлена карта типов файлов, владельцев и уровней доступа.
2. Публичные, приватные, системные и непроверенные данные разделены.
3. Продавцам не выдаются постоянные S3-ключи.
4. Ключ объекта формируется на backend и не зависит от исходного имени.
5. Срок presigned URL ограничен и соответствует операции.
6. После загрузки проверяются размер, MIME, сигнатура и безопасность.
7. Pending-файлы недоступны через публичный CDN.
8. Метаданные о владельце и статусе хранятся в базе маркетплейса.
9. Роли сервисов настроены по принципу минимальных привилегий.
10. Для критичных данных определены версионирование и Object Lock.
11. Настроена очистка временных и незавершенных загрузок.
12. Удаление согласовано со статусами товаров, документов и споров.
13. Публичные объекты используют версионные ключи и корректный кэш.
14. Логируются загрузки, удаления, изменения прав и выдача документов.
15. Проверено восстановление после удаления или ошибочной перезаписи.
16. Проведен нагрузочный тест массовой загрузки и пикового чтения.
17. Стоимость рассчитана с учетом версий, временных данных, CDN и модерации.

Необходимо также проверить объектное хранилище:

• Создать тестовые бакеты и сервисные роли для каждого компонента.
• Проверить подпись запросов, CORS и загрузку из браузера.
• Реализовать генерацию ключа только на backend.
• Проверить presigned URL для загрузки и скачивания.
• Настроить multipart upload и очистку незавершенных операций.
• Проверить метаданные, версионирование и поведение при повторной загрузке.
• Смоделировать недоступность хранилища и повтор операций.
• Проверить публикацию через CDN и обновление версий.
• Провести нагрузочный тест на пиковом профиле распродажи или массового импорта.

PC-Storage – S3-совместимое объектное хранилище собственной разработки PlatformCraft. По официальным материалам сервис поддерживает основные операции с бакетами и объектами, multipart upload, presigned URL, ACL и Bucket Policy, Versioning, Object Lock, CORS и custom metadata. Доступ возможен через S3 REST API, Web GUI, AWS CLI, s3cmd, rclone и стандартные SDK.

Для маркетплейса это означает, что хранилище можно встроить в существующий backend без создания собственного протокола работы с файлами. При этом безопасность и корректность архитектуры зависят не только от возможностей PC-Storage, но и от прикладной реализации: структуры ролей, правил выдачи ссылок, модерации, журналирования и жизненного цикла.

Роль PC-Storage в архитектуре.
PC-Storage хранит объекты и обеспечивает S3-интерфейс. Маркетплейс по-прежнему отвечает за бизнес-права, связь файлов с продавцами и товарами, статусы модерации, правила публикации и юридические сроки хранения.

Интеграция PC-Storage с маркетплейсом

PC-Storage предоставляет S3-совместимый API и единый endpoint. Приложение можно подключать через AWS SDK, AWS CLI, s3cmd, rclone и другие инструменты, поддерживающие пользовательский endpoint. Для продуктивной интеграции недостаточно проверить PutObject и GetObject и необходимо протестировать весь бизнес-процесс.

Практические сценарии

Маркетплейс одежды – продавец загружает основное фото и галерею. Исходники попадают в pending, проверяются по размеру, формату, фону и содержанию. После одобрения создаются версии для каталога и карточки, которые публикуются по версионным ключам. Старые варианты сохраняются на короткий срок для отката.

B2B-маркетплейс – помимо изображений система хранит паспорта изделий, договоры, прайс-листы и технические документы. Публичные инструкции выдаются через CDN, а договорные материалы — только после проверки организации и роли пользователя по временной ссылке.

Маркетплейс с массовыми фидами – поставщики загружают XML, YML или CSV в закрытый системный префикс. После валидации схема импорта связывает строки с объектами каталога, формирует отчет ошибок и удаляет временный файл по регламенту.

Маркетплейс с пользовательскими отзывами – фотографии покупателей хранятся в отдельном pending-контуре. До модерации они не доступны по публичному URL. После удаления отзыва связь с объектом фиксируется, а файл удаляется с учетом периода восстановления и спорных обращений.

Зачем интернет-магазину S3-хранилище?

S3 позволяет хранить изображения, документы, видео и пользовательские файлы отдельно от сервера сайта. Это упрощает масштабирование и снижает файловую нагрузку на приложение.

Подходит ли S3 для маркетплейса?

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

Чем S3 лучше сервера сайта?

S3 масштабируется независимо от приложения, предоставляет API, политики доступа, метаданные и инструменты управления большим числом объектов.

Нужна ли CDN вместе с S3?

Для небольшого проекта она необязательна. При большом каталоге, широкой географии и сезонных пиках CDN снижает задержки и повторную нагрузку на хранилище.

Как хранить видеообзоры?

Исходники можно размещать в S3. Для транскодирования, нескольких качеств, плеера, защиты и аналитики лучше использовать медиаплатформу.

Как рассчитать объем хранилища?

Умножьте число товаров на среднее количество изображений, размер файла и количество версий. Отдельно прибавьте видео, документы, архивы и старые версии.

Как защитить документы покупателей?

Хранить их в приватном бакете, проверять права через приложение и выдавать только по короткоживущим подписанным ссылкам.

Что делать со старыми фотографиями?

Нужно отслеживать связь объектов с товарами, удалять временные файлы и применять правила жизненного цикла к старым версиям и архивам.

Что такое подписанная ссылка?

Это временная ссылка на загрузку или скачивание конкретного объекта. Она не открывает весь бакет и перестает действовать после установленного срока.

Как ограничить продавца только его файлами?

Продавец должен работать через кабинет. Приложение проверяет его идентификатор и выдает доступ только к определенному префиксу или конкретной загрузке.

Нужен ли отдельный бакет каждому продавцу?

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

Можно ли хранить файлы всех продавцов в одном бакете?

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

Можно ли выдавать продавцу Access Key и Secret Key?

Не следует. Постоянные ключи должны храниться только на серверной стороне. Продавцу выдают короткоживущую ссылку на конкретную операцию.

Проверяет ли подписанная ссылка содержимое файла?

Нет. Она только разрешает операцию. Формат, размер, MIME, сигнатуру и безопасность нужно проверять после загрузки.

Где хранить файл до модерации?

В закрытом бакете или префиксе pending/quarantine, который не подключен к публичной выдаче.

Нужно ли сохранять оригиналы изображений?

Обычно да: они позволяют повторно обработать фотографию при изменении требований. Срок хранения оригиналов определяется стоимостью и бизнес-регламентом.

Как обновлять опубликованную фотографию?

Создавать новый версионный ключ, например v8, и переключать карточку на новый URL. Это надежнее перезаписи объекта под старым адресом.

Как хранить сертификаты продавцов?

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

Как предотвращать одинаковые имена файлов?

Backend назначает уникальный ключ, например с UUID, а исходное имя сохраняется только как метаданные.

Нужна ли антивирусная проверка изображений?

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

Нужно ли включать версионирование?

Для критичных объектов оно помогает восстановиться после перезаписи или удаления. Нужно учитывать рост занимаемого объема.

Когда нужен Object Lock?

Когда объект должен быть защищен от изменения или удаления в течение заданного срока. Настройка требует аккуратного регламента.

Как защититься от хотлинков?

Использовать CDN, ограничение прямого доступа к origin, токены или правила источников. Полностью запретить копирование публичного изображения невозможно.

Что логировать?

Загрузку, удаление, публикацию, скачивание приватных документов, генерацию ссылок, изменение политик, массовые операции и ошибки доступа.

Как удалить все файлы товара?

Использовать связь в базе и предсказуемый префикс, но перед удалением учитывать версии, документы, споры и отложенное восстановление.