Хранение секретного ключа в секрете с помощью Amazon Web Services

Я играю с использованием веб-сервисов Amazon в своем личном проекте. Я взял их AWS SDK для .NET и использую его, но немного запутался.

  1. Доступ к веб-службе (в данном случае SimpleDB, хотя я не думаю, что это действительно важно для вопроса) авторизуется через пару закрытый/открытый ключ.

  2. Для AWS SDK для .NET API, используемого для создания клиентского объекта, требуется закрытый ключ:

    AWSClientFactory.CreateAmazonSimpleDBClient(publicKey, privateKey);

  3. Это клиентское приложение, поэтому код будет полностью выполняться на клиенте.

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

Это не имеет смысла для меня, поэтому я полагаю, что я что-то упускаю.

Является ли клиентское приложение неправильной моделью для веб-сервисов Amazon в целом, для использования их AWS SDK для .NET, или я упускаю что-то, что делает клиентское приложение вполне разумным? Есть ли хороший способ обойти это без создания собственного прокси-сервиса, который бы аутентифицировал клиентов и перенаправлял их запросы в SimpleDB?


amazon-web-services c# security secret-key
person Greg D    schedule 10.02.2010    source источник

Ответы (1)


arrow_upward
6
arrow_downward

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

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

person Yetanotherjosh    schedule 13.05.2010
comment
Я ценю ответ. Я работаю в основном в настольном мире, поэтому возможность аутентификации и предоставления подписанного URL-адреса и заголовков даже не приходила мне в голову. - person Greg D; 13.05.2010
comment
Если вы пойдете по этому пути, можно ли по-прежнему использовать .NET API? - person Maurice Flanagan; 13.10.2010
comment
Ответ на мой собственный вопрос: нет, вам нужно изменить код для удаленного вызова AWSSDKUtils.HMACSign. - person Maurice Flanagan; 18.10.2010