Влияние идентификаторов учетной записи AWS

17

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

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

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

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

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

Как я могу свести к минимуму ущерб одного взломанного хоста?

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

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

Кто-нибудь имел дело или, по крайней мере, думал об этой проблеме?

    
задан Gary Richardson 25.09.2008 в 00:09
источник

4 ответа

5

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

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

    
ответ дан davr 25.09.2008 в 19:20
  • «Роллинг собственного» сервера аутентификации такого рода может привести к неожиданным и незаметным недостаткам безопасности. AWS теперь (но не назад, когда это было впервые задано) имеет возможности для управления рисками из вопроса. В частности, роли IAM (как описано в ответе @ cudds) хорошо подходят для этой проблемы. –  Charles Engelke 22.06.2013 в 15:27
5

AWS позволяет создавать несколько пользователей с Identity and Access Management . Это позволит вам реализовать любой из ваших сценариев.

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

    
ответ дан BenM 23.06.2011 в 08:51
  • Да, IAM - это путь. Разрешения IAM могут быть дополнительно уточнены только для того, что должен делать конкретный экземпляр (загрузка или чтение данных из очень конкретного ведра и т. Д.). –  Daniel Lopez 09.08.2011 в 12:40
  • Спасибо за комментарии Daniel, я обновил ответ, чтобы включить ваше предложение. –  BenM 09.08.2011 в 19:05
  • Теперь, когда роли доступны, они являются лучшим выбором, чем пользователи IAM для этой проблемы. –  Charles Engelke 22.06.2013 в 15:20
3

Кроме того, роли AWS IAM позволяют назначать разрешения для экземпляра EC2 вместо того, чтобы размещать ключи в экземпляре. См. Сообщение в блоге Ссылка Большинство SDK используют временные ключи, созданные ролями.

    
ответ дан cudds 22.06.2013 в 07:16
1

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

Ссылка

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

    
ответ дан Erik Osterman 07.09.2010 в 18:40