Управление доступом в облаке: IAM, роли и минимальные привилегии
Ошибки в управлении доступом могут поставить под угрозу безопасность облачной инфраструктуры. Общие учетные записи администраторов, ключи доступа в репозиториях, неотозванные права уволенных сотрудников и избыточные привилегии увеличивают риск утечки данных и несанкционированных действий. Дополнительная проблема возникает, когда сервисы работают от имени личных учетных записей сотрудников.
Снизить эти риски помогает система управления доступом IAM (Identity and Access Management). В статье разбираем, как распределять права между пользователями и сервисами, настраивать роли и применять принцип минимальных привилегий, чтобы каждый получал доступ только к тем ресурсам, которые нужны для работы.
- Управление доступом и IAM: что это
- Модели и типы управления доступом: RBAC, ABAC, ReBAC и другие
- Какую модель управления доступом выбрать
- Принцип минимальных привилегий (Least privilege)
- Сервисные учетные записи: доступ для программ, а не людей
- Ключи и токены
- MFA, SSO и защита входа
- Аудит и ревизия прав
- Как устроено управление доступом в Cloud.ru
- Чек-лист: 10 практик управления удаленным доступом
Управление доступом определяет, кто и какие действия может выполнять с ресурсами. В облачной инфраструктуре для этого используют IAM (Identity and Access Management) — систему управления идентификацией и доступом. Она помогает назначать права пользователям и сервисам, контролировать доступ к ресурсам и ограничивать действия в соответствии с рабочими задачами.
Многие путают понятия аутентификации (Authentication) и авторизации (Authorization). Объясним разницу по этапам:
- Сначала пользователь входит в систему и "представляется" — вводит логин. Это идентификация.
- Дальше пользователь с помощью пароля, токена, одноразового кода или биометрии доказывает системе, что он тот, за кого себя выдает. Система проверяет, совпадают ли данные с логином. Это аутентификация.
- Успешный вход еще не значит, что пользователь получит доступ ко всем ресурсам. Система проверяет политики и определяет, какие у субъекта права и что ему разрешено. Это авторизация.
Система делает свое дело, а владельцы ресурсов должны делать свое — регулярно проверять по журналам, кто заходил, когда и зачем. Это аудит. Он помогает обнаруживать избыточные привилегии и расследовать инциденты несанкционированного доступа.
Аудит помогает обнаруживать избыточные привилегии и расследовать инциденты несанкционированного доступа. Чтобы отслеживать действия пользователей и сервисных учетных записей в облаке, можно использовать сервис"Аудит-логирование". Он позволяет просматривать и фильтровать журналы событий, настраивать оповещения о важных событиях и выгружать логи во внешние системы.
IAM — набор инструментов и процессов, позволяющих управлять учетными записями, ролями и правами доступа пользователей. Он работает вокруг взаимосвязанных сущностей:
- Пользователи — сотрудники, программы или службы, которые имеют доступ к облачным ресурсам.
- Роли — наборы полномочий для должностей или рабочие задачи.
- Политики — правила, определяющие, кому и при каких условиях можно дать доступ к конкретным ресурсам.
- Сервисные аккаунты — учетные записи для виртуальных машин, программ и приложений, созданные под автоматизированные процессы.
- Права и разрешения — конкретные действия, которые пользователь может выполнять, например, читать данные, менять настройки, создавать ресурсы, удалять объекты и прочее.
Многие путают IAM со СКУД (система контроля и управления доступом), которая решает похожие задачи. Однако она работает на физическом уровне — контролирует доступ людей на служебные объекты. IAM по логике делает то же самое, но в цифровой среде.
Модель управления — это система распределения полномочий. Сейчас компании в основном используют две — RBAC (Role-Based Access Control) и ABAC (Attribute-Based Access Control).
RBAC основана на ролях — наборах полномочий, связанных с должностями и рабочими задачами. Это удобно, поскольку не требует назначения отдельных прав. Например, есть роль "Менеджер по продажам" с доступом к CRM, отчетам и карточкам клиентов, привилегиями на чтение/изменение данных. Если для какой-то задачи прав не хватает, сотрудник может запросить их по заявке.
При переходе работника на другую должность достаточно сменить роль. Такой подход снижает нагрузку на администраторов и минимизирует вероятность ошибок при назначении прав.
RBAC — простая в базовом администрировании модель, которая хорошо подходит для среднего и крупного бизнеса. Однако ее гибкость ограничена: при большом количестве исключений и динамических сценариев число ролей быстро растет, что порождает путаницу и усложняет сопровождение.
RBAC особенно эффективна в компаниях, где роли сотрудников устойчивы и повторяются: чем больше людей с одинаковым набором задач, тем выше отдача от модели. В небольших командах с сильно различающимися обязанностями затраты на формализацию ролей могут не окупиться — в таких случаях стоит рассмотреть упрощенные схемы или ABAC с небольшим числом правил.
ABAC (Attribute-Based Access Control) определяет права доступа на основе атрибутов пользователя, ресурса и контекста запроса. В отличие от RBAC, где права связаны с ролями, ABAC позволяет учитывать дополнительные условия: IP-адрес устройства, тип и уровень конфиденциальности ресурса, геолокацию, время обращения и другие параметры.
Например, бухгалтер может получать доступ к счетам и отчетам только в рабочее время, с определенного IP-адреса и на период выполнения задачи. Система проверяет заданные условия при каждом запросе и разрешает доступ, только если они соблюдены. Это позволяет точнее разграничивать права без создания множества узкоспециализированных ролей и постоянного расширения полномочий по заявкам.
ABAC сложнее внедрить, чем RBAC: необходимо централизованно управлять атрибутами, следить за актуальностью данных и поддерживать политики доступа. Современные IAM-платформы, в том числе Microsoft Entra, AWS IAM и Google Cloud IAM, поддерживают атрибутивные политики и помогают упростить их настройку. Поэтому ABAC подходит не только крупным компаниям, но и среднему бизнесу с достаточно зрелыми процессами управления доступом.
Модель особенно полезна, когда права зависят не только от роли сотрудника, но и от контекста запроса. Чтобы ABAC работала корректно, важно регулярно обновлять атрибуты и пересматривать политики доступа.
MAC (Mandatory Access Control) — мандатная модель управления доступом, в которой права определяются централизованными правилами и уровнями конфиденциальности. Ресурсам присваивают грифы, например "не секретно", "секретно" и "строго конфиденциально", а пользователям назначают соответствующие уровни доступа. Пользователь не может самостоятельно изменить эти правила.
Например, менеджер может работать с несекретными документами, но не сможет открыть секретный отчет, если его уровень доступа этого не позволяет. Даже согласие руководителя не отменяет установленных ограничений: для доступа потребуется официально изменить полномочия сотрудника. MAC обеспечивает строгий контроль, но ограничивает гибкость управления правами.
DAC (Discretionary Access Control) — дискреционная модель, в которой владелец ресурса или администратор определяет, кто и какие действия может с ним выполнять. Например, владелец документа может разрешить коллеге просмотр или редактирование, а при необходимости отозвать эти права.
DAC проще адаптировать к повседневным задачам, но при большом количестве пользователей и ресурсов сложнее поддерживать единообразные правила доступа. Если полномочия владельцев и администраторов не ограничены должным образом, они могут случайно или намеренно предоставить лишние права.
MAC и DAC решают разные задачи, но в крупных корпоративных инфраструктурах их бывает недостаточно для удобного управления доступом в масштабе. На практике также применяют модели RBAC и ABAC: первая распределяет права по ролям, вторая учитывает атрибуты пользователя, ресурса и контекста запроса.
Выбор модели зависит от структуры организации, требований безопасности и сложности правил доступа. RBAC подходит для распределения прав по ролям, ABAC — для сценариев с дополнительными условиями, а DAC — для ресурсов, доступ к которым определяют их владельцы.
Сравним три модели по основным критериям.
ReBAC (Relationship-Based Access Control) определяет права доступа на основе связей между пользователями и ресурсами. Система учитывает, например, является ли человек владельцем документа, участником проекта или руководителем отдела. В зависимости от этих отношений она разрешает или ограничивает действия с ресурсом.
Такой подход удобен для корпоративных сервисов совместной работы, систем с иерархией подразделений и платформ, где доступ зависит от принадлежности к проекту или команде. Например, участники проекта могут просматривать его документы, а руководитель проекта — дополнительно изменять настройки доступа.
ReBAC отличается от RBAC тем, что учитывает не только назначенную пользователю роль, но и его конкретные отношения с ресурсом. Модель можно сочетать с RBAC и ABAC, если для принятия решения нужно учитывать одновременно роль пользователя, связи и дополнительные условия. Один из известных примеров реализации такого подхода — Google Zanzibar, система авторизации для управления доступом к отдельным объектам.
Это "железное" правило — полномочий должно быть ровно столько, сколько нужно для работы. Оно лежит в основе архитектуры Zero Trust ("Never Trust, Always Verify"), где каждый запрос к ресурсу проверяется заново, независимо от того, находится пользователь внутри периметра или снаружи. Рассказываем, как принцип реализуется и какие ошибки совершают компании.
Нужно отталкиваться от бизнес-ролей. Определите, какие задачи выполняют конкретные сотрудники, какие системы и данные используют. Например, менеджеру по продажам требуется доступ к CRM для просмотра и редактирования карточек клиентов, а административные права не нужны. Если предоставленных полномочий не хватает, можно дать временные через процедуру согласования. Главное, по истечению срока не забыть их отозвать.
При ролевой модели роли нужно периодически пересматривать, поскольку меняются обязанности сотрудников, появляются новые системы и проекты. Для автоматизации выдачи и отзыва прав при найме, переводе и увольнении используется протокол SCIM (System for Cross-domain Identity Management) — он синхронизирует учетные записи между HR-системой и IAM-провайдером.
Нужно разделять тестовую и продуктивную среды, поскольку они решают разные задачи. Например, разработчику нужен широкий доступ к тестовой, где он может менять код, настройки и данные. Однако это не значит, что такой же доступ и такие же действия будут разрешены в продуктивной среде. Если аналогичные полномочия все же нужны, их предоставляют на ограниченный срок.
Для эффективного управления корпоративными доступами важно заранее определить и зафиксировать, кто и какие действия может выполнять в каждой среде. Должны быть четкие регламенты, которые нужно постоянно актуализировать при изменениях в инфраструктуре.
Некоторые компании (особенно те, что переходят с ручного управления доступом на автоматизированное) совершают ошибки, которые приводят к рискам ИБ:
- Общие учетки. Группа сотрудников использует одни и те же логины и пароли. Это мешает установить, кто выполнял конкретное действие.
- Постоянные пароли и ключи. Есть риск компрометации данных и взлома аккаунтов. Нужна регулярная ротация, особенно для привилегированных учеток.
- Неотозванные доступы для уволенных сотрудников. Из интереса или по злому умыслу человек может заходить в свой аккаунт и взаимодействовать с конфиденциальными ресурсами.
- Права "на всякий случай". Так накапливаются избыточные полномочия, и компания уже не может контролировать действия сотрудников.
Нужно не просто назначить права один раз, но и постоянно поддерживать их актуальность. Если необходимость в полномочиях отпала, их следует сразу отзывать.
Сервисные учетные записи (service accounts) — это учетные записи, которые используются не людьми, а машинами и службами. Например, для подключения приложений к базам данных или обмена информацией между системами через API. К конкретным сотрудникам они не привязаны, но также нуждаются в релевантных правах доступа.
Автоматизированные процессы должны выполняться под отдельными техническими аккаунтами. Это позволяет отделить действия программы от действий человека и управлять полномочиями сервисных учеток независимо от кадровых изменений.
Например, CI/CD-конвейеру нужен доступ к репозиторию, тестовой среде и инструментам развертывания. Если он выдается под личную учетную запись, права смешаются с правами разработчика.
К тому же, возникнет проблема при изменении статуса сотрудника. При переводе или увольнении личную учетку заблокируют, а значит, связанные с ней автоматизированные процессы перестанут работать. У сервисного аккаунта для CI/CD будет отдельный жизненный цикл.
Следует вести реестр сервисных учетных записей, фиксировать их владельцев и контролировать полномочия. Это поможет избавиться от бесхозных и забытых аккаунтов.
Ключи и токены позволяют сервисам и приложениям проходить аутентификацию без участия пользователя. По сути, они работают как учетные данные: с их помощью система подтверждает свою подлинность при обращении к другим сервисам. Поэтому важно ограничивать права таких учетных данных и срок их действия, а также регулярно обновлять их.
Не храните ключи и токены в исходном коде, скриптах и открытых файлах. Если посторонний получит к ним доступ, он сможет использовать их для обращения к системам от имени сервиса. Для защиты секретов используйте специализированные хранилища, например HashiCorp Vault, AWS Secrets Manager или Azure Key Vault. Доступ к таким хранилищам контролируется отдельно, а приложения получают только те секреты, которые нужны им для работы.
Управляйте секретами на протяжении всего жизненного цикла: от генерации и безопасного хранения до ротации, отзыва и уничтожения. Регулярно обновляйте ключи и токены с учетом требований безопасности и особенностей сервисов. Например, можно установить период ротации в один-три месяца, если это соответствует вашей политике безопасности. При подозрении на компрометацию секрет нужно отозвать немедленно. Устаревшие и отозванные секреты следует удалять, чтобы ими нельзя было воспользоваться повторно.
Управление доступом к данным включает и заботу о безопасности аккаунтов. Представим, что злоумышленник получил логин и пароль от корпоративной учетной записи. Значит, он без проблем сможет войти в систему и действовать от имени сотрудника. Чтобы защитить процесс входа, используется многофакторная аутентификация (MFA, Multi-Factor Authentication). Она подразумевает несколько факторов проверки. Например, помимо пароля сотрудник должен ввести одноразовый код с телефона и дополнительный ключ доступа. В зависимости от настроек аутентификации могут быть и другие факторы, например, постоянное кодовое слово, временный токен, биометрия.
Для удобства вместе с MFA используют SSO (Single Sign-On) — технологию единого входа. Пользователю достаточно пройти аутентификацию в одной системе и получить доступ к нескольким связанным. Однако полномочия в каждой могут быть разными.
С помощью MFA часто защищают вход под привилегированными учетками и доступ к административным консолям. Это снижает риски утечки данных и совершения несанкционированных действий. Дополнительную проверку можно использовать и для отдельных критичных операций, например, перед изменением важных настроек.
При этом MFA не заменяет управление правами. После успешной аутентификации сотрудник должен совершать только те действия, которые ему разрешены. Для привилегированных пользователей возможны более строгие правила, например, фиксация всех операций.
Регулярный аудит и строгий контроль привилегий позволяют вовремя замечать избыточные полномочия и подозрительные действия.
В системных журналах фиксируются все операции пользователей и сервисных учеток. Примеры записей:
- кто имеет доступ к системам, облакам и конкретным ресурсам
- какие действия совершались
- когда был вход, в какое время
Журнал можно расширить и фиксировать там все изменения прав доступа, нарушения правил работы с данными, подтверждения критичных операций. Многие компании отдельно ведут статистику по привилегированным учеткам, поскольку они связаны с повышенными рисками ИБ.
Записи помогут провести ревизию прав доступа и расследовать инциденты. Можно проверить действия с конкретными ресурсами, обнаружить нетипичные операции и установить последовательность событий.
Access review — регулярная проверка и пересмотр прав доступа. Цель ревизии — убедиться, что не возникло ненужных и избыточных полномочий.
Ответственные лица проверяют, к каким системам, данным и действиям у сотрудников есть доступ, сопоставляют с текущими ролями и задачами. Если кадровая структура менялась, права отзывают или актуализируют, учетные записи уволенного персонала блокируют.
Ревизия также помогает выявить неактуальные полномочия, которые выдавались временно в дополнение к постоянному набору. Без проверки они могут накапливаться, из-за чего нарушается принцип наименьших привилегий.
Рекомендуемая периодичность: раз в 1 месяц — для привилегированных пользователей, раз в 3 месяца — для остальных. Внеплановые ревизии проводятся после изменения ролей, увольнений и завершения проектов.
Оно построено на ролевой модели — права определяются назначенными ролями и политиками.
Доступ можно разграничивать на уровне проектов и сервисов. Политики позволяют детально настроить права, например, разрешить только определенные действия с конкретными ресурсами. При необходимости набор полномочий в рамках роли можно расширять на время.
Для автоматизированных процессов создаются сервисные аккаунты, которые позволяют обращаться к ресурсам Cloud.ru без использования учетных записей сотрудников. Для них назначаются роли с доступом к нужным проектам и ресурсам.
Для управления доступом к ресурсам облака Cloud.ru Advanced можно использовать сервис Advanced Identity and Access Management. Он позволяет создавать пользователей и группы, назначать роли и настраивать политики доступа. Это помогает централизованно управлять полномочиями и предоставлять пользователям доступ в соответствии с их задачами.
Действия в облаках фиксируются в сервисе "Аудит-логирование". Записи в журналах можно фильтровать по событиям. Также доступны настройки правил алертов и выгрузка логов во внешние системы.
За настройку доступа и журналов отвечает клиент. Однако провайдер со своей стороны тоже помогает защищать данные. Облачные платформы Cloud.ru соответствуют требованиям 152-ФЗ и аттестованы для ПДн (уровень защиты — УЗ-1). Также сервисы прошли оценку по ГОСТ Р 57580 для финансовых организаций.
Рекомендации по внедрению IAM:
- Применяйте ролевую модель доступа — задайте сотрудникам роли с готовыми правами вместо ручного назначения полномочий.
- Соблюдайте принцип минимальных привилегий — выдавайте только те полномочия, которые нужны для работы.
- Разделяйте тестовую и продуктивную среды — не переносите широкие права из тестового контура в продуктивный без необходимости.
- Ограничивайте доступ по времени — устанавливайте сроки на дополнительные полномочия.
- Откажитесь от общих аккаунтов — связывайте учетки с конкретными пользователями или службами.
- Для автоматизации используйте сервисные аккаунты — не запускайте CI/CD и другие процессы под личными учетными записями сотрудников.
- Защищайте ключи и токены — храните их в секрет-менеджере, регулярно проводите ротацию (в случае компрометации немедленно).
- Включайте MFA для привилегированного доступа — настройте дополнительные проверки пользователей с правами администратора.
- Журналируйте действия — фиксируйте входы, изменения прав и другие операции пользователей и сервисных аккаунтов.
- Проводите ревизию прав — проверяйте актуальность полномочий и отзывайте доступ при смене роли, завершении проекта или увольнении сотрудника.
Безопасное управление доступом в облаке требует постоянного контроля: недостаточно один раз настроить права, важно регулярно проверять их актуальность, отзывать ненужные разрешения и следить за использованием ключей и токенов.
IAM помогает выстроить эту работу системно. Ролевая модель упрощает распределение прав, принцип минимальных привилегий ограничивает доступ необходимыми действиями, а многофакторная аутентификация снижает риск несанкционированного входа. Вместе эти меры помогают защищать данные и инфраструктуру без лишних ограничений для сотрудников и сервисов.
Что такое IAM простыми словами?
IAM (Identity and Access Management) — комплекс практик для управления учетными записями и правами доступа.
Что такое RBAC и ролевая модель доступа?
Это модель, которая позволяет вместо отдельных прав присваивать сотрудникам роли с готовыми наборами полномочий согласно должностям и задачам.
Чем RBAC отличается от ABAC?
В RBAC доступ зависит прежде всего от должностей и задач пользователя. В ABAC система учитывает дополнительные условия — например, к какому ресурсу обращаются, откуда и когда. ABAC позволяет точнее задавать правила доступа.
Что такое ReBAC?
ReBAC (Relationship-Based Access Control) — модель, в которой права определяются связями между субъектами и объектами: "владелец", "участник", "руководитель". Применяется в коллаборативных системах и платформах с наследованием прав.
Что такое принцип минимальных привилегий?
Назначение пользователям и службам только тех прав, которые необходимы для работы. Такой подход позволяет избегать избыточных полномочий.
Зачем нужны сервисные учетные записи?
Они позволяют автоматизировать процессы без использования личных учетных записей сотрудников.
Как часто нужно пересматривать права доступа?
ИБ-специалисты рекомендуют делать это раз в 1 месяц для привилегированных пользователей, раз в 3 месяца — для остальных. Ревизия также нужна после изменения ролей сотрудников, увольнения, окончания проектов.
Как контролировать действия пользователей в облаке?
Для этого есть журналирование действий. В журналах можно отслеживать входы, операции с ресурсами и изменения прав.