Могу ли я создать ключи AWS для каждого пользователя, срок действия которых истекает каждые 2 недели?

Моя компания использует AWS для вычислений, хранения, баз данных и многого другого. Однако они используют корневой ключ для доступа ко всему, и я пытаюсь отойти от этого в целях безопасности. Любая утечка может привести к катастрофическим утечкам данных или снижению счетов от AWS. Я хотел бы предотвратить это насколько возможно, разрешив ключи (я знаю, как это сделать) и установив автоматический срок действия ключей через x недель.

Я провел небольшое исследование и не нашел ничего идеального. самое близкое, что я нашел, это следующее. (Мы используем Azure для авторизации пользователей в AWS). Это инструмент, который позволяет aws cli получить доступ к aws путем авторизации через azure: https://github.com/dtjohnson/aws-azure-login

Вышеуказанное дает ежедневную авторизацию через cli для доступа к определенным частям AWS. Однако это не совсем то, что мы хотим. Руководство предпочитает более длительные сроки действия для удобства, и нам нужны реальные ключи, чтобы иметь возможность использовать такой инструмент, как Cyberduck, и запускать экземпляры в AWS и т. Д.

Можно ли создавать ключи пользователем, срок действия которых истекает каждые X недель и требует новый запрос на ключ?

3
задан 5 September 2019 в 22:49
2 ответа

Пользователь root

У пользователя root должен быть включен MFA, затем запереть его и никогда не использовать. Никогда не создавайте ключи доступа для пользователя root.

Администратор IAM

Создайте пользователя-администратора IAM с необходимым MFA, который имеет полные права, включая биллинг.

Политика и группы IAM

Затем создайте политику IAM, которая дает доступ пользователей к службам и функциям, которые им разрешено использовать. Политика должна требовать, чтобы MFA использовался для всех функций, кроме разрешения IAM для установки MFA. Присоедините эту политику к группе. Вы можете создать столько политик и групп, сколько вам нужно. Вы можете дополнительно заблокировать вещи с помощью политик управления службами, если видите какие-либо преимущества. Вы можете делать такие вещи, как принудительное использование регионов и предотвращение использования дорогостоящих ресурсов (например, экземпляров GPU или RedShift / RDS) в IAM или SCP.

Федерация или пользователи IAM

Теперь либо объедините свои учетные записи в локальную сеть. Active Directory или создайте пользователей IAM и добавьте их в группу. Не добавляйте политики пользователям напрямую. У этих пользователей могут быть ключи доступа, но они также подлежат MFA.

Ссылки федерации: один , два . Ключевой поисковый запрос - «Федерация AWS Active Directory».

Две недели

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

Результат

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

6
ответ дан 3 December 2019 в 04:52

НЕ ИСПОЛЬЗУЙТЕ ключ доступа для своего пользователя root учетной записи AWS. Используйте пользователей IAM для повседневного взаимодействия с AWS. Теперь это исключено ...

Использование временных учетных данных безопасности

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

Обычно ключи доступа остаются действительными до тех пор, пока вы не отзовете их вручную. Однако временные учетные данные безопасности, полученные с помощью ролей IAM и других функций AWS Security Token Service, истекают через короткий период времени.

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

4
ответ дан 3 December 2019 в 04:52

Теги

Похожие вопросы