Документы eng
Главная страница / Разработка KasperskyOS / Предпосылки создания операционной системы KasperskyOS

Предпосылки создания операционной системы KasperskyOS

В начале 2000-х годов активное развитие интернета, которому способствовали широкомасштабные инвестиции в телекоммуникационную инфраструктуру, создало все условия для появления организованной киберпреступности. Фактически уже в то время злоумышленники эффективно использовали интернет и зловредное ПО для вымогательства, кибершпионажа и мошенничества. Следуя своей основной миссии, «Лаборатория Касперского» всегда предоставляла средства киберзащиты, способные эффективно бороться с новыми угрозами.

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

Малые вычислительные мощности мобильных и встраиваемых систем не позволяли использовать классический подход, когда средства защиты накладываются отдельно на защищаемый объект. Именно тогда появилась идея создания операционной системы, которая будет обладать «врождённым иммунитетом» по отношению к зловредному ПО.

Для решения этой задачи в «Лаборатории Касперского» было создано отдельное подразделение, первоочередной задачей которого было взглянуть на мировой опыт решения проблемы создания безопасной ОС. В начале 2000-х уже существовало большое количество теоретических исследований на тему безопасности операционных систем. В частности, еще в далеком 1972 году Джеймс Андерсон (James Anderson) ввёл понятие безопасной операционной системы и описал концепцию «монитора обращений» (Reference monitor). Позже, в 1981 году, Джон Рашби (John Rushby) предложил концепцию «ядра разделения» (Separation kernel), которая легла в основу архитектуры MILS (Multiple Independent Level Architecture), а в 1999 г. была представлена архитектура FLASK (Flux Advanced Security Kernel). Эти идеи, а также ряд собственных разработок легли в основу операционной системы KasperskyOS.

Архитектура KasperskyOS

При создании собственной ОС перед командой «Лаборатории Касперского» была поставлена задача обеспечить иммунитет KasperskyOS к зловредному ПО. Кратко её можно сформулировать следующим образом: в случае атаки операционная система должна уметь локализовывать очаг поражения и не допускать его распространения до масштабов, когда это может негативно сказаться на работе самой KasperskyOS и приложений, которые не были заражены зловредным ПО.

Микроядерная архитектура

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

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

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

Изоляция компонентов операционной системы

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

Для соответствия данному требованию, KasperskyOS реализована таким образом, что любое запускаемое в операционной системе приложение представляет из себя отдельную сущность («entity») (см. рис. 1). Для запуска в KasperskyOS каждая сущность должна предоставить перечень интерфейсов, которые позволяют с ней взаимодействовать, а также политику безопасности, описывающую правила взаимодействия.

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

Рис. 1 Высокоуровневая архитектура KasperskyOS

Система контроля доступа

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

Большая часть этих вопросов была теоретически проработана и проверена на прототипах в рамках разработки FLASK-архитектуры. При создании KasperskyOS были использованы результаты этих исследований.

Одной из фундаментальных проблем информационной безопасности современных операционных систем общего назначения, таких как Linux или Windows, является ограниченная поддержка моделей безопасности. В частности, в обеих этих операционных системах используется модель дискреционного доступа, что способствует простоте использования таких систем. К сожалению, дискреционная модель далеко не всегда может описать правила взаимодействия между различными объектами операционной системы. Например, дискреционная модель не регламентирует, в каком состоянии должно находиться пользовательское приложение, чтобы обратиться к определенным ресурсам, например, файлу на диске. Это может быть предусмотрено в коде самого пользовательского приложения, но тогда гибкость приложения будет утеряна, поскольку для изменения политики безопасности придётся его переписать.

Для устранения этого недостатка в KasperskyOS предусмотрен целый ряд механизмов.

Во-первых, конфигурация безопасности и бизнес-логика решения отделены друг от друга. Бизнес-логика определяется в коде сущностей, тогда как конфигурация безопасности описывается в отдельном файле security.cfg (см. рис. 2).

Во-вторых, для обеспечения поддержки нескольких моделей безопасности, а также их комбинирования в рамках одной конфигурации безопасности в KasperskyOS вычисление допустимости операции реализуется на уровне отдельной подсистемы — Kaspersky Security System (см. рис. 2).

Рис. 2 Kaspersky Security System (KSS)

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

Такие технические решения позволяют комбинировать в одной конфигурации безопасности несколько моделей безопасности и добиться необходимой гибкости в их описании. Например, в текущей версии KasperskyOS в рамках одной политики можно комбинировать следующие модели безопасности: ролевой доступ (RBAC), Object Capability, Type Enforcement, а также модели безопасности на базе конечных автоматов или даже темпоральных логик, необходимые для контроля процессов в современных киберфизических системах, и другие модели безопасности.

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

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

Заключение

Разработка новых и портирование существующих приложений под KasperskyOS требует дополнительных усилий от разработчика, но мы в «Лаборатории Касперского» постарались сделать этот процесс наименее трудозатратным, предоставляя разработчику максимально привычное окружение со стороны инструментов разработки и языков программирования. Также мы считаем основополагающей идею о том, что операционная система должна сама подталкивать разработчиков к решению вопросов информационной безопасности приложения ещё на этапе его проектирования, а не во время последней итерации разработки или финального тестирования.

Всем нескучного программирования и поменьше багов!!!

Команда KasperskyOS