Ваша учетная запись AWS является одной из самых ценных вещей, которыми вы владеете, если вы ведете бизнес на AWS. Если у вас есть только одна учетная запись AWS, вы сталкиваетесь с серьезной угрозой безопасности! Пост покажет вам, почему это проблема и как вы можете ее решить.
Опасный дефолт: одна учетная запись AWS
Одна учетная запись AWS содержит пользователей IAM вместе с виртуальными серверами EC2, корзинами S3, базами данных RDS и всем остальным, что нужно для ведения бизнеса. В основном у вас есть два способа входа в свою учетную запись: Консоль управления AWS (используя имя пользователя + пароль) или учетные данные доступа AWS, используемые CLI и SDK. На рисунке показано, как это работает.
Когда вы печатаете что-то вроде
$ aws ec2 describe-instances
в вашем терминале ваши учетные данные для доступа к AWS (обычно находящиеся где-то в ~ / .aws /) используются для аутентификации вашего запроса. Вы аутентифицируетесь как пользователь IAM. Пользователь IAM в большинстве случаев имеет AdministratorAccess
, что означает, что вы можете делать что угодно. Зачем? Потому что вам нужно иметь возможность администрировать все сервисы. Если кто-то получит доступ к вашим учетным данным AWS, у вас возникнут проблемы.
Вы можете улучшить эту ситуацию двумя способами.
1-е улучшение: не используйте пользователя с AdministratorAccess
Чтобы следовать принципу наименьших привилегий , вряд ли это AdministratorAccess
то, что вам нужно. PowerUserAccess
является улучшением, потому что не позволяет использовать службу IAM. Гораздо лучше иметь ReadOnlyAccess
и использовать права на запись только при необходимости. Но это сложно реализовать с помощью пользователей IAM. Вам нужно создать пользователя для каждой «наименьшей привилегии», и вам нужно создать учетные данные для доступа для каждого пользователя. Это быстро становится неуправляемым, если вы не единственный пользователь в своей учетной записи AWS. Я назову этот долг по безопасности .
2-е улучшение: использовать многофакторную аутентификацию
AWS обеспечивает отличную поддержку многофакторной аутентификации (MFA). Вы можете использовать аппаратное или программное устройство для генерации токена. Ваш пароль или учетные данные для доступа вместе с токеном MFA затем используются для аутентификации. Получить доступ к вашей учетной записи теперь гораздо сложнее.
Читайте дальше, чтобы узнать, как реализовать эти улучшения.
Разделение проблем с бастионным аккаунтом
Вместо одной учетной записи AWS вы создаете другую учетную запись. Я назову это твоим бастионным аккаунтом. Аккаунт бастиона содержит только ваших пользователей IAM — больше ничего. На рисунке проиллюстрирована идея.
Пользователи IAM в бастионной учетной записи очень ограничены. Они могут получить только временные полномочия и принять на себя роль. Реализуйте это, создав группу в учетной записи бастиона со встроенной политикой следующим образом:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "*",
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
},
{
"Sid": "2",
"Effect": "Allow",
"Action": [
"sts:GetSessionToken"
],
"Resource": "*"
}
]
}
Назначьте эту группу всем пользователям IAM в учетной записи бастиона. Убедитесь, что к ним не прикреплены никакие другие политики!
Первый Statement
позволяет пользователю взять на себя роль (но только если запрос аутентифицирован с использованием MFA). Второй Statement
позволяет пользователю получить временный сеанс, предоставив токен MFA. Давайте посмотрим, как это работает.
Безопасное решение: MFA с ролью делегирования
Пришло время подвести итог решения: как оно работает? На следующем рисунке показан процесс проверки подлинности MFA и делегирования ролей.
- У вас есть учетные данные доступа AWS для вашего пользователя IAM в учетной записи бастиона на вашем компьютере (обычно в ~ / .aws / или в переменных вашей среды). Вы вызываете API AWS для получения временных учетных данных, предоставляя токен MFA. Если токен MFA действителен, вы создали временный сеанс для пользователя IAM в учетной записи бастиона.
- Вы получаете временные учетные данные для аутентификации в качестве пользователя IAM.
- С помощью временных учетных данных вы можете взять на себя роль в другой учетной записи (раньше это было невозможно, поскольку предполагать, что роль разрешена для этого пользователя, только если пользователь прошел проверку подлинности с помощью MFA). Чтобы принять роль в другой учетной записи, роль должна быть явно разрешена для использования с вашей учетной записью! Максимальные разрешения, которые должна иметь роль, —
PowerUserAccess
. Не позволяйте роли взаимодействовать с IAM! - Вы получаете временные учетные данные и можете начать работу со своей учетной записью AWS.
Реализация
CLI AWS можно использовать с MFA. Андреас написал подробные инструкции здесь .
Узнайте больше о Amazon Web Services
Вы заинтересованы в получении дополнительной информации о Amazon Web Services? Андреас и я пишем книгу под названием « Amazon Web Services in Action» , опубликованную Мэннингом. Книга написана для разработчиков и инженеров DevOps, которые переводят традиционно развернутые распределенные приложения на платформу AWS. Опыт работы с AWS не требуется.