Моя компания использует AWS для вычислений, хранения, баз данных и многого другого. Однако они используют корневой ключ для доступа ко всему, и я пытаюсь отойти от этого в целях безопасности. Любая утечка может привести к катастрофическим утечкам данных или снижению счетов от AWS. Я хотел бы предотвратить это в максимально возможной степени, разрешив ключи (я знаю, как это сделать) и установив автоматический срок действия ключей через x недель.
Я провел небольшое исследование и не нашел ничего идеального. самое близкое, что я нашел, это следующее. (Мы используем Azure для авторизации пользователей в AWS). Это инструмент, который позволяет aws cli получать доступ к aws путем авторизации через azure: https://github.com/dtjohnson/aws-azure-login
Вышеупомянутое дает нам ежедневную авторизацию через cli для доступа к определенным частям AWS. Однако это не совсем то, что мы хотим. Руководство предпочитает более длительные периоды истечения срока действия для удобства, и нам нужны реальные ключи, чтобы иметь возможность использовать такой инструмент, как Cyberduck, и запускать экземпляры в AWS и т. Д.
Можно ли создавать ключи пользователем, срок действия которых истекает каждые X недель и для которых требуется новый запрос ключа?
Корневой пользователь
Пользователь root должен включить MFA, затем заблокировать его и никогда не использовать. Никогда не создавайте ключи доступа для пользователя root.
Администратор IAM
Создайте пользователя-администратора IAM с обязательным MFA, который имеет полные права, включая биллинг.
Политика и группы IAM
Затем создайте политику IAM, которая дает пользователям доступ к службам и функциям, которые им разрешено использовать. Политика должна требовать, чтобы MFA использовался для всех функций, кроме разрешения IAM для установки MFA. Присоедините эту политику к группе. Вы можете создать столько политик и групп, сколько вам нужно. Вы можете дополнительно заблокировать вещи с помощью политик управления службами, если видите какие-либо преимущества. Вы можете делать такие вещи, как принудительное использование регионов и предотвращение использования дорогостоящих ресурсов (например, экземпляров GPU или RedShift / RDS) в IAM или SCP.
Пользователи Федерации или IAM
Теперь либо объедините свои учетные записи в активный каталог на месте, либо создайте пользователей IAM и добавьте их в группу. Не добавляйте политики пользователям напрямую. У этих пользователей могут быть ключи доступа, но они также подлежат MFA.
Ссылки федерации: один, два. Ключевой термин поиска - «Федерация AWS Active Directory».
Две недели
Я подозреваю, что двухнедельный запрос - отвлекающий маневр. После того, как вы правильно настроите всех своих пользователей, вам не нужно так часто менять ключи доступа - скорее всего, каждые несколько месяцев, а может быть, и до года.
Результат
Все это дает вам хороший контроль над вашей учетной записью, позволяет отслеживать, кто что делал (убедитесь, что Cloud Trail включен, а корзина защищена), снижает подверженность хакерам, увеличивая счет, и, возможно, другие преимущества.
НЕ ИСПОЛЬЗУЙТЕ ключ доступа для пользователя root вашей учетной записи AWS. Используйте пользователей IAM для повседневного взаимодействия с AWS. Теперь это не мешает ...
Вы можете создавать роли IAM, а не пользователей, и создавать временные учетные данные безопасности. У них есть идентификатор ключа доступа, секретный ключ доступа и маркер безопасности, который указывает, когда истекает срок действия учетных данных.
Обычно ключи доступа остаются действительными, пока вы не отзовете их вручную. Однако временные учетные данные безопасности, полученные с помощью ролей IAM и других функций AWS Security Token Service, истекают через короткий период времени.
В вашем примере, где речь идет об экземплярах или сценариях CLI, а не о передаче или внедрении ключа доступа в приложение, определите роль IAM, которая имеет соответствующие разрешения для вашего приложения, и запустите экземпляр Amazon EC2 с ролями для EC2. Это связывает роль IAM с экземпляром Amazon EC2 и позволяет приложению получать временные учетные данные безопасности, которые оно, в свою очередь, может использовать для выполнения вызовов. Интерфейс командной строки может автоматически получать временные учетные данные от роли.