Следует ли использовать пользователей IAM или организации AWS?

Существует два основных способа управления доступом сотрудников к учетной записи AWS вашей компании: пользователи IAM и организации AWS. У обоих есть свое применение, но важно подчеркивать различия при планировании структуры разрешений AWS.

Краткий ответ: Оба, на самом деле

Какой из них вы должны использовать? Ответ один: пользователи IAM и организации AWS делают разные вещи. Несмотря на внешнее сходство, они предназначены для разных целей.

Пользователи IAM — отличный способ управлять доступом для сотрудников. Они позволяют вам аутентифицировать сотрудников в «дополнительной учетной записи» с ограниченными разрешениями. Эта система управления разрешениями имеет решающее значение для сегментирования доступа сотрудников к вашим ресурсам AWS.

Пользователи IAM также используются для аутентификации учетных записей служб. Например, если у вас есть интерфейс командной строки AWS, работающий на экземпляре EC2, и вы хотите предоставить ему доступ для управления корзиной S3, вы можете сделать это с помощью пользователя IAM, чтобы вам не приходилось оставлять учетные данные корневой учетной записи на удаленный сервер.

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

Основная проблема заключается в том, что по умолчанию вы ограничены четырьмя учетными записями. Хотя вы можете запросить увеличение лимита, он здесь не просто так: все аккаунты вашей организации полностью разделены. Это означает, что если бы у вас был разработчик, работающий над таблицей DynamoDB в своей учетной записи, он был бы невидим для всех остальных сотрудников.

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

• Используйте AWS Organizations и создайте отдельные аккаунты для разработки и производства. Это снимает нагрузку с ваших разработчиков и позволяет вам давать им более мягкие разрешения в среде разработки, не опасаясь, что они могут испортить ваши производственные серверы.
• Вы также можете создать еще две среды: тестовую, содержащую чистые фиктивные данные и используемую группой QE для запуска автоматизированных сборок; и промежуточный этап — полное зеркало рабочей среды, используемое для обнаружения любых ошибок, которые могут возникнуть с использованием общедоступных API и реальных данных, до того, как они действительно повлияют на клиентов.
• В среде разработки создайте несколько пользователей IAM, чтобы предоставить своим сотрудникам управляемый доступ.
• Повторите тот же процесс для группы контроля качества при тестировании и для руководителей проектов и архитекторов решений при подготовке. Продукт должен обновляться только уполномоченными лицами и, конечно же, содержать сервисные аккаунты IAM, необходимые для правильной работы.

Эта структура сочетает в себе преимущества обоих типов учетных записей, и, похоже, AWS хочет, чтобы вы ее настроили, учитывая правило четырех учетных записей (по умолчанию) организации AWS.