IAM

IAM определяет, кто что может делать с ресурсами AWS. Типы субъектов: users (люди), roles (для сервисов и federated identity), groups. Policies — JSON-документы allow/deny; явный deny побеждает.

Для Node.js в AWS предпочитайте roles вместо access keys: instance profiles EC2, task roles ECS, execution roles Lambda, IRSA в EKS — временные credentials через STS. Ограничивайте policies ARN ресурсов, conditions (source IP, MFA) и permission boundaries для сторонних интеграций.

| Примитив | Типичное применение | |----------|---------------------| | Role | Runtime-credentials приложений и автоматизации | | Policy | На identity или на ресурс | | Service control policy | Ограничители на уровне организации |

На интервью: least privilege, role chaining, cross-account доступ, resource-based policies (bucket policy S3 vs IAM policy) и почему долгоживущие `AKIA` в `.env` — красный флаг.

Типовые ошибки: `*` на actions и resources; один мощный role на все микросервисы; ключи во frontend bundle; нет аудита break-glass для admin roles.

Компромисс — тонкая безопасность против разрастания policies и медленного онбординга без хороших defaults и IaC.

Чеклист:

• Без статических ключей в коде и логах CI.
• Отдельный role на сервис с минимальными actions.
• IAM Access Analyzer и периодический пересмотр policies.
• MFA и SSO для человеческого доступа.