Безопасная архитектура. От принципа наименьших привилегий до вызовов ИИ и трендов 2026 года

Безопасная архитектура. От принципа наименьших привилегий до вызовов ИИ и трендов 2026 года

С чего начинается проектирование защищенного ПО? Как изменяются подходы к проектированию безопасности при разработке AI-систем? Прогноз на ближайшее будущее строим с руководителем направления безопасной разработки УЦСБ Евгением Тодышевым.

— Как на практике применять принцип наименьших привилегий и что такое безопасные настройки по умолчанию?

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

Безопасность настройки по умолчанию основана на принципе «запрещено пока не разрешено» и делает «сервис из коробки» максимально закрытым. Например, при создании новой учетной записи пользователя она по умолчанию не имеет привилегированных прав и доступ к программным интерфейсам (API) выключен. И только администратор системы должен сознательно их включать, понимая все риски. Также при первом входе система сама должна требовать смены пароля администратора, чтобы его нельзя было дальше использовать по умолчанию.

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

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

— Как спроектировать систему разграничения прав в приложении?

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

Для обеспечения гибкой модели доступа можно использовать связку RBAC и ABAC, то есть ролевой и атрибутной модели. Следует предусмотреть отказ от наследования привилегий по умолчанию и явно задавать разрешение для каждой новой сущности. Например, если создается новая папка, пользователь не должен на нее получить те же права, что и на родительскую, — это предотвратит случайное расширение прав. Кроме того, надо создать автоматические тесты на нарушение прав доступа, чтобы пользователю с низкими привилегиями не удалось выполнить действия администратора.

— Атаки на цепочки поставок — один из ключевых вызовов последних лет. На что еще, помимо Supply Chain Attack, стоит обратить внимание в 2026 году?

— Я бы выделил три четких направления. Во-первых, безопасность мобильных приложений. Их количество и зрелость растут, они работают с критичными данными и даже управляют инфраструктурой. Защита от компрометации устройства — must have.

Во-вторых, API Security. Количество API растет лавинообразно, они становятся ядром цифровых продуктов. Необходимы централизованный контроль, анализ трафика и защита от злоупотреблений.

И главный тренд, который мы уже затронули чуть раньше, — MLSecOps. Компании массово внедряют модели машинного обучения (ML-модели) для автоматизации, но часто забывают про их безопасность. В ближайшей перспективе ожидается появление ГОСТа и усиление регуляторных требований к безопасности машинного обучения. Это станет отдельной дисциплиной.

Кстати, детально обсуждать тренды мы будем 19 марта на квартирнике по безопасной разработке в Москве. Приходите, будем рады пообщаться вживую с экспертами-практиками DevSecOps и всеми, кто хочет глубже погрузиться в эту тему.

— Какие проблемы возникают при проектировании AI-систем?

— Проектирование AI-систем, особенно с точки зрения безопасности вообще, достаточно непривычная парадигма, которая порождает и новые вызовы. Если в традиционном софте мы имеем дело с детерминированной логикой и управляемыми рисками в виде известных уязвимостей и ошибок в коде, то здесь работаем с вероятностными моделями. И это вносит определенные корректировки в подходы. В AI-системах появляется фундаментальный класс неуправляемых или слабоуправляемых рисков, связанных с самой природой модели. Также появляются уязвимости, которые присущи данным: то есть атаки смещаются с кода на данные, и тут требуется другой подход к защите. Вдобавок модель сама по себе становится целевым активом и вектором атаки (к примеру, кража интеллектуальной собственности, инверсия модели и т. д.).

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

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

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

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

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