Как веб-приложение должно обеспечивать безопасность при передаче конфиденциальных мультимедийных файлов? - PullRequest
0 голосов
/ 20 марта 2019

Вопрос: Скажите, что пользователь загружает конфиденциальную информацию.Это размещено на стороннем сервере хранения.Эта сторонняя корзина использует различные системы аутентификации для веб-приложения.Каков наилучший способ обеспечить доступ к URL-адресу файла только пользователю или сотруднику администратора?

Дополнительные сведения: Веб-приложение Django работает на Google App Engine Flexible.Google Storage используется для обслуживания статических и мультимедийных файлов через Django.Конфиденциальная информация - это паспорта, юридические контракты и т. Д.

Статические файлы обслуживаются довольно небезопасно.Область /static/ является общедоступной, и файлы передаются через статическую файловую систему django.Это работает, потому что

  • нет никакой конфиденциальной или пользовательской информации ни в одном из наших статических файлов
    , только стоковые изображения, css и javascript, и
  • файлы uglified и minifedдо производства.

Для медиафайлов однако нам нужны специальные разрешения пользователя, если пользователь A загружает изображение, то пользователь A может его просматривать, персонал может его просматривать, но пользовательB & неаутентифицированные пользователи не могут ни при каких обстоятельствах просматривать его.Это включает в себя, если у них есть URL.

Моей предпочтительной системой было бы, чтобы хранилище GCP могло использовать тот же сервер аутентификации django, и поэтому, когда браузер запросил ...google.storage..../media/user_1/verification/passport.png, мы могли проверить, какие разрешения имел этот пользователь, сравнить его с загруженным идентификатором пользователя,и решить, показать ли 403 или фактический файл.

Какое отраслевое стандартное / передовое решение для этой проблемы?

Сделать ли оба сегмента доступными только для приложения, используя служебную учетную запись, и обеспечить, чтобы ссылки на них были общими, только если правильный пользователь просматривает страницу?(кто-нибудь для статических, и {пользователь или персонал} для медиа?)

Мои вопросы, в частности (относительно безопасности веб-приложения):

  1. Это безопаснообслуживать статические файлы из общедоступного сегмента?
  2. Можно ли предположить, что если мое приложение запрашивает URL-адрес файла, то это от аутентифицированного пользователя?
  3. В частности, в отношении Django &Хранилище GCP, если 2 - ложь (я так полагаю), как я могу гарантировать, что файлы, обслуживаемые из контейнеров, будут видны только пользователям с правильными разрешениями?

Ответы [ 2 ]

1 голос
/ 21 марта 2019
  1. Да, это так. Открытые читабельные ведра созданы для этого.Такие вещи, как CSS, логотип вашей компании или некоторые файлы, которые не содержат разумных данных, могут быть безопасны для совместного использования.

Конечно, не используйте одно и то же хранилище Public для хранениячастный / публичный материал.Public with Public, Private with Private.


Вот проблема.Когда вы говорите «аутентифицированный пользователь», для которого вы хотите, чтобы этот пользователь проходил аутентификацию?

Например, если вы аутентифицируете своего пользователя с помощью любых методов Django , то пользовательбудет аутентифицирован в Django, но для Cloud Storage это будет незнакомец.Кроме того, даже пользователь, авторизованный в GCP, не может быть авторизован в сегменте облачного хранилища.

Здесь важно то, что тот, кто обменивается данными с облачным хранилищем и обратно, - это не пользователь, а его Django.Этого можно добиться, используя python SDK облачного хранилища , которое принимает учетные данные учетной записи службы , которая используется в экземпляре для проверки подлинности любого запроса в облачное хранилище.Итак, учетная запись службы , на которой запущена виртуальная машина (поскольку вы находитесь в Flexible), должна быть авторизована для облачного хранилища.


Сначала необходимо авторизовать пользователя в Django, а затем проверить, может ли пользователь получить доступ к этому файлу другими способами (например, сохранить имя загруженного им файла в таблице user_uploaded_files).

Что касается вашего первого вопроса в верхней части поста, Cloud Storage позволяет создавать подписанных URL-адресов .Эти URL-адреса позволяют любому пользователю Интернета загружать / скачивать файлы из облачного хранилища, просто удерживая URL-адрес.Так что вам нужно только авторизовать пользователя на Django, чтобы получить подписанный URL, и все.Он не должен быть «авторизован» в облачном хранилище (поскольку URL-адрес уже делает это)

Взято из документов, на которые ссылались ранее:

Когда следует использовать подписанный URL-адрес?

В некоторых случаях вам может не потребоваться, чтобы у ваших пользователей была учетная запись Google для доступа к облачному хранилищу, но вы все равно хотите контролировать доступ с помощью логики, специфичной для приложения.Типичным способом решения этого варианта использования является предоставление пользователю подписанного URL-адреса, который дает пользователю возможность чтения, записи или удаления доступа к этому ресурсу в течение ограниченного времени.Любой, кто знает URL, может получить доступ к ресурсу до истечения срока действия URL.Вы указываете срок действия в строке запроса для подписи.

0 голосов
/ 21 марта 2019

Исходя из ответа Науэля Варелы:

Моя система теперь состоит из 4 блоков:

  • static
  • media
  • static-staging
  • media-staging

Обе статические корзины являются общедоступными, а медиа-корзины доступны только для учетной записи службы обработчика приложений , созданной в проекте.(Настройки для dev / test разные)

Я использую django-storages[google] с модификацией @ elnygrens .Я изменил это, чтобы удалить метод url для мультимедиа (чтобы мы создавали подписанные URL-адреса), но оставил его для статического (чтобы мы обращались к общедоступному URL-адресу статических файлов).

Аутентификация каждогодоступ к файлу осуществляется в Django, и если пользователь проходит тест (is_staff или id соответствует идентификатору файла), то ему предоставляется доступ к файлу в течение заданного промежутка времени (в настоящее время 1 час), этот доступ обновляется, когда страницанагрузки и т. д.

Последующий вопрос: Какова наилучшая практика для этого ограничения времени, я слышал, что люди используют где-то от 15 минут до 24 часов?

...