Как практиковать правильное управление пользователями IAM с границами разрешений

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

Полный доступ к IAM позволяет повысить привилегии

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

Процесс довольно прост. Допустим, вы создаете новую учетную запись пользователя и наивно прикрепляете разрешение IAMFullAccess :

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

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

Решение: границы разрешений

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

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

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

Вы можете вручную установить границу для данного пользователя на вкладке «Использование политики», но все, что она делает, — это ограничивает доступ к этой границе разрешений, игнорируя другие политики. Технически граница разрешений для сотрудника назначается любым ролям, которые создает сотрудник, а не его собственной учетной записи. Таким образом, вы можете дать сотруднику разрешение на чтение/запись для самостоятельного использования S3, но разрешить чтение только для любых ролей службы, которые они создают. Если вы также установите границу разрешений для учетной записи сотрудника, у них будут те же роли, что и у учетных записей, которые они могут создавать.

Что вы действительно хотите сделать, так это создать настраиваемое разрешение, которое позволяет только пользователю IAM-сотруднику создавать новые роли, но только в пределах установленных вами границ разрешения. Скопируйте ARN политики, которую вы хотите использовать в качестве границы. (Вы можете найти это на странице информации о политике).

Создайте следующую роль, заменив условие собственным ARN.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:DetachRolePolicy",
                "iam:CreateRole",
                "iam:AttachRolePolicy"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::515436951152:policy/S3AccessBoundary"
                }
            }
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "iam:CreateInstanceProfile",
                "iam:GetRole",
                "iam:GetPolicyVersion",
                "iam:GetInstanceProfile",
                "iam:ListRoleTags",
                "iam:GetPolicy",
                "iam:AddRoleToInstanceProfile",
                "iam:CreatePolicy",
                "iam:PassRole",
                "iam:ListPolicyVersions",
                "iam:ListAttachedRolePolicies",
                "iam:CreatePolicyVersion",
                "iam:ListRolePolicies",
                "iam:GetRolePolicy",
                "iam:DeletePolicyVersion"
            ],
            "Resource": [
                "arn:aws:iam::515436951152:role/service-*",
                "arn:aws:iam::515436951152:policy/service-*",
                "arn:aws:iam::515436951152:instance-profile/service-*"
            ]
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": [
                "iam:ListPolicies",
                "iam:GetServiceLastAccessedDetailsWithEntities",
                "iam:ListRoles",
                "iam:GetServiceLastAccessedDetails"
            ],
            "Resource": "*"
        }
    ]
}

Это дает разрешения CreateRole, AttachRolePolicy и DetachRolePolicy, предоставляя пользователю разрешение на создание учетных записей служб и использование роли с другими сервисы АВС. Но эта политика поставляется с условием iam:PermissionsBoundary, которое гарантирует, что создаваемые ими роли контролируются с указанной вами границей разрешений.

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

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

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

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

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

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

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

Другое решение: отдельная среда разработки и производства

Это решение не решает проблему напрямую, но может помочь вам в управлении разрешениями.

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

Это может снять большую нагрузку с разработчиков и сделать среду разработки более спокойной. Вам не придется беспокоиться об ограничении доступа S3 к определенным сегментам разработки; вместо этого вы можете предоставить разработчикам S3FullAccess, зная, что это влияет только на среду разработки. Вы не должны автоматически делать всех своих разработчиков полноправными администраторами в этой среде, и вы можете по-прежнему использовать границы разрешений. Но если это не повлияет на производство, вы можете дать своим разработчикам больше свободы. Руководителям проектов или старшим разработчикам может быть предоставлен полный доступ к большинству сервисов при условии, что вы будете следить за расходами, чтобы убедиться, что они не арендуют экземпляр c5.24xlarge для игры в Minecraft в нерабочее время.