Начало работы с AWS (часть 8)

• Начало работы с AWS (часть 2)
• Начало работы с AWS (часть 3)
• Начало работы с AWS (часть 4)
• Начало работы с AWS (часть 5)
• Начало работы с AWS (часть 6)
• Начало работы с AWS (часть 7)
• Начало работы с AWS (часть 9)
• Начало работы с AWS (часть 10)
• Начало работы с AWS (часть 11)
• Начало работы с AWS (часть 12)
• Начало работы с AWS (часть 13)
• Начало работы с AWS (часть 14)

Вот краткий обзор того, что мы узнали из этой короткой серии статей:

• В части 1 описывался уровень бесплатного использования Amazon Web Services (AWS) и то, как вы можете подписаться на него, чтобы иметь возможность тестировать AWS в течение 12 месяцев.
• Во второй части были рассмотрены различные инструменты управления и разработки, предоставляемые Amazon для создания и управления облачными ресурсами в AWS.
• В части 3 описаны некоторые шаги, которые вы можете использовать для защиты своей учетной записи AWS в случае взлома вашей учетной записи.
• В части 4 был представлен AWS Identity and Access Management (IAM) — веб-сервис, который позволяет создавать пользователей и управлять ими, а также назначать разрешения пользователей для облачной среды AWS.
• В части 5 описаны функции консоли IAM и создание удобного псевдонима для идентификатора вашей учетной записи AWS, чтобы убедиться, что вы не сгенерировали никаких ключей доступа для своей корневой учетной записи AWS.
• В части 6 показано, как создать нового пользователя с правами администратора, чтобы можно было использовать этого пользователя вместо корневой учетной записи для управления средой AWS.
• В части 7 рассматривалось, как внедрить многофакторную аутентификацию (MFA) для добавления дополнительного уровня защиты вашей корневой учетной записи AWS и учетным записям пользователей IAM, а также обсуждались преимущества и недостатки использования MFA для защиты учетных записей AWS, особенно вашей корневой учетной записи.

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

Политики против разрешений

На самом деле ранее мы косвенно представили тему политик в части 6 этой серии, когда создали новую группу IAM под названием «Администраторы» для нашей тестовой среды уровня бесплатного пользования AWS. Если вы помните, одна из страниц мастера создания новой группы называлась Set Permissions и выглядела она так:

Рисунок 1: Страница Set Permissions мастера создания новой группы

Как видно из приведенного выше снимка экрана, разрешения назначаются группе IAM (или пользователю или роли, если на то пошло) путем присоединения политики к группе. Логически говоря, политика — это просто контейнер для разрешений, во многом похожий на список управления доступом (ACL) на платформе Microsoft Windows. С точки зрения внутренней реализации в AWS, политика — это, по сути, просто текстовый файл, содержащий некоторые сценарии JSON (нотация объектов JavaScript), которые определяют действия, которые могут быть выполнены, ресурсы, на которых могут выполняться действия, и эффект (разрешить или запретить), возникающий, когда действующее лицо (например, пользователь) запрашивает выполнение действия над ресурсом. На рис. 2, который также воспроизведен из предыдущей статьи части 6, показан сценарий JSON, лежащий в основе шаблона политики доступа администратора:

Рисунок 2. Сценарий JSON, лежащий в основе шаблона политики доступа администратора

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

Рисунок 3: Новая страница «Присоединить политику» мастера создания новой группы

Политики по умолчанию

Amazon также недавно добавил новую страницу Policies в консоль IAM. Как показано на рис. 4 ниже, страница «Политики» — это центральное место в IAM, где вы можете создавать, управлять и применять политики к пользователям, группам и ролям в вашей среде.

Рисунок 4: Новая страница Policies в консоли IAM

Почему в вашей среде AWS доступно более сотни шаблонов политик по умолчанию? Хотя может показаться, что это большое количество политик, на самом деле все довольно просто: в основном потому, что в облаке AWS так много различных предложений услуг. В качестве примера рассмотрим Amazon EC2, их веб-службу, которая предлагает услуги облачного хостинга с изменяемым размером, чтобы облегчить разработчикам масштабирование веб-вычислений. Как видно из рисунка выше, есть четыре политики по умолчанию, которые вы можете использовать для управления типом доступа, который пользователи, группы или роли могут иметь для этой службы:

• AmazonEC2FullAccess — предоставляет полный доступ к Amazon EC2 через Консоль управления AWS.
• AmazonEC2ReadOnlyAccess — предоставляет доступ только для чтения к Amazon EC2 через Консоль управления AWS.
• AmazonEC2ReportsAccess — предоставляет полный доступ ко всем отчетам Amazon EC2 через Консоль управления AWS.
• AmazonEC2RoleforDataPipelineRole — политика по умолчанию для роли Amazon EC2 для роли сервиса Data Pipeline.

Описания политик в маркированном списке выше можно найти, щелкнув любую из этих политик на странице «Политики» консоли IAM. Например, на следующем рисунке показаны сведения о политике AmazonEC2ReadOnlyAccess:

Рисунок 5: Подробная информация о политике AmazonEC2ReportsAccess

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

Рисунок 6: Мастер создания политики

Теперь нажмите кнопку «Выбрать» в разделе «Копировать политику, управляемую AWS». Вы попадете на страницу со списком доступных политик в алфавитном порядке. Вместо прокрутки введите имя политики, которую вы хотите скопировать (в данном примере это политика AmazonEC2ReadOnlyAccessm), в поле «Политики поиска», и отобразится нужная политика:

Рис. 7. Выбор политики AmazonEC2ReadOnlyAccess для ее копирования.

Нажав кнопку «Выбрать», показанную выше, вы попадете на страницу «Обзор политики», на которой снова отображается документ политики JSON, но на этот раз в форме, которую вы можете щелкнуть и выбрать, чтобы скопировать ее в буфер обмена:

Рисунок 8: Копирование JSON документа политики в буфер обмена.

Вот как выглядит JSON документа политики для политики AmazonEC2ReadOnlyAccess полностью:

{

«Версия»: «2012-10-17»,

"Заявление": [

{

«Эффект»: «Разрешить»,

"Действие": "ec2:Описать*",

"Ресурс": "*"

},

{

«Эффект»: «Разрешить»,

"Действие": "elasticloadbalancing:Describe*",

"Ресурс": "*"

},

{

«Эффект»: «Разрешить»,

"Действие": [

"cloudwatch:ListMetrics",

"cloudwatch:GetMetricStatistics",

"cloudwatch:Описать*"

],

"Ресурс": "*"

},

{

«Эффект»: «Разрешить»,

"Действие": "автомасштабирование:Описать*",

"Ресурс": "*"

}

]

}

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

• Начало работы с AWS (часть 2)
• Начало работы с AWS (часть 3)
• Начало работы с AWS (часть 4)
• Начало работы с AWS (часть 5)
• Начало работы с AWS (часть 6)
• Начало работы с AWS (часть 7)
• Начало работы с AWS (часть 9)
• Начало работы с AWS (часть 10)
• Начало работы с AWS (часть 11)
• Начало работы с AWS (часть 12)
• Начало работы с AWS (часть 13)
• Начало работы с AWS (часть 14)