Multi-User-Support in Embedded Betriebssystemen verstehen

Die Unterstützung von mehreren Benutzern ist eine grundlegende Fähigkeit, die es mehreren Benutzern oder Maschinen ermöglicht, gleichzeitig mit einem eingebetteten System zu interagieren, wobei jedes einzelne mit unterschiedlichen Identitäten, Privilegien und Ressourcenlimits ausgestattet ist. Im Gegensatz zu Desktop- oder Server-Betriebssystemen beginnen eingebettete Betriebssysteme (RTOS, Linux-basierte eingebettete oder benutzerdefinierte Kernel) aufgrund von Ressourcenbeschränkungen oft als Einzelbenutzerdesigns. Da eingebettete Systeme jedoch immer stärker miteinander verbunden sind und heterogene Benutzergruppen bedienen (Betreiber, Maintainer, Remote-Administratoren und Endbenutzer), wächst der Bedarf an robusten Mehrbenutzerarchitekturen. Diese Fähigkeit stellt sicher, dass Aktionen überprüfbar sind, Ressourcen geschützt sind und Sicherheitsrichtlinien durchgesetzt werden, ohne dass die Echtzeitleistung oder -stabilität beeinträchtigt wird.

In der Praxis muss die Unterstützung von mehreren Benutzern in eingebetteten Systemen die Benutzerauthentifizierung, das Sitzungsmanagement, die Zugriffskontrolle und die Ressourcenpartitionierung mit minimalem Overhead handhaben. Die Implementierung muss die begrenzten CPU-Zyklen, den Speicher-Fußabdruck und die für eingebettete Hardware typischen Energiebudgets berücksichtigen. Darüber hinaus muss das System mit deterministischer Planung und Echtzeitgarantien koexistieren. Dieser Artikel untersucht die technischen Herausforderungen, Designmuster und praktischen Strategien für die Integration von Mehrbenutzer-Unterstützung in eingebettete Betriebssysteme, mit Schwerpunkt auf industrieller Steuerung, medizinischen Geräten und Unterhaltungselektronik.

Kernkonzepte und Unterscheidungen

Bevor wir uns mit der Implementierung befassen, ist es wichtig zu klären, was Multi-User-Unterstützung in einem eingebetteten Kontext bedeutet. Im Gegensatz zu einem Allzweck-Betriebssystem, in dem sich mehrere Benutzer über SSH oder grafische Konsolen anmelden können, interagieren eingebettete Systeme oft über spezialisierte Schnittstellen (z. B. Touchscreens, Web-Panels, Feldbus). Ein Benutzer kann ein menschlicher Bediener sein, der ein physisches Terminal verwendet, ein API-Client, der Befehle sendet, oder ein automatisierter Prozess mit Anmeldeinformationen. Das System muss diese Identitäten unterscheiden und Regeln für Dateisystemzugriff, Geräte-I / O, Netzwerkressourcen und Konfigurationsänderungen durchsetzen.

Eingebettete Mehrbenutzersysteme implementieren typischerweise diskretionäre Zugangskontrolle (DAC) oder obligatorische Zugangskontrolle (MAC). DAC, das in Linux-basierten eingebetteten Systemen üblich ist, ermöglicht es Benutzern, den Zugriff auf ihre eigenen Objekte zu kontrollieren. MAC, das in Hochsicherheitsumgebungen (z. B. MILS oder SELinux) verwendet wird, erzwingt systemweit Richtlinien. Die Wahl hängt von den Sicherheitsanforderungen und der Komplexität der Benutzerbasis ab. Zum Beispiel kann eine medizinische Infusionspumpe mit mehreren Pflegepersonal MAC verwenden, um sicherzustellen, dass kein Bediener Dosisgrenzen außer Kraft setzen kann.

Wichtige Herausforderungen bei der Embedded Multi-User Implementierung

Ressourcenbeschränkungen

Eingebettete Systeme arbeiten üblicherweise mit nur 256 KB RAM und einigen Megabyte Flash-Speicher. Jede aktive Benutzersitzung verbraucht Speicher für Anmeldeinformationen, Prozesssteuerungsblöcke, Dateideskriptoren und Sitzungszustand. Der Overhead eines vollständigen POSIX-Benutzerverwaltungs-Frameworks (z. B. PAM, NSS) kann unerschwinglich sein. Ingenieure müssen daher auf minimale Implementierungen reduziert werden - oft ein benutzerdefiniertes Authentifizierungsmodul mit statischen Benutzertabellen oder einen winzigen LDAP-Client. Speicher für die Ressourcenabrechnung pro Benutzer muss statisch zugewiesen oder dynamisch durch eine maximale gleichzeitige Benutzeranzahl begrenzt werden.

Echtzeit-Determinismus

Mehrbenutzeroperationen wie Anmelden, Authentifizierung und Berechtigungsprüfungen führen Latenzvariationen ein, die harte Echtzeit-Fristen beeinflussen können. Wenn eine hochpriore Echtzeit-Task gezwungen ist, auf die Antwort eines Benutzerraum-Authentifizierungs-Daemons zu warten, kann das System ein Unterbrechungsfenster verpassen. Zu den Abschwächungen gehören das Ausführen der Authentifizierung in einer separaten Aufgabe mit niedrigerer Priorität und das Zwischenspeichern von Anmeldeinformationen im Kernel für eine schnelle Suche. Einige eingebettete Betriebssysteme implementieren die Mehrbenutzerunterstützung vollständig im Kernel, um einen Kontextwechsel zu vermeiden. Zum Beispiel kann FreeRTOS mit einem zusätzlichen Zugriffssteuerungsmodul Benutzerberechtigungen in einem Unterbrechungshandler erzwingen.

Sicherheitsangriffsfläche

Das Hinzufügen mehrerer Benutzer erweitert die Angriffsfläche des Systems. Jede Benutzeroberfläche (Terminal, Webserver, BLE-Verbindung) ist ein potenzieller Einstiegspunkt für laterale Bewegungen oder Privilegeskalation. Das eingebettete System muss sich gegen häufige Sicherheitslücken wie Pufferüberläufe in Anmeldeaufforderungen, Anmeldeinformationen und Session-Hijacking schützen. Zu den Hardening-Maßnahmen gehören die Verwendung von minimalen C-Bibliotheken (z. B. uClibc oder musl), Stack-Kanarien, ASLR (wenn ROM es erlaubt) und sicheres Booten, um Benutzerverwaltungskomponenten zu überprüfen. Darüber hinaus sollten alle Benutzerinteraktionen mit Zeitstempeln auf einen Write-once-Audit-Trail protokolliert werden, auch wenn der Speicherplatz begrenzt ist.

Session Management und Robustheit

Mehrere Benutzer möchten möglicherweise gleichzeitig auf das System zugreifen. Zum Beispiel kann ein Techniker über die serielle Konsole debuggen, während ein Remote-Operator den Computer über Ethernet steuert. Das System muss die Erstellung, den Timeout und die Bereinigung der Sitzung bewältigen, ohne Ressourcen zu verlieren. Die Sitzungsabbruch bei Stromausfall oder -absturz muss auch die Integrität bewahren - teilweise angewendete Konfigurationsänderungen von einem Benutzer sollten die Daten eines anderen Benutzers nicht verfälschen. Techniken wie Transaktionsdateisysteme (z. B. JFFS2 oder UBIFS) und Aktualisierungen der Atomkonfiguration helfen, Inkonsistenzen zu vermeiden.

Design-Strategien für Multi-User Embedded OS

Leichtgewichtige Authentifizierung und Identitätsmanagement

Die eingebettete Authentifizierung muss die Sicherheit mit der Ressourcennutzung in Einklang bringen.

  • Token-basierte Authentifizierung: Benutzer präsentieren Hardware-Token (z. B. NFC-Karten, TOTP von einem Smartphone), die gegen ein gespeichertes Geheimnis validiert sind. Der Token-Wert ist ephemer und erfordert kein vollständiges Passwort-Hashing auf dem Gerät. Geeignet für Umgebungen wie den Zugriff auf Industriepanels, in denen Benutzer Badges tragen.
  • Biometrische Authentifizierung: Fingerabdruck- oder Iriserkennung ist in das Gerät integriert. Die biometrische Vorlage wird in einem sicheren Enklavenspeicher gespeichert und die Anpassung läuft in einem dedizierten Prozessor, um das Laden der Haupt-CPU zu vermeiden. Dieser Ansatz gewinnt bei hochsicheren medizinischen Geräten an Zugkraft.
  • Pre-shared key (PSK) oder zertifikatsbasiert: Für Headless-Systeme (z. B. Router, IoT-Gateways) verfügt jeder Benutzer über ein eindeutiges Zertifikat oder einen Schlüssel, der API-Aufrufe authentifiziert. Die eingebettete TLS-Bibliothek (wie wolfSSL) überprüft das Zertifikat mit minimaler RAM-Auslastung.
  • Passwortlose Anmeldung über physische Präsenz: Einige eingebettete Geräte umgehen die traditionelle Authentifizierung, indem sie eine physische Tastendrücke oder eine Jumper-Einstellung benötigen, um die Berechtigung vorübergehend zu erhöhen. Dies reduziert die Codekomplexität, sollte aber mit Hardware-Sicherheitsmaßnahmen kombiniert werden, um Missbrauch zu verhindern.

Unabhängig davon, welche Methode gewählt wird, sollte die Authentifizierung von der Hauptanwendung entkoppelt werden. Ein kleiner Authentifizierungs-Daemon (oder Kernel-Modul) übernimmt die Überprüfung der Anmeldeinformationen, während der Rest des Systems bis zur Prüfung der Berechtigungen keine Benutzeridentitäten kennt. Diese Architektur unterstützt rollenbasierte Zugriffskontrolle (RBAC) out of the box.

Benutzerprofile und Berechtigungsmodelle

Jeder Benutzer muss ein Profil haben, das seine Zugriffsrechte auf Dateien, Geräte und Systemaufrufe definiert. In einem minimalistischen eingebetteten Kernel kann dies als einfache Fähigkeitsliste implementiert werden: eine Bitmaske für jede Ressource. Beispielsweise kann Benutzer A Sensordaten lesen, aber nicht in Aktorregister schreiben, während Benutzer B beides kann. Fortgeschrittene Systeme übernehmen das Unix-Benutzer-Gruppenmodell, wenn auch mit abgeflachten Gruppen, um Nachschlagefunktionen zu reduzieren. Die Berechtigungsüberprüfungsfunktion sollte ein einzelner, kurzer Codepfad sein, der vor jeder sicherheitsrelevanten Operation aufgerufen wird. Es muss darauf geachtet werden, dass Abweichungen zwischen Kernel-Modus- und Benutzermodusüberprüfungen vermieden werden.

Rollenbasierte Zugriffskontrolle (RBAC) ist besonders effektiv bei eingebetteten medizinischen Geräten. Jedem Benutzer wird eine Rolle zugewiesen (Krankenschwester, Arzt, Administrator) mit einem vordefinierten Satz von Privilegien. Rollen werden in einer schreibgeschützten Partition gespeichert, die signiert ist, um Manipulationen zu verhindern. Wenn sich ein Benutzer anmeldet, lädt das System den Rollenkontext und setzt ihn für alle nachfolgenden Aktionen durch. Auditprotokolle zeichnen auf, welche Rolle welche Operation ausgeführt hat, wobei regulatorische Anforderungen wie FDA 21 CFR Part 11 erfüllt werden.

Ressourcenzuweisung und Fairness

Mehrbenutzersysteme riskieren Ressourcenmangel, wenn ein Benutzer CPU-, Speicher- oder E/A-Bandbreite monopolisiert. Eingebettete Scheduler müssen CPU-Budgets pro Benutzer enthalten. Beispielsweise kann jedem Benutzer ein garantierter CPU-Mindestanteil zugewiesen werden, der einen Reservierungs-basierten Scheduler (z. B. POSIX-Sporadic-Server) verwendet. Die Speicherzuweisung kann über vordefinierte Pools begrenzt werden, die mit einer Benutzer-ID verknüpft sind. Die Gestaltung des Netzwerkverkehrs kann mit Token-Bucket-Filtern angewendet werden. Für die Speicherung stellen Kontingentgrenzen auf der Grundlage von Flash-Löschblöcken sicher, dass ein Benutzer nicht das gesamte Dateisystem füllen und andere beeinflussen kann.

Die Verwendung eines leichten Virtualisierungscontainers (wie lxc oder ein Mikrovisor) für jeden Benutzer ist eine Alternative, aber es kommt mit höherem Overhead. In vielen eingebetteten Systemen ist es effizienter, einen einzelnen Kernel mit Ressourcen-Tracking pro Benutzer zu haben. Der Kernel kann eine kleine Datenstruktur (z. B. ein für jeden aktiven Benutzer beibehalten, die vom Scheduler und Speichermanager aktualisiert wird. Wenn ein Benutzer seine Zuweisung überschreitet, kann der Kernel seine Threads drosseln oder weitere Speicherzuordnungen verweigern, bis er Ressourcen freigibt.

Isolationstechniken

Prozessisolierung

Moderne eingebettete Betriebssysteme (wie Zephyr RTOS) bieten Benutzerraum-Threads mit MPU (Memory Protection Unit) oder MMU-Unterstützung. Die Prozesse jedes Benutzers laufen in separaten Hardware-erzwungenen Domänen und verhindern unautorisiertes Lesen/Schreiben. Für MMU-lose Systeme beruht die Isolation auf Software-Prüfungen auf der RTOS-API-Schicht - die Aufgaben jedes Benutzers sind auf disjunkte Speicherbereiche beschränkt, und jede Kreuzung löst eine Privileg-Prüfung aus. Dieser Ansatz funktioniert gut für bekannte statische Aufgabensätze, aber die dynamische Benutzererstellung ist begrenzt.

Virtualisierung

Die vollständige oder paravirtualisierte Version kann verschiedene Benutzer als separate Gast-Betriebsstätten isolieren. Dies ist geeignet für eingebettete High-End-Systeme (ARM Cortex-A, RISC-V mit Hypervisor-Erweiterung), bei denen Hardware-Virtualisierungsunterstützung vorhanden ist. Jeder Benutzer sieht eine vollständige virtuelle Plattform und ein kleiner Hypervisor vermittelt den Zugriff auf physische Ressourcen. Der Overhead ist höher, aber die Sicherheit ist extrem stark, da ein Kompromiss in der Umgebung eines Benutzers andere nicht direkt beeinflussen kann. Anwendungsfälle sind industrielle Gateways mit mehreren Mandanten und medizinische Displays.

TrustZone oder Secure Enclaves

Bei Geräten mit TrustZone (ARM) können die sensiblen Operationen eines Benutzers (z. B. kryptographischer Schlüsselzugriff) in der sicheren Welt ausgeführt werden, während normale Benutzeraufgaben in der normalen Welt ausgeführt werden. Dies bietet eine hardwaregestützte Isolation für Authentifizierungs- und Autorisierungsfunktionen. Die sichere Welt enthält die Master-Benutzerdatenbank und erzwingt Zugriffskontrollentscheidungen, während die normale Welt Anwendungsaufgaben ausführt. Die Kommunikation zwischen den Welten ist auf gut definierte sichere Monitoranrufe (SMC) beschränkt. Dieses Muster ist bei Zahlungsterminals und sicheren medizinischen Geräten üblich.

Case Studies: Multi-User Embedded Systems in der Praxis

Industrielles Steuerungssystem mit rollenbasiertem Zugriff

Man denke an einen programmierbaren Logic Controller (PLC), der in einer Fabrikhalle verwendet wird. Mehrere Operatoren müssen möglicherweise die Produktionslinie überwachen, während ein Supervisor die Steuerungslogik ändern kann und ein Administrator Firmware aktualisieren kann. Ein benutzerdefiniertes RTOS mit Multi-User-Unterstützung wurde mit FreeRTOS + einem Lichtdateisystem mit ACLs implementiert. Operatoren haben Lesezugriff auf E/A-Karten, Supervisoren haben Schreibzugriff auf Logikblöcke und Administratoren können den Kernel und den Bootloader ändern. Jeder Benutzer authentifiziert sich mit einer Proximity Card. CPU-Budgets stellen sicher, dass Supervisor-Aufgaben nicht die Operator-Interface-Aufgaben aushungern lassen. Das System protokolliert jedes Berechtigungsüberprüfungsereignis in einem kreisförmigen Auditpuffer, der regelmäßig auf einen SCADA-Server übertragen wird.

Medizinische Infusionspumpe mit Multi-User-Profilen

Eine Infusionspumpe mit mehreren Rollen ermöglicht es Krankenschwestern, Infusionsraten einzustellen, Apotheker, Arzneimittelbibliotheken außer Kraft zu setzen und biomedizinische Ingenieure, Sensoren zu kalibrieren. Das Betriebssystem (Nucleus RTOS) wurde um einen Benutzerprofilmanager erweitert, der bis zu 10 Benutzer in verschlüsseltem Flash-Speicher speichert. Jedes Profil hat eine eindeutige PIN und Rolle. Der Kernel erzwingt, dass nur ein Benutzer mit "Apotheker"-Rolle die Arzneimittelbibliotheksdatei ändern kann. Die Pumpe enthält auch eine Timeout-Funktion, die den Bildschirm nach 30 Sekunden Inaktivität sperrt, was eine erneute Authentifizierung erfordert. Der sichere Bootvorgang überprüft die Integrität der Benutzerprofildatenbank bei jedem Start.

Consumer Electronics: Smart Home Hub

Ein Smart-Home-Hub kann von mehreren Familienmitgliedern genutzt werden. Jedes Mitglied hat eine andere Zugriffsebene: Eltern können neue Geräte hinzufügen und Sicherheitseinstellungen ändern; Kinder können nur Lichter und Thermostate steuern; Gäste können eine temporäre PIN verwenden, um die Haustür zu entsperren. Der Hub läuft mit Linux mit einem minimalen Dateisystem und verwendet einen Yocto-Projekt-Build. Multi-User-Unterstützung wird mit einem benutzerdefinierten Daemon implementiert, der Token verwaltet und ein Kernel-Modul, das sich in den Dateizugriff des Geräts einbindet. Benutzersitzungen sind leicht und verwenden ephemere Anmeldeinformationen. Ressourcenlimits verhindern, dass ein einzelner Benutzer den Netzwerkstapel sättigt, wodurch sichergestellt wird, dass ein sich falsch benehmendes IoT-Gerät eines Benutzers andere nicht stört.

Sicherheits- und Compliance-Bedenken

Auditing und Verantwortlichkeit

Jede Benutzeraktion, die die Sicherheit oder den Betriebszustand beeinflusst, muss protokolliert werden. Das Auditprotokoll sollte Benutzer-ID, Zeitstempel, Aktionstyp und Ergebnis (Erfolg/Ausfall) enthalten. In regulierten Branchen (Medizin, Industriesicherheit, Automobil) müssen Protokolle manipulationssicher sein und für einen bestimmten Zeitraum aufbewahrt werden. Verwenden Sie eine separate, nur anhängende Speicherpartition (z. B. einen kleinen SPI-NOR-Blitz), die durch Hardware schreibgeschützt ist. Wenn Speichergrenzen die Protokolldrehung erzwingen, stellen Sie sicher, dass Ereignisse mit hohem Schweregrad niemals überschrieben werden, bis sie von einem Administrator bestätigt werden.

Secure Boot und Benutzerdatenintegrität

Die Benutzerdatenbank selbst muss geschützt sein. Ihre Integrität sollte vom Bootloader mit einer digitalen Signatur oder HMAC überprüft werden. Wenn die Datenbank beschädigt oder manipuliert ist, sollte das System mit einem einzigen Standardadministratorkonto, das die Konfiguration wiederherstellen kann, in einen sicheren Modus booten. Dadurch wird verhindert, dass ein Angreifer durch Änderung der Benutzerdatei Privilegien eskaliert. Zusätzlich müssen sensible Benutzeranmeldeinformationen (Password-Hashes, private Token) in einem dedizierten Hardware-Sicherheitsmodul (HSM) oder einem sicheren Element gespeichert werden.

Netzexposition

Embedded-Systeme mit mehreren Benutzern, die mit dem Netzwerk verbunden sind (in IIoT üblich), müssen sich gegen Remote-Angriffe schützen. Verwenden Sie TLS 1.3 oder höher für alle Kommunikationen, die die Benutzerauthentifizierung und Datenübertragung beinhalten. Stellen Sie sicher, dass Abhördienste nach der Bindung an Ports (z. B. HTTP-Server läuft als Nicht-Root-Benutzer) Privilegien aufgeben. Anmeldeversuche mit Geschwindigkeitsbegrenzung, um Brute-Force-Angriffe zu verhindern. Erwägen Sie die Implementierung einer Firmware-Level-Firewall, die einschränkt, welche Quell-IPs die benutzerseitigen Dienste erreichen können.

Da eingebettete Hardware leistungsfähiger wird (Multi-Core-, MMU-, Virtualisierungserweiterungen), wird sich die Multi-User-Unterstützung zu konventionelleren Betriebssystemparadigmen hin verlagern, während sie immer noch Echtzeitanforderungen erfüllt. Der Aufstieg von Open-Source-RTOS wie Zephyr und NuttX standardisiert den Benutzerraum und die Multi-User-Funktionen über eine Vielzahl von Chips hinweg. RISC-V-Plattformen mit PMP (Physical Memory Protection) ermöglichen eine feinkörnige Benutzerisolation auf winzigen Kernen. Ein weiterer Trend ist die Integration von Multi-User-Unterstützung mit Zero-Trust-Architekturen, bei denen jede Benutzeranforderung explizit auf Hardware-Ebene autorisiert wird, sogar innerhalb des gleichen physischen Geräts. Machine Learning-Modelle, die anomales Benutzerverhalten erkennen, könnten in der sicheren Welt eingesetzt werden, um potenzielle Eindringlinge zu kennzeichnen.

Schließlich wird die wachsende Regulierungslandschaft für Medizinprodukte (FDA), Automobil (ISO 26262) und Industriesicherheit (IEC 61508) die Anbieter von eingebetteten Betriebssystemen dazu bringen, ihre Implementierungen für mehrere Benutzer formell zu überprüfen. Dies kann zur Einführung von Mikrokernen (seL4) führen, die nachweislich isolierte Benutzerräume und strenge Zugangskontrollen bieten.

Schlussfolgerung

Die Implementierung von Multi-User-Unterstützung in Embedded-Betriebssystemen erfordert eine sorgfältige Navigation von Ressourcenbeschränkungen, Echtzeitanforderungen und Sicherheitsanforderungen. Die diskutierten Strategien – leichte Authentifizierung, RBAC, Ressourcenbudgets und hardwaregestützte Isolation – sind heute in Produktionssystemen bewährt. Die Herausforderungen sind zwar erheblich, aber die Vorteile in Bezug auf Sicherheit, Auditierbarkeit und Betriebsflexibilität machen die Multi-User-Unterstützung zu einer wertvollen Investition für jedes Embedded-System, das mehr als eine Rolle oder einen Betreiber erfüllt. Da eingebettete Hardware weiter voranschreitet, können wir erwarten, dass Multi-User-Fähigkeiten zu einem Standardmerkmal werden, nicht zu einer benutzerdefinierten Ergänzung.