Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 2)

• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 3)
• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 4)
• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 5)

Введение

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

IAM-политики и разрешения

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

• Пользователи
• Группы
• Роли
• Ресурсы

Ресурсы — это сервисы или продукты AWS, которые интегрируются с AWS. К ним относятся хранилище S3, Amazon Glacier, SNS (простая служба уведомлений), SQS (простая служба очередей), AWS KMS (служба управления ключами) и функция конечной точки Amazon VPC (виртуальное частное облако).

Типы политик: встроенные и управляемые

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

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

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

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

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

Встроенные политики привязаны к конкретному пользователю, группе, роли или ресурсу, и вы сами создаете их и управляете ими. Нет встроенных политик, управляемых AWS. Встроенная политика является неотъемлемой частью объекта. Вы можете внедрить политику во время создания сущности или создать и внедрить политику позже. Если вы удалите объект, политика также будет удалена. Таким образом, отношения объект-политика становятся более простыми и понятными со встроенными политиками. Это предотвращает ошибочное назначение разрешений политики неправильным объектам. Однако вы теряете возможность вернуться к более старым версиям или делегировать ограниченные права администратора другим пользователям.

Типы разрешений: на основе пользователей и на основе ресурсов.

Существует два различных способа назначения разрешений в зависимости от типа объекта, к которому они прикреплены. Пользовательские разрешения прикрепляются к пользовательским сущностям; то есть они привязаны к пользователю, группе или роли. Эти разрешения будут определять, какие действия разрешено выполнять этому пользователю (или тем пользователям в группе, или пользователям в роли). Разрешения на основе ресурсов прикрепляются к ресурсу (как описано выше).

Еще больше усложняет ситуацию то, что разные ресурсы поддерживают разные типы разрешений. Не путайте разрешения на основе ресурсов и разрешения на уровне ресурсов; это не одно и то же. Некоторые ресурсы поддерживают разрешения на уровне действий, что означает, что вы можете указать отдельные действия. Некоторые поддерживают разрешения на уровне ресурсов, что означает, что вы можете указать отдельные ресурсы в политике. Некоторые поддерживают разрешения на уровне ресурсов для одних действий, но не для других. Некоторые поддерживают разрешения на уровне ресурсов только для некоторых API, но не для других. Некоторые также поддерживают разрешения на основе тегов, что позволяет создавать разрешения на уровне ресурса с помощью тегов, прикрепленных к ресурсу. Разрешения ресурсов поддерживаются только S3, Glacier, SNS, SQS и AWS KMS.

ИТ-специалисты, имеющие опыт управления доступом в Windows, знают, что при объединении нескольких наборов разрешений все может быть затруднительно. Точно так же, как те, кто получает доступ к файлу в сети Windows, имеют свои окончательные разрешения, определяемые как разрешениями общего доступа, так и разрешениями файла (NTFS), когда вы работаете с IAM, окончательные разрешения пользователя могут основываться как на пользовательских разрешениях. которые назначаются учетной записи этого пользователя (или группе или роли, к которой принадлежит пользователь) разрешения на основе ресурсов, которые назначаются ресурсу, над которым пользователь пытается выполнить какое-либо действие. Когда ресурсом является хранилище Amazon S3, сюжет становится еще более запутанным.

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

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

Документ политики определяет разрешения, определяя действия, которые может выполнять пользователь, для которого используются ресурсы AWS. Например, если вы хотите предоставить пользователю доступ к просмотру элементов в корзине в службе хранения Amazon S3, действие — это ListBucket, а ресурс — это конкретная корзина S3, которую пользователь сможет использовать для этого действия. за.

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

Для создания документов политики вы используете JSON, который представляет собой формат обмена данными JavaScript Object Notation, основанный на JavaScript, но более удобный для чтения и записи людьми. Вы можете узнать больше о JSON и простое руководство по использованию JSON здесь.

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

Обратите внимание, что политика IAM может включать несколько инструкций, но размер политик IAM ограничен. Ограничение зависит от конкретного объекта (пользователя, роли или группы), к которому применяется политика. Эти ограничения для встроенных политик следующие:

• Политика пользователя: максимальный размер – 2048 символов.
• Групповая политика: максимальный размер 5120 символов
• Политика ролей: максимальный размер — 10 240 символов.

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

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

• СоздатьПолитику
• CreatePolicyVersion
• УдалитьПолитику
• УдалитьПолициверсион
• Сетдефаултполициверсион

Чтобы дать пользователю разрешение создавать, обновлять или удалять политики и версии политик или устанавливать версию по умолчанию, вы должны создать для этого документ политики. Существует множество других API-интерфейсов для предоставления пользователю возможности присоединять и отсоединять политики пользователей, групп или ролей. Если вы хотите контролировать доступ к определенным управляемым политикам, вы используете ARN (имя ресурса Amazon) политики в элементе Ресурс или Условие политики.

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

Резюме

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

• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 3)
• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 4)
• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 5)