Детали кибериммунизации тонкого клиента

Кибериммунные тонкие клиенты — как все устроено
Алексей Матюшин
Cтарший аналитик по информационной безопасности, «Лаборатория Касперского»

1. Введение

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

Kaspersky Thin Client (KTC) — тонкий клиент «Лаборатории Касперского» — создан в соответствии с кибериммунной методологией, и цель этой статьи — ответить на вопрос, как именно реализуется кибериммунитет KTC, за счет чего обеспечивается его защита как от известных, так и от неизвестных угроз.

2. Что это такое и зачем нужен кибериммунитет

Чтобы ответить на вопрос «Как достигается кибериммунность Kaspersky Thin Client?» и оценить преимущества, которыми она обладает, необходимо понимание того, что такое кибериммунитет и зачем он нужен. В этом разделе мы лишь тезисно коснемся этих вопросов, а более подробно они освещаются в многосерийной статье про кибериммунный подход к проектированию.

Современный кибермир характеризуется взаимным проникновением (конвергенцией) всех видов операционных (OT) и информационных (IT) технологий. «Умными» стали не только автомобили, самолеты, системы транспорта, промышленности и управления, но и дома людей. Для конвергентных решений характерны сложность, гетерогенность компонентов, высокая связность, глобальная доступность, высокая скорость и большие объемы передачи данных, а также большой объем программного кода, в том числе заимствованного. 

В таких условиях становится недостаточным использование только наложенных мер для защиты изначально небезопасных киберсистем. Альтернативный подход — создание конструктивно безопасных (Secure by Design) систем — еще не стал повсеместным по двум основным причинам. Во-первых, разработка конструктивно безопасной, в отличие от «просто работающей» системы, требует компетенций в области кибербезопасности, а подходящие специалисты дороги и немногочисленны. Во-вторых, подход Secure by Design пока еще слабо поддержан методически.

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

3. Кибериммунность тонких клиентов

В этом разделе мы описываем верхнеуровневую архитектуру и базовые функции KTC, как достигается его кибериммунитет, какой вклад в это вносит операционная система KasperskyOS.

3.1 Архитектура и функции KTC

На следующем рисунке приведена схема взаимодействия Kaspersky Thin Client с платформами виртуализации:

Схема взаимодействия Kaspersky Thin Client с платформами виртуализации

Типовая схема работы Kaspersky Thin Client (см. рис ниже) такова:

  • Kaspersky Thin Client получает параметры сети от DHCP-сервера, либо администратор настраивает их вручную;
  • администратор подключает и настраивает взаимодействие между Kaspersky Thin Client и Kaspersky Security Center;
  • Kaspersky Thin Client получает параметры подключения к удаленному рабочему столу или приложению, обновлениям, доверенным сертификатам, а также дату и время с политикой от Kaspersky Security Center;
  • пользователь подключается к удаленному рабочему столу по протоколу RDP;
  • пользователь подключается к удаленному рабочему столу через платформу виртуализации Базис.WorkPlace или Citrix Workspace (Web access);
  • пользователь в интерфейсе Kaspersky Thin Client отправляет журналы событий и аудита на сторонний сервер журналирования;
  • Kaspersky Thin Client получает обновление программного обеспечения от сервера обновлений «Лаборатории Касперского» с помощью Kaspersky Security Center.
Типовая схема работы Kaspersky Thin Client

3.2 Обеспечение свойств кибериммунности KTC

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

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

На основе этого описания ценностей с точки зрения потребителя, в соответствии с положениями кибериммунной методологии, техническая команда выработала следующие цели безопасности, фактически являющиеся формализованным «контрактом на безопасность» KTC:

  1. В рабочем режиме устройства обеспечена конфиденциальность и целостность данных, передаваемых между устройством и удалённым рабочим столом; между устройством и брокером соединений с удаленными рабочими столами; между устройством и KSC-сервером; между устройством и сервером логирования.
  2. Обеспечена целостность хранимых на устройстве данных, полученных от пользователя, непосредственно работающего с устройством (сертификатов, реквизитов для подключения) и от KSC-сервера (конфигураций, сертификатов, лицензий, реквизитов для отключения от сервера KSC).
  3. Обновление программного обеспечения тонкого клиента выполняется только если подтверждена аутентичность и целостность обновления.

Были определены также ограничения на предпринимаемые меры защиты (априори принимаемые предположения безопасности), которые также являются частью «контракта на безопасность»: 

  1. В цели безопасности не входит защита от атак с использованием физического доступа к устройству; предотвращение исполнения на устройстве ПО и операций, не относящихся к реализации функций продукта; гарантия доступности функций, выполняемых устройством.
  2. Не рассматриваются угрозы, связанные с уязвимостями аппаратной платформы.
  3. Первоначальная настройка KTC производится доверенным администратором в специальном режиме работы устройства, в условиях отсутствия угрозы подмены адреса KSC-сервера.

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

Обобщенная верхнеуровневая схема организации тонкого клиента

Сопоставив эту схему с целями безопасности КТС, мы видим компоненты, которые напрямую влияют на них:

  • локальное хранилище данных;
  • стандартные библиотеки, имплементирующие протокол RDP и потоковое аудио.

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

В соответствии с традиционным подходом можно было бы взять все известные уязвимости библиотеки RDP (на сегодняшний день их несколько десятков) и выработать ответные меры, предотвращающие угрозы. Однако кибериммунный подход нацелен не столько на защиту активов системы, уже попавших в опасное состояние, сколько на исключение возможности попадания активов в такие состояния. Это существенно, поскольку, с одной стороны, стандартная библиотека постоянно обновляется и в будущем в ней появятся новые уязвимости, а с другой — нет никаких гарантий, что даже в какой-то «замороженной» ее версии выявлены все уязвимости. Это очень большой объем нетривиального кода, и глубокая его верификация коммерчески нецелесообразна. В соответствии с кибериммунным подходом, потенциально опасный компонент должен быть изолирован от защищаемых ценностей. Именно так мы и сделали, «заслонив» стандартную библиотеку RDP собственным стандартным доверенным компонентом с достаточно простой функциональностью — TLS-терминатором, и ограничив политиками безопасности все взаимодействия между компонентами. Все сказанное про библиотеку реализации RDP справедливо и для библиотеки потокового аудио. Впрочем, как и для любой другой сторонней библиотеки, реализующей какой-либо типовой функционал.

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

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

Достижение Цели 1

Цель: в рабочем режиме устройства обеспечена конфиденциальность и целостность данных, передаваемых между устройством и удалённым рабочим столом; между устройством и брокером соединений с удаленными рабочими столами; между устройством и KSC-сервером; между устройством и сервером логирования.

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

Достижение Цели 2

Цель: обеспечение целостности хранимых на устройстве данных, полученных от пользователя, непосредственно работающего с устройством (сертификатов, реквизитов для подключения) и от KSC-сервера (конфигураций, сертификатов, лицензий, реквизитов для отключения от сервера KSC).

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

Достижение Цели 3

Цель: обновление программного обеспечения тонкого клиента выполняется, только если подтверждена аутентичность и целостность обновления.

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

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

Верхнеуровневая (концептуальная) архитектура KTC

Следует напомнить, что все взаимодействия между системными процессами продукта под KasperskyOS определяются политикой архитектуры продукта, все остальные взаимодействия запрещены и в силу изоляции невозможны. Изоляцию процессов и контролируемые взаимодействия между ними по разрешенным IPC-каналам обеспечивает микроядро KasperskyOS. Во время взаимодействия проверяются политики безопасности процессов, которые контролирует выделенный доверенный сервис KasperskyOS — монитор безопасности, Kaspersky Security Module (KSM). Монитор обеспечивает проверку используемых методов, интерфейсов, параметров, состояний системы, моделей безопасности в контексте каждого участвующего процесса.

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

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

3.3 Роль и место KasperskyOS в кибериммунности

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

KasperskyOS — микроядерная ОС, реализующая принципы глубокой изоляции процессов и содержащая среди доверенных системных сервисов монитор безопасности (Kaspersky Security Module, KSM), контролирующий взаимодействие изолированных системных процессов на основе политик безопасности. Для каждого отдельного процесса создается политика, описывающая правила взаимодействия с ним, а общая политика безопасности продукта формируется как совокупность этих частных политик, собранных в единую согласованную структуру общей политикой архитектуры. Политики безопасности являются формализованными, для этого используется специальный язык PSL, то есть фактически политики являются кодом, который подвергается тестированию и верификации.

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

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

4. Заключение

Кибериммунная специфика КТС достигнута не за счет разработки какой-то специальной функциональной архитектуры, а путем модификации одной из таких типовых функциональных архитектур в соответствии со стратегиями достижения установленных целей безопасности. Иначе говоря, KTC — это полнофункциональный тонкий клиент со множеством вариантов его непосредственного подключения к удаленным рабочим столам по протоколу RDP, при помощи брокеров подключений СКАЛА-Р, подключения к Citrix-инфраструктуре. В том числе, KTC поддерживает безопасное использование аудиоконференций.

Для обеспечения высокого уровня безопасности и мониторинга состояния пула развернутых в организации КТС используется Kaspersky Security Center (KSC), который управляет их конфигурациями и обновлениями. KSC имеет модуль расширения Kaspersky Security Management Suite для организации централизованного администрирования тонких клиентов через единую консоль управления KSC.

1. Введение

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

Kaspersky Thin Client (KTC) — тонкий клиент «Лаборатории Касперского» — создан в соответствии с кибериммунной методологией, и цель этой статьи — ответить на вопрос, как именно реализуется кибериммунитет KTC, за счет чего обеспечивается его защита как от известных, так и от неизвестных угроз.

2. Что это такое и зачем нужен кибериммунитет

Чтобы ответить на вопрос «Как достигается кибериммунность Kaspersky Thin Client?» и оценить преимущества, которыми она обладает, необходимо понимание того, что такое кибериммунитет и зачем он нужен. В этом разделе мы лишь тезисно коснемся этих вопросов, а более подробно они освещаются в многосерийной статье про кибериммунный подход к проектированию.

Современный кибермир характеризуется взаимным проникновением (конвергенцией) всех видов операционных (OT) и информационных (IT) технологий. «Умными» стали не только автомобили, самолеты, системы транспорта, промышленности и управления, но и дома людей. Для конвергентных решений характерны сложность, гетерогенность компонентов, высокая связность, глобальная доступность, высокая скорость и большие объемы передачи данных, а также большой объем программного кода, в том числе заимствованного. 

В таких условиях становится недостаточным использование только наложенных мер для защиты изначально небезопасных киберсистем. Альтернативный подход — создание конструктивно безопасных (Secure by Design) систем — еще не стал повсеместным по двум основным причинам. Во-первых, разработка конструктивно безопасной, в отличие от «просто работающей» системы, требует компетенций в области кибербезопасности, а подходящие специалисты дороги и немногочисленны. Во-вторых, подход Secure by Design пока еще слабо поддержан методически.

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

3. Кибериммунность тонких клиентов

В этом разделе мы описываем верхнеуровневую архитектуру и базовые функции KTC, как достигается его кибериммунитет, какой вклад в это вносит операционная система KasperskyOS.

3.1 Архитектура и функции KTC

На следующем рисунке приведена схема взаимодействия Kaspersky Thin Client с платформами виртуализации:

Схема взаимодействия Kaspersky Thin Client с платформами виртуализации

Типовая схема работы Kaspersky Thin Client (см. рис ниже) такова:

  • Kaspersky Thin Client получает параметры сети от DHCP-сервера, либо администратор настраивает их вручную;
  • администратор подключает и настраивает взаимодействие между Kaspersky Thin Client и Kaspersky Security Center;
  • Kaspersky Thin Client получает параметры подключения к удаленному рабочему столу или приложению, обновлениям, доверенным сертификатам, а также дату и время с политикой от Kaspersky Security Center;
  • пользователь подключается к удаленному рабочему столу по протоколу RDP;
  • пользователь подключается к удаленному рабочему столу через платформу виртуализации Базис.WorkPlace или Citrix Workspace (Web access);
  • пользователь в интерфейсе Kaspersky Thin Client отправляет журналы событий и аудита на сторонний сервер журналирования;
  • Kaspersky Thin Client получает обновление программного обеспечения от сервера обновлений «Лаборатории Касперского» с помощью Kaspersky Security Center.
Типовая схема работы Kaspersky Thin Client

3.2 Обеспечение свойств кибериммунности KTC

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

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

На основе этого описания ценностей с точки зрения потребителя, в соответствии с положениями кибериммунной методологии, техническая команда выработала следующие цели безопасности, фактически являющиеся формализованным «контрактом на безопасность» KTC:

  1. В рабочем режиме устройства обеспечена конфиденциальность и целостность данных, передаваемых между устройством и удалённым рабочим столом; между устройством и брокером соединений с удаленными рабочими столами; между устройством и KSC-сервером; между устройством и сервером логирования.
  2. Обеспечена целостность хранимых на устройстве данных, полученных от пользователя, непосредственно работающего с устройством (сертификатов, реквизитов для подключения) и от KSC-сервера (конфигураций, сертификатов, лицензий, реквизитов для отключения от сервера KSC).
  3. Обновление программного обеспечения тонкого клиента выполняется только если подтверждена аутентичность и целостность обновления.

Были определены также ограничения на предпринимаемые меры защиты (априори принимаемые предположения безопасности), которые также являются частью «контракта на безопасность»: 

  1. В цели безопасности не входит защита от атак с использованием физического доступа к устройству; предотвращение исполнения на устройстве ПО и операций, не относящихся к реализации функций продукта; гарантия доступности функций, выполняемых устройством.
  2. Не рассматриваются угрозы, связанные с уязвимостями аппаратной платформы.
  3. Первоначальная настройка KTC производится доверенным администратором в специальном режиме работы устройства, в условиях отсутствия угрозы подмены адреса KSC-сервера.

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

Обобщенная верхнеуровневая схема организации тонкого клиента

Сопоставив эту схему с целями безопасности КТС, мы видим компоненты, которые напрямую влияют на них:

  • локальное хранилище данных;
  • стандартные библиотеки, имплементирующие протокол RDP и потоковое аудио.

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

В соответствии с традиционным подходом можно было бы взять все известные уязвимости библиотеки RDP (на сегодняшний день их несколько десятков) и выработать ответные меры, предотвращающие угрозы. Однако кибериммунный подход нацелен не столько на защиту активов системы, уже попавших в опасное состояние, сколько на исключение возможности попадания активов в такие состояния. Это существенно, поскольку, с одной стороны, стандартная библиотека постоянно обновляется и в будущем в ней появятся новые уязвимости, а с другой — нет никаких гарантий, что даже в какой-то «замороженной» ее версии выявлены все уязвимости. Это очень большой объем нетривиального кода, и глубокая его верификация коммерчески нецелесообразна. В соответствии с кибериммунным подходом, потенциально опасный компонент должен быть изолирован от защищаемых ценностей. Именно так мы и сделали, «заслонив» стандартную библиотеку RDP собственным стандартным доверенным компонентом с достаточно простой функциональностью — TLS-терминатором, и ограничив политиками безопасности все взаимодействия между компонентами. Все сказанное про библиотеку реализации RDP справедливо и для библиотеки потокового аудио. Впрочем, как и для любой другой сторонней библиотеки, реализующей какой-либо типовой функционал.

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

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

Достижение Цели 1

Цель: в рабочем режиме устройства обеспечена конфиденциальность и целостность данных, передаваемых между устройством и удалённым рабочим столом; между устройством и брокером соединений с удаленными рабочими столами; между устройством и KSC-сервером; между устройством и сервером логирования.

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

Достижение Цели 2

Цель: обеспечение целостности хранимых на устройстве данных, полученных от пользователя, непосредственно работающего с устройством (сертификатов, реквизитов для подключения) и от KSC-сервера (конфигураций, сертификатов, лицензий, реквизитов для отключения от сервера KSC).

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

Достижение Цели 3

Цель: обновление программного обеспечения тонкого клиента выполняется, только если подтверждена аутентичность и целостность обновления.

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

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

Верхнеуровневая (концептуальная) архитектура KTC

Следует напомнить, что все взаимодействия между системными процессами продукта под KasperskyOS определяются политикой архитектуры продукта, все остальные взаимодействия запрещены и в силу изоляции невозможны. Изоляцию процессов и контролируемые взаимодействия между ними по разрешенным IPC-каналам обеспечивает микроядро KasperskyOS. Во время взаимодействия проверяются политики безопасности процессов, которые контролирует выделенный доверенный сервис KasperskyOS — монитор безопасности, Kaspersky Security Module (KSM). Монитор обеспечивает проверку используемых методов, интерфейсов, параметров, состояний системы, моделей безопасности в контексте каждого участвующего процесса.

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

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

3.3 Роль и место KasperskyOS в кибериммунности

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

KasperskyOS — микроядерная ОС, реализующая принципы глубокой изоляции процессов и содержащая среди доверенных системных сервисов монитор безопасности (Kaspersky Security Module, KSM), контролирующий взаимодействие изолированных системных процессов на основе политик безопасности. Для каждого отдельного процесса создается политика, описывающая правила взаимодействия с ним, а общая политика безопасности продукта формируется как совокупность этих частных политик, собранных в единую согласованную структуру общей политикой архитектуры. Политики безопасности являются формализованными, для этого используется специальный язык PSL, то есть фактически политики являются кодом, который подвергается тестированию и верификации.

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

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

4. Заключение

Кибериммунная специфика КТС достигнута не за счет разработки какой-то специальной функциональной архитектуры, а путем модификации одной из таких типовых функциональных архитектур в соответствии со стратегиями достижения установленных целей безопасности. Иначе говоря, KTC — это полнофункциональный тонкий клиент со множеством вариантов его непосредственного подключения к удаленным рабочим столам по протоколу RDP, при помощи брокеров подключений СКАЛА-Р, подключения к Citrix-инфраструктуре. В том числе, KTC поддерживает безопасное использование аудиоконференций.

Для обеспечения высокого уровня безопасности и мониторинга состояния пула развернутых в организации КТС используется Kaspersky Security Center (KSC), который управляет их конфигурациями и обновлениями. KSC имеет модуль расширения Kaspersky Security Management Suite для организации централизованного администрирования тонких клиентов через единую консоль управления KSC.

Консультация по решению

Остались вопросы или требуется дополнительная информация по решению? Оставьте заявку на консультацию, и мы с вами свяжемся!

Задать вопрос

Отвечаем на самые популярные вопросы о KasperskyOS и решениях на ее основе

Перейти в FAQ