Table of Contents

Понимание многопользовательской поддержки во встроенных операционных системах

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

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

Основные понятия и различия

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

Встроенные многопользовательские системы обычно реализуют дискреционный контроль доступа (FLT:0) или обязательный контроль доступа (MAC) . DAC, распространенный в встраиваемых системах на базе Linux, позволяет пользователям контролировать доступ к своим собственным объектам. MAC, используемый в средах с высокой безопасностью (например, MILS или SELinux), обеспечивает соблюдение политик в масштабах всей системы. Выбор зависит от требований безопасности и сложности пользовательской базы. Например, медицинский инфузионный насос с несколькими медсестрами может использовать MAC, чтобы гарантировать, что ни один оператор не может переопределить пределы дозы.

Основные проблемы внедрения многопользовательских

Ограничения ресурсов

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

Детерминизм в реальном времени

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

Безопасность Attack Surface

Добавление нескольких пользователей расширяет поверхность атаки системы. Каждый пользовательский интерфейс (терминал, веб-сервер, соединение BLE) является потенциальной точкой входа для бокового перемещения или эскалации привилегий. Встроенная система должна защищать от общих уязвимостей, таких как переполнение буфера в подсказках входа в систему, повторение учетных данных и захват сеанса. Меры укрепления включают использование минимальных библиотек C (например, ]uClibc или musl), канарейки стека, ASLR (если позволяет ROM) и безопасную загрузку для проверки компонентов управления пользователем. Кроме того, все взаимодействия пользователей должны быть зарегистрированы с временными метками в строке аудита записи, даже если хранение ограничено.

Управление сеансами и надежность

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

Стратегии проектирования для многопользовательской встроенной ОС

Легкая аутентификация и управление идентификацией

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

  • Аутентификация на основе токенов: Пользователи представляют аппаратные токены (например, карты NFC, TOTP со смартфона), которые проверяются на соответствие хранимому секрету. Значение токена является эфемерным и не требует полного хеширования пароля на устройстве. Подходит для сред, таких как доступ к промышленным панелям, где пользователи несут значки.
  • Биометрическая аутентификация: Отпечаток пальца или распознавание радужной оболочки глаза, встроенный в устройство. Биометрический шаблон хранится в защищенной анклавной памяти, и сопоставление выполняется в выделенном процессоре, чтобы избежать загрузки основного процессора. Этот подход набирает обороты в медицинских устройствах с высокой степенью безопасности.
  • Предшествующий ключ (PSK) или основанный на сертификате: Для безголовых систем (например, маршрутизаторов, шлюзов IoT) каждый пользователь имеет уникальный сертификат или ключ, который аутентифицирует вызовы API. Встроенная библиотека TLS (например wolfSSL) проверяет сертификат с минимальным использованием оперативной памяти.
  • Без пароля вход через физическое присутствие: Некоторые встроенные устройства обходят традиционную аутентификацию, требуя физического нажатия кнопки или настройки переключателя, чтобы временно повысить привилегию. Это снижает сложность кода, но должно сочетаться с мерами безопасности оборудования для предотвращения злоупотреблений.

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

Профили пользователей и модели разрешений

Каждый пользователь должен иметь профиль, определяющий его права доступа к файлам, устройствам и системным вызовам. В минималистском встроенном ядре это может быть реализовано как простой список возможностей: битмаск для каждого ресурса. Например, пользователь А может считывать данные датчика, но не записывать в регистры привода, в то время как пользователь В может делать и то, и другое. Более продвинутые системы принимают модель пользователя/группы Unix, хотя и с уплощёнными группами для уменьшения поиска. Функция проверки разрешения должна быть единым коротким кодовым путем, на который ссылаются перед любой чувствительной к безопасности операцией. Необходимо соблюдать осторожность, чтобы избежать расхождений между режимом ядра и режимом пользователя.

Контроль доступа на основе ролей (RBAC) особенно эффективен во встроенных медицинских устройствах. Каждому пользователю назначается роль (медсестра, врач, администратор) с заранее определенным набором привилегий. Роли хранятся в разделе только для чтения, который подписан для предотвращения подделки. Когда пользователь входит в систему, система загружает контекст роли и обеспечивает его выполнение для всех последующих действий. Журналы аудита записывают, какая роль выполняет какую операцию, выполняя нормативные требования, такие как FDA 21 CFR Part 11.

Распределение ресурсов и справедливость

Многопользовательские системы рискуют истощением ресурсов, если один пользователь монополизирует ЦП, память или пропускную способность ввода-вывода. Встроенные планировщики должны включать бюджеты ЦП каждого пользователя. Например, каждому пользователю может быть назначен минимальный гарантированный срез ЦП с использованием планировщика на основе резервирования (например, спорадический сервер POSIX). Распределение памяти может быть ограничено через предварительно определенные пулы - каждый пул, связанный с идентификатором пользователя. Формирование сетевого трафика может применяться с использованием фильтров токенов. Для хранения ограничения квот на основе блоков стирания флэш-памяти гарантируют, что один пользователь не может заполнить всю файловую систему и повлиять на других.

Использование легкого контейнера виртуализации (например, lxc или микровизор) для каждого пользователя является альтернативой, но он поставляется с более высокими накладными расходами. Во многих встроенных системах более эффективно иметь одно ядро с отслеживанием ресурсов на пользователя. Ядро может поддерживать небольшую структуру данных (например, FLT:0) для каждого активного пользователя, обновляемую планировщиком и менеджером памяти. Если пользователь превышает свое распределение, ядро может задушить свои потоки или отказать в дальнейших отображениях памяти, пока они не высвободят ресурсы.

Техника изоляции

Процесс изоляции

Современные встроенные операционные системы (такие как Zephyr RTOS) обеспечивают потоки пользовательского пространства поддержкой MPU (Memory Protection Unit) или MMU. Процессы каждого пользователя выполняются в отдельных аппаратно-защищенных доменах, предотвращая несанкционированные чтения/записи. Для систем без MMU изоляция опирается на проверки программного обеспечения на уровне API RTOS — задачи каждого пользователя ограничены несвязанными областями памяти, и любое пересечение запускает проверку привилегий. Этот подход хорошо работает для известных статических наборов задач, но динамическое создание пользователя ограничено.

Виртуализация

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

TrustZone или безопасные анклавы

Для устройств с TrustZone (ARM) чувствительные операции одного пользователя (например, криптографический доступ к ключам) могут выполняться в безопасном мире, в то время как обычные пользовательские задачи выполняются в нормальном мире. Это обеспечивает аппаратную изоляцию для функций аутентификации и авторизации. Безопасный мир содержит основную базу данных пользователей и обеспечивает выполнение решений по контролю доступа, в то время как обычный мир выполняет прикладные задачи. Связь между мирами ограничена четко определенными вызовами безопасного монитора (SMC). Этот шаблон распространен в платежных терминалах и безопасных медицинских устройствах.

Тематические исследования: многопользовательские встроенные системы на практике

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

Рассмотрим программируемый логический контроллер (PLC), используемый на заводском этаже. Множественным операторам может потребоваться контролировать производственную линию, в то время как супервизор может изменять логику управления, а администратор может обновлять прошивку. Пользовательская RTOS с поддержкой нескольких пользователей была реализована с использованием FreeRTOS + легкой файловой системы с ACLs. Операторы имеют доступ только для чтения к картам ввода-вывода, супервизоры имеют доступ к логическим блокам, а администраторы могут изменять ядро и загрузчик. Каждый пользователь аутентифицируется с помощью карты близости. Бюджеты процессора гарантируют, что задачи супервизора не лишают оператора интерфейсных задач. Система регистрирует каждое событие проверки разрешения в круговой буфер аудита, который периодически загружается на сервер SCADA.

Медицинский инфузионный насос с многопользовательскими профилями

Многоцелевой инфузионный насос позволяет медсестрам устанавливать скорости инфузии, фармацевтам переопределять библиотеки лекарств, а биомедицинским инженерам калибровать датчики. Операционная система (Nucleus RTOS) была расширена менеджером профиля пользователя, который хранит до 10 пользователей в зашифрованной флэш-памяти. Каждый профиль имеет уникальный PIN-код и роль. Ядро обеспечивает, чтобы только пользователь с «фармацевтической» ролью мог модифицировать файл библиотеки лекарств. Насос также включает функцию тайм-аута, которая блокирует экран после 30 секунд бездействия, требуя повторной аутентификации. Безопасная загрузка проверяет целостность базы данных профиля пользователя на каждом стартапе.

Потребительская электроника: Smart Home Hub

Умный домашний хаб может использоваться несколькими членами семьи. Каждый член имеет разный уровень доступа: родители могут добавлять новые устройства и изменять настройки безопасности; дети могут только управлять светом и термостатами; гости могут использовать временный PIN-код для разблокировки входной двери. Концентратор работает под управлением Linux с минимальной файловой системой и использует сборку Yocto Project. Поддержка нескольких пользователей реализована с помощью пользовательского демона, который управляет токенами и модулем ядра, который подключается к доступу к файлам устройства. Пользовательские сессии облегчены и используют эфемерные учетные данные. Ограничения ресурсов не позволяют одному пользователю насыщать сетевой стек, гарантируя, что плохое поведение устройства IoT от одного пользователя не беспокоит других.

Соображения в отношении безопасности и соблюдения

Аудит и подотчетность

Каждое действие пользователя, которое влияет на безопасность или рабочее состояние, должно быть зарегистрировано. Журнал аудита должен включать идентификатор пользователя, временную метку, тип действия и результат (успех / сбой). В регулируемых отраслях (медицинская, промышленная безопасность, автомобильная) журналы должны быть защищенными от несанкционированного доступа и храниться в течение определенного периода. Используйте отдельный раздел хранения только с добавлением (например, небольшая вспышка SPI NOR), который защищен от записи аппаратным обеспечением. Если ограничение хранения приводит к ротации журнала, убедитесь, что события с высокой степенью тяжести никогда не перезаписываются, пока не будет признано администратором.

Безопасная загрузка и целостность данных пользователей

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

Сетевая экспозиция

Многопользовательские встроенные системы, которые подключены к сети (обычные в IIoT), должны защищать от удаленных атак. Используйте TLS 1.3 или выше для всех коммуникаций, связанных с аутентификацией пользователя и передачей данных. Убедитесь, что службы прослушивания отменяют привилегии после связывания с портами (например, HTTP-сервер работает как некорневой пользователь). Попытки входа в систему с ограничением скорости для предотвращения атак с применением грубой силы. Подумайте о внедрении межсетевого экрана на уровне прошивки, который ограничивает, какие IP-адреса источника могут достигать служб, ориентированных на пользователя.

Будущие тенденции в многопользовательской встроенной ОС

По мере того, как встроенное оборудование становится более способным (многоядерное, MMU, расширения виртуализации), поддержка нескольких пользователей будет переходить к более традиционным парадигмам ОС, все еще удовлетворяя требованиям реального времени. Рост RTOS с открытым исходным кодом, таких как Zephyr и NuttX, стандартизирует пользовательские пространства и многопользовательские функции в широком диапазоне чипов. Платформы RISC-V с PMP (защита физической памяти) позволяют мелкозернистую изоляцию пользователей на крошечных ядрах. Другая тенденция - интеграция поддержки нескольких пользователей с архитектурами с нулевым доверием, где каждый пользовательский запрос явно авторизован на аппаратном уровне, даже в пределах того же физического устройства. Модели машинного обучения, которые обнаруживают аномальное поведение пользователя, могут быть развернуты в безопасном мире, чтобы опознать потенциальные вторжения.

Наконец, растущий нормативный ландшафт для медицинских устройств (FDA), автомобильной (ISO 26262) и промышленной безопасности (IEC 61508) подтолкнет поставщиков встроенных ОС к формальной проверке их многопользовательских реализаций. Это может привести к принятию микроядер (seL4), которые обеспечивают доказуемо изолированные пользовательские пространства и строгий контроль доступа прямо из коробки.

Заключение

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