Кто такие пользователи AWS IAM и как вы ими управляете?

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

Вы должны использовать пользователей IAM

Ответ: определенно не использовать ваши ключи корневого доступа — это самые важные токены в вашем аккаунте, и они могут обойти любое настроенное вами устройство многофакторной аутентификации. (На самом деле вы можете настроить доступ к API, защищенный MFA, но не для учетной записи root.)

AWS предоставляет сервис для решения этой проблемы. Консоль «Управление идентификацией и доступом» (IAM) позволяет создавать дочерних пользователей отдельно от вашей корневой учетной записи. Это могут быть либо сервисные пользователи с доступом к API, либо полноправные учетные записи пользователей (с доступом к Консоли управления AWS), которые можно использовать для учетных записей сотрудников.

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

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

Как настроить пользователей IAM

В консоли управления IAM щелкните вкладку «Пользователи» и выберите «Добавить пользователя».

Дайте ему имя, затем выберите способ доступа этого пользователя к AWS. Программный доступ дает вам идентификатор ключа доступа и секретный ключ доступа, используемые для аутентификации с помощью AWS API и CLI.

Доступ к консоли управления позволяет пользователю получить доступ к веб-консоли, которую вы включаете, если предоставляете доступ сотруднику. Если вы настраиваете это, AWS по умолчанию предоставляет автоматически сгенерированный пароль и заставляет сотрудника изменить его при входе в систему.

Вы можете предоставить оба типа доступа, если хотите.

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

На самом деле, мы не рекомендуем использовать большинство из этих готовых политик. Вы действительно не хотите предоставлять «Полный доступ» какой-либо отдельной службе, а другой альтернативой обычно является «Только чтение», что, вероятно, само по себе недостаточно доступа. Некоторые из более тонко настроенных разрешений хороши, но вам действительно следует создать свои собственные.

Вы быстро поймете, почему «Полный доступ» — плохая идея. Допустим, вы настраиваете сервер, которому требуется доступ к S3 и загрузка объектов. Возможно, вы захотите предоставить ему доступ «Запись», но это также позволяет этому пользователю удалять целые сегменты, что совсем не идеально. Лучшее решение — предоставить разрешение «PutObject», которое позволяет выполнять запросы PUT.

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

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

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

Замените корневую учетную запись на пользователя IAM

AWS настоятельно рекомендует это для учетных записей организаций. Вместо использования вашей корневой учетной записи для таких вещей, как ваш личный CLI, вы должны создать пользователя IAM «Администратор» с доступом к консоли управления и использовать токен доступа от него для аутентификации вашего личного терминала.

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

При такой настройке единственное, для чего вы используете свою корневую учетную запись, — это сверхбезопасные вещи, которые напрямую связаны с вашей корневой учетной записью, такие как обслуживание учетной записи и выставление счетов. Для всего остального достаточно прав администратора, и вы можете фактически удалить свои ключи корневого доступа, чтобы вы могли получить доступ к учетной записи root, только выполнив вход вручную (и пройдя MFA).