Сравнение пользователей AWS IAM. Роли IAM: какую из них следует использовать?

И пользователи, и роли IAM позволяют управлять доступом к ресурсам AWS с помощью определенных наборов разрешений, но на практике эти два типа доступа IAM используются по-разному. В этой статье мы объясним различия и как их использовать.

Пользователи являются внешними (используются для людей)

Фундаментальное различие между пользователями IAM и ролями заключается в том, откуда разрешен доступ.

• Пользователи IAM разрешают внешний доступ к вашим ресурсам AWS. Эти ресурсы используются для предоставления сотрудникам доступа к Консоли управления AWS и для аутентификации интерфейса командной строки, работающего на их компьютерах. Пользователи IAM предоставляют прямой доступ к службам с использованием заданных токенов безопасности.
• Роли IAM предназначены только для внутреннего использования, и их можно назначать таким вещам, как экземпляры EC2 и функции Lambda, чтобы они могли эффективно выполнять свою работу. Роли сами по себе не предоставляют никакого доступа, но они позволяют службам действовать так, как будто у них есть определенные разрешения.

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

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

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

Однако на практике пользователи представляют несколько проблем. Во-первых, для аутентификации приложения, работающего на EC2, вы должны оставить ключи доступа на этом экземпляре. Это не так плохо, как оставить ключи корневого доступа, но это все еще проблема безопасности, которая не должна существовать. Проблема становится особенно серьезной, если учесть, что это может позволить сотрудникам повысить свои привилегии; если приложение работает с более высокими привилегиями и хранит свои ключи на диске, сотрудник может украсть и использовать эти ключи, что не идеально.

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

Роли должны выполняться уполномоченными лицами

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

Например, распространенная проблема заключается в том, что службы аутентификации должны иметь возможность загружать объекты в S3. Вместо создания учетной записи пользователя, которая оставила бы секретные ключи на вашем сервере EC2 (и любых настроенных вами AMI) и разрешила внешний доступ, вы вместо этого создаете роль, которая разрешает доступ к S3, например «S3Uploader».

Вы можете назначить эту роль функции Lambda, позволяющей ей помещать объекты в вашу корзину, или вы можете назначить ее непосредственно экземпляру EC2. Службе, которой назначена роль, затем разрешается доступ к предоставленным ей ресурсам, но это не представляет угрозы безопасности. Многие сервисы AWS по умолчанию создают роли для работы, поэтому в вашей IAM-консоли их уже может быть несколько.

Роли также могут использоваться пользователями для включения управляемого повышения привилегий. Сотрудник может взять на себя роль (которая зарегистрирована в CloudTrail), предоставив ему разрешения этой роли на короткое время. Это позволяет пользователю запрашивать краткосрочные учетные данные у AWS STS, что более безопасно, чем прикрепление разрешений непосредственно к ключам доступа пользователя.

Добавление ролей к экземплярам EC2 очень полезно. Вы можете добавить роль к экземпляру из консоли управления EC2, щелкнув экземпляр правой кнопкой мыши и выбрав «Настройки экземпляра» > «Прикрепить/заменить роль IAM»:

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

Интерфейс командной строки AWS автоматически использует роль для данного экземпляра, поэтому особых настроек не требуется. Если вы хотите вручную переключиться на роль, вы можете сделать это с помощью команды assume-role :

aws sts assume-role --role-arn "arn:aws:iam::123456789012:role/example-role" --role-session-name AWSCLI-Session

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