Термины и базовая логика: что такое IAM и зачем он нужен
Сегодня поговорим о Cloud IAM. Это штука, без которой любая облачная инфраструктура рано или поздно превращается в проходной двор. IAM расшифровывается как Identity and Access Management — управление идентичностями и доступом. Если перевести на человеческий: это набор правил, который отвечает на три базовых вопроса:
- Кто ты? (пользователь, сервис, команда, подрядчик)
- Что тебе можно? (какие действия разрешены)
- Где границы? (в каких проектах, ресурсах и при каких условиях это действует)
Почему IAM настолько важен именно в облаке? Потому что в облаке “периметр” — это не стены дата-центра и не офисная сеть. Периметр — это доступ. Один удачно украденный пароль или слишком широкая роль — и злоумышленнику не нужно “ломать сервер”. Ему достаточно войти как легитимный пользователь и делать то, что ему разрешили.
Отсюда вытекает главная мысль: облачная безопасность начинается не с фаервола и шифрования, а с того, кто и на каких правах может что-то делать.
IAM нужен не только для защиты от внешних атак. Он ещё и про контроль внутри компании:
- Чтобы у сотрудников были доступы ровно под их задачи, а не “на всякий случай”;
- Чтобы подрядчики не оставались с вечными правами после завершения работ;
- Чтобы сервисы (например, приложение или CI/CD) не работали под человеческим аккаунтом “админа”;
- Чтобы можно было разобраться, кто сделал изменение, когда и зачем.
Обычно в такие моменты появляется типичная иллюзия новичка: “у нас же маленький проект, мы и так всё помним”. На практике IAM ломается не из-за сложных атак, а из-за скучных вещей: общий аккаунт на команду, отсутствие MFA, один ключ “на всё”, и роли типа Admin, которые выдали “временно”, а потом забыли.
В следующих разделах мы разберём IAM без заумных слов: из чего он состоит, чем роли отличаются от политик, зачем нужна MFA и как работает принцип least privilege, чтобы было безопасно — и при этом не превращалось в бюрократию.
Из чего состоит IAM: кто, что и на каких условиях может делать
Идентичности: пользователи, группы, сервисные аккаунты
В IAM под “идентичностью” понимают того, кому вы выдаёте права. Это не только живой человек. В облаке действуют три самые частые категории.
Пользователи (users) — это люди. Сотрудники, админы, разработчики, аналитики, подрядчики. У пользователя есть логин, методы входа (пароль, SSO, MFA), и именно пользователь обычно инициирует действия руками: заходит в консоль, запускает деплой, смотрит логи, меняет конфигурации.
Главная ошибка, которая тут встречается, — воспринимать пользователя как “роль”. То есть создавать один общий аккаунт “DevOps” и давать ему всё. В реальности пользователь должен быть конкретным человеком, чтобы потом можно было ответить на простой вопрос: кто именно сделал изменение.
Группы (groups) — это способ не выдавать права каждому пользователю вручную. Вы объединяете людей по смыслу: “developers”, “billing”, “security”, “support”, “read-only”, и назначаете права на группу. Дальше жизнь становится проще: пришёл новый сотрудник — добавили в нужные группы, и он автоматически получил ровно то, что нужно. Ушёл сотрудник — удалили из групп и доступы исчезли.
Сервисные аккаунты (service accounts) — это самый важный момент для облака. Сервисный аккаунт — это идентичность не человека, а приложения или сервиса. Например, ваше приложение должно читать из очереди, писать в базу, складывать файлы в object storage. Делать это под личной учётной записью сотрудника — плохая идея. Люди увольняются, пароли меняются, доступы отзываются. Приложение же должно работать стабильно и предсказуемо.
Поэтому для автоматизации, приложений, CI/CD, интеграций создают отдельные сервисные аккаунты и выдают им права строго под задачу. Плюс это сильно упрощает расследования: видно, что действие сделал не “кто-то из команды”, а конкретный сервис.
Есть ещё одна важная деталь: сервисный аккаунт не должен быть “суперадмином на всё”. Это часто делают по привычке “чтобы не отвалилось”, а потом именно этот ключ утекает в логах или репозитории — и начинается веселье.
Если подытожить:
- Пользователи — для людей,
- Группы — чтобы управлять людьми массово и аккуратно,
- Сервисные аккаунты — для программ и автоматизации.
Дальше нам нужно ответить на следующий вопрос: что именно разрешено этим идентичностям. И тут мы подходим к ролям и политикам — где обычно и начинается путаница.
Права доступа: роли и политики (allow/deny)
Тут важно не запутаться в терминах. Политика (policy) — это набор правил доступа: какие действия разрешены или запрещены, над какими ресурсами и иногда при каких условиях. Роль (role) — это удобная “упаковка” таких правил под типовую задачу. То есть политика — это конкретика, а роль — понятный ярлык вроде “ReadOnly” или “Developer”, за которым спрятан набор разрешений.
Почти везде встречаются две логики:
- Allow — разрешить действие.
- Deny — запретить действие.
Deny часто недооценивают, но именно он помогает подстраховаться от “случайных” широких прав. Например, можно разрешить команде работать с ресурсами, но жёстко запретить удаление критичных объектов или изменение настроек безопасности. В системах, где deny сильнее allow, это работает как ремень безопасности: даже если кто-то получил лишнее, запрет всё равно остановит опасное действие.
Ещё один неочевидный момент: доступ почти никогда не бывает “в целом”. Он почти всегда привязан к ресурсам и контексту. Можно иметь право читать логи в одном проекте и не иметь его в другом. Можно создавать VM в dev-среде, но не иметь таких прав в production. И именно в этом смысл IAM: доступ “по делу”, а не “по всей инфраструктуре”.
Чтобы это не превращалось в хаос, обычно хватает одной простой привычки: выдавайте роли группам и сервисным аккаунтам, а не раздавайте права точечно каждому человеку. Тогда доступ становится управляемым: пришёл новый сотрудник — добавили в группу, ушёл — удалили, изменилась роль в проекте\компании - изменили группу\группы. И ничего не нужно “вспоминать руками”.
Итого: роли и политики — это язык, на котором вы описываете доступ. Как только вы перестаёте раздавать “всё всем” и начинаете мыслить “какое действие, над каким ресурсом и кому именно”, IAM становится вашим главным инструментом контроля.
MFA и безопасный вход: как закрыть самый частый риск
Если бы нужно было выбрать одну настройку, которая чаще всего спасает облачную инфраструктуру от неприятностей, это была бы MFA.
MFA (Multi-Factor Authentication) — многофакторная аутентификация. По сути, это правило “одного пароля недостаточно”. Чтобы войти, нужно подтвердить вход вторым фактором: кодом из приложения-аутентификатора, push-подтверждением, аппаратным ключом и т.д.
Почему это так важно? Потому что самый частый сценарий взлома в облаке — не “хакеры пробили фаервол”, а гораздо скучнее: у кого-то утек пароль. Фишинг, повтор пароля с другого сервиса, утечка базы, пароль в заметках, пароль в чате, заражённый ноутбук — способов много. И если у вас нет MFA, один пароль часто означает “добро пожаловать внутрь”.
С MFA картина меняется: даже если пароль оказался у злоумышленника, ему всё равно нужен второй фактор. Да, MFA — не абсолютная броня (есть атаки и на неё), но это резкий рост сложности атаки и огромный фильтр от массовых взломов.
Есть ещё одна практическая причина включать MFA: она защищает не только от внешних угроз, но и от внутренних ошибок. Например, сотрудник случайно логинится не туда, попадает на поддельную страницу, вводит пароль — и вот он уже “подарил” доступ. MFA часто становится последним стоп-краном.
Чтобы MFA реально работала, важно не свести её к формальности. Самые частые ошибки здесь — включить MFA “для админов”, а остальные оставить как есть, или разрешить обход MFA через слабые механизмы восстановления доступа.
По-хорошему, MFA должна быть:
- Обязательной для всех пользователей, у кого есть доступ к консоли и критичным операциям;
- Особенно строгой для привилегированных ролей (админы, security, billing);
- Частью нормального процесса входа (а не “иногда просит код”).
Если хотите совсем короткое правило: пароль — это то, что можно украсть. MFA — это то, что обычно украсть сложнее. И в IAM это один из самых дешёвых способов закрыть большой класс рисков.
Принцип least privilege: как выдавать минимум прав и не ломать работу
Принцип least privilege звучит строго, но по факту он про здравый смысл: каждый пользователь или сервис должен иметь минимальный набор прав, который реально нужен для работы — не больше.
Почему это важно? Потому что в облаке “лишние права” — это как лишние ключи от всех дверей. С ними проще жить… пока не случится неприятность. А неприятность в IAM почти всегда выглядит одинаково: кто-то получает доступ, который ему не нужен, и этот доступ однажды используют — случайно или намеренно.
Давай на примере.
Представим компанию StepUp, которая продаёт степперы для ходьбы через интернет. У них есть сайт, складская система, CRM и аналитика. Всё это работает в облаке. Команда небольшая, времени вечно не хватает, поэтому в какой-то момент они делают “как проще”: дают разработчику роль Admin, потому что “ему же нужно всё настроить”, а подрядчику по рекламе — доступ к консоли, потому что “ему надо поставить пиксель и выгрузить отчёт”.
И вот здесь начинается классическая ловушка. Разработчик не злодей и не халтурщик — он просто живёт в режиме “сегодня надо, чтобы работало”. Admin кажется идеальным решением: не нужно каждый раз просить доступ, ждать согласования и ловить ошибки “permission denied” в самый неподходящий момент.
План выглядит разумно: “сделаю сейчас быстро, а потом сузим права до нужного минимума”. Но “потом” обычно проигрывает реальности. Вылезает баг, срочно нужен хотфикс, параллельно горит релиз, затем прилетает ещё одна задача — и широкая роль остаётся висеть как технический долг. Причём невидимый: всё же работает, значит “проблемы нет”.
А дальше добавляется второй фактор — подрядчики. Их зовут под конкретную задачу, а доступ выдают с запасом “чтобы не дёргали”. В результате у StepUp получается типичный набор: несколько аккаунтов с правами шире нужного, и ни у кого нет времени разбираться, где именно границы.
Первое время всё нормально. А потом происходит история из серии “никто не хотел, но получилось”:
- Подрядчику приходит письмо “подтвердите вход”, он вводит пароль на фишинговой странице;
- Злоумышленник заходит в консоль под этим аккаунтом;
- у аккаунта оказывается доступ шире, чем нужно (например, не только к аналитике, но и к хранилищам/секретам/настройкам);
- Дальше уже вопрос фантазии: можно выгрузить клиентские данные, подменить конфиги, слить ключи, поднять ресурсы под майнинг — и всё это будет выглядеть как “легитимный вход”, потому что права были выданы заранее.
Обратим внимание, что злоумышленнику даже не нужно “взламывать облако”. Ему достаточно один раз войти под чужим аккаунтом — а дальше облако честно выполнит всё, на что этому аккаунту разрешили права.
Самое обидное в таких историях: проблема не в облаке, и даже не в MFA (хотя оно бы помогло). Проблема в том, что доступы выдавались “на всякий случай”.
Как least privilege помогает, но без боли для команды?
Во-первых, доступы выдаются не “человеку вообще”, а под конкретную задачу. Нужен доступ к отчётам — даём доступ к отчётам, а не ко всей инфраструктуре. Нужен деплой — даём право деплоить, но не удалять production-ресурсы.
Во-вторых, появляется понятная привычка: права по умолчанию минимальные, расширение — только по запросу. Это не бюрократия, если вы делаете это через роли и группы. На практике это выглядит так: есть стандартные роли (“read-only”, “developer”, “ops”, “billing”), и вы просто добавляете человека в нужную группу.
В-третьих, least privilege отлично сочетается с временными доступами. Очень частая ситуация: нужно “на час” дать право изменить настройку или провести миграцию. И вот здесь правильный подход — дать доступ на время, а не навсегда. В зрелых командах это превращается в нормальный процесс: доступ повышается, задача делается, доступ автоматически откатывается.
И, наконец, самое важное: least privilege относится не только к людям, но и к сервисам. Если приложение StepUp читает сообщения из очереди и пишет результаты в базу — ему не нужен доступ к управлению сетью, к биллингу и к созданию новых ключей. Сервисные аккаунты должны быть “узкими” по правам — это один из лучших способов ограничить ущерб, если ключ всё-таки утечёт.
Итог простой: least privilege не делает систему “невзламываемой”, но резко снижает радиус поражения. Даже если доступ где-то утёк, злоумышленник упрётся в ограничения и не сможет развернуться на полную.
Быстрый чек-лист настройки Cloud IAM
Чтобы не утонуть в деталях, полезно держать под рукой короткий baseline: несколько проверок, которые быстро показывают, насколько IAM у вас “в порядке” или где есть очевидные дыры. Пройдитесь по таблице — это занимает пару минут, зато сразу видно, что стоит подкрутить в первую очередь:
| Проверка | Зачем это нужно | Быстрый признак “всё ок” |
| MFA включена для пользователей с доступом к консоли | Закрывает самый частый риск: украденный пароль | MFA обязательна хотя бы для привилегированных ролей, лучше — для всех |
| Нет общих аккаунтов “на команду” | Аудит и ответственность: кто сделал изменение | У каждого человека свой аккаунт, доступы управляются централизованно |
| Доступы выдаются через группы/роли | Управляемость и масштабирование доступа | Новичка добавляют в группу — и он получает ровно нужные права |
| Least privilege реально применяется | Снижает радиус ущерба при утечке | Админка не “по умолчанию”, права узкие и под задачу |
| Production отделён от dev/stage | Ошибки в тесте не бьют по бою | Отдельные проекты/аккаунты или хотя бы жёсткие ограничения доступа к prod |
| Сервисные аккаунты используются для приложений/CI/CD | Автоматизация не должна работать “от имени человека” | У сервисов отдельные аккаунты и минимальные права |
| Секреты хранятся в нормальном месте | Ключи и токены — частая причина компрометации | Secret manager, запрет секретов в репозитории/чатах, ротация |
| Включён аудит действий и логи | Чтобы расследовать инциденты и ловить аномалии | Видно, кто менял роли, политики, публичность, ключи |
| Есть процесс offboarding | “Ушёл человек” не должен означать “остался доступ” | Доступы отзываются быстро, ключи/токены пересматриваются |
Если по большинству пунктов у вас уверенное “да” — значит базовая гигиена IAM уже на хорошем уровне. А если где-то получилось “нет” или “не уверен”, это отличный список задач для ближайшей итерации: IAM проще всего улучшать маленькими шагами, но эффект от этих шагов обычно очень заметный.
Заключение
Управление доступом в облаке — это не “страшные политики”, а простой ответ на главный вопрос: кто может войти, что ему разрешено и на каких условиях. Как только вы начинаете мыслить этими тремя пунктами, доступ перестаёт быть хаосом и становится управляемым.
Дальше всё держится на базовой гигиене: роли и правила доступа дают структуру, двухфакторная аутентификация закрывает самый частый риск со взломом аккаунтов, а принцип минимально необходимых прав не даёт одной ошибке (или утечке) превратиться в катастрофу.
Если нужен короткий итог, он такой: в облаке безопасность часто начинается не с сетевых настроек, а с доступа. И чем раньше вы приводите права в порядок, тем меньше сюрпризов прилетает потом — и по безопасности, и по стабильности инфраструктуры.
