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