Synology Hyper Backup в Amazon S3: как настроить права IAM

Почему одного PutObject недостаточно

Hyper Backup не работает как простая программа «скопировать файл в S3». Во время создания задачи он проверяет расположение bucket, получает списки, загружает данные частями, завершает или отменяет multipart upload, а при ротации удаляет устаревшие объекты и версии. Synology отдельно указывает, что системе требуется возможность перечислять buckets учётной записи при создании задачи. Если разрешить только s3:PutObject, мастер может не показать bucket или завершиться AccessDenied ещё до первой резервной копии. При этом выдавать AdministratorAccess не нужно: задача должна иметь ровно тот набор действий, который необходим репозиторию backup.

Важно: Создавайте отдельные ключи для Hyper Backup. Тогда их можно отозвать без остановки других приложений и без доступа ко всем AWS-сервисам.

Какие группы разрешений нужны Hyper Backup

• Bucket-level: ListBucket, GetBucketLocation и действия, связанные со списком multipart uploads.
• Object-level: чтение, загрузка, удаление объектов и версий, а также операции multipart upload.
• List buckets: Synology требует возможность получить список buckets при создании задачи, даже если backup идёт только в один выбранный bucket.

Как настроить доступ и проверить его

1. В AWS создайте отдельного IAM-пользователя или другой механизм доступа только для NAS. Не переиспользуйте root credentials.
2. Создайте или выберите S3 bucket для backup. Зафиксируйте его регион и имя.
3. Соберите IAM policy по актуальному списку действий Synology. Ограничьте ресурсы выбранным bucket и его объектами там, где это поддерживает конкретное действие.
4. Создайте Access Key/Secret Key и внесите их в Hyper Backup → Data backup task → S3 storage. Выберите bucket и каталог назначения.
5. Запустите небольшую тестовую копию, затем восстановите один файл. Только после этого включите расписание, ротацию и уведомления.

Совет: Сначала тестируйте восстановление. Успешный upload подтверждает запись в S3, но не гарантирует, что вы правильно настроили путь возврата данных.

Как ограничить права без поломки задачи

Принцип наименьших привилегий полезен, но его нужно применять с учётом реального протокола Hyper Backup. У bucket и объектов разные ARN, а некоторые действия нельзя ограничить тем же ресурсом, что и другие. Если задача создаётся, но позже падает на ротации или удалении старых версий, проверьте не только запись, но и DeleteObject, DeleteObjectVersion и multipart actions. Если bucket использует customer-managed KMS key, потребуются отдельные разрешения на этот ключ — они не появляются автоматически из S3 policy. Не добавляйте такие права «на всякий случай»: сначала зафиксируйте схему шифрования и конкретную ошибку.

Что проверить, если Hyper Backup не видит bucket

Убедитесь, что ключ активен и введён без лишних пробелов. Затем проверьте регион и возможность перечислять buckets: мастер обращается к API ещё до передачи данных. Если bucket виден, но тест соединения падает, смотрите сообщение Synology или CloudTrail — они помогают понять, какое действие запрещено. AccessDenied после нескольких успешно загруженных гигабайт часто указывает не на PutObject, а на multipart или удаление версий. Проверьте также системное время NAS: подпись AWS зависит от времени. После изменения policy повторите тест с тем же ключом, не создавая новый без необходимости.

Предупреждение: Не вставляйте AWS Secret Key в заметки, скриншоты и общие конфиги. Храните его как пароль.

Как завершить проверку настройки

После изменения IAM policy не ограничивайтесь Test Connection. Запустите реальную небольшую задачу, дождитесь создания версии, затем удалите тестовый файл на NAS и восстановите его через Hyper Backup. Такой цикл одновременно проверяет запись, чтение, структуру репозитория и ваши инструкции на случай сбоя. Если используется versioning или lifecycle на S3, убедитесь, что они не конфликтуют с логикой хранения Hyper Backup. Для критичных данных дополнительно полезно периодически повторять пробное восстановление, а не считать один успешный backup вечным доказательством работоспособности.

Как проверить права до первой резервной копии

После создания IAM-политики не начинайте сразу с многотерабайтного задания. Создайте отдельный тестовый bucket или префикс и проверьте, что Hyper Backup видит целевое хранилище, может создать задачу, записать небольшой набор данных и затем выполнить проверку/восстановление тестового файла. Если список buckets виден, но запись не начинается, обычно не хватает уже не ListAllMyBuckets, а действий на bucket/object или multipart-операций. Если первая копия проходит, а очистка старых версий ломается позднее, проверьте разрешения на delete/versioning, которые могут не проявиться при простом upload. Не выдавайте пользователю NAS административный доступ ко всему AWS-аккаунту ради обхода ошибки: безопаснее добавить только те S3-действия и ресурсы, которые требует Hyper Backup. После изменения policy подождите применения настроек AWS и повторите минимальный тест. Отдельно сохраните данные о регионе и имени bucket: ошибка endpoint или региона внешне может выглядеть как проблема авторизации.

Минимальные права проще проверять поэтапно

Если вы ужесточаете IAM после первоначальной настройки, меняйте политику небольшими шагами и после каждого шага запускайте короткий backup и тест восстановления. Так проще понять, какое действие действительно нужно приложению. Политика, которая разрешает только upload, может выглядеть рабочей до первого multipart-задания, ротации версий или удаления старого backup. Цель — не дать Hyper Backup «всё в S3», а оставить ровно тот набор операций и ресурсов, который требуется для полного жизненного цикла резервной копии.

Как не сломать least privilege при ограничении ARN

В S3 политика обычно делится как минимум на два уровня ресурсов: действия над самим bucket и действия над объектами внутри него. Поэтому попытка привязать все разрешения только к ARN вида bucket/* может дать AccessDenied ещё до загрузки данных, а слишком широкий Resource "*" уничтожит смысл least privilege. Практически удобнее взять актуальный список действий из Synology, разнести их по тем ресурсам, к которым AWS позволяет применять ограничение, и затем сузить доступ до одного backup-bucket. После этого проверьте не только создание задачи, но и ротацию, удаление старой версии и восстановление. Если используются Object Lock, versioning или собственный KMS key, фиксируйте эти особенности отдельно: они добавляют условия, которых нет в базовой S3-конфигурации Hyper Backup.

Что учитывать

Hyper Backup не работает как простая программа «скопировать файл в S3». Во время создания задачи он проверяет расположение bucket, получает списки, загружает данные частями, завершает или отменяет multipart upload, а при ротации удаляет устаревшие объекты и версии. Synology отдельно указывает, что системе требуется возможность перечислять buckets учётной записи при создании задачи. Если разрешить только s3:PutObject, мастер может не показать bucket или завершиться AccessDenied ещё до первой…

Источники и проверка

Инструкция составлена редакцией N1RO на 2026-09-22. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.

• Which AWS S3 permissions are required for Hyper Backup?
• Create Backup Tasks | Hyper Backup