Аудит безопасности личного кабинета: изоляция данных компаний

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

Вход и доступ к конкретной записи — разные проверки

Аутентификация отвечает на вопрос, кто выполняет действие. Затем приложение должно решить, разрешено ли этому человеку именно это действие с именно этой записью. OWASP выделяет ошибки авторизации на уровне объектов в отдельную категорию API Security Top 10: доступная функция сама по себе не означает доступ ко всем переданным ей объектам.

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

Согласуйте правило до проверки

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

Почему нужны и разрешённые, и запрещённые случаи

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

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

Процент проверок не равен проценту безопасности

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

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

Как читать локальную матрицу ниже

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

Затем внесите результаты выполненных вами проверок. Строка allow означает, что вы наблюдали разрешение, deny — отказ. Пропущенные сочетания остаются непроверенными. Инструмент не делает запросы к приложению, не получает доступы и не может подтвердить подлинность введённого наблюдения.

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

Что запросить по итогам аудита

1. Границы проверенной системы и перечень подготовленных ролей.
2. Описание ожидаемой политики, включая исключения и общие ресурсы.
3. Воспроизводимые результаты на согласованных тестовых данных.
4. Перечень непроверенных сценариев и причины пропусков.
5. Повторную проверку исправлений и влияние на разрешённую работу.

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

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