Как сайт может работать, но не зарабатывать: о доступе, иерархии и фильтрации данных
В статье на Habr-Infosec инженер из «Северстали» Дмитрий Коновалов описал, как реализует сложную авторизацию на основе ABAC через Open Policy Agent в Spring Boot. Это не просто техническая реализация — это ответ на вызов, который сталкиваются многие бизнесы: как управлять доступом к данным, когда он зависит от иерархии, атрибутов и условий. Мы в Cetera сталкиваемся с этим каждый день. И это не про безопасность в узком смысле — это про то, как сайт может работать, но не зарабатывать, если не умеет фильтровать доступ и синхронизировать данные.
О чём речь и почему это важно для бизнеса
Речь о том, как система решает, кто может что видеть и редактировать. Не просто «вход есть — вход», а «может ли этот пользователь увидеть товар из другого каталога, если у него нет прав на родителя?». Это звучит как технический нюанс, но на деле — это выручка. Если клиент видит товары, которых у него нет, он может попробовать купить — и получить отказ. Если сотрудник видит данные, которые ему не предназначены, он может ошибиться. Это не просто ошибка — это потеря доверия. Я считаю, что это важно, потому что бизнес, который не умеет управлять доступом по условиям, не может масштабироваться. Сайт, который не фильтрует данные, не зарабатывает. Он просто висит. И это не про «безопасность» — это про эффективность.
Как это устроено — что тут вообще происходит
В основе — модель ABAC: доступ определяется не только ролью, но и атрибутами. У пользователя есть роль, но ещё и тег, и принадлежность к каталогу, и иерархия. Система не просто говорит «да» или «нет» — она решает, какие именно данные можно показать. Это делается через Open Policy Agent (OPA), который работает как внешний движок политик. Приложение отправляет запрос с контекстом: кто, что, над чем, в каком окружении. OPA возвращает решение. Всё это происходит на уровне API — и даже фильтрация списков (например, «выведи только товары, которые доступны пользователю») решается не в памяти, а в SQL-запросе. Это не просто проверка, это интеграция на уровне данных. И да, это работает. Но не в любой системе. Это не то, что можно «включить» — это архитектурное решение, которое требует понимания.
Что изменилось на рынке: как делали раньше и как делают сейчас
Раньше в системах с доступом по ролям всё было проще: «у тебя роль — ты можешь». Даже в Spring Security есть @PreAuthorize и ACL. Но это не масштабируется. ACL — это таблицы, которые растут с каждым изменением. Когда товаров миллион, а права зависят от тегов, это становится ETL-процессом. И если кто-то меняет тег — нужно пересчитать всё. Всё это — ручная работа. Сейчас же рынок перешёл к модели, где политики вынесены из кода. Они живут отдельно, тестируются, управляются. Это не код — это политика. И она пишется на языке Rego, который понятен и проверяем. Это не просто «допустить» — это «позволить, если условие выполнено». И это работает. На уровне API, на уровне сервиса, на уровне шлюза. Это не новое изобретение — это уже реальность. И она требует другой подход к разработке.
Кому это касается и как понять, что это про ваш проект
Если у вас есть интернет-магазин с несколькими каталогами, если вы работаете с разными командами, если у вас есть теги, категории, иерархия — это про вас. Если вы когда-либо сталкивались с тем, что «в списке видны товары, которых быть не должно», или «пользователь не может отредактировать, хотя у него права», или «мы вручную скидываем права» — это про вас. Если вы думаете, что «всё работает», но при этом тратите время на проверку доступа — это про вас. Я бы на месте владельца магазина смотрел прежде всего на то, как система фильтрует данные. Если фильтрация — в памяти, если она не учитывает иерархию, если права не наследуются — это устаревший подход. И он тормозит бизнес. Не потому что сломался, а потому что не даёт результата.
Что с этим делать — порядок действий в общем виде
Начинаем с аудита. Проверяем, как сейчас устроена авторизация. Есть ли иерархия? Есть ли фильтрация списков? Есть ли зависимость от атрибутов? Потом — анализ. Сколько точек, где доступ зависит от условия? Где права выдаются? Где они наследуются? Потом — выбор архитектуры. Можно ли вынести политики? Нужен ли OPA? Нужно ли разделение на слои? Потом — реализация. Не сразу всё. Сначала — фильтрация списков. Потом — иерархия. Потом — атрибуты. Потом — тестирование политик. Всё это делается не в одном пул-реквесте. Это процесс. И он требует понимания, а не просто установки библиотеки.
Почему сайт может работать, но не зарабатывать
Потому что не умеет управлять доступом. Потому что фильтрация — в памяти, а не в SQL. Потому что права не наследуются, и приходится вручную выдавать. Потому что пользователь видит товары, которых у него нет. Потому что сотрудник видит данные, которые ему не предназначены. Это не ошибка — это потеря доверия. И это не про безопасность. Это про то, как сайт работает. Если он не умеет фильтровать данные, он не может быть эффективным. И если он не может быть эффективным, он не зарабатывает. А мы в Cetera — не просто делаем сайты. Мы делаем системы, которые работают. И которые зарабатывают. И для этого нужно, чтобы они умели управлять доступом. Не просто «вход есть» — а «всё, что нужно, доступно, всё, что не нужно, скрыто».
Это часть нашей работы — Информационная безопасность. Поддержка сайтов всех типов для обеспечения их информационной безопасности. Информационная безопасность
Автор: Святослав Семенов из Cetera Labs