На конференции OS Day руководитель группы системных исследований «Лаборатории Касперского» Игорь Сорокин представил доклад «Применение возможностей KasperskyOS и принципов SOLID при проектировании информационных систем». В своем выступлении он предложил переосмыслить привычные подходы к архитектуре ИС, объединив практики из промышленного программирования и инструментарий KasperskyOS. Игорь объяснил, что при проектировании любых информационных систем, важно не просто разрабатывать код, а выстраивать четкую архитектуру, где каждый модуль знает свою роль. И здесь помогают принципы SOLID.
Он напомнил, что SOLID-принципы, разработанные Робертом Мартином, традиционно применяются в классическом ООП. Однако, по его мнению, они отлично ложатся и на архитектуру распределенных и изолированных компонентов в KasperskyOS. Прежде всего потому, что сама микроядерная архитектура ОС задает модульность по умолчанию, а политики безопасности привязываются к интерфейсам на уровне компиляции.
Первый и, пожалуй, основной принцип — Single Responsibility. Мы выделяем каждый модуль под одну бизнес-функцию. Это упрощает сопровождение, снижает поверхность атаки и делает политику безопасности точечной.
По его словам, это позволяет избежать ситуации, когда компрометация одного модуля (например, сетевого) приводит к срыву работы другого — скажем, файлового. В случае KasperskyOS, где модули изолированы и взаимодействуют строго по IPC, подобное разделение становится особенно естественным.
Продолжая логическую цепочку, Сорокин объяснил, как принцип Open/Closed позволяет развивать систему без вмешательства в существующий код. Добавляя новый модуль, разработчик не ломает уже налаженную архитектуру и может применять механизм graceful degradation — отказоустойчивость за счет модульности. Например, если выходит из строя драйвер Wi-Fi, все равно по-прежнему остаются Bluetooth или Ethernet. Это и есть управляемая деградация. Теряется не систему целиком, а только один канал связи.
Не менее важен и принцип стабильных API — Liskov Substitution. По словам спикера, при проектировании информационной системы архитекторы должны избегать частой смены интерфейсов, поскольку это влечет лавинообразное обновление зависимостей и пересмотр политик безопасности.
Дискуссию вызвало применение Interface Segregation и Dependency Inversion — двух наиболее спорных принципов в контексте верифицируемых систем. Сорокин настоял на том, что эти принципы работают на минимизацию привилегий и снижение связанности.
Мы делим интерфейсы по логике безопасности. Аутентификация — один модуль. Доступ к БД — другой. Между ними — политика. Даже если атакующий получит доступ к первому, второй останется защищен.
В докладе также прозвучал кейс применения этих принципов на практике. Сорокин рассказал, как в KasperskyOS используется декларативное описание IPC-интерфейсов. На базе этих описаний автоматически генерируется транспортный код и накладываются политики безопасности. По словам Сорокина, в итоге получается не сырой пайп между процессами, а бизнес-интерфейс с четкими правами доступа. Это упрощает как разработку, так и анализ поведения системы.
Отдельное внимание докладчик уделил подсистеме System Health Management — встроенному механизму обнаружения аномалий поведения на уровне control flow graph. Система строит сигнатуру процесса еще на этапе сборки, а затем в реальном времени отслеживает отклонения. Если кто-то использует IPC-методы не так, как заложено в сигнатуре, это может быть признаком атаки. И специалисты могут автоматически отключить или перезапустить скомпрометированный процесс.
Доклад вызвал одну из самых оживленных дискуссий на OS Day. Станислав Долматин, эксперт в области верифицируемых систем, подверг сомнению применимость принципов SOLID в архитектурах, где критичны жесткая определенность, стабильность и формальная верификация. Он указал, что SOLID изначально был создан для гибких бизнес-приложений на Java и плохо масштабируется на системное ПО.
В частности, Долматин утверждал, что:
• Liskov Substitution — это про расширяемость и наследование, а не про стабильность API;
• Dependency Injection разрушает статический анализ и делает поведение системы менее предсказуемым;
• принципы гибкости противоречат требованиям безопасности, где нежелательны «неожиданные» поведения и типы данных.
Игорь Сорокин подробно прокомментировал каждый из тезисов критики. Он напомнил, что SOLID — это не догма, а набор архитектурных рекомендаций, которые при должной адаптации могут быть применены в самых разных средах, включая архитектуры на базе микроядерной ОС.
Liskov Substitution — это не про наследование ради гибкости, а про неизменность контракта. Когда мы обновляем модуль, например, драйвер или подсистему, интерфейс остается прежним — это и есть гарантия подстановки без разрушения других частей системы.
В отношении Dependency Injection Сорокин привел пример из системного программирования, где используется абстракция «сетевая карта». Конкретные реализации могут подставляться в зависимости от оборудования, при этом интерфейс остается универсальным. Такой подход помогает упростить декомпозицию, описание связей между модулями и последующую реализацию политик безопасности.
Что касается гибкости и сертификации, гибкость архитектуры не мешает прохождению сертификационных процедур. Напротив, модульность и ясная структура на уровне интерфейсов только упрощают проверку соответствия требованиям. SOLID — это не культ Мартина. Это инженерный инструмент, которым архитектор должен уметь пользоваться осмысленно, опираясь на контекст и здравый смысл.
В целом, можно сказать, что грамотное проектирование архитектуры — это не только про безопасность, но и про удобство сопровождения, масштабирование и адаптацию под новые бизнес- и технические требования. А в связке с возможностями KasperskyOS эти архитектурные принципы становятся не просто теорией, а практическим инструментом создания устойчивых и защищенных ИС — от промышленной автоматизации до государственной инфраструктуры. Причем даже в среде с жесткими требованиями к надежности есть место архитектурному мышлению и переосмыслению классических подходов.
На конференции OS Day руководитель группы системных исследований «Лаборатории Касперского» Игорь Сорокин представил доклад «Применение возможностей KasperskyOS и принципов SOLID при проектировании информационных систем». В своем выступлении он предложил переосмыслить привычные подходы к архитектуре ИС, объединив практики из промышленного программирования и инструментарий KasperskyOS. Игорь объяснил, что при проектировании любых информационных систем, важно не просто разрабатывать код, а выстраивать четкую архитектуру, где каждый модуль знает свою роль. И здесь помогают принципы SOLID.
Он напомнил, что SOLID-принципы, разработанные Робертом Мартином, традиционно применяются в классическом ООП. Однако, по его мнению, они отлично ложатся и на архитектуру распределенных и изолированных компонентов в KasperskyOS. Прежде всего потому, что сама микроядерная архитектура ОС задает модульность по умолчанию, а политики безопасности привязываются к интерфейсам на уровне компиляции.
Первый и, пожалуй, основной принцип — Single Responsibility. Мы выделяем каждый модуль под одну бизнес-функцию. Это упрощает сопровождение, снижает поверхность атаки и делает политику безопасности точечной.
По его словам, это позволяет избежать ситуации, когда компрометация одного модуля (например, сетевого) приводит к срыву работы другого — скажем, файлового. В случае KasperskyOS, где модули изолированы и взаимодействуют строго по IPC, подобное разделение становится особенно естественным.
Продолжая логическую цепочку, Сорокин объяснил, как принцип Open/Closed позволяет развивать систему без вмешательства в существующий код. Добавляя новый модуль, разработчик не ломает уже налаженную архитектуру и может применять механизм graceful degradation — отказоустойчивость за счет модульности. Например, если выходит из строя драйвер Wi-Fi, все равно по-прежнему остаются Bluetooth или Ethernet. Это и есть управляемая деградация. Теряется не систему целиком, а только один канал связи.
Не менее важен и принцип стабильных API — Liskov Substitution. По словам спикера, при проектировании информационной системы архитекторы должны избегать частой смены интерфейсов, поскольку это влечет лавинообразное обновление зависимостей и пересмотр политик безопасности.
Дискуссию вызвало применение Interface Segregation и Dependency Inversion — двух наиболее спорных принципов в контексте верифицируемых систем. Сорокин настоял на том, что эти принципы работают на минимизацию привилегий и снижение связанности.
Мы делим интерфейсы по логике безопасности. Аутентификация — один модуль. Доступ к БД — другой. Между ними — политика. Даже если атакующий получит доступ к первому, второй останется защищен.
В докладе также прозвучал кейс применения этих принципов на практике. Сорокин рассказал, как в KasperskyOS используется декларативное описание IPC-интерфейсов. На базе этих описаний автоматически генерируется транспортный код и накладываются политики безопасности. По словам Сорокина, в итоге получается не сырой пайп между процессами, а бизнес-интерфейс с четкими правами доступа. Это упрощает как разработку, так и анализ поведения системы.
Отдельное внимание докладчик уделил подсистеме System Health Management — встроенному механизму обнаружения аномалий поведения на уровне control flow graph. Система строит сигнатуру процесса еще на этапе сборки, а затем в реальном времени отслеживает отклонения. Если кто-то использует IPC-методы не так, как заложено в сигнатуре, это может быть признаком атаки. И специалисты могут автоматически отключить или перезапустить скомпрометированный процесс.
Доклад вызвал одну из самых оживленных дискуссий на OS Day. Станислав Долматин, эксперт в области верифицируемых систем, подверг сомнению применимость принципов SOLID в архитектурах, где критичны жесткая определенность, стабильность и формальная верификация. Он указал, что SOLID изначально был создан для гибких бизнес-приложений на Java и плохо масштабируется на системное ПО.
В частности, Долматин утверждал, что:
• Liskov Substitution — это про расширяемость и наследование, а не про стабильность API;
• Dependency Injection разрушает статический анализ и делает поведение системы менее предсказуемым;
• принципы гибкости противоречат требованиям безопасности, где нежелательны «неожиданные» поведения и типы данных.
Игорь Сорокин подробно прокомментировал каждый из тезисов критики. Он напомнил, что SOLID — это не догма, а набор архитектурных рекомендаций, которые при должной адаптации могут быть применены в самых разных средах, включая архитектуры на базе микроядерной ОС.
Liskov Substitution — это не про наследование ради гибкости, а про неизменность контракта. Когда мы обновляем модуль, например, драйвер или подсистему, интерфейс остается прежним — это и есть гарантия подстановки без разрушения других частей системы.
В отношении Dependency Injection Сорокин привел пример из системного программирования, где используется абстракция «сетевая карта». Конкретные реализации могут подставляться в зависимости от оборудования, при этом интерфейс остается универсальным. Такой подход помогает упростить декомпозицию, описание связей между модулями и последующую реализацию политик безопасности.
Что касается гибкости и сертификации, гибкость архитектуры не мешает прохождению сертификационных процедур. Напротив, модульность и ясная структура на уровне интерфейсов только упрощают проверку соответствия требованиям. SOLID — это не культ Мартина. Это инженерный инструмент, которым архитектор должен уметь пользоваться осмысленно, опираясь на контекст и здравый смысл.
В целом, можно сказать, что грамотное проектирование архитектуры — это не только про безопасность, но и про удобство сопровождения, масштабирование и адаптацию под новые бизнес- и технические требования. А в связке с возможностями KasperskyOS эти архитектурные принципы становятся не просто теорией, а практическим инструментом создания устойчивых и защищенных ИС — от промышленной автоматизации до государственной инфраструктуры. Причем даже в среде с жесткими требованиями к надежности есть место архитектурному мышлению и переосмыслению классических подходов.
Подпишитесь на наши сообщества и получите ссылку на дистрибутив в чате
