Пентест SaaS: охват, изоляция тенантов и выбор подрядчика

Сценарий ниже условный, но узнаваемый. Небольшая B2B-платформа для управления закупками готовится подписать договор с крупным клиентом. Его служба безопасности присылает анкету с пунктом: «Приложите результаты тестирования на проникновение за последние двенадцать месяцев». Сроки поджимают, и команда заказывает самый быстрый вариант — автоматическое сканирование основного домена с отчётом в PDF. В отчёте пара устаревших заголовков и предупреждение о версии TLS; анкета закрыта, договор подписан.

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

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

Чем пентест SaaS отличается от проверки обычного сайта

Тестирование на проникновение — санкционированная и ограниченная по времени оценка: специалисты ищут уязвимости в продукте, его API и окружении и безопасно демонстрируют последствия их эксплуатации. Руководство NIST SP 800-115 ставит пентест в один ряд со сканированием и другими техниками технической оценки, а их цель описывает как поиск уязвимостей и проверку соответствия политикам и требованиям. Для SaaS-компании важны обе стороны: выявленные и затем исправленные проблемы могут снижать риск, а ограниченные рамками теста результаты дают материал для разговора с клиентами и аудиторами.

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

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

Поверхность атаки: от HTTP-сессий до фоновых задач

Почти всё в SaaS-продукте проходит через HTTP. Протокол не хранит состояние между запросами, и MDN описывает, как его добавляют cookie. Но сессии в HTTP не «запрещены»: приложение может хранить сессию на сервере и связывать её с запросами через идентификатор в cookie или использовать подписанные токены. Тестировщику важно, как продукт превращает независимые запросы в пользователя, роль и тенанта — и где эта связь рвётся.

Сессии, cookie и токены

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

API заслуживают не меньшего внимания, чем интерфейс. OWASP API Security Top 10 в редакции 2023 года разделяет три уровня авторизации: доступ к объекту, к отдельным свойствам объекта и к функциям. Пользователь может не иметь права открыть чужой заказ, но получить его поля через вложенный объект, или не видеть кнопку администратора, но успешно вызвать соответствующий метод напрямую. Отдельно выделены неограниченное потребление ресурсов и доступ к чувствительным бизнес-процессам — например, массовое создание пробных тенантов. Подробнее — в материале про оценку безопасности REST API.

Браузерные заголовки: что они защищают, а что нет

MDN описывает несколько механизмов на стороне браузера. Content Security Policy помогает обнаруживать и смягчать часть атак, включая межсайтовый скриптинг и внедрение данных. CORS определяет, может ли скрипт с другого источника прочитать ответ, но не является авторизацией на сервере: в зависимости от метода, учётных данных и обработки endpoint запрос с чужого сайта может дойти до API и выполнить действие, даже если браузер не отдаст скрипту ответ. Cross-Origin Resource Policy ограничивает загрузку тела ответа в определённых сценариях без CORS, но не мешает отправлять запросы. Permissions Policy управляет доступом страницы к возможностям браузера.

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

Учётные данные людей и сервисов

Вход, регистрация, MFA, SSO, сброс пароля и приглашения — классическая часть охвата. Но есть и сервисные учётные данные: API-ключи клиентов, токены интеграций, секреты подписи вебхуков, OAuth-подключения, учётные записи фоновых обработчиков. MFA защищает человека при входе и ничего не говорит о том, как ограничивается и отзывается ключ интеграции. Для применяемого SSO-протокола отдельно проверяют предусмотренные им подпись и ключи, issuer и audience, redirect URI или RelayState/state, привязку учётной записи и тенанта, а также создание и завершение локальной сессии. Если ключ одного клиента открывает ресурсы другого или не теряет силу после отключения интеграции, серьёзность зависит от доступных данных, действий и числа затронутых тенантов — как и при обходе авторизации в интерфейсе.

Изоляция тенантов — главная граница SaaS

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

Граница тенанта проходит не только через видимые запросы чтения: изоляция должна выдерживать экспорт и отчёты, поиск, кеши, фоновые задачи, очереди, вебхуки, интеграции, файловые хранилища и инструменты поддержки. Для кешей, очередей, ссылок на файлы и фоновых работ отдельно проверяют, откуда берётся контекст тенанта и включён ли он в ключи и проверки доступа. Биллинг требует проверки прав на смену тарифа и просмотр счетов, привязки вебхуков к тенанту, подписи, защиты от повторов и идемпотентности; реальные списания выполняют только если это явно разрешено. Экспорт или поиск формально «только читают», но могут раскрыть больше любой формы редактирования, так что чтение не стоит автоматически считать малорисковым. И не всякий запрос, похожий на чтение, лишён побочных эффектов: генерация отчёта может запустить тяжёлую задачу или отправить уведомление.

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

1. Пробный тенантАтакующий регистрирует бесплатный тенант и получает легитимную роль с правом выгрузки отчётов.
2. Подмена идентификатораВ запрос на экспорт подставляется идентификатор объекта другого клиента; API проверяет только, что пользователь вошёл в систему.
3. Фоновая задачаВоркер формирует файл под сервисной учётной записью и не сверяет принадлежность объекта тенанту инициатора.
4. Ссылка на файлГотовый архив выдаётся инициатору по ссылке, и в нём оказываются данные чужой организации.

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

Как готовить тестовые тенанты и данные

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

Какие тенанты, роли и интеграции включить в охват, удобно обсудить с командой Pentest.red: на странице определения охвата пентеста можно описать модель тенантов, API и ограничения среды — от этого зависят глубина и состав работ.

Какие стандарты действительно помогают задать глубину проверки

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

WSTG и ASVS как язык охвата

OWASP Web Security Testing Guide — методологический каркас тестирования веб-приложений; здесь версия 4.2 используется как зафиксированный пример, а в проекте нужно записать фактически выбранную версию. Подрядчик должен объяснить, какие категории тестов WSTG выполнены, какие исключены и почему — например, нагрузочные проверки могли исключить правила работ.

OWASP ASVS решает другую задачу: его заявленная цель — выровнять разброс охвата и строгости проверок на рынке открытым, коммерчески применимым стандартом. Здесь версия 5.0.0 служит зафиксированным примером. Идентификаторы требований меняются между версиями, поэтому ASVS рекомендует указывать версию — в формате вида v5.0.0-1.2.5. Если подрядчики привязывают охват и находки к версионированным требованиям ASVS, предложения становятся сравнимыми, а повторная проверка — проверяемой.

WSTG и ASVS относятся к прикладному уровню: веб-приложению и его API. Облачная конфигурация, Kubernetes или конвейер сборки требуют своих методик, и их включение в охват оговаривается отдельно.

OWASP Top 10 в редакции 2025 года — документ для повышения осведомлённости о наиболее критичных рисках веб-приложений. Он удобен, чтобы объяснить результаты руководству и разработчикам, но это перечень категорий риска, а не план тестирования. Обещание лишь «покрыть OWASP Top 10» описывает минимум, а не оценку SaaS-продукта.

Управленческий и продуктовый контекст: NIST CSF 2.0 и CISA Secure by Design

NIST SP 800-115 опубликован в сентябре 2008 года и заменил SP 800-42. Он старше многих облачных архитектур, и сам NIST подчёркивает, что документ даёт обзор ключевых элементов технического тестирования, а не готовую программу. Его ценность — в дисциплине: формальная оценка делится на планирование, выполнение и этап после выполнения, включающий анализ находок и выработку мер по устранению. Сочетать его стоит с выбранными для проекта и зафиксированными по версии материалами OWASP.

NIST Cybersecurity Framework 2.0 помогает видеть пентест как один из входов в управление киберрисками, а не разовое событие. Инициатива CISA Secure by Design добавляет взгляд производителя: ответственность за безопасность на уровне высшего руководства, защищённость по умолчанию, MFA, журналирование и SSO без доплаты. В пределах согласованного охвата пентест может проверить, как выбранные обязательства реализованы на практике.

Какие законы, стандарты или договоры требуют пентеста и как часто, уточняйте у юристов и аудиторов. Отчёт может быть одним из доказательств для SOC 2, ISO 27001 или PCI DSS, но не делает компанию соответствующей им автоматически.

Сканер, ручной пентест или тестирование по релизам

NIST SP 800-115 рассматривает сканирование и тестирование на проникновение как разные техники со своими ограничениями. Сканирование масштабирует широкие повторяемые проверки, но хуже охватывает бизнес-логику, многошаговые сценарии и межтенантную авторизацию. Ручной пентест может глубже исследовать цепочки слабостей и безопасно подтвердить последствия, но остаётся срезом на момент, ограниченным днями, доступом и охватом.

Чёрный, серый и белый ящик

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

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

Периодичность для продукта, который меняется каждую неделю

SaaS меняется постоянно, и результаты ежегодного теста могут перестать отражать текущую версию. Руководство CISA по безопасному развёртыванию ПО делает акцент на процессах выпуска с надёжными элементами тестирования и измерения. Один практический вариант — многоуровневая модель: автоматические проверки в конвейере, целевые тесты при выпуске рискованных функций — нового API, изменения модели ролей, новой интеграции — и более глубокий независимый пентест регулярно или перед крупными релизами. Как ограничивать точечные проверки изменённой частью продукта, мы описали в материале о пентесте по изменениям.

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

Как провести тест безопасно: разрешение, среда, мониторинг

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

Стенд или продуктив

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

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

Проверка обнаружения

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

Приоритизация находок: класс слабости, эксплуатация и радиус поражения

MITRE публикует список CWE Top 25 наиболее опасных слабостей ПО за 2025 год и отдельный список слабостей, связанных с уязвимостями из каталога CISA Known Exploited Vulnerabilities. Связь класса с реально эксплуатируемыми уязвимостями — повод проверить контекст внимательнее; повышать приоритет конкретной находки следует только когда это поддерживают её достижимость, последствия, экспозиция и компенсирующие меры.

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

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

Ищите подтверждённые корневые причины, а не ограничивайтесь симптомами: их анализ может обосновать более широкое исправление, а материалы CISA Secure by Design рассматривают предотвращение повторяющихся межсайтовых скриптингов, внедрения команд ОС и обхода каталогов на уровне класса. Применимый идентификатор CWE классифицирует тип слабости, а подходящее требование ASVS связывает применимую веб/API-проверку с конкретным требованием верификации. Если повторяющаяся причина подтверждена доказательствами в нескольких местах, рассматривают исправление общего компонента: централизованную проверку тенанта при обращении к данным, безопасные шаблонизаторы или параметризованные запросы.

От отчёта к исправлению и повторной проверке

По NIST SP 800-115 оценка включает анализ находок и выработку мер по устранению. Полезный отчёт содержит резюме для руководства, охват и методологию с привязкой применимых веб/API-проверок к WSTG и ASVS, воспроизводимые доказательства по каждой находке, идентификаторы CWE, радиус поражения по тенантам, влияние на бизнес и конкретные рекомендации. Отдельно указываются ограничения: что не проверялось, какие роли и интеграции были недоступны, на какой сборке шла работа.

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

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

Что можно показать клиентам

Руководство CISA Secure by Demand помогает заказчикам ПО задавать поставщикам вопросы при закупке, а MITRE отмечает, что прозрачность в работе со слабостями демонстрирует приверженность безопасности. Короткое письмо-подтверждение или сводка с охватом, датами, методологией и статусом устранения отвечает клиенту, не раскрывая деталей эксплуатации, — при условии, что она честно описывает границы проверки и не выдаёт пентест за сертификат.

Как выбрать подрядчика для пентеста SaaS

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

Что запросить до коммерческого предложения

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

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

Цены сравнивают только после выравнивания охвата: за разной стоимостью может стоять разное число ролей, методов API и дней работы. Для применимых веб/API-проверок один из проверяемых способов описать охват — версионированные требования ASVS и категории WSTG; остальные компоненты требуют своих критериев.

Тревожные сигналы

Насторожиться стоит, если автоматическое сканирование выдаётся за пентест; если охват фиксирован и не учитывает вашу модель тенантов; если в примерах отчётов нет воспроизводимых доказательств; если предложение обещает «покрыть OWASP Top 10» без подробностей; если исполнитель не хочет фиксировать разрешение и правила работ письменно или обещает «гарантированно найти все уязвимости».

С Pentest.red можно обсудить ручной пентест SaaS-продукта в согласованном охвате: какие тенанты, роли, API и интеграции включить, какие доказательства должны быть в отчёте и как будет устроена повторная проверка. Условия обсуждаются индивидуально через страницу услуги тестирования на проникновение. Аудит соответствия, аттестация или заключение по SOC 2 — отдельные работы квалифицированных аудиторов, и пентест их не заменяет.

Последовательность решений для руководства

Если базовая гигиена безопасности уже есть, а от теста ждут измеримого вклада в снижение риска после исправлений, руководство может пройти эту последовательность за несколько встреч. Сначала — повод (запрос клиента, крупный релиз, новый API, смена архитектуры, аудит): он определяет, нужен широкий тест или точечный. Затем — инвентаризация поверхности, включая фоновые задачи и границы тенантов, и целевая строгость через требования ASVS и категории WSTG.

Дальше — модель работ (серый ящик для глубины, сканирование для широты, тесты по релизам для изменений), письменное разрешение, тестовые тенанты, синтетические данные, план мониторинга и описание различий стенда и продуктива. Заранее решите, блокирует ли критичная межтенантная находка релиз, кто принимает остаточный риск и когда будет повторная проверка. Результаты приоритизируйте по доказанным последствиям, достижимости, экспозиции и радиусу поражения; CWE и связь класса с KEV используйте как контекст, передавайте в управление рисками в логике CSF 2.0, а клиентам — честную сводку.

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

Что в итоге должен дать пентест SaaS

Пентест SaaS-продукта особенно полезен, когда охват построен вокруг изоляции тенантов, учётных данных и API, применимые веб/API-проверки заданы через WSTG и ASVS, а находки приоритизированы по доказанным условиям эксплуатации и радиусу поражения и доведены до проверенного исправления.

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