Comprendre le support multi-utilisateurs dans les systèmes d'exploitation embarqués

Contrairement aux systèmes d'exploitation de bureau ou de serveur, les systèmes d'exploitation intégrés (RTOS, embarqués Linux ou noyaux personnalisés) commencent souvent à être conçus par un seul utilisateur en raison de contraintes en matière de ressources. Cependant, à mesure que les systèmes intégrés deviennent plus interconnectés et servent des groupes d'utilisateurs hétérogènes — opérateurs, responsables, administrateurs distants et utilisateurs finaux —, le besoin d'architectures multi-utilisateurs robustes augmente. Cette capacité garantit que les actions sont auditables, les ressources sont protégées et les politiques de sécurité sont mises en œuvre sans sacrifier les performances ou la stabilité en temps réel.

Dans la pratique, le support multi-utilisateurs dans les systèmes embarqués doit gérer l'authentification des utilisateurs, la gestion des sessions, le contrôle d'accès et le partage des ressources avec un minimum de frais généraux. L'implémentation doit respecter les cycles CPU limités, l'empreinte mémoire et les budgets d'alimentation typiques du matériel embarqué. De plus, le système doit coexister avec un calendrier déterministe et des garanties en temps réel.

Concepts et distinctions de base

Avant de passer à l'implémentation, il est important de préciser ce que signifie le support multi-utilisateurs dans un contexte intégré. Contrairement à un système d'exploitation général où plusieurs utilisateurs peuvent se connecter via des consoles SSH ou graphiques, les systèmes intégrés interagissent souvent par des interfaces spécialisées (par exemple, écrans tactiles, panneaux Web, bus de terrain). Un utilisateur peut être un opérateur humain utilisant un terminal physique, des commandes d'envoi de client API ou un processus automatisé avec des identifiants.

Les systèmes multi-utilisateurs embarqués mettent généralement en œuvre un contrôle d'accès discrétionnaire (DAC) ou un contrôle d'accès obligatoire (MAC)[. Le DAC, commun aux systèmes embarqués basés sur Linux, permet aux utilisateurs de contrôler l'accès à leurs propres objets. Le MAC, utilisé dans des environnements de haute sécurité (p. ex., MILS ou SELinux), fait appliquer les politiques à l'échelle du système. Le choix dépend des exigences de sécurité et de la complexité de la base d'utilisation.

Principaux défis dans la mise en œuvre intégrée de l'utilisation multi-utilisateurs

Contraintes en matière de ressources

Les systèmes embarqués fonctionnent généralement avec aussi peu que 256 KB de RAM et quelques mégaoctets de stockage flash. Chaque session active d'utilisateur consomme de la mémoire pour le stockage des justificatifs d'identité, des blocs de contrôle de processus, des descripteurs de fichiers et l'état de session. Le coût supérieur d'un cadre de gestion utilisateur POSIX complet (p. ex. PAM, NSS) peut être prohibitif. Les ingénieurs doivent donc déclasser jusqu'à des implémentations minimales — souvent un module d'authentification personnalisé avec des tables d'utilisateur statiques ou un petit client LDAP. La mémoire pour la comptabilité des ressources par utilisateur doit être allouée statiquement ou limitée dynamiquement par un nombre maximum d'utilisateurs simultanés.

Déterminisme en temps réel

Les opérations multi-utilisateurs telles que les vérifications de connexion, d'authentification et de permissions introduisent des variations de latence qui peuvent affecter les délais en temps réel. Si une tâche en temps réel hautement prioritaire est obligée d'attendre qu'un démon d'authentification de l'espace utilisateur réponde, le système peut manquer une fenêtre d'interruption. Les mesures d'atténuation comprennent l'authentification en cours dans une tâche séparée, moins prioritaire et l'identification de cache dans le noyau pour une recherche rapide. Certains systèmes d'exploitation intégrés mettent en œuvre la prise en charge multi-utilisateurs entièrement dans le noyau pour éviter le changement de contexte en amont.

Surface d'attaque de sécurité

Chaque interface utilisateur (terminal, serveur web, connexion BLE) est un point d'entrée potentiel pour les mouvements latéraux ou l'escalade des privilèges. Le système intégré doit se défendre contre les vulnérabilités communes comme les débordements de tampons dans les invites de connexion, la rejoue des titres de créance et le détournement de session. Les mesures de durcissement comprennent l'utilisation de bibliothèques C minimales (p. ex., uClibc ou Musl), les canaris de pile, ASLR (si ROM le permet) et le démarrage sécurisé pour vérifier les composants de gestion des utilisateurs.

Gestion des séances et robustesse

Par exemple, un technicien peut déboger via console série pendant qu'un opérateur distant contrôle la machine via Ethernet. Le système doit gérer la création de session, le délai de sortie et le nettoyage sans fuite de ressources. La fin de session sur panne d'alimentation ou de plantage doit également préserver l'intégrité — les modifications de configuration partiellement appliquées d'un utilisateur ne doivent pas corrompre les données d'un autre utilisateur.

Stratégies de conception pour un système intégré multi-utilisateurs

Authentification légère et gestion de l'identité

L'authentification intégrée doit équilibrer la sécurité et l'utilisation des ressources.

  • Authentification basée sur un jeton: Les utilisateurs présentent des jetons matériels (par exemple, cartes NFC, TOTP d'un smartphone) qui sont validés par rapport à un secret stocké. La valeur du jeton est éphémère et ne nécessite pas de hachage complet du mot de passe sur l'appareil.
  • Authentification biométrique:[ Reconnaissance d'empreinte digitale ou d'iris intégrée dans l'appareil. Le modèle biométrique est stocké dans une mémoire sécurisée enclave, et l'appariement fonctionne dans un processeur dédié pour éviter de charger le processeur principal.
  • Clace pré-partagée (PSK) ou basée sur un certificat: Pour les systèmes sans tête (par exemple, routeurs, passerelles IoT), chaque utilisateur a un certificat ou une clé unique qui authentifie les appels d'API. La bibliothèque TLS intégrée (comme wolfSSL) vérifie le certificat avec un minimum d'utilisation de RAM.
  • Connexion sans mot de passe via présence physique :[ Certains appareils intégrés contournent l'authentification traditionnelle en exigeant une pression de bouton physique ou un réglage de saut pour élever temporairement le privilège. Cela réduit la complexité du code, mais devrait être combiné avec des mesures de sécurité matérielle pour prévenir les abus.

Quelle que soit la méthode choisie, l'authentification doit être découplée de l'application principale. Un petit démon d'authentification (ou module noyau) gère la vérification des titres de compétence, tandis que le reste du système reste ignorant des identités des utilisateurs jusqu'à ce qu'une vérification des autorisations soit nécessaire.

Profils des utilisateurs et modèles de permission

Chaque utilisateur doit avoir un profil qui définit ses droits d'accès aux fichiers, aux périphériques et aux appels système. Dans un noyau intégré minimaliste, cela peut être mis en œuvre comme une simple liste de capacités : un bitmask pour chaque ressource. Par exemple, l'utilisateur A peut lire les données des capteurs mais ne pas écrire pour les registres de l'actionneur, tandis que l'utilisateur B peut faire les deux. Les systèmes plus avancés adoptent le modèle utilisateur/groupe Unix, bien qu'avec des groupes aplatis pour réduire les recherches. La fonction de vérification des autorisations doit être un seul chemin de code court invoqué avant toute opération sensible à la sécurité.

Le contrôle d'accès basé sur les rôles (RBC) est particulièrement efficace dans les dispositifs médicaux embarqués. Chaque utilisateur se voit attribuer un rôle (infirmière, médecin, administrateur) avec un ensemble prédéfini de privilèges. Les rôles sont stockés dans une partition en lecture seule qui est signée pour empêcher toute manipulation. Lorsqu'un utilisateur se connecte, le système charge le contexte de rôle et l'applique pour toutes les actions subséquentes.

Affectation des ressources et équité

Les systèmes multi-utilisateurs risquent la famine des ressources si un utilisateur monopolise la bande passante CPU, mémoire ou E/S. Les planificateurs intégrés doivent intégrer des budgets CPU par utilisateur. Par exemple, chaque utilisateur peut se voir attribuer une tranche de CPU minimale garantie à l'aide d'un planificateur basé sur la réservation (par exemple, serveur sporadique POSIX). L'allocation de mémoire peut être captée par des pools prédéfinis — chaque pool associé à un ID utilisateur. La configuration du trafic réseau peut être appliquée à l'aide de filtres à godets en jeton.

L'utilisation d'un conteneur de virtualisation léger (comme lxc ou microviseur) pour chaque utilisateur est une alternative, mais elle est accompagnée de frais généraux plus élevés. Dans de nombreux systèmes intégrés, il est plus efficace d'avoir un noyau unique avec un suivi des ressources par utilisateur. Le noyau peut maintenir une petite structure de données (par exemple, un ) pour chaque utilisateur actif, mis à jour par le planificateur et le gestionnaire de mémoire. Si un utilisateur dépasse son allocation, le noyau peut battre ses fils ou refuser d'autres mappages de mémoire jusqu'à ce qu'ils libèrent des ressources.

Techniques d'isolement

Isolation des processus

Les systèmes d'exploitation modernes intégrés (comme Zephyr RTOS) fournissent des fils d'espace utilisateur avec le support MPU (Memory Protection Unit) ou MMU. Chaque processus utilisateur fonctionne dans des domaines distincts renforcés par le matériel, empêchant les lectures/écritures non autorisées. Pour les systèmes sans MMU, l'isolement repose sur les vérifications logicielles à la couche API RTOS. Les tâches de chaque utilisateur sont limitées aux régions de mémoire disjointe, et tout croisement déclenche un contrôle de privilège.

Virtualisation

La mise en place de systèmes intégrés haut de gamme (ARM Cortex-A, RISC-V avec extension hypervisor) permet d'isoler différents utilisateurs en tant qu'instances d'exploitation clientes distinctes. Chaque utilisateur voit une plate-forme virtuelle complète et un petit hyperviseur facilite l'accès aux ressources physiques. Le coût des frais généraux est plus élevé, mais la sécurité est extrêmement forte parce qu'un compromis dans l'environnement d'un utilisateur ne peut pas affecter directement les autres.

Enclaves sécurisées ou TrustZone

Pour les appareils avec TrustZone (ARM), les opérations sensibles d'un utilisateur (par exemple, l'accès à la clé cryptographique) peuvent fonctionner dans le monde sécurisé pendant que les tâches normales de l'utilisateur s'exécutent dans le monde normal. Cela permet d'isoler les fonctions d'authentification et d'autorisation avec le matériel. Le monde sécurisé détient la base de données principale de l'utilisateur et fait appliquer les décisions de contrôle d'accès, tandis que le monde normal effectue des tâches d'application.

Études de cas : Systèmes intégrés multi-utilisateurs en pratique

Système de contrôle industriel avec accès par rôle

Considérez un contrôleur logique programmable (PLC) utilisé sur un plancher d'usine. Plusieurs opérateurs peuvent avoir besoin de surveiller la ligne de production, tandis qu'un superviseur peut modifier la logique de contrôle, et un administrateur peut mettre à jour le firmware. Un RTOS personnalisé avec support multi-utilisateurs a été mis en place avec FreeRTOS + un système de fichiers légers avec ACL. Les opérateurs ont accès en lecture seule aux cartes d'E/S, les superviseurs ont accès par écrit aux blocs logiques, et les administrateurs peuvent modifier le noyau et le chargeur de démarrage. Chaque utilisateur authentifie avec une carte de proximité. Les budgets du CPU garantissent que les tâches de superviseur ne privent pas les tâches d'interface opérateur. Le système enregistre chaque événement de vérification de permission à un tampon d'audit circulaire, qui est déchargé périodiquement sur un serveur SCADA.

Pompe à perfusion médicale avec profils multi-utilisateurs

Une pompe à perfusion à multiples rapports permet aux infirmières de fixer les taux de perfusion, aux pharmaciens de remplacer les bibliothèques de médicaments et aux ingénieurs biomédicaux de calibrer les capteurs. Le système d'exploitation (Nucleus RTOS) a été étendu avec un gestionnaire de profil utilisateur qui stocke jusqu'à 10 utilisateurs dans une mémoire flash cryptée. Chaque profil a un NIP et un rôle unique. Le noyau fait en sorte que seul un utilisateur ayant un rôle « pharmaco » peut modifier le fichier de la bibliothèque de médicaments. La pompe comprend également une fonctionnalité de temps d'arrêt qui verrouille l'écran après 30 secondes d'inactivité, nécessitant une nouvelle authentification.

Électronique de consommation: Smart Home Hub

Chaque membre a un niveau d'accès différent : les parents peuvent ajouter de nouveaux appareils et modifier les paramètres de sécurité ; les enfants ne peuvent contrôler que les lumières et les thermostats ; les invités peuvent utiliser un NIP temporaire pour déverrouiller la porte d'entrée. Le hub exécute Linux avec un système de fichiers minimal et utilise une compilation de projet Yocto. Le support multi-utilisateur est implémenté avec un démon personnalisé qui gère des jetons et un module noyau qui se branche dans l'accès au fichier de périphérique. Les sessions utilisateur sont légères et utilisent des identifiants éphémères.

Considérations relatives à la sécurité et au respect

Vérification et responsabilisation

Dans les industries réglementées (médicale, sécurité industrielle, automobile), les journaux doivent être protégés contre les manipulations et conservés pendant une période donnée. Utilisez une partition de stockage séparée, en appendice seulement (p. ex. un petit flash SPI NOR) qui est protégée par écrit par du matériel. Si le stockage limite la rotation du journal, assurez-vous que les événements de haute gravité ne sont pas écrasés avant d'être reconnus par un administrateur.

Sécurité de l'intégrité des données de démarrage et d'utilisation

La base de données utilisateur elle-même doit être protégée. Son intégrité doit être vérifiée par le chargeur de démarrage à l'aide d'une signature numérique ou HMAC. Si la base de données est corrompue ou altérée, le système doit démarrer en mode sûr avec un seul compte administrateur par défaut qui peut restaurer la configuration. Cela empêche un attaquant d'augmenter les privilèges en modifiant le fichier utilisateur.

Exposition au réseau

Les systèmes intégrés multi-utilisateurs connectés au réseau (communs dans IIoT) doivent se défendre contre les attaques à distance. Utilisez TLS 1.3 ou plus pour toute communication impliquant l'authentification des utilisateurs et le transfert de données. Assurez-vous que les services d'écoute perdent des privilèges après avoir lié les ports (par exemple, le serveur HTTP fonctionne comme un utilisateur non root).

Tendances futures du système intégré multi-utilisateurs

Le développement de la technologie de l'information (RTOS open source comme Zephyr et NuttX) permet de normaliser les fonctionnalités utilisateur-espace et multi-utilisateurs sur une large gamme de puces. Les plateformes RISC-V avec PMP (Physical Memory Protection) permettent une isolation des utilisateurs à grain fin sur de minuscules noyaux. Une autre tendance est l'intégration de la technologie de l'information multi-utilisateurs avec des architectures de confiance zéro, où chaque demande utilisateur est explicitement autorisée au niveau matériel, même au sein du même appareil physique.

Enfin, le paysage réglementaire croissant pour les dispositifs médicaux (FDA), l'automobile (ISO 26262) et la sécurité industrielle (IEC 61508) poussera les fournisseurs de systèmes d'exploitation embarqués à vérifier officiellement leurs implémentations multi-utilisateurs. Cela peut conduire à l'adoption de micro-kernels (seL4) qui fournissent des espaces utilisateur facilement isolés et un contrôle d'accès strict immédiatement hors de la boîte.

Conclusion

La mise en oeuvre du support multi-utilisateurs dans les systèmes d'exploitation intégrés exige une navigation attentive des contraintes de ressources, des exigences en temps réel et des exigences de sécurité. Les stratégies discutées - authentification légère, RBAC, budgets des ressources et isolement soutenu par le matériel - sont prouvées dans les systèmes de production aujourd'hui. Bien que les défis soient importants, les avantages en termes de sécurité, de auditabilité et de flexibilité opérationnelle font du multi-utilisateurs un investissement précieux pour tout système intégré d'ingénierie qui sert plus d'un rôle ou un opérateur.