Загрузка файлов в масштабе: валидация, хранение и доступ

Почему загрузки файлов становятся сложными в масштабе

Загрузки от пользователей кажутся простыми, когда тестируют пара человек. Всё меняется, когда реальные люди начинают отправлять реальные файлы: гигантские фото, отсканированные PDF и загадочные документы с неверным расширением. Тогда кнопка «загрузить» превращается в проблему безопасности и операционной поддержки.

Первые трещины обычно проявляются в трёх областях: безопасность, стоимость и приватность. Злоумышленники пытаются загрузить вредоносный софт, пользователи присылают файлы, которые ваше приложение не может открыть, а команды случайно открывают доступ к чувствительным документам через публичный URL. Счета за хранение и трафик растут, особенно если один и тот же файл скачивают снова и снова.

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

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

Цель не в том, чтобы просто «обрабатывать загрузки». Цель — безопасные загрузки, которыми легко управлять через месяцы: понятные правила, предсказуемые пути хранения, метаданные, пригодные для аудита, и доступ, соответствующий реальным бизнес‑процессам.

Классифицируйте типы файлов и кто должен иметь к ним доступ

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

Начните с списка реальных категорий, а не просто «документы» и «изображения». Аватар ведёт себя совсем иначе, чем контрактный PDF, а скриншот поддержки отличается от ежемесячного отчёта.

Практичный способ — привязать каждую категорию к шаблону доступа:

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

Затем сделайте быстрый анализ рисков. Загрузки могут скрывать malware, утекать чувствительные данные (паспортные данные, банковская информация, медицинские записи) или выставлять слабые права, когда доступ даёт угадывание URL. Поэтому работа с загрузками в масштабе — это по сути управление доступом к файлам, а не только байтам.

Производительность тоже имеет значение. Большие PDF, изображения высокого разрешения и ненадёжные мобильные сети вызывают частичные загрузки и повторные попытки. Решите заранее, какие загрузки должны пройти обязательно (счета, удостоверения), а какие опциональны (баннер профиля).

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

• Кто может загружать, просматривать, заменять и удалять файл?
• Приватный ли он, общий для группы или публичный?
• Должен ли доступ истекать или быть мгновенно отзывным?
• Что происходит при прерывании загрузки и повторной попытке?
• Как долго вы храните файл и кто может его экспортировать?

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

Правила валидации, которые предотвращают проблемы заранее

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

Начните с allowlist, а не blacklist. Проверяйте расширение файла и одновременно подтверждайте MIME‑тип по содержимому. Полагаться только на расширение легко обойти; полагаться только на MIME может быть ненадёжно на разных устройствах.

Ограничения по размеру должны соответствовать типу файла и вашим продуктовыми правилами. Для изображений обычно хватает 5–10 МБ, для PDF может потребоваться более высокий предел. Видео — совсем отдельная история и обычно требует отдельного конвейера. Если у вас платные тарифы, привязывайте лимиты к плану, чтобы можно было сообщить: «Ваш тариф позволяет PDF до 10 МБ», вместо расплывчатой ошибки.

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

Переименовывайте файлы при загрузке. У пользователей часто имена с пробелами, эмодзи или повторяющиеся названия вроде scan.pdf. Используйте сгенерированный ID плюс безопасное расширение, а оригинальное имя храните в метаданных для отображения.

Базовый набор проверок, подходящий для многих приложений:

• Allowlist типов (расширение + MIME), всё остальное отклонять.
• Максимальный размер по типу (и по плану при необходимости).
• Проверка размеров изображений и отклонение экстремальных значений.
• Проверка числа страниц PDF, если кейс этого требует.
• Переименование в безопасное уникальное имя и сохранение оригинала в метаданных.

Когда валидация не проходит, показывайте одно понятное сообщение, по которому пользователь сможет действовать, например: «PDF должны быть меньше 20 МБ и не более 50 страниц». Параллельно логируйте технические детали для админов (определённый MIME, размер, ID пользователя и причина). В AppMaster эти проверки можно размещать в Business Process так, чтобы все пути загрузки следовали одинаковым правилам.

Модель данных для загрузок и метаданных

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

Надёжный паттерн — двухэтапный поток. Сначала создавайте запись в базе и возвращайте upload ID. Затем загружайте бинарные данные в хранилище, используя этот ID. Это избегает загадочных файлов в бакете без соответствующей строки в БД и позволяет проверять права до передачи байтов.

Простой стол/коллекция uploads обычно достаточна. В AppMaster это хорошо мапится на модель PostgreSQL в Data Designer и может использоваться в вебе и мобильных приложениях.

Храните то, что действительно понадобится позже для поддержки и аудита:

• Ссылка на владельца (user_id) и область (org_id или team_id)
• Назначение (avatar, invoice_pdf, ticket_attachment)
• Оригинальное имя файла, определённый MIME‑тип и size_bytes
• Указатель на хранилище (bucket/container, object_key) и контрольная сумма (опционально)
• Метки времени (created_at, uploaded_at) и IP/устройство загрузчика (опционально)

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

• pending: запись создана, загрузка не завершена
• uploaded: байты сохранены
• verified: прошли проверки и готово к использованию
• blocked: не прошло проверки или политик

Планируйте очистку с первого дня. Брошенные pending появляются, когда пользователь закрыл вкладку или потерял соединение. Ежедневная задача может удалять объекты в хранилище для просроченных pending записей, помечать строки как canceled для отчётности, удалять старые blocked после окна ретенции и хранить verified файлы до тех пор, пока бизнес‑правила не скажут иначе.

Такая модель даёт трассируемость и контроль без лишней сложности.

Организация хранилища, которая остаётся опрятной со временем

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

Выберите один предсказуемый подход к папкам и придерживайтесь его. Многие команды организуют по арендаторам (company), затем по назначению, затем по дате. Другие используют tenant, user, purpose. Важнее не точный выбор, а последовательность. Даты помогают держать каталоги в пределах разумного и упрощают очистку.

Избегайте помещать персональные данные в пути или имена файлов. Не включайте email, полные имена, номера счетов или телефоны. Используйте случайные ID. Если нужно искать по «человеческому» смыслу, храните это в метаданных базы, а не в object key.

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

Простой и надёжный подход к именованию:

• Разделяйте по tenant ID (или workspace ID)
• Добавляйте префикс назначения (avatars, invoices, attachments)
• Добавляйте временные корзины (YYYY/MM)
• Используйте непрозрачный ID файла как имя
• Храните производные под отдельным префиксом (previews, thumbnails)

Решите, как будете работать с версиями. Если пользователи могут заменять файлы, либо перезаписывайте объект (просто и без истории), либо создавайте новую версию и помечайте старую как неактивную (удобнее для аудита). Многие держат историю для compliance‑документов и перезаписывают для профилей.

Запишите правила именования. В AppMaster относитесь к ним как к общей конвенции проекта: бекенд‑логика, UI‑билдеры и будущие интеграции должны генерировать одинаковые пути.

Шаблоны прав доступа и контроля

В загрузках в масштабе маленькие упрощения быстро приводят к серьёзным инцидентам. Начните с deny‑by‑default: каждый загруженный файл приватен, пока правило явно не разрешит доступ.

Полезно разделять два вопроса: кто видит запись в базе, и кто может получить сами байты. Это разные вещи. Часто можно позволить просматривать метаданные (имя файла, размер, дата загрузки), не давая права скачивать.

Распространённые шаблоны доступа

Выберите основной паттерн для каждого типа файла и добавляйте исключения осторожно:

• Только владелец: скачать может только загрузивший и сервисные аккаунты.
• По команде: члены workspace/project могут скачивать.
• По ролям: роли вроде Finance или HR могут скачивать файлы по всему приложению.
• Доступ по ссылке: специальный токен даёт скачивание, обычно с истечением срока и ограничением по области.

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

Отдельная обработка метаданных и загрузок

Простой шаблон — две проверки: (1) может ли пользователь читать запись uploads, (2) может ли пользователь запросить ответ на скачивание. Вторая проверка — место, где вы применяете «приватно, пока не разрешено», даже если кто‑то угадал ID.

Для чувствительных документов логируйте доступ. Как минимум, регистрируйте кто скачал (ID пользователя и роль), что скачал (ID файла и тип), когда это произошло (время), почему было разрешено (результат политики, share‑токен, админ‑оверрайд) и откуда пришёл запрос (IP или устройство, если нужно).

В AppMaster эти правила часто живут в Business Process Editor: один поток для списка метаданных и более строгий поток для генерации ответа на скачивание.

Ссылки со сроком действия: безопасные скачивания без лишнего трения

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

Два распространённых подхода:

• Подписанные URL автоматически истекают. Они просты и быстры, но отзыв ссылок сложен, если ссылка уже распространена.
• Токен‑эндпойнт даёт больший контроль. Ссылка содержит короткий токен, приложение проверяет права при каждом запросе и затем отдаёт или редиректит на файл.

Практичная настройка:

• Используйте короткое время жизни для общих ссылок (10–60 минут) и обновляйте по требованию.
• Длинные сроки держите только для доверенных, залогиненных сессий (например, «скачать снова» генерирует новую ссылку).
• Узко ограничивайте ссылки: один файл, один получатель и одно действие (просмотр или скачивание).
• Логируйте создание и использование ссылок, чтобы отслеживать утечки.

Важно разграничивать просмотр и скачивание: view обычно значит inline‑отображение, download — сохранение копии. Для обеих целей создавайте отдельные ссылки с разными правилами.

Планируйте отзыв доступа. Если пользователь теряет права (возврат средств, смена роли, окончание контракта), самих подписанных URL может быть недостаточно. С токен‑эндпойнтом вы можете сразу аннулировать токены. Для подписанных URL держите короткие сроки действия и используйте ротацию ключей аккуратно — повсеместная ротация отзовёт все существующие ссылки.

Пример: ссылка на счёт в портале клиентов, отправленная бухгалтеру по почте, истекает через 30 минут, даёт возможность только просматривать и привязана к ID счёта и аккаунту клиента. Если клиента удаляют из аккаунта, токен отвергается, даже если письмо переслали.

Пошаговый масштабируемый поток загрузки

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

Практичный поток для изображений, PDF и большинства UGC:

1. Задайте правила по назначению. Для каждого назначения (avatar, invoice, ID document) укажите допустимые типы, максимальный размер и дополнительные проверки (макс страниц и т. п.).
2. Создайте запрос на загрузку на бэкенде. Клиент просит разрешение — бэкенд возвращает цель загрузки (ключ объекта и короткоживущий токен) и создаёт запись uploads со статусом pending.
3. Загрузите байты в хранилище, затем подтвердите. Клиент загружает в объектное хранилище, затем вызывает бэкенд для подтверждения. Бэкенд сверяет ожидаемый ключ и основные свойства, затем помечает запись как uploaded.
4. Выполните асинхронную верификацию. На фоне проверьте реальный тип файла (включая magic bytes), соблюдение лимитов, извлеките безопасные метаданные (размеры, количество страниц) и при необходимости запустите сканирование на malware. При провале помечайте blocked и блокируйте скачивания.
5. Отдавайте файлы через политику. При скачивании подтверждайте, что пользователь имеет доступ к владельцу файла (user, org, ticket, order). Затем проксируйте скачивание или возвращайте короткоживущие ссылки, чтобы держать хранилище приватным.

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

Если вы создаёте это в AppMaster, моделируйте uploads как сущность с полем статуса и ссылками на владельца, затем применяйте одинаковые проверки прав во всех Business Process, отвечающих за скачивание.

Пример: счета в портале клиентов

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

Для организации хранения держите оригинал в предсказуемом пути, совпадающем с тем, как люди ищут. Например: invoices/<company_id>/<yyyy-mm>/<upload_id>.pdf. Компания и месяц упрощают отчётность и очистку, а upload_id избегает коллизий при одинаковых именах.

В БД храните метаданные, объясняющие, что это за файл и кто к нему имеет доступ:

• company_id и billing_month
• uploaded_by_user_id и uploaded_at
• original_filename и content_type
• size_bytes и контрольная сумма (опционально)
• статус (active, replaced, quarantined)

Для шаринга: менеджер по биллингу хочет отправить счет внешнему бухгалтеру на 24 часа. Вместо изменения глобальных прав генерируйте expiring download link, привязанный к конкретному счету, с жёстким временем жизни и единственной целью (скачать). Когда бухгалтер кликает ссылку, приложение проверяет токен, убеждается, что он не истёк, и отдает файл.

Если пользователь загрузил неправильный PDF или заменил файл, не перезаписывайте старый объект. Пометьте предыдущую запись как replaced, храните её для аудита и укажите invoice‑записи новый upload_id. При необходимости соблюсти правила ретенции, удалите заменённые файлы позже по расписанию.

Когда поддержка получает тикет «не могу скачать», метаданные помогают быстро диагностировать: истекла ли ссылка, помечен ли счёт как replaced, принадлежит ли пользователь правильной компании или файл попал в quarantine? В AppMaster эти проверки можно вынести в Business Process, чтобы каждое скачивание шло по одним и тем же правилам.

Частые ошибки и как их избегать

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

• Полагаться только на расширение или только на MIME. Расширения подделываются, браузеры могут некорректно указывать MIME. Проверяйте и то, и другое, а на сервере сверяйте magic bytes.
• Использовать публичное хранилище и надеяться, что права решают всё. Публичный бакет превращает любую пропущенную проверку в утечку данных. Держите хранилище приватным и проксируйте доступ через приложение.
• Вставлять пользовательские имена в пути хранения или URL. invoice_john_smith.pdf раскрывает личные данные и упрощает угадывание. Используйте случайные ID для ключей и храните отображаемое имя в метаданных.
• Смешивать файлы разных арендаторов в одном пути без сильных проверок. Путь вроде /uploads/2026/01/ не заменяет модель прав. Всегда проверяйте tenant и права пользователя перед выдачей скачивания.
• Пренебрегать очисткой брошенных или неудачных загрузок. Многопартовые загрузки и повторные попытки оставляют мусор. Запустите фоновую задачу, удаляющую pending, которые так и не завершились.

Ещё одна забываемая ошибка — отсутствие плана для повторов и дубликатов. Мобильные сети падают. Пользователи нажимают дважды. Система должна нормально относиться к «загрузке того же файла второй раз». Практичный подход — сначала сгенерировать upload ID, затем принимать чанки или целый файл, помечая запись verified только после успешной валидации. Если тот же файл загружают снова, возвращайте существующую запись вместо создания новой копии.

В AppMaster держите основные правила в одном месте (бэкенд‑логике), чтобы веб и мобильные клиенты вели себя одинаково, даже если UI меняется.

Контрольный список перед релизом

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

• Allowlist типов и ограничения по размеру для каждого сценария (аватары vs счета). Проверяйте и расширение, и реальный тип содержимого.
• Сохраняйте метаданные в БД: кто владеет файлом (user, team, account), назначение и ясный статус pending, verified или blocked.
• Держите хранилище приватным по умолчанию и проверяйте права при каждом скачивании (не полагайтесь на скрытые URL).
• Используйте ссылки со сроком действия при необходимости шаринга и держите времена короткими (минуты или часы, не дни).
• Избегайте персональных данных в путях и именах файлов. Используйте случайные ID и показывайте удобочитаемое имя в UI.

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

Простой план очистки:

• Удаляйте сиротские файлы, не дошедшие до verified после установленного времени.
• Храните заменённые файлы в окне ретенции, затем удаляйте.
• Логируйте ключевые события (upload, validation, download, delete), чтобы поддержка могла расследовать.

В AppMaster обычно хранят метаданные в PostgreSQL через Data Designer, применяют проверки в Business Process Editor и генерируют короткоживущие токены перед выдачей файлов.

Следующие шаги: выпустите безопасно, затем улучшайте понемногу

Самый быстрый путь к безопасному релизу — выбрать один подход к загрузкам и придерживаться его. Решите, проходят ли файлы сначала через ваш бэкенд или загружаются напрямую в объектное хранилище с короткоживущим токеном. Затем пропишите шаги и ответственность (клиент, бэкенд, хранилище). Последовательность важнее хитростей при работе с загрузками в масштабе.

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

Подключите базовый мониторинг рано, чтобы проблемы появлялись в метриках, а не в тикетах:

• Частота ошибок загрузки (по устройствам, браузерам и типам файлов)
• Средний и p95 размеров загрузок
• Время загрузки (особенно в мобильных сетях)
• Рост хранения в день или неделю
• Ошибки скачивания (включая истёкшие и запрещённые ссылки)

Если система загрузок — часть большого приложения, держите модель данных и права рядом с бизнес‑логикой. Команды, использующие AppMaster, часто хранят записи загрузок в PostgreSQL, реализуют валидацию и контроль доступа в Business Processes и повторно используют ту же логику для бэкенда, веба и нативных мобильных приложений.

Полезное следующее улучшение — превью для распространённых форматов, аудит‑логи для чувствительных документов или простые правила ретенции (например, авт−удаление временных загрузок через 30 дней). Маленькие и последовательные улучшения держат систему надёжной по мере роста использования.