Цена аудита безопасности для небольшой компании: за что берут деньги

MAATRIX

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

Из чего на самом деле складывается счёт

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

Дальше — по каждому пункту отдельно, потому что именно тут прячутся вопросы «а почему так дорого» и «а можно дешевле».

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

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

• читает правила firewall и ищет не «открытый порт», а логическую ошибку — например, правило, которое случайно разрешает доступ откуда угодно из-за неверного порядка цепочек;
• смотрит на разграничение доступа (IAM-политики, sudo-права, SSH-ключи) и ищет накопленный за годы избыточный доступ, который сканер не видит вообще — это не уязвимость в смысле CVE, а организационная дыра;
• проверяет код на бизнес-логические ошибки: можно ли изменить чужой заказ, подменив ID в запросе, можно ли обойти проверку прав через параметр, который разработчик не предусмотрел как атакуемый;
• изучает хранение секретов — не «зашифрованы ли пароли», а где именно лежат ключи API, кто до них может достать, что произойдёт при компрометации одного сервиса.

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

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

Инструменты сканирования: лицензии тоже стоят денег

Вторая статья расходов менее заметна клиенту, но вполне реальна для подрядчика. Коммерческие сканеры уязвимостей (класса Nessus, Qualys, Burp Suite Professional) стоят денег за годовую лицензию, и эта стоимость так или иначе закладывается в цену проекта — либо через фиксированную наценку, либо через почасовую ставку, которая учитывает амортизацию лицензии на объём проектов в год.

Это не значит, что без коммерческой лицензии аудит невозможен — open-source инструменты вроде OpenVAS, Lynis, OWASP ZAP, Trivy закрывают значительную часть задач бесплатно. Но здесь есть нюанс, который часто упускают: бесплатный инструмент не означает бесплатное время. Открытый сканер обычно даёт больше ложных срабатываний и требует более тщательной ручной проверки результатов — то есть экономия на лицензии частично компенсируется дополнительным временем специалиста на верификацию находок. Мы разбирали конкретный пример с Lynis — там как раз видно, что сырой вывод инструмента без интерпретации специалистом мало что говорит о реальном риске.

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

Отчёт с рекомендациями: не «нашли — значит готово»

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

• краткое резюме для руководства — без технических терминов, с оценкой рисков в понятных категориях (критично / высоко / средне / низко);
• детальный список находок с указанием, где именно проблема (конкретный сервис, файл конфигурации, строка кода), и почему она опасна именно в вашем контексте;
• конкретные шаги по устранению — не общую фразу «обновите ПО», а точную рекомендацию: какую версию поставить, какой параметр конфигурации изменить, какой код переписать;
• приоритизацию — что чинить в первую очередь, потому что у небольшой команды обычно нет ресурсов закрыть всё сразу.

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

Ретест после исправлений: когда он нужен

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

Ретест иногда включают в базовую стоимость проекта (особенно если аудитор заинтересован в подтверждённом результате для своего портфолио или у вас долгосрочный контракт), а иногда оплачивают отдельно как дополнительный этап. Здесь стоит трезво оценить, для какого масштаба бизнеса ретест действительно нужен:

• если аудит проводился из-за регуляторного требования (например, для соответствия стандарту, который прямо требует подтверждения устранения находок) — ретест обязателен, без него аудит формально не закрыт;
• если аудит был инициативным, для собственного спокойствия — можно ограничиться самостоятельной проверкой по чек-листу из отчёта, если в команде есть кто-то, способный это сделать компетентно;
• если исправления касались критичных уязвимостей (удалённое выполнение кода, обход аутентификации) — ретест того стоит почти всегда, потому что цена ошибки при неполном исправлении высока.

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

Кому внешний аудит действительно нужен

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

Аудит стоит заказывать, если:

• вы обрабатываете чувствительные данные — персональные данные клиентов, медицинскую информацию, платёжные реквизиты, юридически значимую переписку;
• на вас распространяются регуляторные требования — 152-ФЗ, GDPR для работы с европейскими пользователями, отраслевые стандарты (PCI DSS для платежей, требования к финтеху);
• у вас публичный сервис с достаточно большой аудиторией, где инцидент безопасности означает не только технические потери, но и репутационный удар, который сложно измерить заранее;
• вы готовитесь к сделке (due diligence при продаже компании, привлечении инвестиций), где независимый аудит — часть процесса, а не опция;
• у вас нет в штате специалиста, способного трезво оценить собственную инфраструктуру — сторонний взгляд в этом случае не роскошь, а единственный способ получить объективную картину.

Можно обойтись базовыми мерами самостоятельно, если:

• проект небольшой, внутренний, некритичный — например, служебный дашборд без доступа извне или тестовая среда без реальных данных;
• вы не подпадаете под регуляторные требования и не обрабатываете данные третьих лиц;
• в команде есть человек, способный пройтись по чек-листу безопасности нового сервера, настроить SSH-ключи вместо паролей, обновления безопасности и базовый firewall — этого достаточно для проекта, где риск утечки не критичен для бизнеса.

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

Как снизить итоговый счёт, не теряя в качестве

Раз основная статья расходов — оплачиваемое время специалиста, есть несколько способов законно сократить его без ущерба для результата:

1. Соберите документацию заранее. Схема сети, список серверов и сервисов, версии ПО, список пользователей с доступом — всё, что не нужно реконструировать в процессе, экономит часы работы.
2. Сузьте область проверки осознанно. Аудит «всей компании» стоит дороже аудита конкретного продакшн-периметра. Если бюджет ограничен, начните с систем, где выше риск — это честнее, чем формальный поверхностный аудит всего сразу.
3. Устраните низко висящие плоды до начала работы. Обновите ПО, закройте очевидно лишние открытые порты, включите SSH-ключи вместо паролей — специалист не будет тратить оплачиваемое время на находки, которые вы могли закрыть сами за час.
4. Договоритесь о формате отчёта заранее. Если вам не нужна презентация для совета директоров, а нужен только технический список с рекомендациями — это может сократить время на оформление.

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

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