Однако с ростом гибкости возникает риск того, что пользователи или сторонние разработчики могут изменить или создать собственные запросы, нарушая заложенную в бизнес-логику системы.
Обнуление заложенной логики — ситуация, когда пользовательские запросы или фильтры вносят изменения, которые противоречат исходным условиям, что приводит к извлечению данных и неправильным аналитическим выводам.
В данной статье рассмотрим причины возникновения таких ситуаций и предложим методы их предотвращения.
Почему возникает проблема?
· Неограниченное редактирование запросов : Пользователи могут вручную изменять условия, соединения, сортировку или даже структуру запроса.
· Отсутствие контроля и правил: В системе не прописаны механизмы ограничения прав и проверки правильности требований.
· Недостаточная автоматизация: Запросы разрабатываются вручную или через гибкие интерфейсы без автоматических проверок.
Последствия
· Нарушение бизнес-логики.
· Получение неправильных данных.
· Ошибки в аналитике и умных решениях.
· Больше времени на исправление ошибок.
Методы борьбы с обнуляющими заложенную логику запросов
1. Ограничение прав доступа
· Ограничьте возможность редактирования критических запросов.
· Используйте ограничение прав: только доверенные специалисты могут изменять сложные запросы.
· В интерфейсе воспользуйтесь возможностью ручного редактирования запросов, а также формируйте их. их программно.
2. Строгая обработка форм и обработка запросов.
· Создавайте запросы в коде, а не в интерфейсе пользователя.
· Используйте параметры и переменные, чтобы оценить их изменения.
· Например, фиксированные параметры, которые пользователь может изменять только в определенных пределах.
Пример:
3. Использование условий перед выполнением запроса.
· Внедрите условия проверки, чтобы убедиться, что параметры и условия соответствуют заложенной логике.
· Например, перед выполнением запроса проверьте, что дата начала не позднее даты конца.
Пример:
4. Внедрение логирования и аудита.
· Ведите журнал изменений условий и параметров запросов.
· Анализируйте логирование для выявления несанкционированных изменений.
5. Использование специальных шаблонов и принципов защиты.
· Создавайте шаблоны запросов, из которых пользователь не может выйти.
· Встроенные механизмы защиты обеспечивают возможность ручного редактирования важных частей запроса.
Примеры
Пример 1: Защита фильтра по дате
· Задача: Запретить изменение условий по дате в отчете.
· Решение: Фиксированные параметры и проверки.
Пример 2: Ограничение доступа к запросу на редактирование
· Только доверенные пользователи могут изменять структуру запроса.
· Для остальных — только запуск постоянного отчета.
Борьба пользователя с такими запросами, которые могут обнулить заложенную бизнес-логику, — важная часть грамотного проектирования систем на базе 1С и СКД. Использование программных измерений, ограничения прав доступа и автоматизированных формирований обеспечивает целостность данных и надежность аналитики.
