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

Question

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

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

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

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

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

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

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

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

С кем связано или, по крайней мере, подумал об этой проблеме?

Answer 1

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

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

Answer 2

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

https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=consolidated-billing

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

Answer 3

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

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

Answer 4

Кроме того, роли 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 используют временные ключи, созданные ролями.