Как проверить изоляцию компаний в CRM на рабочем сценарии

Подготовьте безопасные организации

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

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

Проверьте сервер, а не только меню

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

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

Разделите обычные роли и оператора

Здесь важно учесть риск: отсутствие чужих кнопок в интерфейсе не доказывает надёжное ограничение доступа на сервере.

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

Включите связанные сущности

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

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

Сохраните результат и ограничения

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

Частые вопросы