🟪 В современных цифровых экосистемах маркетплейсов разграничение прав доступа является краеугольным камнем информационной безопасности и устойчивого функционирования бизнеса. Каждый участник — от рядового покупателя до администратора платформы — должен иметь строго определённый набор полномочий, соответствующий его роли и выполняемым функциям. Однако практика показывает, что в процессе разработки и эксплуатации крупных интернет-площадок нередко возникают уязвимости, связанные с некорректной настройкой прав, ошибками в логике авторизации, а также неэффективным контролем сессий и привилегий. Подобные нарушения могут привести к несанкционированному доступу к персональным данным, финансовым операциям, торговым секретам и административным инструментам, что создаёт огромные риски как для самой платформы, так и для её пользователей. В таких условиях назначение независимой IT-экспертизы становится необходимым для объективной оценки корректности реализованной модели разграничения доступа.

• Данная статья представляет собой систематическое изложение методологии проведения IT-экспертизы систем контроля доступа на примере сложных распределённых платформ маркетплейсов. В работе последовательно рассматриваются все ключевые уровни проверки: от анализа архитектуры ролевой модели (RBAC) и политик безопасности до тестирования механизмов аутентификации, управления сессиями, межсервисной авторизации и аудита. Особое внимание уделяется дифференциации таких понятий, как аутентификация, авторизация и учёт, а также их практической реализации в микросервисных средах. Также исследуются вопросы изоляции данных между клиентами (мультитенантность), корректности работы API-шлюзов и систем Single Sign-On, если они применяются.
• Ключевым аспектом является не только выявление фактов нарушения разграничения, но и оценка их критичности с точки зрения потенциального ущерба. Эксперт должен квалифицировать каждое отклонение как незначительное, существенное или критическое, исходя из возможных векторов атак и ценности защищаемых ресурсов. В статье приведены практические примеры из деятельности Союза «Федерация судебных экспертов» , демонстрирующие разнообразие проблемных ситуаций и эффективность предлагаемых подходов. Материал будет полезен экспертам в области информационной безопасности, юристам, специализирующимся на цифровых спорах, а также разработчикам и архитекторам систем, стремящимся обеспечить надёжное разграничение прав.

🔐 Раздел 1. Понятие и модели разграничения доступа в информационных системах

• Разграничение доступа — это процесс и результат организации прав субъектов на выполнение определённых операций над объектами системы. В основе лежат три основных подхода: мандатное управление доступом (MAC), дискреционное управление доступом (DAC) и ролевое управление доступом (RBAC). Для современных маркетплейсов стандартом де-факто является RBAC, дополненное атрибутивным управлением (ABAC) в сложных сценариях. Ролевая модель предполагает, что права назначаются не каждому пользователю индивидуально, а через его роль, что значительно упрощает администрирование.
• Тем не менее, даже при корректно спроектированной ролевой модели могут возникать проблемы наследования прав, конфликты между ролями, а также избыточные привилегии («право бесконечности»). Эксперт должен чётко понимать, какая модель декларируется производителем или разработчиком, и сравнивать её с фактической реализацией. Часто оказывается, что в коде присутствуют «запасные» права для отладки или административные бэкдоры, которые не описаны в документации.
• Кроме того, важной составляющей является разделение обязанностей (SoD), которое препятствует концентрации полномочий в одних руках. Нарушение этого принципа, например, когда один и тот же пользователь может и создавать заказ, и подтверждать его оплату, и изменять статус доставки, является грубым дефектом политики безопасности.

📋 Раздел 2. Нормативные требования и стандарты для систем авторизации

• В Российской Федерации основным регулятором является Федеральный закон № 149-ФЗ «Об информации, информационных технологиях и о защите информации», а также приказы ФСТЭК России, устанавливающие требования к защите персональных данных (ПДн). Для маркетплейсов, работающих с платёжными картами, обязателен стандарт PCI DSS, который содержит строгие требования к разграничению доступа к карточным данным. Согласно этим документам, доступ к ПДн и платёжной информации должен предоставляться только на основе принципа минимальной необходимости.
• Также применяются международные стандарты ISO/IEC 27001 и 27002, которые регламентируют процессы управления доступом. Эксперт должен проверить, соответствуют ли реализованные механизмы этим требованиям, и если нет — зафиксировать нарушения. Особое внимание уделяется процедурам регистрации новых пользователей, назначения им ролей и своевременной деактивации учётных записей при увольнении или блокировке.
• Важно отметить, что требования к разграничению прав различаются для B2C (бизнес-потребитель), B2B (бизнес-бизнес) и административных сегментов. Например, для продавцов на маркетплейсе должен быть закрыт доступ к данным других продавцов (коммерческая тайна), а для покупателей — к данным банковских карт других пользователей. Нарушение этих изоляционных барьеров является предметом серьёзных юридических претензий.

🔍 Раздел 3. Архитектурный анализ ролевой модели и её декларации

• Эксперт начинает исследование с изучения проектной документации, спецификаций API, диаграмм потоков данных и матриц доступа. Сравнивается, какие роли заявлены (например, «Администратор», «Модератор», «Менеджер продавца», «Покупатель», «Аналитик», «Поддержка») и какие права им назначены по проекту. Фиксируется, предусмотрена ли возможность динамического изменения прав, наследования ролей и временного делегирования.
• Затем проводится сопоставление с реальной конфигурацией базы данных прав, которая часто хранится в виде таблиц связей «роль-разрешение». Если обнаруживаются роли, которых нет в документации, или разрешения, привязанные к ролям нелогично (например, продавцу дано право удалять чужие товары), это является основанием для заключения о некорректной реализации.
• Кроме того, оценивается масштабируемость модели: может ли она адаптироваться к появлению новых типов пользователей или функций без переписывания всей системы. Отсутствие такой гибкости часто приводит к созданию «костылей» — временных решений, которые впоследствии становятся уязвимостями.

🛠️ Раздел 4. Анализ механизмов аутентификации и управления сессиями

• Аутентификация является первым рубежом защиты. Эксперт проверяет, используются ли стойкие протоколы, такие как OAuth 2.0 / OpenID Connect, а также наличие многофакторной аутентификации (MFA) для критических ролей. Проверяется политика паролей: минимальная длина, сложность, срок действия, хранение хешей (не должен использоваться устаревший MD5 или SHA-1). Обнаружение хранения паролей в открытом виде или с обратимым шифрованием является критическим дефектом.
• Управление сессиями оценивается по следующим критериям: время жизни токена доступа и обновления (refresh token), механизм их инвалидации при смене пароля или подозрительной активности, защита от кражи токенов (XSS, CSRF, защита от перехвата). Если сессии не завершаются корректно при закрытии браузера или по таймауту, это создаёт риск сохранения доступа злоумышленником.
• Отдельно исследуется процесс восстановления пароля — он должен быть защищён от brute-force и социальной инженерии. Если процедура позволяет злоумышленнику сменить пароль, зная лишь адрес электронной почты, это грубейшее нарушение.

📊 Раздел 5. Тестирование авторизации на уровне API-запросов

API маркетплейса — это основной вектор атак, поскольку через него передаются все команды. Эксперт проводит серию тестов, имитирующих запросы от разных ролей к разным ресурсам. Проверяется, может ли пользователь с низкой ролью (например, «Покупатель») получить доступ к административному эндпоинту (например, /admin/users или /api/v1/orders/all), просто подставив другой идентификатор в запросе. Это называется прямой ссылкой на объект (IDOR — Insecure Direct Object Reference) и является распространённой уязвимостью.

Также проверяется, корректно ли проверяются права на уровне каждого метода HTTP (GET, POST, PUT, DELETE). Нередко разработчики защищают только GET-запросы, забывая про модифицирующие. Эксперт использует прокси-инструменты (Burp Suite, OWASP ZAP) для модификации запросов и анализа ответов сервера. Если сервер возвращает данные, которые не должны быть доступны, это фиксируется как нарушение.

Важным аспектом является проверка авторизации на уровне отдельных полей. Например, продавец должен видеть только свою выручку, но не общую статистику платформы. Если в ответе на его запрос приходят агрегированные данные всех продавцов — это утечка конфиденциальной информации.

👥 Раздел 6. Мультитенантность и изоляция данных между арендаторами

Маркетплейсы работают с множеством продавцов, каждый из которых является отдельным «тенантом». Эксперт проверяет, реализована ли физическая или логическая изоляция данных между ними. В идеале запросы одного продавца не должны затрагивать таблицы другого. Для этого обычно используется идентификатор tenant (tenant_id) во всех запросах и автоматическое добавление этого фильтра на уровне ORM или шлюза.

Тестирование мультитенантности включает попытки подставить чужой tenant_id в URL или теле запроса. Если система позволяет просмотреть или модифицировать данные другого продавца, это критическая уязвимость. Также проверяется, не происходит ли утечка через кэши (например, Redis) — если кэш не учитывает tenant_id, то данные одного продавца могут быть отданы другому.

Дополнительно оценивается возможность администратора просматривать данные всех тенантов — такая функция должна быть строго ограничена несколькими выделенными сотрудниками с обязательным логированием каждого просмотра.

🧩 Раздел 7. Проверка системы наследования прав и делегирования

В реальных организациях часто возникают ситуации, когда руководитель должен временно делегировать свои права подчинённому. Эксперт проверяет, реализован ли такой механизм безопасно, без создания «бесконечных» цепочек наследования. Опасность заключается в том, что при неправильной реализации делегирование может дать права не только на выполнение действия, но и на его переназначение дальше, создавая «пирамиду» привилегий.

Наследование прав проверяется через создание иерархических ролей (например, «Супервайзер продавцов» наследует права «Менеджера продаж»). Если в результате наследования у пользователя появляются права, которых нет ни у одной из его ролей (из-за ошибок в объединении), это дефект. Также проверяется, можно ли с помощью наследования обойти ограничение на количество одновременно активных сессий или на доступ к определённым IP-адресам.

Особое внимание уделяется отзыву делегированных прав: если после завершения срока делегирования права остаются активными из-за отсутствия механизма их ревокации, это серьёзная проблема.

📡 Раздел 8. Анализ журналов аудита и событий безопасности

Эффективное разграничение прав невозможно без системы аудита, которая фиксирует все действия пользователей, особенно с правами на запись и удаление. Эксперт проверяет, ведётся ли логирование, какие события записываются (вход, выход, изменение прав, доступ к чувствительным данным), и как долго хранятся логи. Отсутствие логирования критических событий само по себе является нарушением.

Если журналы ведутся, эксперт проверяет их целостность — могут ли быть изменены или удалены самим пользователем (особенно администратором). Для этого используются методы, предотвращающие подделку (например, запись в отдельную СУБД с жёстким контролем). Также оценивается, есть ли автоматическое оповещение о подозрительных действиях (несколько неудачных входов, доступ в нерабочее время).

В ходе экспертизы может быть проведён ретроспективный анализ логов для выявления уже произошедших инцидентов несанкционированного доступа. Если такой доступ был, но не обнаружен системой, это указывает на недостатки мониторинга.

🧪 Раздел 9. Моделирование атак на разграничение прав (этичный пентест)

Эксперт проводит ограниченное пентест-сканирование с использованием инструментов Kali Linux, Metasploit и специализированных скриптов. Цель — не взлом системы, а проверка устойчивости к наиболее распространённым векторам: подбор прав через IDOR, повышение привилегий (Privilege Escalation), подделка JWT-токенов, эксплуатация уязвимостей CSRF для совершения действий от имени администратора.

Тестирование должно проводиться с письменного разрешения заказчика и в согласованные временные окны, чтобы не нарушить работу платформы. Все действия документируются, и если уязвимости найдены, они классифицируются по шкале CVSS, что позволяет судить об их серьёзности.

Если пентест выявляет возможность простого получения прав суперпользователя, это является основанием для вывода о том, что система разграничения прав не работает в принципе и требует полной переработки.

⚙️ Раздел 10. Проверка работы на мобильных платформах и в браузерах

Маркетплейсы доступны через веб-сайты и мобильные приложения. Эксперт проверяет, что модель разграничения прав не отличается на разных клиентах. Часто бывает, что веб-версия имеет строгий контроль, а мобильное приложение из-за упрощения содержит уязвимости (например, хардкод ключей API или отсутствие проверки прав на уровне клиентского кода).

Проводится тестирование на популярных браузерах и ОС (iOS, Android), включая проверку обработки непредвиденных входных данных (fuzzing). Если на клиенте права проверяются только на frontend-уровне, а не на backend, это смертельная уязвимость, так как любой запрос может быть подделан.

Также оценивается защита от клиентских атак, таких как XSS, которые могут украсть токен сессии и позволить злоумышленнику действовать от имени жертвы. Если такая уязвимость есть, она автоматически ставит под вопрос всю систему авторизации.

🧑‍💻 Раздел 11. Ручной анализ кода и выявление backdoor

Эксперт проводит выборочный статический анализ кода (или требует его предоставить, если доступен). Особое внимание уделяется модулям аутентификации и авторизации. Ищутся комментарии типа // FIXME: временное решение, // TO-DO: убрать перед релизом, а также недокументированные URL, которые могут быть использованы для обхода проверок.

Также проверяется наличие «административных ключей» в коде (hardcoded credentials) — это грубейшее нарушение. Если такие находки есть, они классифицируются как критические, так как дают злоумышленнику полный контроль.

В случае использования opensource-библиотек проверяется их версия на предмет известных уязвимостей (CVE). Использование устаревших библиотек с дырами в безопасности также является дефектом, так как может быть использовано для обхода авторизации.

📌 Раздел 12. Проверка обработки ошибок и информативности сообщений

Система не должна раскрывать информацию о правах в сообщениях об ошибках. Например, при попытке доступа к запрещённому ресурсу должно выдаваться общее сообщение «Ошибка доступа», а не «У вас недостаточно прав для просмотра данных продавца №12345», что даёт атакующему информацию о структуре и идентификаторах.

Эксперт проверяет, что стек-трейсы и ошибки базы данных не выводятся пользователю, так как они содержат информацию о таблицах и запросах. Если это происходит, фиксируется как нарушение конфиденциальности и потенциальная помощь в проведении IDOR-атак.

Также проверяется поведение системы при изменении ролей в процессе активной сессии: если права меняются, сессия должна быть принудительно завершена или перезапрошена. Отсутствие такого механизма ведёт к ситуации, когда пользователь продолжает обладать старыми правами.

🧾 Раздел 13. Анализ управленческих процессов назначения прав

Помимо технической части, эксперт исследует процессы управления доступом: кто и как назначает права, как часто они пересматриваются, есть ли процедура ежеквартального аудита прав. Отсутствие регламентов или их нарушение также является предметом экспертизы, так как даже самая совершенная система рухнет при хаотичном управлении.

Проверяется, доступна ли возможность самозаписи в привилегированные группы (например, через форму заявки без согласования). Если да — это дефект бизнес-логики. Также оценивается, как обрабатывается увольнение сотрудников: должны быть чёткие сроки блокировки учётных записей (желательно автоматические через интеграцию с HR-системой).

Особое внимание к временным ролям: стажёрам или внештатным сотрудникам должны назначаться минимальные права с автоматическим истечением срока. Отсутствие этого механизма часто приводит к забытым, но активным учёткам с большими полномочиями.

🔬 Раздел 14. Стресс-тестирование системы при больших нагрузках

Под высокой нагрузкой некоторые системы авторизации «срезают углы» для производительности, например, кэшируют результаты проверок на слишком длительное время или используют небезопасные локальные переменные. Эксперт проводит нагрузочное тестирование с имитацией тысяч одновременных запросов от разных ролей и проверяет, не появляются ли при этом ошибки авторизации или, наоборот, ложные разрешения.

Если система в момент пиковой нагрузки перестаёт проверять права (timeout приводит к пропуску проверки), это критический дефект. Фиксируется также время отклика при проверке прав — если оно превышает 200 мс для простых запросов, это свидетельствует о неоптимальной архитектуре, которая может привести к отказам.

Все найденные проблемы заносятся в протокол с указанием условий возникновения (количество RPS, тип запросов и т.д.).

🔏 Раздел 15. Проверка интеграции со сторонними сервисами (платёжные системы, службы доставки)

Маркетплейсы интегрируются с платёжными шлюзами, системами доставки, службами логистики. Эксперт проверяет, используются ли для этих интеграций отдельные сервисные аккаунты с минимальными правами. Нередко разработчики используют один супераккаунт для всех интеграций, что создаёт огромную поверхность атаки.

Проверяется, как передаются данные между системами: если ключи API или токены передаются в открытом виде или хранятся в клиентской части, это нарушение. Также проверяется, имеют ли внешние сервисы доступ к внутренним данным, не предназначенным для них (например, к личным данным покупателей).

Эксперт оценивает, что происходит при сбое внешней системы: не открывается ли автоматически избыточный доступ для обхода ошибок. Часто такие «fallback» механизмы становятся уязвимостями.

📁 Раздел 16. Тестирование удалённого управления сессиями и завершения всех сессий

При компрометации учётной записи пользователь должен иметь возможность завершить все активные сессии (кроме текущей). Эксперт проверяет наличие такой функции и её корректную работу. Если после смены пароля старые токены остаются рабочими, это критический дефект.

Также проверяется реакция системы на блокировку пользователя — она должна мгновенно разорвать все его сессии, иначе заблокированный пользователь сможет продолжать действия до истечения времени жизни токена.

Особое внимание к случаям, когда одна учётная запись используется на нескольких устройствах: должно быть ограничение на число параллельных сессий для чувствительных ролей (администраторы, менеджеры с правом изменения цен).

📂 Раздел 17. Анализ журналов доступа к конфиденциальным данным

Эксперт проверяет, ведётся ли детальный журнал доступа к персональным данным (ФИО, адреса, телефоны, паспортные данные, банковские реквизиты). Для каждого обращения должно фиксироваться: кто запросил, когда, с какого IP, на какую операцию. Если подобный журнал отсутствует или неполон, это является нарушением требований по защите ПДн.

Проверяется, может ли администратор просматривать эти журналы и изменять их. Доступ к самим логам также должен быть ограничен. Наличие неограниченного доступа к логам доступа — это уже вторая уязвимость.

Если экспертиза обнаруживает попытки доступа к данным без соответствующих прав, которые не были залогированы, это указывает на наличие скрытой функциональности (бэкдора).

🧩 Раздел 18. Проверка процесса смены ролей и их влияния на уже открытые сессии

При изменении роли пользователя (например, повышение до администратора) система должна либо перезапросить авторизацию, либо мгновенно обновить права во всех активных токенах. Эксперт проверяет, что при повышении прав не требуется повторный вход, а старые права не остаются активными.

Особый случай — понижение прав: оно должно быть мгновенным. Если бывший администратор сохраняет доступ к закрытым разделам после увольнения, потому что его сессия ещё жива, это недопустимо.

Тестирование проводится путём изменения прав через админку и последующего выполнения запросов от имени пользователя до истечения старого токена. Если запросы проходят, фиксируется нарушение.

📡 Раздел 19. Анализ влияния систем кэширования на авторизацию

Кэши (Redis, Memcached, Varnish) часто используются для ускорения ответов, но если они не учитывают права доступа, данные одного пользователя могут быть отданы другому. Эксперт проверяет, кэшируются ли ответы с персонализированными данными без включения идентификатора пользователя в ключ кэша.

Если кэш содержит чувствительные данные, которые могут быть доступны другим, это серьёзная уязвимость. Тестирование заключается в отправке запросов от разных пользователей и проверке, не получают ли они одинаковые (чужие) ответы.

Особенно опасно кэширование на уровне CDN, когда данные могут раздаваться глобально без учёта географии и прав.

📝 Раздел 20. Оценка критичности выявленных нарушений и их влияния на бизнес

Каждое обнаруженное нарушение классифицируется по шкале критичности:

• Низкая: ошибки в интерфейсе, не влияющие на безопасность (например, дублирование кнопок).

• Средняя: возможный доступ к нечувствительным данным (например, к истории заказов, но без финансовых деталей).

• Высокая: доступ к персональным данным, платёжным реквизитам, возможность изменения статусов заказов без авторизации.

• Критическая: возможность получить права суперпользователя, удалить/изменить любые данные, изменить политику безопасности.

Эксперт даёт экономическую оценку потенциального ущерба от использования каждой уязвимости, основываясь на возможных штрафах за утечку ПДн (до 1% от оборота для операторов персональных данных) и репутационных потерях.

📌 Раздел 21. Кейс-практика экспертизы разграничения прав маркетплейсов

В данном разделе представлены пять подробных примеров из деятельности Союза «Федерация судебных экспертов».

Кейс 1. IDOR-уязвимость, позволяющая просматривать заказы других покупателей. Маркетплейс крупной сети розничной торговли имел API, где в GET-запросе передавался номер заказа в открытом виде. Эксперты подставили номера соседних заказов и получили полную информацию о них, включая ФИО, адрес, состав корзины. Это нарушало ст. 7 закона о персональных данных. После заключения Союза платформа была модернизирована, внедрена проверка принадлежности заказа текущему пользователю на уровне бизнес-логики.

Кейс 2. Повышение привилегий через модификацию JWT-токена. В ходе пентеста эксперты обнаружили, что сервер принимает поддельные токены с изменёнными полями ролей, так как не проверял подпись должным образом. Это позволяло любому пользователю получить роль администратора, изменив один байт в локальной копии токена. Уязвимость была признана критической, поскольку давала полный контроль над системой. После экспертизы продавец программного обеспечения внёс изменения в алгоритм проверки и провёл перевыпуск всех токенов.

Кейс 3. Нарушение мультитенантности: продавец видел данные конкурента. Эксперты проверили API для продавцов и обнаружили, что параметр seller_id не проверялся на сервере — он просто подставлялся в запрос. Подставив чужой ID, продавец получал статистику, цены и остатки склада другого продавца. Это нарушало коммерческую тайну и приводило к недобросовестной конкуренции. Платформа обязана была внедрить механизм привязки всех запросов к авторизованному пользователю через внутренний контекст безопасности.

Кейс 4. Сессии не завершались после увольнения администратора. Бывший сотрудник службы поддержки через месяц после увольнения смог войти в систему, так как его токен не был инвалидирован, а аккаунт не заблокирован. Эксперты воспроизвели ситуацию и зафиксировали, что система не имеет автоматической синхронизации с HR-базой. Это было признано нарушением требований к управлению доступом. По рекомендации Союза внедрена интеграция с Active Directory и процедура немедленной блокировки.

Кейс 5. Отсутствие разделения прав на уровне мобильного приложения. В мобильной версии маркетплейса все проверки прав выполнялись на стороне клиента. Эксперты легко подменили ответы сервера с помощью прокси, и приложение позволяло просматривать внутренние отчёты, предназначенные только для администраторов. Это было классифицировано как проектная ошибка, повлекшая полную переработку архитектуры мобильного клиента.

📌 Раздел 22. Рекомендации по устранению выявленных нарушений

На основе каждого выявленного дефекта эксперт формулирует конкретные технические рекомендации: внедрение обязательной проверки прав на серверной стороне для каждого запроса, использование подписанных токенов с коротким временем жизни, регулярный аудит прав, внедрение системы оповещений о подозрительных действиях, обучение персонала правилам работы с привилегированными учётными записями.

Особо подчёркивается необходимость разделения сред разработки, тестирования и продакшена, чтобы тестовые ключи не попадали в боевую среду. Также рекомендуется использовать решения для управления доступом на основе политик (PDP/PEP), которые централизуют логику проверки.

Для долгосрочного улучшения предлагается внедрение SIEM-системы и проведение регулярных независимых аудитов безопасности с периодичностью не реже одного раза в полгода.

📚 Раздел 23. Роль Союза в формировании стандартов безопасности

Союз «Федерация судебных экспертов» является признанным лидером в области IT-экспертиз. Благодаря многолетнему опыту и высококвалифицированным кадрам, Союз разработал собственные методические рекомендации по проверке систем разграничения доступа, которые применяются в судебной практике и признаны арбитражными судами.

Союз активно взаимодействует с регуляторами (ФСТЭК, Роскомнадзор), участвуя в разработке требований к защите информации. Обобщая случаи из своей практики, эксперты Союза выпускают аналитические отчёты, которые помогают компаниям предотвращать типичные ошибки ещё на стадии проектирования.

Таким образом, привлечение Союза «Федерация судебных экспертов» гарантирует не только качественное исследование, но и получение рекомендаций, соответствующих самым современным стандартам безопасности.

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте 🟩 https://centrexp.ru