Теория и практика науки и образования №6 (6) август 2026 г.

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

Особенность рассматриваемого класса систем состоит в том, что точкой входа выступает чат-бот мессенджера. Пользователь приходит из внешней среды, где его учётная запись не тождественна записи в системе и может быть изменена или утрачена. Это добавляет к задаче разграничения доступа вопрос устойчивого связывания внутренних сущностей с внешними учётными записями [3].

Постановка задачи

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

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

Метод исследования

Изоляция построена на трёх рубежах, каждый из которых сохраняет разграничение при отказе предыдущего. Состав рубежей приведён в таблице 1.

Таблица 1

Рубежи разграничения доступа к данным

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

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

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

Отдельно решается связывание с внешней учётной записью. Учебная история хранится в сущности ученика, а соответствие учётной записи мессенджера вынесено в отдельную связь; подключение выполняется по временному приглашению. При смене учётной записи прежняя связь закрывается датой отвязки, тогда как расписание, пакеты и платежи остаются неизменными, вследствие чего прикладные данные не зависят от внешнего аккаунта, который система не контролирует.

Результаты

Проверка выполнена автоматизированным набором тестов в контейнере серверной части: приложение зависит от базы данных, хранилища состояния, миграций схемы и параметров окружения, поэтому проверка отдельных функций вне этого окружения не отражала бы рабочих условий. Контрольный прогон включил 535 проверок; все завершились успешно за 199,53 секунды.

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

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

Обсуждение результатов

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

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

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

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

Заключение

Предложена схема изоляции данных независимых пользователей в информационной системе с общей базой данных и точкой входа через чат-бот. Схема включает признак принадлежности во всех прикладных таблицах, формирование контекста доступа серверными зависимостями и обязательную фильтрацию в сервисном слое при запрете использовать для разграничения данные, полученные от клиента.

Корректность подтверждена набором из 535 автоматизированных проверок, выполненных за 199,53 секунды в контейнерном окружении, включая целенаправленные сценарии обращения к чужому рабочему пространству. Установлено, что дефекты изоляции не проявляются как отказ системы и требуют отдельных проверок. Предложенный подход применим к прикладным системам учёта с общей базой данных и внешней точкой входа; дальнейшая работа предполагает оценку нагрузочных свойств схемы и дополнение прикладной изоляции механизмами разграничения на уровне системы управления базой данных.

***

1. Bezemer C.-P., Zaidman A. Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare? // Proceedings of the Joint ERCIM Workshop on Software Evolution and International Workshop on Principles of Software Evolution. — Antwerp, 2010. — P. 88–92. — DOI: 10.1145/1862372.1862393.
   
   
2. Guo C. J., Sun W., Huang Y., [et al.] A Framework for Native Multi-Tenancy Application Development and Management // Proceedings of the 9th IEEE International Conference on E-Commerce Technology. — Tokyo, 2007. — P. 551–558. — DOI: 10.1109/CEC-EEE.2007.4.
   
   
3. Klopfenstein L. C., Delpriori S., Malatini S., Bogliolo A. The Rise of Bots: A Survey of Conversational Interfaces, Patterns, and Paradigms // Proceedings of the Conference on Designing Interactive Systems. — Edinburgh, 2017. — P. 555–565. — DOI: 10.1145/3064663.3064672.
   
   
4. Chong F., Carraro G., Wolter R. Multi-Tenant Data Architecture // Microsoft Architecture Journal. — 2006. — Vol. 9. — P. 16–24.
   
   
5. Fowler M. Patterns of Enterprise Application Architecture. — Boston : Addison-Wesley, 2003. — 560 p. — ISBN 978-0-321-12742-6.
   
   
6. Newman S. Building Microservices: Designing Fine-Grained Systems. — 2nd ed. — Sebastopol : O’Reilly Media, 2021. — 616 p. — ISBN 978-1-492-03402-5.
   
   
7. Kleppmann M. Designing Data-Intensive Applications. — Sebastopol : O’Reilly Media, 2017. — 616 p. — ISBN 978-1-449-37332-0.
   
   
8. Meszaros G. xUnit Test Patterns: Refactoring Test Code. — Boston : Addison-Wesley, 2007. — 944 p. — ISBN 978-0-13-149505-0.
   
   
9. Ferraiolo D., Sandhu R., Gavrila S., [et al.] Proposed NIST Standard for Role-Based Access Control // ACM Transactions on Information and System Security. — 2001. — Vol. 4, № 3. — P. 224–274. — DOI: 10.1145/501978.501980.