Хранение учетных данных AWS во внешнем интерфейсе

Question

Я пытаюсь достать свои объекты изображений из S3, из моего внешнего приложения JavaScript.

Согласно документации, необходимо выполнить следующие шаги:

import * as AWS from "aws-sdk";

AWS.config.update({accesKeyId, secretAccesKey, region});

let s3 = new AWS.S3();

И затемВы можете получить объекты примерно так:

function listObjects(bucketName, folderName) {
  return new Promise((resolve) => {
    s3.listObjects({Bucket: bucketName, Prefix: folderName}).promise()
      .then((data) => {
        resolve(data.Contents);
      })
  });
}

Кажется, что все работает правильно, но меня беспокоит то, что мне также нужно сохранить accessKeyId и secretAccessKey в моем приложении для доступа кведро.

Как защитить хранилище или получить доступ к объектам без предоставления этих конфиденциальных данных?

Answer 1

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

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

• , еслиобъекты чувствительны , тогда у вас уже есть какая-то система аутентификации для ваших пользователей.Если вы используете для авторизации учетные записи Oauth (Google, Amazon, Facebook и т. Д.), Вы можете использовать AWS Cognito для создания недолговечных учетных данных AWS, связанных с этим пользователем, что позволит вам различать разрешения между пользователями ... этодовольно гладкий и отлично подходит, если уже используется oauth.Если вы не используете OAUT, подумайте, следует ли вам.Это гораздо безопаснее, чем настраивать собственный уровень авторизации для своих пользователей.https://aws.amazon.com/cognito/

• Если вы не хотите или не можете использовать Cognito, вы все равно можете взять на себя роль AWS из бэкэнда и генерировать временные учетные данные, которые автоматически истекают в любом месте от 15 минут до 1.час или более, а затем передать эти учетные данные в интерфейс.Я бы назвал это «когнитивным бедняком», но я думаю, что на самом деле запуск инфраструктуры для предоставления услуги дороже, чем затраты на когнито.

• Или, как предлагает @Tomasz Swinder, вы можете просто прокси-запросы через ваше приложение, разрешая ресурс, который пользователь запрашивает на ресурсе s3, и перетаскивая его в свой бэкэнд, а затем обслуживаяваш пользователь.В большинстве случаев это плохое решение, поскольку ваши серверы находятся дальше от конечного пользователя, чем, вероятно, будут конечные точки s3.И вы должны запустить инфраструктуру для прокси.Но, как уже было сказано, это имеет свое место.

• Наконец, предварительно подписанные URL-адреса s3 могут хорошо подойти для вашего приложения.Обычно бэкэнд подписывает URL-адреса s3 непосредственно перед тем, как предоставить их пользователю.Подпись достаточна для авторизации операции (которая может быть PUT или GET), но сама по себе не содержит закрытый ключ, используемый для подписи - другими словами, предопределенные URL предоставляют авторизованный URL, но не используемые учетные данныеавторизовать их, так что это отличный способ предоставить специальную авторизацию для s3.

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

Также имейте в виду, что LISTing для объектов s3 намного медленнее и намного дороже (все еще дешевый за операцию, но в 10 раз), чем GETing для объектов s3, поэтому обычно лучше по возможности избегать вызова lIST.Я просто добавляю это, я подозреваю, что вы просто делаете это, чтобы проверить соединение s3.

Answer 2

Один из методов, который мы используем, - это сохранение учетных данных в файле .env и использование dotenv (https://github.com/motdotla/dotenv) для чтения в переменных. Затем к ним можно получить доступ через process.env. Например, файл .env.будет содержать:

AWSKEY=1234567abcdefg
AWSSECRET=hijklmn7654321
REGION=eu-west

Затем в вашем коде вы будете вызывать require('dotenv').load() для чтения переменных среды. Затем вы будете обращаться к ним как:

AWS.config.update({process.env.AWSKEY, process.env.AWSSECRET, process.env.REGION});

Убедитесь, что .envфайл не передан в ваш репозиторий. Если вы хотите, вы можете иметь env.example и инструкции о том, как создать .env при создании dev или производственной установки.

Что касается защиты корзины, вы можетесделать это, ограничив доступ на чтение / запись для пользователя IAM, которому принадлежит пара ключ / секрет AWS.

Answer 3

Не могли бы вы запросить это через ваш сервер?или это статический сайт?

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