Влияние идентификаторов аккаунта AWS - PullRequest
17 голосов
/ 25 сентября 2008

Я использую инструменты Amazon для создания веб-приложения. Я очень доволен ими, но у меня есть проблема с безопасностью.

Сейчас я использую несколько экземпляров EC2, S3, SimpleDB и SQS. Чтобы аутентифицировать запросы к различным службам, вы включаете свои идентификаторы доступа (требуется вход в систему).

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

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

Если один из моих экземпляров будет взломан, все мои активы Amazon будут взломаны. С помощью клавиш можно загружать / заменять данные S3 и SimpleDB, запускать и останавливать экземпляры EC2 и т. Д.

Как можно минимизировать повреждение одного скомпрометированного хоста?

Моя первая мысль - получить несколько идентификаторов для каждой учетной записи, чтобы я мог отслеживать внесенные изменения и быстро отзывать «взломанную» учетную запись. Amazon не поддерживает более одного набора учетных данных для каждой учетной записи.

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

Кто-нибудь имел дело или хотя бы думал об этой проблеме?

Ответы [ 4 ]

5 голосов
/ 23 июня 2011

AWS позволяет создавать нескольких пользователей с Управление идентификацией и доступом . Это позволит вам реализовать любой из ваших сценариев.

Я бы предложил определить пользователя IAM для каждого экземпляра EC2, это позволяет вам аннулировать доступ к определенному пользователю (или только его ключам доступа), если соответствующий экземпляр EC2 скомпрометирован, а также использовать детальные разрешения для ограничения того, какие API пользователь может позвонить и к каким ресурсам он может получить доступ (например, разрешить пользователю загружать данные только в определенное место).

5 голосов
/ 25 сентября 2008

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

Это возможно из-за способа аутентификации AWS. Скажем, ваш веб-сервер должен загрузить файл на S3. Сначала он сгенерирует запрос AWS и отправит этот запрос вместе с вашим пользовательским ключом сервера на «сервер аутентификации». Сервер аутентификации аутентифицирует запрос, выполняет крипто-магию и возвращает аутентифицированную строку обратно на веб-сервер. Затем веб-сервер может использовать это для фактической отправки запроса вместе с файлом для загрузки на S3.

3 голосов
/ 22 июня 2013

Более того, роли AWS IAM позволяют вам назначать разрешения для экземпляра EC2, а не помещать ключи в экземпляр. Смотрите сообщение в блоге на http://aws.typepad.com/aws/2012/06/iam-roles-for-ec2-instances-simplified-secure-access-to-aws-service-apis-from-ec2.html В большинстве SDK используются временные ключи, созданные ролями.

1 голос
/ 07 сентября 2010

AWS предлагает «Консолидированный биллинг», который решает вашу проблему во второй мысли.

https://aws -portal.amazon.com / зм / AWS / разработчик / счет / index.html? Т = UTF8 & действие = консолидированы биллинга

«Консолидированный биллинг» позволяет консолидировать платежи за несколько учетных записей Amazon Web Services в вашей компании, назначив одну платёжную учетную запись. Вы можете увидеть комбинированное представление расходов AWS, понесенных всеми учетными записями, а также получить подробный отчет. отчет о затратах для каждой отдельной учетной записи AWS, связанной с вашей платной учетной записью. Консолидированный биллинг также может снизить общие затраты, поскольку сводное использование по всем вашим учетным записям может помочь вам быстрее достичь более дешевых уровней объема. "

...