Управление доступом к службам AWS для клиентов iOS и на серверных серверах

Ответ 1

Хотя есть много сценариев, когда вы, возможно, захотите сделать это в любом случае в общем, вряд ли есть случаи, когда вы захотите сделать это прямо от клиента, так как вы упомянули ios:

Плюсы для загрузки данных с сервера на AWS:

• Безопасность

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

• Ограничение скорости, пользовательские квоты и т.д.

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

• Аудит трейла

  Если вам нужно отслеживать, кто загрузил что-то, когда, откуда и какая такая информация, это снова намного проще отслеживать, если вы получите первоначальный запрос непосредственно на своем сервере.

• Обработка исключений при сбое

  Вполне возможно иметь сбои, которые вы не могли бы легко предсказать, или пропустить критическую ошибку во время тестирования QA. Обработка этой серверной части намного эффективнее, потому что она находится под вашим контролем. Когда какие-либо проблемы возникают на стороне клиента, вы можете себе позволить, чтобы ваши клиенты могли обновить приложение. Если вы имеете дело с этой серверной стороной, дополнительные проверки могут быть легко размещены/развернуты для многих таких ошибок, что ограничивает область ошибок.

• Время в прямом эфире

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

Единственные случаи, когда я думаю, что вы хотите загрузить данные непосредственно с клиентской стороны в AWS, будут

• Загрузка больших объемов данных очень, очень часто, без прямой обработки.

  Если загрузка однажды требует определенного объема полосы пропускания и сетевых ресурсов, загрузка дважды требует удвоения ресурсов (один раз от client --> server, затем от server --> AWS). Поэтому, если вы часто загружаете большое количество данных (ежедневно думайте о туберкулезе), вы теряете много ресурсов, просто копируя данные из одной точки в другую. В таких случаях имеет смысл напрямую передавать данные S3. Но для такого подхода к работе ваша экономия средств должна быть достаточно высокой, чтобы переопределить проблемы безопасности и конфиденциальности, а для большинства приложений это просто не так.

• Вы находитесь в огороженном саду

  В принципе, приложение работает только для определенных предварительно определенных пользователей, приложение просто не работает для кого-либо еще (скажем, вы разрабатываете это для домашнего использования в корпоративном). По сути, это означает, что у вас есть 100% -ная уверенность в мотивах конечного пользователя, чтобы использовать ваше приложение.

EDIT: OP запрашивает комментарии

Как насчет сервера, предоставляющего подписанный URL/cookie, и клиент использует их для загрузки на S3 или загрузки из Cloudfront. Клиент по-прежнему напрямую взаимодействует с AWS, но требует разрешений, контролируемых сервером.

На первый взгляд, мне кажется, что это очень эффективно. Это сообщение в блоге предоставляет множество вариантов использования (например, предоставление подстановочных подписей для чтения) с использованием подписанных URL-адресов (хотя примеры находятся в .NET) и более подробная информация доступна по адресу Документация AWS.

Поскольку вы собираетесь обрабатывать сервер подписи, вы можете легко позаботиться о каждом из пунктов, о которых я упоминал ранее в своем сообщении (ограничение скорости, пользовательские квоты, контрольный журнал и т.д. все работоспособны, так как запрос сначала будет отправлен на сервер). Как этот ответ упоминает,

Подписанные URL-адреса помогают контролировать, кто может получить доступ к данному файлу и как долго они могут получить к нему доступ.

В целом, это должно хорошо работать в довольно многих случаях.

Ответ 2

Безопасность - основная причина, по которой я установил всю/большую часть аутентификации службы AWS в фоновом режиме после того, как вы аутентифицировали пользователя.

Еще одно соображение - это время, необходимое для обновления вашего приложения в Apple Store с учетом процесса их утверждения. В зависимости от очереди магазина Apple может потребоваться несколько дней, чтобы вы могли внести изменения в свое приложение; изменения в AWS-back-end могут быть выполнены по желанию.

Кроме того, при разработке приложения для взаимодействия с службами AWS я всегда предполагаю, что что-либо переданное может быть скомпрометировано и, скорее всего, будет использоваться людьми, которые деконструировали ваши звонки и реконструировали свои собственные, чтобы удовлетворить их потребности.

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

Надеюсь, что это поможет.

Ответ 3

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

Вы можете, конечно, выбрать механизм принудительного обновления в приложении, где вы не сможете его использовать до тех пор, пока не будете обновлены (это распространено в многопользовательских играх, но не во многих других местах) или просто не заботятся о меньшинство пользователей старых версий вашего приложения, чья жизнь вы делаете несчастной (закручивание сюжета - они могут застрять на старой версии вашего приложения, потому что их устройство не может быть обновлено до последней версии iOS).

Но лучшее решение IMO - это скрыть URL-адреса AWS за вашими собственными серверами, поэтому вы никогда не сталкиваетесь с этой проблемой. Это деталь реализации, которую вы действительно не должны течь в клиенте.

Ответ 4

В целях безопасности важно, чтобы ваши ключи находились в том месте, где их нельзя подделать: обычно это означает, что они оставляют их на сервере.

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

Вы также указываете загрузки на S3. AWS имеет хороший объект, называемый назначенным пост, где ваш сервер генерирует одноразовые учетные данные загрузки, которые ваше мобильное устройство может использовать для загрузки данных на S3, без проксирования данных через ваш сервер.

Пример Ruby code:

presigned_post = bucket.presigned_post(key: key, success_action_status: 201, acl: :public_read)