«Пред-CISO»: Как меняется профессия ИБ-архитектора

Статья продолжает серию материалов SecPost о профессиях рейтинга «Новая элита кибербеза». О том, как изменилась работа ИБ-архитектора и почему специалистов с нужным сочетанием опыта и компетенций по-прежнему не хватает, мы поговорили с Евгением Балком, руководителем департамента развития и архитектуры «Кросстеха», Андреем Бариновым, и.о. директора НОЦ «Информационная безопасность» ЮУрГУ, Евгением Гуляевым, руководителем отдела поддержки продаж R-Vision, Владимиром Садовским, исполняющим обязанности руководителя департамента информационной безопасности «М.Видео-Эльдорадо», и Дмитрием Соколовым, экс-CISO «Моего Офиса

Заявки на участие в рейтинге «Новая элита кибербеза» принимаются до 30 сентября 2026 года.

Архитектор подключается раньше

Самостоятельная роль ИБ-архитектора существовала далеко не во всех компаниях. Ее функции могли выполнять системные администраторы, специалисты по защите информации или эксперты по отдельным направлениям. По словам Андрея Баринова, по мере усложнения ИТ-инфраструктуры появилась потребность в специалистах, которые способны видеть систему защиты целиком, связывать между собой разные механизмы и учитывать требования бизнеса.

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

На практике даже одно требование способно заметно повлиять на проект. Дмитрий Соколов приводит пример с шифрованием: если необходимость в нем выявляется после проектирования, могут потребоваться дополнительные вычислительные мощности, диски, деньги и время. В итоге меняется не отдельная настройка, а стоимость и сроки всего решения. В некоторых случаях после пересчета первоначальный вариант теряет экономический смысл.

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

Сложность возникает между системами

Работу ИБ-архитектора усложняют прежде всего зависимости между системами и высокая скорость изменений, считает Владимир Садовский. Один бизнес-процесс может задействовать внутренние приложения, облачный сервис и подрядчика, а проблемы возникают на стыках: сервисная учетная запись получает лишние права, временный доступ остается после завершения работ, одна система начинает доверять другой больше, чем нужно. Поэтому оценивать приходится не только отдельные компоненты, но и последствия их взаимодействия.

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

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

Архитектура меняется вместе с системой

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

На это накладывается смена технологий. Евгений Балк отмечает, что к привычной инфраструктуре добавились контейнерные платформы, облачные сервисы, большие языковые модели и ИИ-агенты. Одновременно сократились сроки вывода цифровых продуктов, а требования к их бесперебойной работе выросли. Архитектору приходится учитывать новые технологии, не теряя из виду базовые задачи — доступ, сегментацию и защиту инфраструктуры.

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

Опыт складывается из полного цикла проектов

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

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

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

Как специалист становится ИБ-архитектором

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

Архитектор корпоративной системы и архитектор продукта, который затем внедряется в разных инфраструктурах, решают разные задачи, отмечает Андрей Баринов. Для первого хорошей базой может быть сетевая и инфраструктурная безопасность, для второго — разработка, AppSec или DevSecOps.

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

ИБ-архитектор может быть промежуточной ступенью между глубоким техническим экспертом и руководителем функции ИБ. Дмитрий Соколов называет такую роль «пред-CISO»: специалист уже выходит за пределы одной технологии, оценивает риски и учитывает бизнес-контекст, но еще не отвечает за всю функцию информационной безопасности – такое сближение ролей особенно заметно в небольших и средних компаниях.

Что останется важным

В ближайшие пять–десять лет в работу ИБ-архитектора войдет больше задач, связанных с защитой ИИ-систем, гибридных и мультиоблачных сред. Евгений Балк отмечает, что при этом сохранят значение базовые знания сетевой и инфраструктурной безопасности, а роль коммуникационных навыков будет расти: архитектору придется объяснять сложные решения руководству, работать с владельцами систем и обосновывать расходы на безопасность.

Конкретные технологии будут меняться, поэтому строить карьеру вокруг одного набора инструментов вряд ли имеет смысл. Евгений Гуляев советует молодым специалистам искать проекты, где приходится менять угол зрения — работать с инфраструктурой, приложениями, доступом, данными и облаками, общаться с разработкой, эксплуатацией и бизнесом. Через несколько лет ценность будет иметь способность быстро разобраться в новой среде, увидеть зависимости, оценить риск и предложить решение, которое можно реализовать.

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