Как ограничить доступ к S3 без проксирования?

Question

[Bolage]

Есть сервис. Им пользуются много клиентов. У каждого клиента много пользователей.

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

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

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

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

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

Comments

[Zerg89]

Боюсь этой информации для решения мало как проходит авторизация пользователей изначально не понятно

[Zerg89]

Вот прям сразу скажу что стоит использовать acl и заводить всех в домен, делить на группы доступа,(ну или разные домены под разные проекты) а группы назначать тем кому надо, можно автоматически s3 поддерживает ldap

[Bolage]

Zerg89, простейшая авторизация по сессии из куки. Обычное приложение на laravel

[Drno]

Zerg89, при чем тут домен вообще... это ж явно не под винду делается, а под веб

[Zerg89]

Drno, а доменная авторизация может быть и не под виндой и acl тоже, samba rurez

[Zerg89]

Drno, проще сделать там где проще делать и тестировать и перенести в среду в которую надо

[Zerg89]

Drno, но спорить не буду говорю со своей "колокольни" в web не особо погружался вполне возможно что ваш вариант лучше

[Drno]

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

[Zerg89]

Drno, Про виндовс я ничего не говорил, группы доступа существуют и вне os windows да и домен понятие очень растяжимое, просто все привыкли что домен это виндовс а на самом деле виндовс домен это gpo, а linux domen это kerberos, sss, samba, ldap(как протокол проверки) расположенный в базе вне виндовс.
В итоге неважно какая система, важна проверка авторизации по какому либо признаку это и куки может быть который записан в базе как признак авторизации или keberos tiket записанный в системном каталоге или прямой запрос к Pam авторизации или его форвардинг к серверу для подтверждения валидности или сертификат выданный на устройство который так или иначе должен быть перечислен в конфиге или в бд или каталог в котором эти сертификаты для валидации искать
Ещё раз спорить намерения нету, я изначально писал что непонятно как пользователь себя идентифицирует и исходя из этого надо выстраивать цепочку всех размышлений
Т.е если пользователь регистрируется самостоятельно на сайте это должно лежать где-то в базе данных или в файле или ещё где-то и исходя из этого надо строить цепочку доступов
Тут уже оффтоп
например сделать форму веб регистрации с указанием необходимых проектов и с подтверждением руководителей проектов на разрешение доступа к проекту и/или выбора типа доступа (read write group)

[pfg21]

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

Answer 1

[Дмитрий]

В S3 есть ACL и Access Policy. Причем это касается и "оригинала" - Amazon S3 .https://aws.amazon.com/blogs/security/iam-policies...
Так и разных совместимых сервисов, таких как например Yandex Object Storage https://yandex.cloud/ru/docs/storage/concepts/policy
ровно как и например "свой собственный" minio.

Comments

[Bolage]

Вот этот момент мне не совсем понятен. А кто будет проверять авторизацию?

Есть мой сервис (сайт) — example.com
Есть файлы загруженные в облако на S3 — s3.example.cloud/client1/file.txt

Человек авторизован у меня на сайте для клиента client2, а не client1.
Как S3 проверит это и даст отлуп?
S3 провайдеру же нужно как то получить от моего сайта ID пользователя как минимум.

[Дмитрий]

на s3 кто ходит? клиент или ваш сайт? Если сайт -- то реализуете проверку своими силами, на стороне сайта.

[Mikhail Osher]

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

Answer 2

[mayton2019]

В S3 можно фолдеры создавть. Как часть ключа-пути.

s3://bucket/Bolage/file1.txt
s3://bucket/mayton2019/file1.txt

Answer 3

[d'Ivan]

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

Клиенты, использующие Jira, не заходят в свои бакеты. За них это делает бэк.
Не так ли?
Что значит "просматривать"? Пути к файлам должны быть определены на бэке и пусть клиент смотрит через веб-интерфейс на свои файлы. Допустим, файлы отчетов лежат в s3://reports-bucket/reports/customer-12345/. Бэк ведь знает где отчеты находятся?! Вот он их и показывает! Список имен файлов отчетов должен храниться в СУБД. Бэк просто составляет полный путь в "ведре" и если надо дать ссылку на скачивание, то просто создается presigned URL. Ссылка показывается в веб-интерфейсе и нет никаких нарушений прав доступа.
А можно ли текущему пользователю показывать создавать ссылку на отчет или нет - зависит от авторизации пользователя на сайте.