Паттерны безопасности при разработке под KasperskyOS

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

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

Система паттернов безопасности – это набор паттернов безопасности вместе с инструкциями по их реализации, сочетанию и практическому использованию в проектировании безопасных программных систем.

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

Этот раздел содержит описание набора паттернов безопасности, примеры реализации которых содержатся в составе KasperskyOS Community Edition.

Паттерн Distrustful Decomposition

Описание

При использовании монолитного приложения появляется необходимость дать все необходимые для его работы привилегии одному процессу. Эту проблему решает паттерн Distrustful Decomposition.

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

Использование паттерна Distrustful Decomposition уменьшает:

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

Альтернативные названия

Privilege Reduction.

Контекст

Различные функции приложения требуют разного уровня привилегий.

Проблема

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

Решение

Паттерн Distrustful Decomposition разделяет функциональность по отдельным процессам и изолирует возможные уязвимости в небольшом подмножестве системы. Злоумышленник в случае успешной атаки будет иметь в своем распоряжении функциональность и данные только одного скомпрометированного компонента, но не всего приложения.

Структура

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

Работа

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

Рекомендации по реализации

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

Особенности реализации в KasperskyOS

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

Специфика применения этого паттерна при разработке под KasperskyOS состоит в том, что контроль над процессами и IPC возложен на микроядро, атака на которое сложна. Для контроля IPC используется модуль безопасности Kaspersky Security Module.

За счет использования механизмов KasperskyOS достигается высокий уровень надежности программной системы при том же или меньшем объеме усилий разработчика в сравнении с использованием этого же паттерна в программах под универсальные ОС.

Кроме этого, KasperskyOS предоставляет возможность гибкой настройки политик безопасности. При этом процесс задания и изменения политик безопасности потенциально независим от процесса разработки самих приложений.

Связанные паттерны

Использование паттерна Distrustful Decomposition предполагает использование паттернов Defer to Kernel и Policy Decision Point.

Примеры реализации

Примеры реализации паттерна Distrustful Decomposition:

• Secure Logger
• Separate Storage

Источники

Паттерн Distrustful Decomposition подробно рассмотрен в следующих работах:

• Chad Dougherty, Kirk Sayre, Robert C. Seacord, David Svoboda, Kazuya Togashi (JPCERT/CC), "Secure Design Patterns" (March-October 2009). Software Engineering Institute. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15110.pdf
• Dangler, Jeremiah Y., "Categorization of Security Design Patterns" (2013). Electronic Theses and Dissertations. Paper 1119. https://dc.etsu.edu/etd/1119

Пример Secure Logger

Пример Secure Logger демонстрирует использование паттерна Distrustful Decomposition для решения задачи разделения функциональности чтения и записи в журнал событий.

Архитектура примера

Цель безопасности в примере Secure Logger заключается в том, чтобы предотвратить возможность искажения или удаления информации в журнале событий. В примере для достижения этой цели безопасности используются возможности, предоставляемые KasperskyOS.

При рассмотрении системы журналирования можно выделить следующие функциональные шаги:

• генерация информации для записи в журнал;
• сохранение информации в журнал;
• чтение записей из журнала;
• предоставление записей в удобном для потребителя виде.

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

Для этого пример Secure Logger содержит четыре программы: Application, Logger, Reader и LogViewer.

• Программа Application инициирует создание записей в журнале событий, поддерживаемом программой Logger.
• Программа Logger создает записи в журнале и записывает их на диск.
• Программа Reader читает записи с диска для передачи программе LogViewer.
• Программа LogViewer передает записи пользователю.

IPC-интерфейс, который предоставляет программа Logger, предназначен только для записи в хранилище. IPC-интерфейс программы Reader предназначен только для чтения из хранилища. Архитектура примера выглядит следующим образом:

• Программа Application использует интерфейс программы Logger для сохранения записей.
• Программа LogViewer использует интерфейс программы Reader для чтения записей и предоставления их пользователю.

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

Политика безопасности в примере Secure Logger имеет следующие особенности:

• Программа Application имеет возможность обращаться к программе Logger для создания новой записи в журнале событий.
• Программа LogViewer имеет возможность обращаться к программе Reader для чтения записей из журнала событий.
• Программа Application не имеет возможности обращаться к программе Reader для чтения записей из журнала событий.
• Программа LogViewer не имеет возможности обращаться к программе Logger для создания новой записи в журнале событий.

Файлы примера

Код примера и скрипты для сборки находятся по следующему пути:

Сборка и запуск примера

См. "Сборка и запуск примеров".

Пример Separate Storage

Пример Separate Storage демонстрирует использование паттерна Distrustful Decomposition для решения задачи раздельного хранения данных для доверенных и недоверенных приложений.

Архитектура примера

Пример Separate Storage содержит две пользовательские программы: UserManager и CertificateManager.

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

• Программа UserManager работает с данными из файла userlist.txt;
• Программа CertificateManager работает с данными из файла certificate.cer.

Каждая из этих программ использует собственный экземпляр программы VFS для доступа к отдельной файловой системе. При этом каждая программа VFS включает в себя драйвер блочного устройства, связанный с отдельным логическим разделом диска. Программа UserManager не имеет доступа к файловой системе программы CertificateManager и наоборот.

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

Политика безопасности в примере Separate Storage имеет следующие особенности:

• Программа UserManager имеет доступ к файловой системе только через программу VfsUser.
• Программа CertificateManager имеет доступ к файловой системе через только через программу VfsCertificate.

Файлы примера

Код примера и скрипты для сборки находятся по следующему пути:

Сборка и запуск примера

Чтобы запустить пример на QEMU, перейдите в директорию с примером, соберите пример и выполните следующие команды:

Также см. "Сборка и запуск примеров".

Подготовка SD-карты для запуска на Raspberry Pi 4 B

Для запуска примера Separate Storage на Raspberry Pi 4 B необходимы следующие дополнительные действия:

• SD-карта, помимо загрузочного раздела с образом решения, должна также содержать 2 дополнительных раздела с файловой системой ext2 или ext3.
• первый дополнительный раздел должен содержать файл userlist.txt из директории ./resources/files/
• второй дополнительный раздел должен содержать файл certificate.cer из директории ./resources/files/

Паттерн Defer to Kernel

Описание

Паттерн Defer to Kernel предполагает использование преимущества контроля разрешений на уровне ядра ОС.

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

Альтернативные названия

Policy Enforcement Point (PEP), Protected System, Enclave.

Контекст

Паттерн Defer to Kernel применим, если система имеет следующие характеристики:

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

Проблема

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

Решение

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

Структура

Работа

• Функциональность и управление данными с разными привилегиями разделены между процессами.
• Изоляцию процессов обеспечивает ядро ОС.
• Процесс-1 хочет запросить привилегированную функциональность или данные у Процесса-2, используя IPC.
• Ядро контролирует IPC и разрешает или не разрешает коммуникацию исходя из политик безопасности и доступной ему информации о контексте работы и состоянии Процесса-1.

Рекомендации по реализации

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

• Изоляция

  Необходимо обеспечить полную и гарантированную изоляцию процессов.

• Невозможность обойти ядро

  Абсолютно все IPC-взаимодействия должны контролироваться ядром.

• Самозащита ядра

  Необходимо обеспечить доверенность ядра, его собственную защиту от компрометации.

• Доказуемость

  Требуется определенный уровень гарантий безопасности и надежности в отношении ядра.

• Возможность внешнего вычисления разрешений о доступе

  Необходимо, чтобы разрешения о доступе вычислялись на уровне ОС, а не были реализованы в прикладном коде.

  Для этого, в частности, необходимо предоставить инструменты для описания политик доступа, чтобы политики безопасности были отделены от бизнес-логики.

Особенности реализации в KasperskyOS

Ядро KasperskyOS гарантирует изоляцию процессов и представляет собой Policy Enforcement Point (PEP).

Связанные паттерны

Паттерн Defer to Kernel является частным случаем паттернов Distrustful Decomposition и Policy Decision Point. Паттерн Policy Decision Point определяет абстрактный процесс, перехватывающий все запросы к ресурсам и проверяющий их на соответствие заданной политике безопасности. Специфика паттерна Defer to Kernel в том, что эту проверку выполняет ядро ОС – это более надежное и портируемое решение, сокращающее время разработки и тестирования.

Следствия

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

Кроме этого, появляется возможность доказать безопасность решения в целом, доказав правильность работы ядра. Сложность доказуемости правильной работы кода нелинейно растет с увеличением его размера. Паттерн Defer to Kernel минимизирует объем доверенного кода – при условии, что ядро ОС невелико.

Примеры реализации

Пример реализации паттерна Defer to Kernel: Пример Defer to Kernel.

Источники

Паттерн Defer to Kernel подробно рассмотрен в следующих работах:

• Chad Dougherty, Kirk Sayre, Robert C. Seacord, David Svoboda, Kazuya Togashi (JPCERT/CC), "Secure Design Patterns" (March-October 2009). Software Engineering Institute. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15110.pdf
• Dangler, Jeremiah Y., "Categorization of Security Design Patterns" (2013). Electronic Theses and Dissertations. Paper 1119. https://dc.etsu.edu/etd/1119
• Schumacher, Markus, Fernandez-Buglioni, Eduardo, Hybertson, Duane, Buschmann, Frank, and Sommerlad, Peter. "Security Patterns: Integrating Security and Systems Engineering" (2006).

Пример Defer to Kernel

Пример Defer to Kernel демонстрирует использование паттернов Defer to Kernel и Policy Decision Point.

Пример Defer to Kernel содержит три пользовательские программы: PictureManager, ValidPictureClient и NonValidPictureClient.

В этом примере программы ValidPictureClient и NonValidPictureClient обращаются к программе PictureManager для получения информации.

Только программе ValidPictureClient разрешено взаимодействие с программой PictureManager.

Ядро KasperskyOS гарантирует изоляцию запущенных программ (процессов).

Контроль взаимодействия программ в KasperskyOS вынесен в модуль безопасности Kaspersky Security Module. Эта подсистема анализирует каждый отправляемый запрос и ответ и на основе заданной политики безопасности выносит решение: разрешить или запретить его доставку.

Политика безопасности в примере Defer to Kernel имеет следующие особенности:

• Программе ValidPictureClient явно разрешено взаимодействие с программой PictureManager.
• Программе NonValidPictureClient взаимодействие с программой PictureManager не разрешено явно. Таким образом, это взаимодействие запрещено (принцип Default Deny).

Динамическое создание IPC-каналов

Пример также демонстрирует возможность динамического создания IPC-каналов между процессами. Динамическое создание IPC-каналов осуществляется с помощью сервера имен – специального сервиса ядра, представленного программой NameServer. Возможность динамического создания IPC-каналов позволяет изменять топологию взаимодействия программ "на лету".

Любая программа, которой разрешено взаимодействие с NameServer по IPC, может зарегистрировать в сервере имен свои интерфейсы. Другая программа может запросить у сервера имен зарегистрированные интерфейсы, после чего осуществить подключение к нужному интерфейсу.

При этом все взаимодействия по IPC (даже созданные динамически) контролируются с помощью модуля безопасности.

Файлы примера

Код примера и скрипты для сборки находятся по следующему пути:

Сборка и запуск примера

См. "Сборка и запуск примеров".

Паттерн Policy Decision Point

Описание

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

Альтернативные названия

Check Point, Access Decision Function.

Контекст

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

Проблема

Если проверки соблюдения политики безопасности разнесены по разным компонентам системы, возникают следующие проблемы:

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

Решение

Все проверки соблюдения политики безопасности проводятся в отдельном компоненте Policy Decision Point (PDP). Этот компонент отвечает за обеспечение правильного порядка проверок и за их полноту. Происходит отделение проверки политики от кода, реализующего бизнес-логику.

Структура

Работа

• Policy Enforcement Point (PEP) получает запрос на доступ к функциональности или данным.

  PEP может представлять собой, например, ядро ОС. Подробнее см. Паттерн Defer to Kernel.

• PEP собирает атрибуты запроса, необходимые для принятия решений по управлению доступом.
• PEP запрашивает решение по управлению доступом у Policy Decision Point (PDP).
• PDP вычисляет решение о предоставлении доступа на основе политики безопасности и информации, полученной в запросе от PEP.
• PEP отклоняет или разрешает взаимодействие на основе решения PDP.

Рекомендации по реализации

При реализации необходимо учитывать проблему "Время проверки vs. Время использования". Например, если политика безопасности зависит от быстро меняющегося статуса какого-либо объекта системы, вычисленное решение так же быстро теряет актуальность. В системе, использующей паттерн Policy Decision Point, необходимо позаботиться о минимизации интервала между принятием решения о доступе и моментом выполнения запроса на основе этого решения.

Особенности реализации в KasperskyOS

Ядро KasperskyOS гарантирует изоляцию процессов и представляет собой Policy Enforcement Point (PEP).

Контроль взаимодействия процессов в KasperskyOS вынесен в модуль безопасности Kaspersky Security Module. Этот модуль анализирует каждый отправляемый запрос и ответ и на основе заданной политики безопасности выносит решение: разрешить или запретить его доставку. Таким образом, Kaspersky Security Module выполняет роль Policy Decision Point (PDP).

Следствия

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

Связанные паттерны

Использование паттерна Policy Decision Point предполагает использование паттернов Distrustful decomposition и Defer to Kernel.

Примеры реализации

Пример реализации паттерна Policy Decision Point: Пример Defer to Kernel.

Источники

Паттерн Policy Decision Point подробно рассмотрен в следующих работах:

• Chad Dougherty, Kirk Sayre, Robert C. Seacord, David Svoboda, Kazuya Togashi (JPCERT/CC), "Secure Design Patterns" (March-October 2009). Software Engineering Institute. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15110.pdf
• Dangler, Jeremiah Y., "Categorization of Security Design Patterns" (2013). Electronic Theses and Dissertations. Paper 1119. https://dc.etsu.edu/etd/1119
• Schumacher, Markus, Fernandez-Buglioni, Eduardo, Hybertson, Duane, Buschmann, Frank, and Sommerlad, Peter. "Security Patterns: Integrating Security and Systems Engineering" (2006).
• Bob Blakley, Craig Heath, and members of The Open Group Security Forum. "Security Design Patterns" (April 2004). The Open Group. https://pubs.opengroup.org/onlinepubs/9299969899/toc.pdf

Паттерн Privilege Separation

Описание

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

Паттерн Privilege Separation является частным случаем паттерна Distrustful Decomposition.

Пример

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

Контекст

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

Проблема

Когда клиент, имеющий неизвестные привилегии, взаимодействует с привилегированным компонентом системы, возникают риски компрометации данных и функциональности, доступных этому компоненту.

Решение

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

Работа

Работа паттерна делится на две фазы:

• Pre-Authentication. Клиент еще не аутентифицирован. Он отправляет запрос к привилегированному мастер-процессу. Мастер-процесс создает дочерний процесс, лишенный привилегий (в том числе, доступа к файловой системе), который выполняет аутентификацию клиента.
• Post-Authentication. Клиент аутентифицирован и авторизован. Привилегированный мастер-процесс создает новый дочерний процесс, обладающий привилегиями, соответствующими правам клиента. Этот процесс отвечает за все дальнейшее взаимодействие с клиентом.

Рекомендации по реализации в KasperskyOS

На этапе Pre-Authentication мастер-процесс может хранить состояние каждого непривилегированного процесса в виде конечного автомата и изменять состояние автомата при аутентификации.

Запросы дочерних процессов к мастер-процессу выполняются с использованием стандартных механизмов IPC. При этом контроль взаимодействий осуществляется с помощью модуля безопасности Kaspersky Security Module.

Следствия

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

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

Примеры реализации

Пример реализации паттерна Privilege Separation: Пример Device Access.

Источники

Паттерн Privilege Separation подробно рассмотрен в следующих работах:

• Chad Dougherty, Kirk Sayre, Robert C. Seacord, David Svoboda, Kazuya Togashi (JPCERT/CC), "Secure Design Patterns" (March-October 2009). Software Engineering Institute. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15110.pdf
• Dangler, Jeremiah Y., "Categorization of Security Design Patterns" (2013). Electronic Theses and Dissertations. Paper 1119. https://dc.etsu.edu/etd/1119

Пример Device Access

Пример Device Access демонстрирует использование паттерна Privilege Separation.

Архитектура примера

Пример содержит три программы: Device, LoginManager и Storage.

В этом примере программа Device обращается к программе Storage для получения информации и к программе LoginManager для авторизации.

Программа Device получает доступ к программе Storage только после успешной авторизации.

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

Политика безопасности в примере Device Access имеет следующие особенности:

• Программа Device имеет возможность обращаться к программе LoginManager для авторизации.
• Вызовами метода GetInfo() программы Storage управляют методы модели безопасности Flow:
  • Конечный автомат, описанный в конфигурации объекта session, имеет два состояния: unauthenticated и authenticated.
  • Исходное состояние – unauthenticated.
  • Разрешены переходы из unauthenticated в authenticated и обратно.
  • Объект session создается при запуске программы Device.
  • При успешном вызове программой Device метода Login() программы LoginManager состояние объекта session изменяется на authenticated.
  • При успешном вызове программой Device метода Logout() программы LoginManager состояние объекта session изменяется на unauthenticated.
  • При вызове программой Device метода GetInfo() программы Storage проверяется текущее состояние объекта session. Вызов разрешается, только если текущее состояние объекта – authenticated.

Файлы примера

Код примера и скрипты для сборки находятся по следующему пути:

Сборка и запуск примера

См. "Сборка и запуск примеров".

Паттерн Information Obscurity

Описание

Цель паттерна Information Obscurity – шифрование конфиденциальных данных в небезопасных средах с целью защиты данных от кражи.

Контекст

Этот паттерн следует использовать, когда данные часто передаются между частями системы и/или между системой и другими (внешними) системами.

Проблема

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

Решение

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

Примеры реализации

Пример реализации паттерна Information Obscurity: Пример Secure Login.

Источники

Паттерн Information Obscurity подробно рассмотрен в следующих работах:

• Dangler, Jeremiah Y., "Categorization of Security Design Patterns" (2013). Electronic Theses and Dissertations. Paper 1119. https://dc.etsu.edu/etd/1119
• Schumacher, Markus, Fernandez-Buglioni, Eduardo, Hybertson, Duane, Buschmann, Frank, and Sommerlad, Peter. "Security Patterns: Integrating Security and Systems Engineering" (2006).

Пример Secure Login (Civetweb, TLS-terminator)

Пример Secure Login демонстрирует использование паттерна Information Obscurity. Пример демонстрирует возможность передачи критической для системы информации через недоверенную среду.

Архитектура примера

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

С точки зрения архитектуры в таких системах можно выделить следующие субъекты:

• Источник данных: браузер пользователя.
• Точка коммуникации с устройством: веб-сервер.
• Подсистема обработки информации от пользователя: подсистема аутентификации.

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

1. Обеспечить взаимодействие источника данных и устройства по протоколу HTTPS. Это позволит избежать "прослушивания" HTTP-трафика и атак типа MITM (man in the middle).
2. Выработать между источником данных и подсистемой обработки информации общий секрет.
3. Использовать этот секрет для шифрования информации на стороне источника данных и расшифровки на стороне подсистемы обработки информации. Это позволит избежать компрометации данных внутри устройства (в точке коммуникации).

Пример Secure Login включает следующие компоненты:

• Веб-сервер Civetweb (недоверенный компонент, программа WebServer).
• Подсистему аутентификацию пользователей (доверенный компонент, программа AuthService).
• TLS-терминатор (доверенный компонент, программа TlsEntity). Этот компонент поддерживает транспортный механизм TLS (transport layer security). TLS-терминатор совместно с веб-сервером поддерживают протокол HTTPS на стороне устройства (веб-сервер взаимодействует с браузером через TLS-терминатор).

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

1. Пользователь открывает в браузере страницу по адресу https://localhost:1106 (при запуске примера на QEMU) или по адресу https://<IP-адрес Raspberry Pi>:1106 (при запуске примера на Raspberry Pi 4 B). HTTP-трафик между браузером и TLS-терминатором будет передаваться в зашифрованном виде, а веб-сервер будет работать с открытым HTTP-трафиком.

   В примере используется самоподписанный сертификат, поэтому большинство современных браузеров сообщит о незащищенности соединения. Нужно согласиться использовать незащищенное соединение, которое тем не менее будет зашифрованным. В некоторых браузерах возможно возникновение сообщения "TLS: Error performing handshake: -30592: errno = Success".

2. Веб-сервер Civetweb, запущенный в программе WebServer, отображает страницу index.html, содержащую приглашение к аутентификации.
3. Пользователь нажимает на кнопку Log in.
4. Программа WebServer обращается к программе AuthService по IPC для получения страницы, содержащей форму ввода имени пользователя и пароля.
5. Программа AuthService выполняет следующие действия:
   • генерирует закрытый ключ, открытые параметры, а также вычисляет открытый ключ по алгоритму Диффи-Хеллмана;
   • создает страницу auth.html с формой ввода имени пользователя и пароля (код страницы содержит открытые параметры и открытый ключ);
   • передает полученную страницу программе WebServer по IPC.
6. Веб-сервер Civetweb, запущенный в программе WebServer, отображает страницу auth.html с формой ввода имени пользователя и пароля.
7. Пользователь заполняет форму и нажимает на кнопку Submit (корректные данные для аутентификации содержатся в файле secure_login/auth_service/src/authservice.cpp).
8. Код страницы auth.html, который исполняется на стороне браузера, осуществляет следующие действия:
   • генерирует закрытый ключ, вычисляет открытый ключ и общий секретный ключ по алгоритму Диффи-Хеллмана;
   • выполняет шифрование пароля операцией XOR с использование общего секретного ключа;
   • передает веб-северу имя пользователя, зашифрованный пароль и открытый ключ.
9. Программа WebServer обращается к программе AuthService по IPC для получения страницы, содержащей результат аутентификации, передавая имя пользователя, зашифрованный пароль и открытый ключ.
10. Программа AuthService выполняет следующие действия:
    • вычисляет общий секретный ключ по алгоритму Диффи-Хеллмана;
    • расшифровывает пароль с использованием общего секретного ключа;
    • возвращает страницу result_err.html или страницу result_ok.html в зависимости от результата аутентификации.
11. Веб-сервер Civetweb, запущенный в программе WebServer, отображает страницу result_err.html или страницу result_ok.html.

Таким образом, конфиденциальные данные передаются через сеть и веб-сервер только в зашифрованном виде. Кроме того, весь HTTP-трафик передается через сеть в зашифрованном виде. Для передачи данных между компонентами используются взаимодействия по IPC, которые контролируются модулем Kaspersky Security Module.

Unit-тестирование с использованием фреймворка GoogleTest

Помимо паттерна Information Obscurity пример Secure Login демонстрирует использование фреймворка GoogleTest для выполнения unit-тестирования программ, разработанных под KasperskyOS (KasperskyOS Community Edition содержит в своем составе этот фреймворк).

Исходный код тестов находится по следующему пути:

/opt/KasperskyOS-Community-Edition-<version>/examples/secure_login/tests

Эти unit-тесты предназначены для верификации некоторых cpp-модулей подсистемы аутентификации и веб-сервера.

Чтобы запустить тестирование, выполните следующие действия:

1. Перейдите в директорию с примером Secure Login.
2. Удалите директорию build с результатами предыдущей сборки, выполнив команду:

   sudo rm -rf build/

3. Откройте файл скрипта cross-build.sh в текстовом редакторе.
4. Добавьте в скрипт флаг сборки -D RUN_TESTS="y" \ (например, после флага сборки -D CMAKE_BUILD_TYPE:STRING=Release \).
5. Сохраните файл скрипта, а затем выполните команду:

   $ sudo ./cross-build.sh

Тесты выполняются в программе TestEntity. Программы AuthService и WebServer не запускаются, поэтому при выполнении тестирования пример нельзя использовать для демонстрации паттерна Information Obscurity.

После завершения тестирования выводятся результаты выполнения тестов.

Файлы примера

Код примера и скрипты для сборки находятся по следующему пути:

Сборка и запуск примера

Чтобы запустить пример на QEMU, перейдите в директорию с примером, соберите пример и выполните следующие команды:

Также см. "Сборка и запуск примеров".