Мы работаем над веб-приложением, в которое (помимо других функций) наши пользователи могут загружать свои файлы. Однако мы не можем хранить эти файлы на нашем VPS, потому что пространство для хранения ограничено, поэтому мы решили использовать S3.
Основная проблема заключается в том, что мы должны убедиться, что пользователи могут получить доступ только к своим данным. Таким образом, мы храним список файлов в нашей базе данных и список пользователей, имеющих к ним доступ. Наш сервер может легко решить, есть ли у пользователя доступ к файлу. Но как на самом деле предоставлять файлы пользователям?
Я уже рассмотрел некоторые возможности, но ни один из них не кажется лучшим.
Это действительно простой подход, он также быстрый, но приводит к очень-очень уродливым и длинным URL-адресам.
Это означает, что мы оставляем файлы общедоступными для чтения на S3, но все файлы хранятся в трудно угадываемых именованных папках, например: 24fa0b8ef0ebb6e99c64be8092d3ede20000. Однако, возможно, это не самый безопасный способ. Даже если вы никогда не сможете угадать имя папки, после того, как вы его узнаете (потому что у вас есть к нему доступ), вы можете поделиться этой ссылкой с кем угодно (с любым неуполномоченным лицом).
Это означает, что файлы не обслуживаются напрямую S3, но сначала наш сервер безопасно читает их и обслуживает. Мы действительно этого не хотим :)
В Обфусцированные URL Решение можно улучшить, "убедившись", что запрос исходит от нашего сервера (вы можете настроить S3 для проверки реферера). Однако это было бы очень ненадежным решением, потому что не все браузеры отправляют данные реферера, и их также можно подделать.
Как лучше всего безопасно обслуживать файлы из Amazon S3 для разных клиентов?
Для вас это действительно граничит с «Сделай мою системную архитектуру», но ваши четыре идеи представляют собой интересные примеры из практики переменной безопасности, поэтому давайте рассмотрим ваши варианты и посмотрим, как они работают:
Реферер предоставляется клиентом. Доверие предоставленным клиентом данным аутентификации / авторизации в значительной степени аннулирует безопасность (я могу просто заявить, что меня отправили туда, откуда вы ожидаете).
Вердикт: ТЕРРИБАД идея - банальна для обхода.
Неплохая идея, если вы готовы потратить на это пропускную способность, а ваш сервер надежен.
Исходя из предположения, что вы уже решили проблему безопасности для своего обычного сервера / приложения, это самый безопасный из представленных вами вариантов.
Вердикт: Хорошее решение. Очень безопасно, но, возможно, неоптимально, если важна пропускная способность.
Безопасность через неизвестность? В самом деле? Нет.
Я даже не буду это анализировать. Просто нет.
Вердикт: Если # 4 был ТЕРРИБАД это ТЕРРИВОРС потому что людям даже не нужно создавать заголовок реферера. Угадай нить и выиграй Призвсе данные!
Этот вариант имеет довольно низкий коэффициент отсасывания.
Любой может щелкнуть URL-адрес и перехватить данные, что не является безопасным, но вы смягчаете это, делая ссылку истекающей (пока срок действия ссылки достаточно короткий, окно уязвимости мало).
Срок действия URL-адреса истекает может неудобства для некоторых пользователей, которые хотят удерживать ссылку для загрузки в течение длительного времени или которые не получают ссылку вовремя - это немного отстой для пользователя, но оно того стоит.
Вердикт: Не так хорошо, как №3, но если пропускная способность является серьезной проблемой, это определенно лучше, чем №4 или №2.
Учитывая эти варианты, я бы выбрал №3 - передать файлы через ваш собственный интерфейсный сервер и аутентифицировать так, как обычно это делает ваше приложение. Предполагая, что ваша обычная безопасность довольно приличная, это лучший вариант с точки зрения безопасности.
Да, это означает, что на вашем сервере используется больше пропускной способности, и больше ресурсов играет роль посредника, но вы всегда можете взять немного больше за это.
Использовать Предварительно подписанные запросы Amazon S3 для обслуживания объектов S3 непосредственно пользователям после выполнения любой проверки пользователя, которую вы хотите. Этот метод создает ограниченный по времени URL-адрес, на который вы можете перенаправлять пользователей.
Есть и другой способ.
Вы можете привязать AWS CloudFront к своей корзине S3 и использовать подписанные файлы cookie для безопасного предоставления контента конечным пользователям.
Конечным пользователям необходимо войти на ваш сервер, чтобы получить подписанные файлы cookie, которые затем будут отправлены в CDN при доступе к любому файлу.