Лучшие практики безопасности AWS IAM

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

“Безопасность – это работа номер ноль”.

Когда речь заходит о безопасности в AWS, это де-факто культура и стандарт.

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

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

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


Содержание
  1. 1 Краткий обзор AWS IAM
  2. 1.1 Что такое IAM
  3. 1.2 Идентификаторы IAM: Пользователи, группы, роли
  4. 1.3 Политики IAM
  5. 2 Принципы безопасности
  6. 2.1 Нулевое доверие
  7. 2.2 Наименее привилегированный доступ
  8. 3 Сокращение операционных расходов на IAM
  9. 3.1 Централизованный IAM
  10. 3.2 DevSecOps – автоматизируйте все
  11. 4 Базовая настройка
  12. 4.1 НЕ используйте корневого пользователя
  13. 4.2 Включите многофакторную аутентификацию (MFA)
  14. 4.3 Используйте строгую политику паролей
  15. 4.4 Используйте роли IAM вместо долгосрочных ключей доступа
  16. 4.5 Регулярно меняйте учетные данные
  17. 4.6 Удалите устаревшие и ненужные учетные данные
  18. 5 Группы
  19. 6 Роли
  20. 6.1 Использование ролей для делегирования прав доступа
  21. 6.2 Использование ролей для приложений на EC2-установках
  22. 7 Политики
  23. 7.1 Управляемые политики AWS
  24. 7.2 Политики, управляемые клиентом, лучше встроенных политик (для большинства случаев)
  25. 7.3 Дополнительная безопасность: Условия политики
  26. 7.4 Проверка политик
  27. 7.5 Генерирование политики на основе активности доступа
  28. 7.6 Использование уровней доступа для проверки разрешений IAM
  29. 8 Управление доступом точно в срок
  30. 9 Мониторинг и аудит
  31. 9.1 Планирование аудита доступа
  32. 9.2 Информация о последнем доступе
  33. 9.3 Мониторинг действий
  34. 9.4 Другие службы AWS, которые могут помочь
  35. Резюме

1 Краткий обзор AWS IAM

В этом разделе представлен краткий обзор AWS IAM и некоторых его терминов.

Если вы уже хорошо знакомы с AWS IAM, смело переходите к следующему разделу. Если вы новичок в AWS и IAM, рекомендуем прочитать официальную документацию и поиграть с ней в среде “песочницы”.

1.1 Что такое IAM

AWS Identity and Access Management (IAM) обеспечивает тонкий контроль доступа во всей AWS. С помощью IAM вы можете определить, кто и при каких условиях может получить доступ к каким службам и ресурсам.

Она обеспечивает две важные функции, которые работают вместе:

  • Аутентификация (Authn): она подтверждает личность пользователя. Обычно это делается путем проверки учетных данных, таких как имена пользователей и пароли. Расширенный Authn может включать многофакторную аутентификацию (MFA), которая сочетает традиционные учетные данные с третьей формой аутентификации, например, отправкой уникального кода на смартфон пользователя.
  • Авторизация (Authz): не каждый пользователь будет иметь доступ ко всем приложениям, наборам данных или услугам в организации. После того как пользователь аутентифицирован, авторизация определяет разрешения для этого пользователя и ограничивает доступ только к ресурсам, разрешенным для этого конкретного пользователя.

1.2 Идентификаторы IAM: Пользователи, группы, роли

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

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

-верх: корневой пользователь
-нижний: пользователи
-группы

  • Корневой пользователь. Когда вы впервые создаете учетную запись Amazon Web Services (AWS), вы начинаете с единой учетной записи, которая имеет полный доступ ко всем службам и ресурсам AWS в этой учетной записи. Этот идентификатор называется корневым пользователем учетной записи AWS, и доступ к нему осуществляется путем входа с помощью адреса электронной почты и пароля, которые вы использовали при создании учетной записи.
  • Пользователи. Пользователь IAM – это сущность, которую вы создаете в AWS. Пользователь IAM представляет лицо или службу, которые используют его для взаимодействия с AWS. Основное назначение пользователей IAM – дать людям возможность входить в консоль управления AWS для выполнения интерактивных задач и делать программные запросы к службам AWS с помощью API или CLI. Пользователь IAM имеет постоянные долгосрочные учетные данные и используется для прямого взаимодействия со службами AWS.
  • Группы (пользователей). Группа пользователей IAM – это совокупность пользователей IAM. Вы можете использовать группы пользователей для определения разрешений для группы пользователей, что может облегчить управление этими разрешениями для этих пользователей.
  • Роли. Роль IAM очень похожа на пользователя, поскольку это идентификатор с политиками разрешений, которые определяют, что идентификатор может и не может делать в AWS. Однако роль не имеет никаких долгосрочных учетных данных (пароля или ключей доступа), связанных с ней. Вместо этого, когда вы вступаете в роль, она предоставляет вам временные учетные данные безопасности для сеанса работы с ролью. Роль не связана с одним человеком, она предназначена для того, чтобы ее мог принять любой человек или любая служба, которой она нужна (пользователи IAM, приложения или служба AWS, например EC2).

1.3 Политики IAM

  • Вы управляете доступом в AWS, создавая политики и прикрепляя их к IAM-идентификаторам (пользователям, группам пользователей или ролям) или ресурсам AWS.
  • Политика – это объект в AWS, который, будучи связанным с идентификатором или ресурсом, определяет их разрешения.
  • Разрешения в политиках определяют, будет ли запрос разрешен или отклонен.
  • Большинство политик хранятся в AWS в виде документов JSON.

2 Принципы безопасности

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

2.1 Нулевое доверие

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

Модель безопасности Zero Trust опирается на следующие основные принципы:

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

Приняв модель Zero Trust, мы можем снизить риск непреднамеренного предоставления доступа неавторизованным пользователям. IAM и стратегия Zero Trust хорошо сочетаются, поскольку Zero Trust гарантирует, что политики и процедуры IAM будут соблюдаться всегда и везде, когда пользователю необходим доступ.

Основополагающим правилом Zero Trust является наименее привилегированный доступ.

2.2 Наименее привилегированный доступ

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

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

Мы достигаем этого, определяя минимальный объем привилегий, необходимых пользователям каждой роли для выполнения своей работы. И, регулярно проводя аудит использования, по возможности сокращаем ненужные постоянные разрешения.

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

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

Помня о принципах нулевого доверия и наименьших привилегий, давайте приступим к работе с IAM.


3 Сокращение операционных расходов на IAM

Скажу прямо: IAM – это сложно.

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

3.1 Централизованный IAM

Если вы управляете более чем одной “средой” (например, средами dev/test/production), то вполне вероятно, что вы используете отдельную учетную запись AWS для каждой среды, чтобы добиться максимального разделения ресурсов и разрешений.

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

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

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

3.2 DevSecOps – автоматизируйте все

Поверьте мне, вы не хотите входить в веб-консоль AWS, переходить в IAM и нажимать несколько кнопок для управления пользователями/группами/ролями IAM. Единственные случаи, в которых это может быть полезно, это:

  • первый раз, когда вы используете новую учетную запись,
  • и когда вы хотите поэкспериментировать с некоторыми незнакомыми функциями.

Но позвольте мне остановить вас прямо здесь. Кроме этих двух сценариев, управление ресурсами IAM вручную, через консоль, вообще не рекомендуется.

Почему автоматизация? Конечно, автоматизация сокращает ручной труд. Но дело не только в этом.

  • Автоматизация также позволяет сократить количество человеческих ошибок. Мы – люди, и люди совершают ошибки. Именно это делает нас людьми, а не роботами.
  • Автоматизация позволяет легко регистрировать, проводить аудит и генерировать отчеты по регулярному графику в соответствии с нормативными требованиями.

Если вы хотите приступить к автоматизации IAM, Terraform и Terraform AWS Provider – хорошее место для начала.


4 Базовая настройка

4.1 НЕ используйте корневого пользователя

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

Чтобы делать программные запросы к AWS, вам нужен ключ доступа (ID ключа доступа + секретный ключ доступа). НИКОГДА не используйте ключ доступа корневого пользователя вашей учетной записи AWS. Ключ доступа для корневого пользователя вашей учетной записи AWS дает полный доступ ко всем вашим ресурсам для всех служб AWS. Вы не можете уменьшить разрешения, связанные с ключом доступа корневого пользователя учетной записи AWS.

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

  • Не используйте пользователя root для выполнения повседневных задач, даже административных. Вместо этого используйте учетные данные пользователя root только для создания пользователя IAM admin. Затем надежно заблокируйте учетные данные пользователя root. Для выполнения повседневных задач даже не используйте пользователя IAM admin. Вместо этого используйте роли для делегирования прав доступа.
  • Удалите ключ доступа корневого пользователя. Если вы должны хранить его (что не обязательно), регулярно ротируйте (меняйте) ключ доступа.

4.2 Включите многофакторную аутентификацию (MFA)

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

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

4.3 Используйте строгую политику паролей

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

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

4.4 Используйте роли IAM вместо долгосрочных ключей доступа

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

Учитывая это, не помещайте ключи доступа в незашифрованный код. Например, если вы используете ключи доступа в системе непрерывной интеграции, не используйте их в виде открытого текста. Вместо этого используйте их как “секреты”. Например, в Jenkins вы можете создавать учетные данные или в GitHub Actions вы также можете создавать секреты репо.

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

4.5 Регулярно меняйте учетные данные

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

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

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

4.6 Удалите устаревшие и ненужные учетные данные

Например, если вы создали IAM-пользователя для приложения, которое вообще не использует консоль, ему не нужен пароль.

Аналогично, если пользователь использует только консоль, удалите его ключи доступа.

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


5 Группы

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

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

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

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


6 Роли

6.1 Использование ролей для делегирования прав доступа

Не следует помещать ключи в код или экземпляры.

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

Вы можете принять роль IAM с помощью операций AWS Security Token Service (STS) или переключиться на роль в консоли управления AWS Management Console, чтобы получить временную сессию роли. Это более безопасно, чем использование вашего долгосрочного пароля или ключей доступа. Сессия имеет ограниченный срок действия, что снижает риск в случае компрометации ваших учетных данных.

Для пользователей IAM создайте отдельные роли для конкретных рабочих задач и используйте эти роли для выполнения этих задач. Не используйте пользователя IAM admin для повседневной работы.

6.2 Использование ролей для приложений на EC2-установках

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

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

Но проблема заключается в распространении: чтобы безопасно распространить учетные данные на каждый экземпляр, особенно на те, которые AWS создает от вашего имени (например, Spot Instances или экземпляры в группах Auto Scaling), вы также должны иметь возможность обновлять учетные данные на каждом экземпляре при ротации учетных данных AWS.

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

Напоминание: роль – это объект, который имеет свой собственный набор разрешений, но не является пользователем или группой пользователей. Роли также не имеют собственного постоянного набора учетных данных, как это делают пользователи IAM. В случае с Amazon EC2, IAM динамически предоставляет временные учетные данные для экземпляра EC2, и эти учетные данные автоматически меняются для вас.

Подробности: Amazon EC2 использует профиль экземпляра в качестве контейнера для роли IAM. Когда вы создаете роль IAM с помощью консоли IAM, консоль автоматически создает профиль экземпляра и дает ему такое же имя, как и роли, которой он соответствует. Если вы используете консоль Amazon EC2 для запуска экземпляра с ролью IAM или для прикрепления роли IAM к экземпляру, вы выбираете роль на основе списка имен профилей экземпляров. Таким образом, приложения, запускаемые на экземпляре EC2, могут использовать учетные данные роли при доступе к ресурсам AWS.


7 Политики

7.1 Управляемые политики AWS

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

Управляемые политики AWS охватывают общие случаи использования и хорошо согласованы с общими ИТ-функциями. Неважно, являетесь ли вы сетевым специалистом, которому нужно установить и настроить что-то в AWS, или специалистом по анализу данных, пытающимся выполнить несколько запросов Hadoop, есть вероятность, что для вас уже существует управляемая политика AWS, предназначенная именно для этой работы.

Использование управляемых AWS политик снижает ваши операционные накладные расходы. Кроме того, есть еще одно важное преимущество: автообновление. Эти политики обновляются каждый раз, когда появляется новая служба AWS или API. Это экономит много времени и действительно улучшает качество жизни. Например, AWS управляет политикой под названием ‘ReadOnlyAccess’, которая предоставляет доступ на чтение ко всем службам и ресурсам AWS. Допустим, AWS запускает новую службу. AWS проследит за тем, чтобы политика ‘ReadOnlyAccess’ была обновлена с учетом этой новой запущенной услуги. Кроме того, это изменение будет применено ко всем сущностям (группам, пользователям или ролям), к которым уже подключена политика ReadOnlyAccess.

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

7.2 Политики, управляемые клиентом, лучше встроенных политик (для большинства случаев)

Хотя политики, управляемые AWS, являются хорошим местом для начала работы, они не следуют принципу наименьших привилегий.

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

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

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

Если вы сомневаетесь между управляемой и встроенной политикой, выбирайте управляемую политику.

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

7.3 Дополнительная безопасность: Условия политики

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

Например, вы можете написать условия, определяющие диапазон IP-адресов, с которых должен поступать запрос. Например, можно потребовать, чтобы пользователь прошел аутентификацию с помощью устройства MFA, чтобы ему разрешили завершить работу экземпляра Amazon EC2.

Но будьте осторожны, не переусердствуйте, чтобы это не стало непрактичным.

7.4 Проверка политик

Проверяйте создаваемые политики.

Вы можете проверить синтаксис (JSON) и логику. Первое происходит автоматически, и это может сделать любой современный текстовый редактор.
Второй вариант немного сложнее: вы можете использовать IAM Access Analyzer для проверки ваших политик и получения рекомендаций по написанию более безопасных политик. Он генерирует предупреждения безопасности, когда утверждение в вашей политике разрешает доступ, который мы считаем чрезмерно разрешенным.

7.5 Генерирование политики на основе активности доступа

Умный вариант: вы понятия не имеете, кто и чем пользуется, но хотите обеспечить соблюдение наименьших привилегий? Легко! Генерируйте IAM-политики на основе активности доступа, регистрируемой AWS CloudTrail!

При предоставлении IAM-сущности (пользователя или роли) IAM Access Analyzer может просмотреть ваши журналы AWS CloudTrail и сгенерировать шаблон политики, содержащий разрешения, которые использовались этой сущностью в указанный вами период времени.
Этот шаблон можно использовать для создания управляемой политики с более точными разрешениями. Просто прикрепите его к сущности IAM, и вуаля!

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

7.6 Использование уровней доступа для проверки разрешений IAM

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

Вы можете просмотреть сводку политики, которая включает в себя сводку уровня доступа для каждой службы в рамках данной политики. AWS относит каждое действие службы к одному из пяти уровней доступа, основываясь на том, что делает каждое действие: Список, Чтение, Запись, Управление разрешениями или Тегирование. Вы можете использовать эти уровни доступа для определения того, какие действия следует включить в политику.


8 Управление доступом точно в срок

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

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

Это то, что мы называем управлением доступом “точно в срок”.

Например, с помощью HashiCorp Vault AWS Engine можно динамически генерировать учетные данные доступа AWS на основе политик IAM.

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

Например, Vault создаст пользователя IAM для каждой аренды и прикрепит к нему управляемые и встроенные политики IAM, указанные в роли. И Vault удалит IAM-пользователя по истечении TTL.

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


9 Мониторинг и аудит

Бизнес и приложения меняются с течением времени. Создание пользователей, групп, ролей и политик и их автоматизация – это только начальный этап. Далее нам также необходимо регулярно проверять и обновлять настройки и политики, связанные с безопасностью.

9.1 Планирование аудита доступа

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

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

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

9.2 Информация о последнем доступе

Политики и разрешения необходимо регулярно пересматривать, особенно когда люди уходят или меняются.

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

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

9.3 Мониторинг действий

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

Многие службы AWS поддерживают ведение журналов; они могут подробно регистрировать запросы пользователей.

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

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

9.4 Другие службы AWS, которые могут помочь

AWS Config

AWS Config – это служба, которая позволяет вам оценивать, аудировать и анализировать конфигурации ваших ресурсов AWS.

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

AWS GuardDuty

AWS GuardDuty – это служба обнаружения угроз, которая непрерывно отслеживает учетные записи и рабочие нагрузки AWS на предмет вредоносной активности и предоставляет подробные выводы по безопасности для наглядности и исправления ситуации.

Например, если вы находитесь в ЕС, а в один прекрасный день ваша учетная запись вошла в систему в Африке (личная правдивая история), GuardDuty может обнаружить это и предупредить вас.


Резюме

При всем уважении к AWS, IAM – это действительно боль. Нелегко изучить или понять все концепции, и уж точно нелегко использовать его идеально автоматизированным образом. Если вы также заинтересованы в автоматическом управлении пользователями, ролями и политиками IAM для снижения эксплуатационных затрат, обязательно подпишитесь, потому что в следующей статье мы сделаем практическое руководство по управлению AWS IAM с помощью HashiCorp Terraform. До встречи в следующей статье!

Оцените статью
Procodings.ru
Добавить комментарий