#javascript #amazon-s3 #encryption #pre-signed-url
Вопрос:
Я долго искал, но не вижу, чтобы у кого-то были сценарии ниже, поэтому очень признателен, если кто-то может помочь.
Мы хотим загрузить большой файл, используя URL-адрес с подписью S3, но мы используем шифрование на стороне клиента, используя KMS, по соображениям безопасности, для загрузки файла.
Один из вариантов-использовать AWS Encryption SDK для шифрования файла в браузере, загрузки в серверную часть S3, а затем расшифровать его в браузере после получения файла по указанному URL. Но меня беспокоит раскрытие учетных данных в браузере пользователя. В документах AWS https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/js-examples.html()
Начните с предоставления своих учетных данных браузеру. Пакет SDK AWS для шифрования для примеров JavaScript использует веб-пакет.Определите плагин, который заменяет константы учетных данных вашими фактическими учетными данными. Но вы можете использовать любой метод для предоставления своих учетных данных. Затем используйте учетные данные для создания клиента AWS KMS.
- У тебя есть какое-нибудь решение для этого ?
- При использовании AWS SDK, в любом случае, чтобы избежать раскрытия учетных данных, если пользователи используют F12 ?
Ответ №1:
Но меня беспокоит раскрытие учетных данных в браузере пользователя.
При использовании шифрования на стороне клиента предполагается, что зашифрованный секрет является случайным и уникальным/специфичным для содержимого (с использованием шифрования конверта).
Поэтому, если клиент имеет право на контент (для загрузки), то может быть нормально предоставить клиенту ключ для расшифровки контента (вы можете рассматривать ключ как часть контента) . Ключ (ключ данных) не должен использоваться для расшифровки чего-либо еще.
Комментарии:
1. Да, глядя на этого дока: docs.aws.amazon.com/encryption-sdk/latest/developer-guide/… , знаете ли вы, почему у AWS есть способ — использовать KMS для шифрования. Разве они не боятся, что секретный ключ/ключ доступа будет раскрыт ?
2. @futurexv зависит от.. Я имею в виду — при работе с криптографией нужно быть очень осторожным с тем, что отправляется клиенту. Клиенту нужен ключ шифрования данных для содержимого. Действительно, я был бы обеспокоен, в примерах используются временные учетные данные сеанса. Это может быть безопасно, когда учетные данные ограничены конкретными операциями (например, расшифровкой зашифрованного ключа) и временными (после принятия роли или удостоверения)
3. да, учетные данные ограничены конкретными операциями. Но дело в том, что я не знаю, почему AWS предложил способ, которым секретный ключ/ключ доступа раскрывается в JS, который пользователи могут увидеть, если они попытаются найти в уродливом/уменьшенном JS