3

WebTech

Личный кабинет

Проекты, коммерческие предложения, документы и отчёты — в одном месте.

Войти Зарегистрироваться Забыли пароль?
Безопасность и комплаенс SaaS

Безопасность, которую можно доказать аудитору и корпоративному клиенту

Строим защиту от модели угроз, а не от чек-листа: MFA и SSO, короткоживущие токены, права с проверкой на сервере, защита API, управление секретами, журнал аудита и отработка инцидентов.

Или сразу: +7 (962) 368-39-51 Telegram

MFA
обязательна для сотрудников и админов
SSO
OAuth 2.0 и SAML для корпоративных клиентов
RBAC
права проверяются на сервере, а не в UI
152-ФЗ
GDPR и PCI DSS в одном контуре
Задачи

Где SaaS теряет данные и клиентов

Типовые провалы безопасности в продуктовых командах, которые не проходили ни модель угроз, ни пентест.

Общие аккаунты вместо персональных

Один админский логин на команду, пароли в мессенджере, отсутствие отзыва доступа при увольнении — по журналам невозможно понять, кто именно сделал действие.

Нет MFA и корпоративного входа

Утёкший пароль от почты клиента открывает доступ ко всему рабочему пространству, а крупный заказчик уходит, потому что нет входа через свой SSO.

Сессии и токены живут вечно

JWT без срока жизни и без отзыва, refresh-токены в localStorage, сессия не инвалидируется при смене пароля или выходе на другом устройстве.

Права проверяются только в интерфейсе

Кнопку скрыли, а эндпоинт остался: смена идентификатора в запросе отдаёт чужие проекты, документы и счета — классический IDOR в мультитенантном API.

Секреты хранятся рядом с кодом

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

Нет журналов и плана реагирования

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

Решения

Контур безопасности SaaS

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

Аутентификация, MFA и SSO

Персональные учётные записи, второй фактор и вход через корпоративный провайдер идентичности.

  • MFA через TOTP и защита от повторного использования кода
  • SSO по OAuth 2.0 и SAML 2.0 с привязкой по домену клиента
  • SCIM-подготовка и отзыв доступа при увольнении сотрудника
  • Защита входа: ограничение попыток, блокировка по IP и уведомления

Сессии, токены и разграничение прав

Управляемый жизненный цикл сессии и права, которые проверяются на каждом запросе к серверу.

  • Короткоживущие access-токены и отзываемые refresh-токены
  • Ротация токенов, инвалидация всех сессий при смене пароля
  • RBAC с ролями и политиками, проверка прав на уровне эндпоинта
  • RLS в PostgreSQL как второй барьер между арендаторами

Защита API, секреты и журналирование

Ограничиваем злоупотребление API, убираем секреты из кода и фиксируем все значимые действия.

  • Rate limiting по пользователю, ключу и IP, отдельные лимиты на дорогие операции
  • Валидация входных данных, защита от инъекций и подписи вебхуков
  • Секреты в Vault или менеджере секретов с ротацией ключей
  • Журнал аудита: кто, что, когда и из какой точки доступа изменил

Комплаенс и реагирование на инциденты

Приводим процессы и данные к требованиям регуляторов и готовим команду к худшему сценарию.

  • Модель угроз и классификация данных по 152-ФЗ и GDPR
  • Границы PCI DSS: минимизация контура карточных данных
  • Пентест и сканирование зависимостей перед релизами
  • План реагирования: роли, каналы, сроки уведомления и разбор инцидента
Процесс

Как мы выстраиваем комплаенс

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

  1. 01 1–2 недели

    Модель угроз и аудит доступа

    Описываем активы и данные, составляем сценарии атак, проверяем текущие права, сессии, хранение секретов и состояние журналов.

  2. 02 2–3 недели

    Проектирование контура защиты

    Определяем схему аутентификации, матрицу ролей, политику токенов, лимиты API и границы контура карточных данных.

  3. 03 6–12 недель

    Внедрение и миграция

    Подключаем MFA и SSO, переводим права на RBAC и RLS, переносим секреты в хранилище, настраиваем журнал аудита и алерты в Sentry.

  4. 04 2–3 недели

    Пентест и подготовка к аудиту

    Проводим тестирование на проникновение, устраняем находки, готовим политики и доказательства для аудита и опросников заказчиков.

Модель угроз важнее чек-листа

Безопасность SaaS начинается с ответа на вопрос «что именно мы защищаем и от кого». Мы описываем активы: персональные данные клиентов, платёжные реквизиты, коммерческую документацию, доступы к интеграциям. Затем составляем сценарии атак — компрометация учётной записи сотрудника, перебор паролей, кража токена, доступ к чужому арендатору через подмену идентификатора, утечка ключей из репозитория.

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

Доступ, токены и журналирование: что чаще всего ломается

Большинство найденных нами проблем — не экзотические уязвимости, а базовая гигиена доступа. Кнопку в интерфейсе скрыли, а проверку права на сервере не добавили, и смена идентификатора в запросе отдаёт чужие данные. Токен выпустили без срока жизни и без возможности отзыва, поэтому увольнение сотрудника не закрывает доступ немедленно.

  • персональные учётные записи и MFA вместо общих логинов;
  • короткоживущие access-токены с отзываемыми refresh-токенами;
  • проверка прав на каждом эндпоинте и RLS как второй барьер;
  • rate limiting и отдельные лимиты для дорогих операций;
  • журнал аудита и алерты на аномальные входы и массовые выгрузки.

Отдельно мы закрываем комплаенс: размечаем данные по требованиям 152-ФЗ и GDPR, минимизируем контур PCI DSS и готовим план реагирования на инцидент до того, как он случится.

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

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

Интерфейс — это лишь один из клиентов API. Скрытая кнопка не мешает отправить запрос напрямую, поэтому единственная надёжная точка проверки — сервер. Мы проверяем права на уровне эндпоинта, а в мультитенантной базе дополнительно включаем RLS, чтобы запрос без фильтра по арендатору физически не мог вернуть чужие строки.

Требования пересекаются в главном: нужно знать, какие персональные данные хранятся, где именно, кто имеет к ним доступ и как долго они живут. Мы ведём реестр данных, ограничиваем доступ по ролям, шифруем чувствительные поля и реализуем удаление и выгрузку по запросу субъекта. Различия касаются локализации данных и сроков уведомления об инциденте — они фиксируются в политиках и в плане реагирования.

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

Технические основы: другие темы

Смежные технические темы, с которыми эта задача обычно решается в одном проекте.

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

Разберём модель угроз, доступы и хранение секретов, покажем разрывы и предложим план приведения к требованиям 152-ФЗ, GDPR и PCI DSS.