В облачном аккаунте пользователю одновременно назначили разрешение на чтение бакета и явный запрет для этого же действия. Как система IAM принимает итоговое решение?
В типичной политико-ориентированной системе IAM явный запрет имеет приоритет над разрешением. Поэтому пользователь не сможет читать бакет, даже если действие разрешено другой политикой.
Облачные платформы изначально требовали управлять доступом не к отдельным серверам, а к большому числу API-операций и ресурсов. Политики IAM появились как способ централизованно описывать права, применять принцип наименьших привилегий и отзывать доступ без изменения приложения.
При этом одного списка разрешений оказалось недостаточно: требовались ограничения для целых организаций, сетей, регионов, типов ресурсов и временных условий. Поэтому в современных IAM обычно есть несколько источников политик и специальный механизм приоритета явного запрета.
У пользователя могут одновременно действовать политики личности, политики ресурса, ограничения организации, границы разрешений роли и временные условия. Если система просто объединяла бы все разрешения по принципу «хотя бы одна политика разрешает», администратор не мог бы надёжно запретить опасное действие на более высоком уровне.
Например, разработчику можно разрешить чтение объектов конкретного бакета, но одновременно запретить чтение данных за пределами утверждённого региона. Ошибка в оценке политик в такой ситуации может привести либо к лишней блокировке работы, либо к нарушению требований безопасности.
Система обычно оценивает запрос по нескольким этапам. Сначала проверяется, относится ли политика к субъекту, ресурсу, действию и контексту запроса: например, к IP-адресу, региону, MFA или тегам ресурса. Затем учитываются все подходящие разрешения и запреты.
Если найден подходящий явный запрет, итоговое решение — отказ, независимо от числа разрешающих политик. Разрешение действует только тогда, когда оно существует и при этом не перекрыто запретом; отсутствие разрешения также обычно означает неявный отказ.
На практике эффективный доступ часто определяется пересечением нескольких ограничений. Политика пользователя или роли может разрешать действие, но граница разрешений, организационная политика, политика сессии или политика ресурса может сузить допустимый набор операций. Точные названия и комбинации этих уровней зависят от облачного провайдера, поэтому при расследовании нужно сверяться с моделью конкретной платформы.
Важно различать явный и неявный запрет. Явный запрет записан в политике и имеет приоритет над разрешением, а неявный возникает потому, что подходящего разрешения не найдено. Удаление разрешающей политики не «отменяет» явный запрет — для восстановления доступа потребуется устранить или изменить сам запрет и проверить остальные ограничения.
Команде аналитики разрешили читать объекты из хранилища через политику роли. Позже организация добавила явный запрет на чтение этого хранилища из-за пределов корпоративной сети. Запросы из внутренней сети продолжили работать, а запросы с ноутбуков через публичный интернет начали получать отказ.
Рассматривались два варианта. Можно было удалить разрешение роли и выдать новое разрешение только внутренним узлам, но это усложнило бы сопровождение и не гарантировало защиту от других источников доступа. Другой вариант — оставить базовое разрешение роли, а ограничение по сетевому контексту выразить отдельной политикой: такой подход лучше разделяет рабочие права и защитный барьер.
Выбрали второй вариант и дополнительно проверили, что корпоративный прокси действительно передаёт ожидаемый сетевой контекст. Результатом стал единый запрет для всех ролей, который нельзя обойти добавлением ещё одной разрешающей политики, при этом внутренний сценарий чтения сохранился.
Нет. В модели, где явный запрет имеет приоритет, дополнительные разрешения не меняют результат. Нужно найти источник запрета: это может быть политика пользователя, роли, ресурса, организации, граница разрешений или политика сессии, — а затем проверить, действительно ли она соответствует текущему действию и контексту.
При отсутствии разрешения система не нашла подходящую разрешающую политику. При явном запрете она нашла правило, которое прямо запрещает действие. Практическое различие важно для расследования: добавление разрешения может устранить неявный отказ, но не устранит явный.
Да. Политика может применяться только при совпадении условий: например, при использовании MFA, из определённой сети, в конкретном регионе или для ресурса с нужным тегом. Если условие явного запрета выполняется, запрос отклоняется; если не выполняется, этот конкретный запрет не участвует в оценке, но доступ всё равно требует подходящего разрешения и прохождения остальных ограничений.