Принципы SOLID и безопасность информационных систем

Надо учить не наступать на грабли!

Г. Макеев, «Объектно-ориентированное программирование: с нуля к SOLID и MVC»

 

Пять основных принципов объектно-ориентированного программирования, направленных на создание более понятного, гибкого и поддерживаемого кода (принципы SOLID), которые впервые сформулировал и обобщил Роберт Мартин (Robert C. Martin) еще в 2000 г., актуальны и сегодня. Так, в июне этого года они активно обсуждались в ходе XII научно-практической конференции Института системного программирования РАН OS DAY 2025 «Изолированные среды исполнения в современных ОС», проходившей в новом корпусе РЭУ им. Г.В. Плеханова и ставшей логическим продолжением прошлогодней XI научно-практической конференции OS DAY 2024 «Архитектурные аспекты безопасности операционных систем».

*Рисунки к статье взяты из доклада И. Сорокина («Лаборатория Касперского») на конференции OS Day 2025.

Вот что говорит о принципах SOLID их автор**: «Данные принципы являются итогом опыта, накопленного за десятилетия разработки ПО. Это не плод одного ума, а результат интеграции мыслей и записей большого числа разработчиков и исследователей ПО. Хотя они представлены как принципы объектно-ориентированного проектирования, в действительности это специальные случаи устоявшихся принципов разработки ПО».

**Роберт С. Мартин. Гибкая разработка программ на Java и C++. Принципы, паттерны и методики. СПб.: БХВ-Петербург, 2017 г., – 269 с.

О принципах SOLID на OS Day 2025

В первый день работы конференции OS Day 2025 большой интерес и оживленную дискуссию вызвал доклад Игоря Сорокина, руководителя группы системных исследований «Лаборатории Касперского», «Применение возможностей KasperskyOS и принципов SOLID при проектировании информационных систем». Он, в частности, сказал: «У нас проектирование информационной системы всегда начинается с анализа бизнес-требований, в которых определяются ее цели и задачи. Затем формулируются функциональные и нефункциональные (производительность, масштабируемость, отказоустойчивость, безопасность и т.д.) требования, которые предъявляются к информационной системе.

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

_{Важный шаг при проектировании информационной системы – выбор ее архитектуры*}

В модульной архитектуре каждый модуль выполняет какую-то определенную функцию, причем может оказаться, что для выполнения некоторой функции необходимо разработать несколько модулей. И может получиться так, что этих модулей станет слишком много, связанность будет слишком большой, и поддерживать такую систему разработчикам будет сложно. Поэтому в случае выбора модульной архитектуры перед  разработчиком встает задача – понять, сколько модулей должно быть в ИС и как эти модули будут между собой взаимодействовать. Наш опыт показал, что при решении этой задачи (декомпозиции архитектуры проектируемой ИС на оптимальное количество модулей) возможно использование принципов SOLID».

На вопрос автора статьи о том, много ли отечественных разработчиков программных продуктов используют если не все, то хотя бы некоторые из пяти принципов SOLID, И. Сорокин ответил так: «В нашей компании практикуется применение принципов SOLID. Если оценивать рынок в целом, то, на мой взгляд, как молодые специалисты, так и опытные разработчики, с которыми удается пообщаться в рамках мероприятий или при приеме на работу, в целом и разделяют эти принципы, и используют их в работе».

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

Во второй день работы конференции OS Day 2025 состоялся круглый стол «Безопасность операционных систем в контексте искусственного интеллекта», который вел вице-президент, директор департамента перспективных технологий «Лаборатории Касперского» Андрей Духвалов. Интересно, что во время этого круглого стола никто не упомянул ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования», который пришел на смену во многом устаревшему стандарту ГОСТ Р 56939-2016 и проект которого активно обсуждался год назад в рамках OS Day 2024.

На вопрос о том, стоит ли разработчикам ОС и другого системного ПО для повышения уровня кибербезопасности своих продуктов повнимательнее присмотреться к SOLID и/или ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» (введен в действие 20 декабря 2024 г.), А. Духвалов ответил так: «Безопасность – это такое же свойство разрабатываемой системы, как и любая другая функциональность. И проектировать свойства безопасности нужно одновременно с проектированием системы в целом. А, значит, и требования к безопасности системы нужно предъявлять одновременно с остальными требованиями. Если же говорить о радикальном повышении уровня кибербезопасности в системном ПО, то главный шаг — это переосмысление архитектуры систем. Именно поэтому мы выступаем за внедрение решений, безопасных на уровне архитектуры».

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

«Что касается ГОСТа по разработке безопасного ПО, – добавил эксперт, – да, это важнейший документ. Стандарты – это в первую очередь каркас, набор методических и процессных рекомендаций. Их применение действительно может улучшить процессы разработки, особенно в части управления уязвимостями, требований к обновлениям и контроля качества. Поэтому изучение и внедрение ГОСТов необходимо, особенно в сочетании с переходом к созданию конструктивно безопасных решений. То есть от наложенных средств защиты софта необходимо переходить к защите на уровне его архитектуры. И именно такой подход, на наш взгляд, станет ключевым в будущем безопасного программного обеспечения».

Как считает Екатерина Свиридова, руководитель экспертизы по сопровождению СУБД Газпромбанка, для повышения кибербезопасности своих продуктов разработчикам необходимо использовать комплексный подход, учитывая и методологическую основу, т. е. ГОСТы; документ ISO/IEC 25002:2024 «Системная и программная инженерия. Требования и оценка качества систем и программных средств (SQuaRE). Обзор и использование модели качества»; принципы разработки SOLID, а также современные технологические инструменты и ПО, в которых устранены известные уязвимости. Кроме того, следует обратить внимание на тестирование и покрытие тестами, в том числе на наличие в коде компрометирующих данных, отлаженные CI/CD процессы, выполняющие тестирование перед размещением в репозиториях, а также собственные, отраслевые или единые отечественные репозитории ПО, библиотек, фреймворков, и других артефактов open-source проектов, которые были получены из надежных источников и/или прошедших проверку по ФСТЭК.

«Среди положений текущего ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования», – добавляет Е. Свиридова, – есть и такие неочевидные на первый взгляд методы повышения кибербезопасности, как обучение сотрудников, а также формирование и поддержание в актуальном состоянии правил кодирования, что в свою очередь и определяют пять принципов SOLID. Создание понятного, гибкого и легко поддерживаемого кода позволяет не только построить надежную и масштабируемую архитектуру продукта, но также обезопасить себя от уязвимостей».

Мнения других участников ИТ-рынка

«Принципы SOLID, сформулированные еще 20 лет назад — это своего рода «правила хорошего тона» в разработке, ориентируясь на которые можно написать понятный, надежный и легко проверяемый код, – полагает Елена Скалозубова, ведущий архитектор ИБ MONS (ГК «КОРУС Консалтинг»). – Безусловно, это играет важную роль в кибербезопасности: чем понятнее и «чище» сделана программа, тем меньше в ней скрытых ошибок и уязвимостей, которыми могут воспользоваться злоумышленники. Особенно это важно при создании и развитии базового софта, например, тех же ОС, критичных, высоконагруженных специализированных ИТ-решений или систем, от которых зависит безопасность данных миллионов пользователей».

«Обеспечение безопасности того или иного ИТ-продукта строится не только на антивирусах и файерволах, – добавляет Е. Скалозубова, – но и на грамотной инженерной культуре. Когда код написан по понятным принципам (таким как SOLID), его легче защищать, сопровождать и развивать».

Более осторожно комментирует ситуацию технический директор ИТ-экосистемы «Лукоморье» («РТК ИТ плюс») Алексей Щербаков: «Да, мы применяем принципы SOLID там, где это оправдано с точки зрения архитектуры и безопасности. Хотя сами по себе эти принципы не заменяют специализированные меры кибербезопасности – такие как шифрование, соответствие рекомендациям OWASP Top 10 и другие практики. Они формируют архитектурную основу, которая помогает таким мерам эффективно работать, например, облегчает внедрение таких практик, снижает вероятность ошибок разработчика, упрощает реагирование на инциденты. Код, написанный с учетом SOLID, легче покрывать юнит-тестами, включая тесты на уязвимости. Четкая структура упрощает ревью кода и поиск так называемых дыр. А модульный подход позволяет изолировать компоненты, минимизируя возможное влияние локальных изменений или сбоев на всю систему».

Заключение

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

Автор принципов SOLID Роберт Мартин в своей книге «Принципы, паттерны и методики гибкой разработки на языке C#»*** тоже обращает внимание на то, что при разработке ПО успех зависит прежде всего от людей: «Работайте с командой увлеченных программистов, применяйте упрощенные процессы, подстроенные под эту команду, непрерывно адаптируйтесь к задаче, и успех вам гарантирован… Людей и их взаимоотношения надо ценить больше, чем процессы и инструменты… Плодотворное сотрудничество с заказчиком важнее, чем формальные договоренности по контракту…».

*** Роберт Мартин, Мика Мартин. Принципы, паттерны и методики гибкой разработки на языке C#. СПб.: Символ-Плюс, 2011 г. — 768 с.

Логично предположить, что принципы естественного отбора справедливы не только для живых организмов, но и для команд, занимающихся разработкой ПО. Поэтому выживать и развиваться будут только те команды, которые придерживаются правильных и проверенных временем принципов разработки. Кстати, эпиграф к этой публикации взят из выпущенной в прошлом году монографии Григория Макеева «Объектно-ориентированное программирование: с нуля к SOLID и MVC»**** (автор – инженер-программист с почти 20-летним стажем, канд. техн. наук, руководитель группы разработчиков наукоемкого инженерного ПО, преподаватель Уфимского университета науки и технологий).

****Григорий Макеев. Объектно-ориентированное программирование: с нуля к SOLID и MVC. СПб.: БХВ-Петербург, 2024 г., – 272 с.

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

Наступать на грабли иногда полезно. Но учиться лучше не на своих, а на чужих ошибках!