Журнал "Information Security/ Информационная безопасность" #2, 2026

по-прежнему существует. И здесь ключевую роль играет позиция руко- водства. Если есть четкое решение, что переход – это стратегическая зада- ча, под нее выделяются ресурсы, фор- мируется команда, ставятся KPI, – про- ект, как правило, реализуется успешно. Если же отношение формальное – нам это навязали, но мы не очень хотим, – начинаются организационные пробле- мы: не хватает ресурсов, нет ответ- ственных, процесс буксует. По моему опыту, не бывает проектов, которые невозможно реализовать. Бывают проекты, которые по-настояще- му не захотели реализовать. И в основе этого выбора – вопрос риска. Насколько компания готова оставаться зависимой от внешних технологий в критичных точ- ках инфраструктуры. – Встроенные механизмы без- опасности скорее усложняют или упрощают работу администрато- ров? – Здесь эффект двойственный. На этапе внедрения встроенные механизмы безопасности, безусловно, усложняют работу. Требуется больше времени, выше требования к экспертизе: нужно глубже разобраться в архитектуре, пра- вильно настроить политики, учесть влия- ние на сервисы и бизнес-приложения. Это особенно заметно, если внедрение выполняется силами заказчика или интегратора. Но это неизбежная плата за фундамент. Если проводить аналогию: при строительстве сложной системы – как и высотного здания – нельзя эконо- мить на основании. Зато после того как базовая конфигу- рация выстроена, ситуация меняется. Система становится более предсказуе- мой, снижается количество ошибок, уменьшается число инцидентов. Адми- нистрирование в итоге упрощается, пото- му что многие механизмы контроля и защиты уже работают из коробки. Поэтому в стратегическом смысле встроенная безопасность скорее упро- щает жизнь – за счет того, что снижает операционную нагрузку и риски. – Как вы выстраиваете интег- рацию Astra Linux, ALD Pro и решений вроде SIEM, PAM и дру- гих ИБ-систем? – Мы подходим к интеграции системно – через модель технологического парт- нерства и продуктовый подход. Сначала четко определяем зоны ответственности: что закрывают наши продукты, какую цен- ность дают партнерские решения. Дальше формируем сквозные сценарии – не на уровне отдельных функций, а на уровне бизнес-задач заказчика. Ключевое здесь – не просто подключить системы друг к другу, а описать, как с этим жить: настрой- ки, эксплуатация, типовые сценарии. Очень важна документация и сопро- вождение. Интеграция – это не разовое действие. Продукты обновляются, появляются новые версии, и связка должна оставаться стабильной. Поэтому мы выстраиваем долгосрочные парт- нерские отношения, в рамках которых поддерживаем совместимость и акту- альность интеграций. Это напрямую сни- жает риски внедрения и повышает устой- чивость инфраструктуры. Если говорить о типичных проблемах на практике, многие заказчики идут по пути "соберем лучшее по частям": отдельно выбирают почту, отдельно вир- туализацию, ОС, инструменты управле- ния – и рассчитывают, что на выходе получится оптимальная система. Но так не работает. В итоге получается набор решений, которые плохо интегрированы друг с другом. На их сведение уходит от нескольких месяцев, и даже после этого стабильность не гарантирована: любое обновление одного из компонентов может нарушить работу всей связки. Поэтому мы как раз и уходим от такого подхода – в сторону заранее прорабо- танных, проверенных интеграций. – Что на практике означает сер- тификация ФСТЭК России и без- опасная разработка в жизненном цикле продукта? – Часто сертификацию воспринимают как формальность – получили бумагу и забыли. На практике это не так. Во-первых, сертификация подтвер- ждает, что решение действительно исследовано. Регуляторы детально изучают архитектуру, документацию, процессы развертывания. Это полно- ценная экспертиза, а не формальная проверка. Во-вторых, безопасность закладыва- ется в архитектуру изначально. Мы пони- маем требования регуляторов и строим решения с учетом этих требований, осо- бенно учитывая, что наши заказчики – это КИИ и госсектор. Сертификат РБПО означает, что без- опасность контролируется на всем жиз- ненном цикле: анализ кода, тестирова- ние на уязвимости, проверка изменений. То есть речь идет не только о безопас- ном продукте на выходе, но и о безопас- ном процессе его создания. В итоге все это сводится к ключевой ценности инфраструктуры – надежности. Можно сделать производительное и функциональное решение, но если оно ненадежно, то оно не имеет практиче- ской ценности. Поэтому для нас сертификация – это не формальность, а инструмент обес- печения надежности и безопасности, которые ожидает заказчик. – Какую роль багбаунти играет в выявлении уязвимостей в инфраструктурном ПО – на уровне ОС и домена? – Багбаунти – это, на мой взгляд, один из самых эффективных инстру- ментов для повышения безопасности, потому что он позволяет привлечь внеш- нюю экспертизу. Внутри любой команды, какой бы сильной она ни была, со вре- менем формируется определенная логи- ка мышления и, как следствие, появляют- ся слепые зоны. Даже при наличии внут- ренних тестов и автоматизированных инструментов невозможно предусмот- реть все сценарии эксплуатации. Внеш- ние исследователи смотрят на продукт иначе, проверяют нестандартные гипо- тезы и часто находят те уязвимости, которые неочевидны для разработчиков. В этом смысле багбаунти дополняет внутренние процессы и делает их более полноценными. Участие в таких программах – это еще и признак зрелости вендора. Ком- пания демонстрирует, что она не закры- вается от внешнего мира, готова прини- мать обратную связь и инвестировать в безопасность, в том числе оплачивая работу исследователей. Ключевым здесь остается скорость реакции: найденные уязвимости должны оперативно устра- няться, иначе сама модель теряет смысл. В итоге багбаунти напрямую влияет на надежность решений, особенно на инфраструктурном уровне, где послед- ствия ошибок могут быть максимально критичными. – Как неизменяемый режим Astra Linux влияет на поверхность атаки? – Влияние здесь прямое и довольно ощутимое. Прежде всего за счет сокра- щения самой поверхности атаки: в систе- ме остается только тот набор компонен- тов, который действительно необходим для ее работы. Чем меньше элементов – тем меньше потенциальных уязвимостей. Дополнительно фиксируется состоя- ние операционной системы. В неизме- няемом режиме исключаются любые незапланированные изменения, что принципиально усложняет жизнь зло- умышленнику. У него практически нет возможности внедрить вредоносный код, изменить конфигурацию или закрепиться в системе. В результате такая комбина- ция – минимизация и неизменяемость – заметно повышает устойчивость инфра- структуры и снижает риски компроме- тации. – Что для заказчика означает выпуск ALD Pro 3.2 LTS с точки зрения эксплуатации и обновле- ний? – Выпуск LTS-версии (с долгосрочной поддержкой), по сути, говорит о зрелости продукта и готовности вендора сопро- вождать его в долгосрочной перспекти- ве. Для заказчика это означает пред- сказуемость: можно спокойно планиро- вать обновления, изменения в инфра- структуре, не находясь в постоянном режиме срочных переходов с версии на версию. 38 • СПЕЦПРОЕКТ