Связаться с нами
УСЛУГИ АУДИТА БЕЗОПАСНОСТИ
Находим уязвимости раньше,
чем их найдёт нарушитель
Аудит безопасности веб-приложений, API, инфраструктуры, облаков, бизнес-платформ и криптосервисов. Проверяем не только периметр, но и то, что чаще всего ломается на практике: логику процессов, ролевую модель, интеграции и права сервисных учётных записей. Каждая находка подтверждается воспроизводимым сценарием эксплуатации и оценкой влияния на бизнес
ОБСУДИТЬ ЗАДАЧУ
СКАЧАТЬ ПРИМЕР ОТЧЁТА
  • 0
    ЛОЖНЫХ СРАБАТЫВАНИЙ
    Каждая находка подтверждена ручной эксплуатацией
  • 2-4
    НЕДЕЛИ
    Средний срок проекта от старта до защиты отчёта
  • Ретест
    ВКЛЮЧЕН
    Повторная проверка исправлений в рамках договора
Аудит нужен, если знакома хотя бы одна ситуация
Система выросла быстрее, чем регламенты
1
Ролевая модель обрастала правами годами, кто и что реально может — точно не знает никто
Периметр вышел за контур
2
Появились API, партнёрские интеграции, внешние кабинеты, публичые формы, мобильное приложение.
Внешнее требование
3
Аудит запросил регулятор, инвестор, крупный клиент в рамках vendor assessment или M&A due diligence
Был инцидент или близко к нему
4
Утечка, подозрительная выгрузка данных, злоупотребление доступом со стороны сотрудника или подрядчика
Направления аудита
Проверяем всю поверхность атаки
От внешнего периметра до бизнес-логики внутри системы. Работаем руками, а не отчётом сканера
  • Веб и мобильные приложения
    Ищем уязвимости в реализации, конфигурации и бизнес-логике приложений — от классики OWASP Top 10 до многошаговых цепочек, которые не находит ни один автоматический сканер
  • API и интеграции
    Отдельный периметр, который почти всегда защищён слабее веб-интерфейса. Проверяем авторизацию на уровне объектов, rate limiting, webhooks и права интеграционных учётных записей
  • Инфраструктура и сеть
    Внешний периметр и внутренняя сеть: что видно снаружи, как далеко продвинется атакующий изнутри, как сегментированы среды, где лежат секреты
  • Облака и контейнеры
    Ошибки конфигурации, избыточные IAM-политики, пути повышения привилегий, публично доступные хранилища и небезопасные CI/CD-цепочки
  • Бизнес-платформы и low-code
    ELMA365, Битрикс24, 1С, кастомные BPM-контуры. Ядро платформы защищает вендор, но уязвимости возникают на внедрении: в ролевой модели, скриптах процессов и автоматизациях
  • Внутренний нарушитель и бизнес-логика
    Моделируем сотрудника или подрядчика с легитимным доступом: попытки расширить права, выгрузить данные, обойти согласования и следы в журналах
Выберите формат под свою задачу
Одна и та же методология, разный охват.
Ниже — что входит в каждый формат и что мы находим в проектах такого типа
Комплексный аудит
Для кого и когда
Компаниям, которым нужна полная картина: не отдельная проверка приложения, а понимание всех путей, по которым можно добраться до критичных данных и денег. Типичный запрос — перед выходом на новый рынок, перед инвестраундом, после смены ИТ-подрядчика или после инцидента.
Что входит в scope:

  • Внешний периметр: всё, что доступно из интернета, включая забытые и теневые сервисы
  • Внутренняя сеть: развитие атаки от рядового сотрудника до администратора домена
  • Ключевые приложения и их API
  • Облачная инфраструктура и CI/CD
  • Ролевая модель и бизнес-логика процессов
  • Сервисные учётные записи, ключи, токены, хранение секретов
  • Журналирование и способность службы ИБ заметить атаку
  • Сценарий внутреннего нарушителя (assumed breach)
Типовые находки
  •   КРИТИЧЕСКИЙ  
    Цепочка от публичной формы до полного доступа к клиентской базе
    •
    Сервисная учётная запись с правами администратора и паролем в открытом коде репозитория
  •   ВЫСОКИЙ  
    Отсутствие сегментации: из гостевого Wi-Fi доступны продуктивные серверы
    •
    Тестовый стенд с копией боевой базы, опубликованный наружу без аутентификации
  •   СРЕДНИЙ  
    Действия администраторов не логируются или логи хранятся 7 дней
Мини-кейс
Контекст
1
Производственная компания, 1500 сотрудников, три площадки, ИТ-ландшафт собирался 12 лет
Что нашли
2
В новом модуле выгрузки отчётов идентификатор организации передавался с клиента и не проверялся на сервере — любой авторизованный пользователь выгружал отчёты чужих компаний
Чем грозило
3
Полная компрометация всех данных компании одной цепочкой, без единого фишингового письма
Что сделали
4
Релиз приостановили на 2 дня, проверку прав перенесли на сервер, провели ретест перед выкаткой
ELMA365 и low-code платформы
Для кого и когда
Компаниям, у которых ELMA365 (или аналогичная BPM/low-code платформа) стала центральной системой: через неё проходят договоры, платежи, персональные данные, согласования. Особенно актуально при сложной матрице ролей, большом количестве кастомных процессов и подключённых внешних кабинетах.

Почему это нужно, если платформу обновляет вендор: Вендор отвечает за безопасность ядра. Уязвимости появляются на этапе внедрения и кастомизации: в настроенной ролевой модели, в скриптах BPMN-процессов, в правах сервисных аккаунтов, в low-code автоматизациях. Обновление платформы эти ошибки не закрывает.
Что входит в scope:

  • Аудит ролей и доступов: ролевая модель, наследование прав, сценарии избыточного доступа
  • Контроль доступа к данным: приложения, документы, отдельные поля, отчёты
  • Проверка бизнес-процессов: обходы согласований и логических ограничений
  • Аудит BPMN и автоматизаций: скрипты, обработчики, кастомная логика
  • Проверка API и интеграций: webhooks, service accounts, интеграционные сценарии
  • Аудит внешних кабинетов: публичные формы, self-service интерфейсы
  • Контроль выгрузок и отчётности: массовый доступ через списки и экспорт
  • Проверка сервисных учётных записей: токены, ключи, технические аккаунты
  • Аудит журналирования: логирование действий пользователей и интеграций
  • Сценарий внутреннего нарушителя: злоупотребление легитимным доступом
Типовые находки
  •   КРИТИЧЕСКИЙ  
    Скрипт в BPMN-процессе выполняется от имени системного аккаунта и позволяет прочитать любой объект в обход прав
    •
    Внешний кабинет отдаёт данные по прямому изменению идентификатора в запросе
  •   ВЫСОКИЙ  
    Роль «Менеджер» через отчёт выгружает базу контрагентов целиком, включая закрытые поля
    •
    Согласование обходится изменением статуса через API без прохождения по маршруту
  •   СРЕДНИЙ  
    Действия интеграционных учётных записей не различаются в журнале — расследование инцидента невозможно
Мини-кейс
Контекст
1
Дистрибьютор, ELMA365 как основная система: сделки, договоры, взаиморасчёты. Около 40 кастомных процессов, портал для дилеров
Что нашли
2
Обработчик в процессе согласования скидки выполнялся с повышенными правами. Менеджер мог инициировать процесс, прервать его на нужном шаге и получить доступ к карточкам сделок других менеджеров, включая маржинальность
Чем грозило
3
Утечка коммерческих условий по всей клиентской базе при увольнении сотрудника
Что сделали
4
Переписали обработчик под ограниченный контекст, пересобрали ролевую модель по принципу минимальных прав, включили детальное журналирование операций с полями маржи
Криптобиржа, кошельки, финтех
Для кого и когда
Криптобиржам, обменникам, кастодиальным сервисам, платёжным шлюзам и финтех-продуктам. Здесь уязвимость конвертируется в прямой убыток за минуты, а публичный инцидент почти всегда означает конец продукта. Отдельный повод — требования банка-партнёра, листинга или инвестора.
Что входит в scope:

  • Архитектура хранения средств: разделение hot / warm / cold, лимиты, мультиподпись
  • Управление ключами: генерация, хранение, HSM, доступ к seed-фразам, процедуры восстановления
  • Логика пополнения: подтверждения сети, реорганизации блокчейна, нестандартные токены, фейковые депозиты
  • Логика вывода: подтверждение операций, лимиты, whitelisting адресов, обход 2FA
  • Внутренняя денежная логика: балансы, race conditions при одновременных операциях, отрицательные балансы, округления
  • Торговое ядро: манипуляции ордерами, self-trading, некорректная обработка отменённых ордеров
  • Смарт-контракты (если применимо): аудит кода, права владельца, механизмы обновления
  • API для торговых ботов: разграничение прав ключей, ограничения по IP, rate limiting
  • Аутентификация пользователя: 2FA, восстановление доступа, сессии, смена email/телефона
  • Административные интерфейсы и внутренний нарушитель: что может сотрудник поддержки или разработчик
  • Бонусы, рефералы, промокоды: сценарии злоупотребления
  • KYC/AML-контур: обходы верификации, разделение операций для ухода от лимитов
  • Инфраструктура нод и мониторинг подозрительных операций
Типовые находки
  •   КРИТИЧЕСКИЙ  
    Состояние гонки при одновременных выводах позволяет вывести больше, чем есть на балансе
    •
    Ключи горячего кошелька доступны с сервера приложения, компрометация приложения = потеря средств
    •
    Депозит засчитывается до достаточного числа подтверждений — возможен возврат транзакции после зачисления
  •   ВЫСОКИЙ  
    API-ключ с правом «только чтение» позволяет отменять чужие ордера
    •
    Смена email не требует подтверждения со старого адреса — цепочка полного перехвата аккаунта
    •
    Сотрудник поддержки может изменить баланс пользователя без второго подтверждения и без записи в неизменяемый журнал
  •   СРЕДНИЙ  
    Реферальная программа позволяет накручивать вознаграждение самому себе через связанные аккаунты
Мини-кейс
Контекст
1
Криптобиржа среднего размера, собственная торговая платформа, около 60 торговых пар
Что нашли
3
Операция списания при выводе и проверка баланса выполнялись разными запросами без блокировки. Отправка нескольких параллельных запросов на вывод давала суммарный вывод выше доступного баланса
Чем грозило
2
Прямая кража средств биржи в объёме, ограниченном только ликвидностью горячего кошелька
Что сделали
4
Перевели операции с балансом в транзакцию с блокировкой строки, добавили идемпотентность запросов вывода, настроили алерт на аномалии баланса. Ретест подтвердил закрытие
Криптобиржа, кошельки, финтех
Для кого и когда
Когда нужен конкретный, ограниченный по объёму результат: проверить один релиз, закрыть требование регулятора, оценить систему перед покупкой, проверить исправления после предыдущего аудита. Быстрее, дешевле, с чётко зафиксированными границами.

Что можно взять отдельно
Типовые находки
  •   КРИТИЧЕСКИЙ  
    В мобильном приложении токен доступа хранится в незащищённом виде и извлекается с устройства
    •
    На периметре найден сервис разработки
    с включённым режимом отладки и доступом
    к переменным окружения
  •   СРЕДНИЙ  
    Ролевая модель содержит 14 учётных записей уволенных сотрудников с активными правами
Мини-кейс
Контекст
1
Онлайн-сервис перед крупным релизом, срок на проверку — одна неделя
Что нашли
2
В новом модуле выгрузки отчётов идентификатор организации передавался с клиента и не проверялся на сервере — любой авторизованный пользователь выгружал отчёты чужих компаний
Чем грозило
3
Утечка данных всех клиентов сервиса сразу после релиза
Что сделали
4
Релиз приостановили на 2 дня, проверку прав перенесли на сервер, провели ретест перед выкаткой
Как мы работаем
Процесс, у которого есть результат, а не только отчёт
Границы и модель угроз
Что делаем: подписываем NDA и договор, разбираем архитектуру, процессы, роли и интеграции, строим модель угроз под конкретный бизнес, фиксируем границы проверки и правила безопасного тестирования. Результат: согласованный scope, перечень критичных зон, график работ
Активное тестирование
Что делаем: работаем руками. Автоматические инструменты используем только для инвентаризации, находки подтверждаем ручной эксплуатацией. Критичные уязвимости сообщаем сразу, не дожидаясь отчёта. Результат: подтверждённые находки, воспроизводимые сценарии эксплуатации, доказательная база
Анализ и оценка риска
Что делаем: оцениваем критичность по CVSS и по фактическому влиянию на бизнес, выстраиваем цепочки атак, приоритизируем. Результат: ранжированный список рисков с понятной для руководства интерпретацией
Отчётность и защита результатов
Что делаем: готовим отчёт для двух аудиторий сразу — руководства и технической команды, проводим встречу, отвечаем на вопросы, согласуем план. Результат: Executive Summary, техническое приложение, remediation roadmap, согласованные приоритеты.
Ретест
Что делаем: после исправлений проверяем, что уязвимости действительно закрыты и что фиксы не создали новых проблем. Результат: письмо о результатах ретеста, пригодное для предъявления регулятору, клиенту или инвестору
Почему мы
  • Ручная работа, а не отчёт сканера
    Автоматика используется для инвентаризации. Всё, что попадает в отчёт, воспроизведено вручную
  • Каждая находка доказана
    Ложные срабатывания в отчёт не попадают.
    Для критичных уязвимостей прикладываем PoC
  • Понимаем бизнес-логику, а не только код
    Основная часть реальных инцидентов — это злоупотребление легитимными возможностями, а не эксплойт из публичной базы
  • Работаем по NDA, не трогаем продуктив
    Границы фиксируются заранее, деструктивные проверки согласовываются отдельно, продуктивная среда остаётся стабильной
Оценим готовность вашей системы
к аудиту без передачи доступов
Бесплатный технический разбор с экспертом,
30−40 минут. На встрече:
  • разберём вашу архитектуру и обозначим наиболее вероятные слепые зоны
  • отдадим чек-лист для самостоятельной экспресс-проверки прав и API-интеграций
  • сформируем предварительные границы работ и ориентир по срокам и бюджету под ваш масштаб
Доступы, выгрузки и любые данные систем для этого не нужны
ЗАБРОНИРОВАТЬ РАЗБОР
FAQ
Нет. Границы и допустимые типы проверок согласуются до старта. Нагрузочные и потенциально деструктивные тесты либо выносятся на тестовый контур, либо проводятся в согласованное окно. По умолчанию работаем без нарушения стабильности продуктивной среды.
Аудит не делает систему неуязвимой — такого результата не даёт ни одна проверка. Он даёт другое: проверяемую картину того, где вы сейчас уязвимы, во что это может обойтись бизнесу и в каком порядке это закрывать. Дальше риск становится управляемым решением, а не неизвестностью.
Оставьте заявку на аудит безопасности
Специалист свяжется в течение рабочего дня, поможет определить границы проверки, оценит сложность инфраструктуры и подготовит предварительную оценку сроков и трудозатрат.
Есть внешние кабинеты и публичные формы
Есть API и внешние интеграции
Есть ли внешние требования (регулятор, клиент, инвестор)
Я согласен (а) на обработку персональных данных
Работаем по NDA. Информация о вашей инфраструктуре не передаётся третьим лицам и не используется в маркетинговых материалах без письменного согласия. Нажимая кнопку «Отправить» я подтверждаю, что ознакомился с Политикой обработки персональных данных Общества с ограниченной ответственностью «Тихая гавань» и даю согласие на обработку всех моих персональных данных, указанных в форме.