Аудит информационной безопасности: что проверяют в приложении и коде

Перед крупным клиентом или тендером. Требование по безопасности всё чаще входит в договор, а анкету поставщика заполняют совместно с ИТ.

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

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

После инцидента. Своего или отраслевого: утечка у конкурента — хороший повод проверить себя.

Перед запуском продукта с платежами или медицинскими данными. Дешевле заложить требования в проект, чем переделывать после запуска.

Раз в год как регламент. Код меняется, зависимости стареют, права накапливаются.

Даже когда речь идёт о продукте, а не о серверном парке, часть находок всегда лежит в организации доступов.

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

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

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

Экономика вопроса изменилась, и это главный аргумент в разговоре с руководством.

С 30 мая 2025 года действуют новые штрафы за утечки персональных данных. За первую утечку — от нескольких миллионов до пятнадцати миллионов рублей в зависимости от числа пострадавших, а для биометрии и особых категорий данных — до двадцати миллионов. За повторную — оборотный штраф от 1 до 3% годовой выручки, при этом не меньше двадцати с лишним миллионов и не больше 500 млн.

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

Дополнительно стоит держать в голове требования к размещению данных и к используемому ПО — особенно если компания попадает под регулирование по отраслевому признаку. Общая картина требований разобрана в материале про импортозамещение ПО.

Порядок работ примерно такой.

• 1. Модель угроз на страницу. Что защищаем, от кого, что будет, если это утечет. Без этого шага проверка превращается в перечисление всего подряд.
• 2. Обзор архитектуры. Схема компонентов, где хранятся данные, кто с кем общается, где границы доверия.
• 3. Автоматические проверки. Статический анализ кода, анализ зависимостей, поиск секретов в репозитории. Дают быстрый первый список.
• 4. Ручной разбор критичных мест. Аутентификация, права, платежи, работа с файлами, интеграции. Это то, что автоматика находит хуже всего.
• 5. Проверка доступов и окружений. Кто имеет доступ, чем отличается тестовый контур, как хранятся ключи.
• 6. Воспроизведение находок. Каждая проблема подтверждается на тестовом контуре: без воспроизведения это гипотеза.
• 7. Оценка риска и отчёт. Вероятность, последствия, стоимость исправления.

Сроки: для среднего продукта — от двух до четырёх недель, в зависимости от объёма кода и числа интеграций.

Плохой отчёт — список из ста пунктов с уровнями критичности из инструмента. Хороший отвечает на четыре вопроса.

Что именно нашли — с описанием на человеческом языке, местом в коде и шагами воспроизведения.

Чем это грозит — какие данные и какие деньги под риском. «Обход прав в кабинете даёт доступ к заказам и телефонам всех клиентов» вместо «нарушение контроля доступа».

Что делать — конкретное решение, а не отсылка к стандарту.

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

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

Аудит без плана исправлений — документ, который через полгода будет неактуален. Рабочая схема — три горизонта.

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

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

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

И повторная проверка через несколько месяцев: без неё непонятно, закрыты ли находки на самом деле.

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

• Анализ зависимостей на каждый релиз: новые уязвимости в библиотеках появляются постоянно, и это самая дешёвая автоматизация.
• Поиск секретов в коммитах — до попадания в репозиторий, а не после.
• Статический анализ с разумным набором правил: слишком строгий набор команда отключит через месяц.
• Обновление зависимостей по расписанию, а не «когда сломается».
• Ревью изменений в чувствительных местах — права, аутентификация, платежи — обязательным вторым человеком.
• Проверка прав в тестах: автотест, который убеждается, что чужой заказ недоступен, ловит регрессию навсегда.

Это и есть безопасная разработка в практическом смысле: не отдельная дисциплина, а несколько шагов, встроенных в обычный конвейер сборки.

Тест на проникновение отвечает на другой вопрос: что можно сделать с системой снаружи, не имея доступа к коду.

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

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

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

Стоимость определяется объёмом кода, числом интеграций и глубиной проверки.

По нашим работам: аудит кода и архитектуры — от 200 до 600 тыс. ₽, консалтинг по стеку и разбор смет подрядчика — от 300 до 900 тыс. ₽, исправления в составе разработки — от 1,7 млн ₽, работы по конвейеру и инфраструктурным проверкам отдельной услугой — от 200 тыс. ₽. Аттестацией и защитой серверного парка мы не занимаемся — это работа лицензированных организаций. Точная цифра зависит от объёма системы: оценка проекта бесплатная.

Прикинуть бюджет можно заранее — бесплатный калькулятор оценки собирает вилку по составу работ за несколько минут.

Покупают не ту работу. Нужен был разбор кода, заказали проверку документов — бумаги есть, дыра в правах доступа осталась.

Собирают данные «на всякий случай». Чем больше собрано, тем дороже утечка; половину полей в формах можно убрать без потерь для бизнеса.

Тестируют на копии боевых данных. Тестовый контур защищён слабее, а данные в нём те же самые.

Исправляют по списку из инструмента. Команда тратит недели на предупреждения низкой критичности, а обход прав доступа остаётся.

Не проверяют восстановление из резервных копий. Копии есть, но никто не пробовал развернуть их; выясняется это в худший момент.

Первое — написать модель угроз на одну страницу: какие данные у вас есть, кто может ими заинтересоваться, что произойдёт при утечке и при недоступности сервиса. Этот документ определяет всё остальное.

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

Третье — включить в конвейер анализ зависимостей и поиск секретов. Два дня работы, а закрывают целый класс типовых проблем.