Политики AWS IAM : Лучшие практики и как создать политику IAM

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

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

Что такое AWS IAM?

AWS Identity and Access Management (IAM) – это веб-служба, которая помогает управлять и контролировать доступ и разрешения к ресурсам и другим службам AWS. Используя эту службу, мы можем установить строительные блоки для управления аутентификацией и авторизацией наших учетных записей AWS.

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

  • Аутентификация: Процесс подтверждения личности пользователя. По сути, проверка того, за кого человек себя выдает.
  • Авторизация: Определение уровня разрешений и прав доступа для данного пользователя. Авторизация происходит после аутентификации и устанавливает, что кому-то разрешено делать.
  • Принципы: Лица или приложения, которые пытаются выполнить действия на AWS. Пользователи: Идентификаторы в IAM, которые соответствуют пользователям в организации. Они представляют реальных людей или приложения и учетные записи служб.
  • Группы: Пользователи IAM логически объединяются в группы IAM. Таким образом, мы можем назначать разрешения нескольким пользователям в массовом порядке. Общим шаблоном является создание групп в соответствии с различными ролями в организации.
  • Роли: Роли предоставляют временный доступ к ресурсам и не связаны с конкретными пользователями. Вместо этого роли позволяют принципалам временно принимать на себя набор разрешений для выполнения операции.
  • Политики: Для управления доступом в AWS мы создаем политики IAM, которые определяют уровни разрешений и прикрепляют их к идентификаторам IAM (пользователям, группам, ролям) или ресурсам AWS.
  • Запросы: Принципалы пытаются выполнить действия на AWS, создавая запросы к AWS через AWS API, консоль управления или CLI.
  • Действия: Каждый запрос имеет определение действия, которое объявляет конкретную запрашиваемую операцию. Если аутентификация и авторизация пройдены, действие утверждается.
  • Ресурсы: Ресурсом в данном контексте может считаться любой объект AWS в рамках сервиса.

Типы политик

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

  • Политики на основе идентификации – это политики, привязанные к идентификаторам (пользователям, группам, ролям) и предоставляющие им необходимые разрешения. Политики на основе идентификации могут быть либо управляемыми политиками, либо встроенными. Управляемые политики либо подготовлены и управляются AWS для общих случаев использования (управляемые политики AWS), либо пользовательские политики, созданные пользователями (управляемые политики клиента), подходящие для достижения тонкого контроля. Встроенные политики используются, когда нам нужно сделать политику частью сущности принципала и поддерживать между ними строгую связь один-к-одному.
  • Политики на основе ресурсов прикрепляются непосредственно к ресурсам и определяют разрешения на определенные действия над ресурсом для некоторых принципалов.
  • Границы разрешений IAM определяют максимальные разрешения для сущности IAM и используются в качестве гарантий.
  • Списки контроля доступа (ACL) прикрепляются к ресурсам и контролируют кросс-учетные разрешения для принципалов из других учетных записей.
  • Политики контроля сервисов организаций (SCP) определяют максимальный уровень разрешений для учетных записей организации. Эти политики используются для ограничения разрешений, которые могут быть назначены в рамках учетных записей участников.
  • Политики сеансов – это расширенные политики, используемые во время временных сеансов для ролей или объединенных пользователей.

Структура документа политики

Теперь, когда мы увидели различные типы политик IAM, которые существуют в контексте AWS, давайте посмотрим, как они структурированы. Большинство из них хранятся в формате JSON и привязаны к ресурсам или идентификаторам. Единственный тип политики, который использует другой формат, – это ACL, но в этой статье мы не будем фокусироваться на ACL.

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

Вот простая политика, основанная на идентификации, которая позволяет принципалу, который ее прикрепил, перечислять объекты одного ведра S3 с именем this-is-an-example-s3-bucket-name.

{
   "Version": "2012-10-17",
   "Statement": {
       "Sid": "ListObjectsInBucket",
       "Effect": "Allow",
       "Action": "s3:ListBucket",
       "Resource": "arn:aws:s3:::this-is-an-example-s3-bucket-name"
   }
}
Вход в полноэкранный режим Выход из полноэкранного режима

Политики IAM строятся с использованием комбинации следующих элементов:

  • Версия: Определяет версию языка политики. Всегда используйте последнюю версию.
  • Заявление: Этот аргумент используется в качестве родительского элемента для различных утверждений в политике.
  • Sid: Это необязательный элемент, который позволяет нам определить идентификатор утверждения.
  • Effect (Эффект): Этот элемент может иметь значения Allow или Deny.
  • Действие: Список действий, связанных с политикой.
  • Resource (Ресурс): Определяет список ресурсов, к которым применяется политика. Для политик, основанных на ресурсах, это необязательно, поскольку политика применяется к ресурсу, к которому она прикреплена.
  • Принципал: определяет идентификаторы, которым разрешен или запрещен доступ к политике на основе ресурсов.
  • Условие: Определяет некоторые условия, при которых применяется политика. Этот элемент практичен, когда нам нужно добиться пользовательских правил для тонкого доступа.

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

Если вы хотите узнать больше об этих элементах и компонентах политики JSON, ознакомьтесь со справочником по политике IAM JSON.

Далее мы рассмотрим пример более сложной политики IAM с более чем одним утверждением с использованием условий.

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "DenyAllOutsideRequestedRegions",
           "Effect": "Deny",
           "NotAction": [
               "cloudfront:*",
               "iam:*",
               "route53:*",
               "support:*"
           ],
           "Resource": "*",
           "Condition": {
               "StringNotEquals": {
                   "aws:RequestedRegion": [
                       "eu-west-1",
                       "eu-central-1"
                   ]
               }
           }
       },
       {
           "Sid": "DenyAccessFromNonCorporateIPs",
           "Effect": "Deny",
           "Action": "*",
           "Resource": "*",
           "Condition": {
               "NotIpAddress": {
                   "aws:SourceIp": [
                       "192.0.1.0/24"
                   ]
               },
               "Bool": {"aws:ViaAWSService": "false"}
           }
       }
   ]
}
Вход в полноэкранный режим Выйти из полноэкранного режима

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

Второе условие определяет политику отказа в доступе к AWS на основе IP источника запросов. Здесь, поскольку у нас есть два условия, они объединены логическим AND. Более конкретно, политика запрещает все действия AWS, когда запросы исходят от IP, не входящего в корпоративный диапазон IP (в данном примере: 192.0.1.0/24), и когда служба AWS не выполняет вызов.

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

Наконец, вот политика на основе ресурсов для ведра S3.

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "DenyS3AccessWithNoMFA",
       "Effect": "Deny",
       "Principal": "*",
       "Action": "s3:*",
       "Resource": "arn:aws:s3:::this-is-an-example-s3-bucket-name/example-directory/*",
       "Condition": { "Null": { "aws:MultiFactorAuthAge": true }}
     }
   ]
}
Войти в полноэкранный режим Выйти из полноэкранного режима

Связав эту политику с ведром this_is_an_example_s3_bucket_name, каждое действие с ведром будет запрещено, если запрос не аутентифицирован с помощью механизма многофакторной аутентификации. Обратите внимание на использование здесь элемента Principal, поскольку мы используем политику на основе ресурсов.

Создание политики IAM

Существует три основных способа создания политики IAM. Мы можем использовать консоль AWS, AWS CLI или AWS API. В данной демонстрации мы рассмотрим создание политики IAM под управлением клиента с помощью консоли AWS.

Самый простой вариант создания политики – использовать полезный визуальный редактор, который предоставляет консоль AWS, без необходимости писать JSON-файл и заботиться о правильном синтаксисе. После входа в консоль управления AWS перейдите в раздел IAM и выберите Политики и Создать политику.

На этом экране вы можете выбрать использование визуального редактора или JSON.

Давайте повторим наш первый пример политики, который позволяет перечислить объекты в ведре S3. Для Service мы выбираем S3, для Actions выбираем ListBucket, а для Resources используем arn ведра S3 arn:aws:s3:::this-is-an-example-s3-bucket-name. Затем выберите Далее: Теги.

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

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

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

Отлично, мы воспроизвели политику IAM, которую мы представили в первом примере.

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

Другим вариантом использования AWS API под капотом может быть создание ваших IAM-ресурсов с помощью выбранного вами инструмента Infrastructure as Code. Вот пример использования Terraform для определения той же политики.

resource "aws_iam_policy" "list_bucket_policy_example" {

 name        = "list_bucket_policy_example"
 path        = "/"
 description = "AWS IAM Policy example for listing the objects of a bucket"
 policy      = <<EOF
{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Action": "s3:ListBucket",
     "Resource": "arn:aws:s3:::this-is-an-example-s3-bucket-name",
     "Effect": "Allow",
     "Sid": "ListObjectsInBucket"
   }
 ]
}
EOF
}
Вход в полноэкранный режим Выход из полноэкранного режима

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

При создании или редактировании политик IAM с помощью консоли управления AWS Management Console проверяется их синтаксис и грамматика на предмет соответствия грамматике политик IAM. Если есть какие-либо проблемы или ошибки, вы получаете соответствующее уведомление и должны исправить политику.

AWS предоставляет IAM Access Analyzer с дополнительными проверками политик и рекомендациями по их улучшению. При создании или редактировании политики с помощью вкладки JSON под политикой появляется панель проверки политики, в которой представлены различные результаты проверки политики. Там вы получите информацию о проблемах, отнесенных к категориям “Безопасность”, “Ошибки”, “Предупреждения” и “Предложения”. Обновите политику соответствующим образом, чтобы устранить обнаруженные проблемы.

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

Мы получаем результат Error, потому что не указали правильное поле ARN для элемента Resource.

Далее, на вкладке Warnings, мы получаем уведомление о том, что мы пропустили элемент Version верхнего уровня.

Наконец, на вкладке Suggestions мы получаем уведомление о том, что наш элемент Action не включает никаких действий.

Тестирование политик IAM

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

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

Например, мы создали IAM-пользователя test-user и подключили политику ListBucketContents, которую мы создали ранее. Мы можем использовать симулятор политики AWS для проверки того, что этот пользователь действительно может перечислить объекты примера ведра.

После определения всех параметров для симуляции, мы выбираем Run Simulation и проверяем, что результат Permission разрешен. Ознакомьтесь с подробным руководством Troubleshooting IAM Policies для решения проблем с политиками IAM.

Версионирование политик IAM

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

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

Лучшие практики IAM-политик

  • Следуйте принципам наименьших привилегий: При создании политик IAM предоставляйте только те разрешения, которые необходимы для выполнения работы. Указывайте конкретные действия, ресурсы и принципы, а также добавляйте пользовательские условия для достижения необходимого контроля.
  • Создавайте политики на основе активности доступа: Хотя это считается лучшей практикой, при создании политик IAM может быть сложно реализовать тонкие политики, предоставляющие наименьшие привилегии. По этой причине вы можете изначально использовать политики, которые разрешают больше прав, чем должны, а затем доработать их, создав новую политику на основе активности доступа IAM-сущности. Это более прагматичный подход к достижению наименьших привилегий для неопытных пользователей, который делает путь к улучшению безопасности и управления доступом более плавным.
  • Начните с управляемых политик: Совершенно нормально начинать с управляемых политик AWS, когда вы начинаете экспериментировать и учиться. Эти политики охватывают общие случаи использования и помогают вашей команде установить необходимые разрешения для быстрого начала работы. Когда вы почувствуете себя достаточно комфортно с IAM, рассмотрите возможность ограничения политик путем создания управляемых клиентом политик, которые следуют подходу с наименьшими привилегиями.
  • Назначайте разрешения с помощью ролей и групп; избегайте встроенных политик: Считается, что лучше избегать назначения разрешений непосредственно пользователям или использования встроенных политик. Для упрощения управления доступом и улучшения контроля безопасности прикрепляйте политики к группам или ролям.
  • Проверяйте политики: Каждый раз, когда вы создаете или редактируете политики, проверяйте их с помощью вспомогательных инструментов AWS, как мы видели в разделе Проверка политик IAM.
  • Используйте роли IAM для экземпляров EC2 (EC2 Instance Profiles): Для приложений, которые запускаются на экземплярах EC2, прикрепите необходимые разрешения к ролям IAM и укажите роль в качестве параметра запуска для экземпляра.
  • Используйте условия политики: Используйте условия политики для создания сложных политик с пользовательскими правилами. Комбинируя различные условия в политиках, мы можем выполнять определенные требования в соответствии со стандартами нашей организации. Ознакомьтесь с Элементы политики: Условия для получения дополнительной информации.
  • Тестируйте политики IAM с помощью IAM Policy Simulator: Тестируйте существующие и новые политики быстро и без влияния на какую-либо среду с помощью симулятора политики IAM. Используйте его, чтобы лучше понять свои политики и устранить различные неполадки.
  • Регулярно пересматривайте политики IAM: Облачные среды не являются статичными; они развиваются с течением времени. По этой причине политики IAM необходимо пересматривать и обновлять, чтобы отразить изменения. Следуя лучшим практикам и наименьшим привилегиям, это не то, что вы настроите один раз и забудете, а требует постоянных усилий.
  • Пометить политики IAM: Пометьте свои политики IAM, чтобы добавить к ним метаданные так же, как вы помечаете другие ресурсы AWS.
  • Управление доступом к ресурсам с помощью тегов: Если у вас есть правильная стратегия маркировки ресурсов AWS, вы можете создавать сложные политики IAM, которые контролируют доступ к ним на основе тегов. Этот метод становится удобным, когда вы хотите разделить доступ к ресурсам на основе владельцев или команд.
  • Используйте IaC для создания политик IAM: В этом руководстве мы рассмотрели, как создавать IAM-политики из консоли AWS, и это может быть хорошей отправной точкой, но в конечном итоге вы должны рассматривать ваши IAM-ресурсы как компоненты инфраструктуры и применять те же принципы Infrastructure as Code, что и к любым другим ресурсам AWS.

Ключевые моменты

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

Здесь вы можете узнать больше об интеграции Spacelift с AWS, а здесь – об использовании политик в Spacelift.

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

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