Политики AWS IAM, которые различают доступ через консоль и ключи доступа

Содержание

Вопрос или проблема
Ответ или решение
Понимание проблемы
Проблемы с инструментами IAM
Возможные решения
Заключение

Вопрос или проблема

Вопрос:
Как можно разработать политику AWS IAM, чтобы различать доступ через консоль (веб) и доступ по ключу (API)?

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

Конкретный случай заключается в том, что я доверяю некоторым пользователям AWS полные права IAM, так как у них есть 2факторная аутентификация для доступа к консоли. Они не используют 2факторную аутентификацию для доступа по ключу и это значительно проще злоупотребить. Тем не менее, им также нужен некоторый доступ (чтение) по ключу доступа (API), так как они используют инструменты аудита и часто работают с CLI.

Продвижение:
Компонент condition в политике AWS IAM выглядит многообещающе, я смог эффективно использовать его для обеспечения использования IAM;

"Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }

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

Очевидно, я не могу.

AWS не различает аутентификацию по ключу доступа и пароль консоли. Есть некоторые временные учетные данные и условия политики IAM по 2FA, но они не подходят для нашего случая использования.

Можно использовать некоторые условия IAM для соответствия моему или подобным случаям использования, но не так, как я планировал;

условие UserAgent для различия между пользователями cli, браузера и sdk. НО ОСТОРОЖНО, его ЛЕГКО подделать, это НЕ является надежным контролем.
условие sourceVpc
(применить глобальную политику 2FA и исключить все из вашего VPC, таким образом приложения, работающие с ключами доступа пользователя AWS IAM, не будут нарушены. Хотя я знаю, что они не должны, но они есть);

"Condition": { "StringNotEquals": { "aws:sourceVpc": "vpc-111bbb22" } }

Ответ или решение

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

Понимание проблемы

В данном сценарии требуется предоставить определенной группе пользователей полный доступ к управлению IAM через веб-интерфейс (консоль), в то время как доступ через ключи API должен быть ограничен только правами на чтение. Это вызвано тем, что пользователи с доступом к консоли защищены двухфакторной аутентификацией (2FA), в то время как доступ по ключам API не имеет такой строгой безопасности.

Проблемы с инструментами IAM

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

Возможные решения

Использование условий на основе User-Agent:
Вы можете попытаться использовать aws:UserAgent в условиях вашей политики. Это позволяет различать запросы, поступающие из разных клиентов, но вызывает ряд рисков. Например, заголовок User-Agent может легко быть подделан, что открывает возможности для злоупотреблений. Вам следует использовать это решение с осторожностью.

Пример политики:
```
{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Action": "iam:*",
           "Resource": "*",
           "Condition": {
               "StringEquals": {
                   "aws:UserAgent": "aws-sdk-java/1.*"  // Пример для SDK
               }
           }
       },
       {
           "Effect": "Deny",
           "Action": "iam:*",
           "Resource": "*",
           "Condition": {
               "StringEquals": {
                   "aws:UserAgent": "Mozilla/5.0"*  // Пример для браузера
               }
           }
       }
   ]
}
```

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

Пример политики:

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Action": "iam:*",
           "Resource": "*",
           "Condition": {
               "StringEquals": {
                   "aws:sourceVpc": "vpc-111bbb22"
               }
           }
       },
       {
           "Effect": "Deny",
           "Action": "iam:*",
           "Resource": "*",
           "Condition": {
               "StringNotEquals": {
                   "aws:sourceVpc": "vpc-111bbb22"
               }
           }
       }
   ]
}

Создание отдельных ролей:
Один из наиболее безопасных подходов заключается в создании отдельных ролей для доступа к консоли и API. Например, пользователям с двухфакторной аутентификацией можно предоставить доступ к роли с полными правами управления IAM через консоль. В то же время, для доступа по API можно создать отдельную роль с правами только на чтение и назначить ее только тем пользователям, которым это необходимо.
Мониторинг и ведение журналов активности:
Независимо от того, какую политику вы решите применить, важно проводить тщательный мониторинг активности пользователей. Используйте AWS CloudTrail для отслеживания действий пользователей и AWS Config для управления конфигурациями популярных сервисов AWS.

Заключение

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