Общие аккаунты вместо персональных
Один админский логин на команду, пароли в мессенджере, отсутствие отзыва доступа при увольнении — по журналам невозможно понять, кто именно сделал действие.
Выберите тему — соберём контекст
Строим защиту от модели угроз, а не от чек-листа: MFA и SSO, короткоживущие токены, права с проверкой на сервере, защита API, управление секретами, журнал аудита и отработка инцидентов.
Или сразу: +7 (962) 368-39-51 Telegram
Типовые провалы безопасности в продуктовых командах, которые не проходили ни модель угроз, ни пентест.
Один админский логин на команду, пароли в мессенджере, отсутствие отзыва доступа при увольнении — по журналам невозможно понять, кто именно сделал действие.
Утёкший пароль от почты клиента открывает доступ ко всему рабочему пространству, а крупный заказчик уходит, потому что нет входа через свой SSO.
JWT без срока жизни и без отзыва, refresh-токены в localStorage, сессия не инвалидируется при смене пароля или выходе на другом устройстве.
Кнопку скрыли, а эндпоинт остался: смена идентификатора в запросе отдаёт чужие проекты, документы и счета — классический IDOR в мультитенантном API.
Ключи эквайринга, доступы к базе и токены ботов лежат в репозитории или в файле на сервере и попадают в бэкапы, дампы и переписку.
Об инциденте узнают от клиента: события не собираются в одном месте, непонятно, что скомпрометировано, а уведомление регулятора и клиентов некому и негде готовить.
Четыре направления, которые закрывают доступ, данные, наблюдаемость и требования регуляторов и корпоративных заказчиков.
Персональные учётные записи, второй фактор и вход через корпоративный провайдер идентичности.
Управляемый жизненный цикл сессии и права, которые проверяются на каждом запросе к серверу.
Ограничиваем злоупотребление API, убираем секреты из кода и фиксируем все значимые действия.
Приводим процессы и данные к требованиям регуляторов и готовим команду к худшему сценарию.
Начинаем с модели угроз и инвентаризации данных: требования регуляторов определяют, что защищать в первую очередь.
Описываем активы и данные, составляем сценарии атак, проверяем текущие права, сессии, хранение секретов и состояние журналов.
Определяем схему аутентификации, матрицу ролей, политику токенов, лимиты API и границы контура карточных данных.
Подключаем MFA и SSO, переводим права на RBAC и RLS, переносим секреты в хранилище, настраиваем журнал аудита и алерты в Sentry.
Проводим тестирование на проникновение, устраняем находки, готовим политики и доказательства для аудита и опросников заказчиков.
Безопасность SaaS начинается с ответа на вопрос «что именно мы защищаем и от кого». Мы описываем активы: персональные данные клиентов, платёжные реквизиты, коммерческую документацию, доступы к интеграциям. Затем составляем сценарии атак — компрометация учётной записи сотрудника, перебор паролей, кража токена, доступ к чужому арендатору через подмену идентификатора, утечка ключей из репозитория.
Только после этого выбираются меры: где достаточно второго фактора, где нужна подпись вебхука, а где единственный выход — изоляция контура карточных данных. Такой порядок экономит бюджет, потому что защита ставится на реальные пути атаки, а не на весь список известных рекомендаций. Модель угроз мы пересматриваем при каждом изменении продукта: новые интеграции и роли добавляют новые способы добраться до данных.
Большинство найденных нами проблем — не экзотические уязвимости, а базовая гигиена доступа. Кнопку в интерфейсе скрыли, а проверку права на сервере не добавили, и смена идентификатора в запросе отдаёт чужие данные. Токен выпустили без срока жизни и без возможности отзыва, поэтому увольнение сотрудника не закрывает доступ немедленно.
Отдельно мы закрываем комплаенс: размечаем данные по требованиям 152-ФЗ и GDPR, минимизируем контур PCI DSS и готовим план реагирования на инцидент до того, как он случится.
SSO передаёт аутентификацию провайдеру идентичности клиента: вход идёт по OAuth 2.0 или SAML 2.0, а ваш сервис получает подтверждённый профиль и права. Для корпоративного заказчика это означает единый вход и мгновенный отзыв доступа при увольнении сотрудника. Обычные пароли в SaaS-продукте остаются как резервный способ входа — например, для небольших команд без своего провайдера.
Интерфейс — это лишь один из клиентов API. Скрытая кнопка не мешает отправить запрос напрямую, поэтому единственная надёжная точка проверки — сервер. Мы проверяем права на уровне эндпоинта, а в мультитенантной базе дополнительно включаем RLS, чтобы запрос без фильтра по арендатору физически не мог вернуть чужие строки.
Требования пересекаются в главном: нужно знать, какие персональные данные хранятся, где именно, кто имеет к ним доступ и как долго они живут. Мы ведём реестр данных, ограничиваем доступ по ролям, шифруем чувствительные поля и реализуем удаление и выгрузку по запросу субъекта. Различия касаются локализации данных и сроков уведомления об инциденте — они фиксируются в политиках и в плане реагирования.
Сканер находит известные сигнатуры в зависимостях и конфигурациях, но не логические ошибки доступа. Тестирование на проникновение показывает то, что не видит автоматика: обход авторизации, доступ к чужому арендатору, подделку вебхука, эскалацию прав через роли. Мы проводим пентест перед крупными релизами и после существенных изменений в модели доступа, а находки закрываем с проверкой повторным тестом.
Смежные технические темы, с которыми эта задача обычно решается в одном проекте.
Разберём модель угроз, доступы и хранение секретов, покажем разрывы и предложим план приведения к требованиям 152-ФЗ, GDPR и PCI DSS.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.