В этой статье руководитель группы защиты инфраструктурных ИТ-решений компании «Газинформсервис» Сергей Полунин рассмотрит два способа управления учётными записями и их правами в облачной среде на примере Amazon Web Services.
Identity and Access Management
Одним из сервисов, отвечающих за безопасность AWS является служба Identity and Access Management (IAM). Именно она обеспечивает триаду – идентификация, аутентификация, авторизация. Обычно при первом знакомстве с IAM рассказывают об обязательном включении многофакторной аутентификации и запрете пользоваться рутом.
Также обязательно упоминают про парольную политику, почти такую же, как в прочих системах, которыми вы уже управляете. Заодно намекают, что с логином и паролем можно зайти только в административный интерфейс, а вот управлять «начинкой» придётся с помощью специально созданных ключей. Все это вопросов не вызывает, примерно этого мы и ожидали, но есть нюансы.
IAM Policy
Управление доступом осуществляется при помощи политик IAM Policy, а правила пишутся в формате JSON и в этот момент начинают закрадываться некоторые сомнения, что легко не будет, потому что придется писать код самостоятельно, а не просто нажимать на кнопки.
Например,
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FullAccess",
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": ["*"]
}
]
}
Это политика, например, даёт доступ ко всем S3 хранилищам, но запрещает работать с объектами в S3 хранилище my-secure-bucket.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllObjectActions",
"Effect": "Deny",
"Action": "s3:*Object",
"Resource": ["arn:aws:s3:::my-secure-bucket/*"]
}
]
}
Политики вполне понятны без специальной подготовки, хотя, когда их становится много, приходится разбираться, как они пересекаются между собой. Так, например, если оба приведенных выше примера будут применены, то, с одной стороны, вы получите полный доступ к службе S3, а с другой – не будете иметь доступа к конкретному хранилищу.
Можно пойти более простым путем и использовать группы пользователей. Работают они примерно так же, как группы в других сервисах – не имеют собственных учётных данных, просто являются контейнерами для учётных записей. Именно учётных записей, потому что вкладывать группы внутри групп нельзя. Есть ещё ряд ограничений, с которыми можно ознакомиться в документации, но они, как правило, не касаются работы с маленькими и средними проектами.
Использование ролей имеет одно существенное ограничение – лимит на количество пользователей в IAM. Бесконечно создавать их не получится – 5000 и ни пользователем больше. Кроме этого, один пользователь IAM не может быть членом более, чем 10 групп. Поэтому, если вы думали перетащить свой огромный Active Directory в облако, то лучше пересмотреть стратегию уже сейчас, однако альтернативное решение есть, в помощь нам механизм – IAM Roles.
IAM Roles
Роль не предназначена для того, чтобы персонифицировать конкретного пользователя. Она показывает ваши права в какой-то момент времени. Её берут и используют другие учётные записи на какое-то время, чтобы выполнить определённые действия.
Работает это так: допустим, вы мобильный клиент, которому нужно что-то сделать в AWS-приложении. Я могу создать для вас аккаунт, а могу создать роль. И эту роль вы будете получать, когда аутентифицируетесь.
Вы спросите где аутентифироваться, если нет аккаунта? Вы ведь замечали, что при регистрации в приложении вам предлагают подключаться с помощью Google, Twitter или чего-то подобного? Это как раз потому что мы не создаём новые учётные записи, а используем какой-нибудь внешний источник. Так же вы можете развернуть в облаке Active Directory и использовать его аккаунты.
Звучит избыточно и сложно. Какая же разница, если и в том, и в другому случае я аутентифицирируюсь и получаю некие права? Дело в том, как это устроено внутри: к IAM User мы добавляли некие права через Inline policy либо Managed policy. У ролей ситуация немного другая.
Для роли есть Trust Policy и Permission policy. Trust Poliсy указывает на то, какие сущности могут получить эту роль. Если политика и Identity совпали, AWS выдаст нам временные учётные данные. И теперь каждый раз, когда эти временные учётные данные используются, их права проверяются в permission policy.
Из всего вышеописанного делаем вывод, что лучшим вариантом будет использование ролей, а не учетных записей, ведь в таком случае, во-первых, мы не храним учётные записи в приложении. Во-вторых, мы можем не заставлять пользователя плодить новые учётные записи под новое приложение, и наконец, у нас больше не будет лимита в 5000 пользователей.
Материал подготовил руководитель группы защиты инфраструктурных ИТ-решений компании «Газинформсервис» Сергей Полунин, блог Сергея можно почитать по ссылке.