Определяет непрозрачные ключи объектов с областью действия арендатора и запись владения в базе данных, чтобы имена файлов, пользователи и изменяемые права доступа никогда не становились идентификатором хранения или не просачивались через URL и логи.
Статус пакета: справочный контекст готов для проверки человеком. Контракт и сценарии тестирования завершены, но не заявляется, что реализующая система их прошла.
Решение
Генерировать непрозрачные ключи на стороне сервера в пространстве имён окружения и арендатора; хранить оригинальные имена и права доступа в базе данных приложения. Рассматривать бакет как приватный и разрешать каждую загрузку или скачивание через запись владения.
Область применения
- Грамматика ключей, отображение владения, идентичность версии, многокомпонентные загрузки, временные объекты, логи, префиксы жизненного цикла и миграция.
- Приватные объекты приложения в хранилище, совместимом с S3.
- Контроль коллизий, перечислений и межарендного доступа.
Вне этого блока
- Дедупликация по содержимому между проектами.
- Использование ключей объектов как механизма авторизации или раскрытие прямого списка бакета.
Контракт
- Ключ содержит только контролируемые слаги и случайные или серверные идентификаторы; исключает оригинальное имя файла, email, имя аккаунта и недоверенный текст пути.
- Идентификатор арендатора и окружение — отдельные сегменты ключа, проверяемые по записи владения.
- Одна логическая версия файла соответствует одному неизменяемому ключу объекта; замены создают новый ключ версии.
- Запись в базе данных владеет состоянием, типом медиа, размером, дайджестом, загрузчиком, арендатором, версией и жизненным циклом; метаданные объекта не являются единственным источником истины.
- Имена, предоставленные клиентом, — это метаданные для отображения и отдельно очищаются для заголовков скачивания.
- Временные и карантинные префиксы имеют явные правила жизненного цикла и не могут обслуживаться как активные файлы.
Руководство по реализации
- Используйте грамматику вида
env/tenant-id/files/file-id/version-id/blob, где каждый идентификатор генерируется и проверяется на сервере. - Выпускайте ограниченные намерения загрузки, привязанные к ожидаемому ключу, лимиту байт, политике content-type и сроку действия.
- Логируйте идентификаторы объектов или хэши вместо оригинальных имён файлов, если это достаточно для операций.
- Мигрируйте, записывая отображение и копируя на новые неизменяемые ключи перед переключением чтения; проверяйте дайджест перед очисткой старых объектов.
Обработка сбоев и меры безопасности
- Отклонять ключи, содержащие сегменты обхода, управляющие символы, неоднозначную нормализацию или арендатора, не совпадающего с записью владения.
- Если загрузка завершилась без подтверждённой записи в базе, оставлять объект в карантине для последующего сопоставления сирот.
- Если дайджесты базы данных и объекта не совпадают, блокировать обслуживание и расследовать, а не обновлять владение молча.
Проверка и эксплуатация
- Измерять отклонения валидации ключей, отказ межарендного доступа, сопоставление отсутствующих и не принадлежащих объектов, несоответствие дайджестов и возраст временных объектов.
- Тестировать, что логи, подписанные URL и ответы об ошибках не раскрывают оригинальные приватные имена.
- Аудитировать политики бакета, чтобы прямое публичное чтение и перечисление оставались отключены.
Примеры, похожие на исполняемые, в этом пакете являются фикстурами и контрактами приёмки. Запустите
python tools/validate.py из корня коллекции для проверки структуры пакета и метаданных; затем
реализуйте и выполните сценарии в целевом репозитории.
Предположения при внедрении
- Имена и числовые значения в
example.yaml— это профиль внедрения, а не универсальные значения по умолчанию. - Команда внедрения должна сопоставить акторов, классы данных, словарь ошибок и владение со своей системой.