Passer au contenu 
Sur les serveurs Linux modernes, SELinux AppArmor détermine le niveau de restriction auquel les processus sont soumis, même lorsqu'ils disposent des droits root. Je présente les différences concrètes entre le contrôle d'accès basé sur les étiquettes et celui basé sur les chemins d'accès, et j'évalue leur utilité pour les conteneurs, Renforcement de la sécurité des serveurs et de la conformité.
Points centraux
- Principe MAC: Tous deux imposent des restrictions supplémentaires aux processus, en plus des droits Unix.
- Modèle: SELinux utilise des étiquettes, AppArmor des chemins d'accès.
- Conteneur: SELinux assure une isolation plus fine des conteneurs grâce au MCS.
- Opération: AppArmor est considéré comme plus facile à utiliser.
- Utilisation: Le choix découle souvent de la distribution.
SELinux et AppArmor en bref
Je mise sur Obligatoire Contrôle d'accès lors de la sécurisation de serveurs Linux. SELinux étend le noyau avec un modèle basé sur des étiquettes qui attribue des contextes de sécurité aux processus, fichiers, sockets et ports. Une politique globale définit quels types sont autorisés à interagir et lesquels bloquent strictement tout accès. AppArmor suit une approche basée sur les profils et les chemins d'accès, qui permet de définir, pour chaque application, les chemins d'accès, les capacités et les interfaces autorisées. Ces deux systèmes complètent les droits DAC classiques afin que les processus compromis ne puissent accéder qu'à Personnes agréées effectuer ce mouvement et il est impossible de se déplacer latéralement.
Modèle de sécurité : étiquettes vs chemins
J'évalue d'abord le modèle de sécurité, car il détermine la facilité de maintenance et minimise les erreurs. SELinux associe des règles à des étiquettes qui suivent le fichier et restent donc cohérentes lors des déplacements dans le système de fichiers. AppArmor associe les règles à des chemins d'accès, ce qui est très concret, mais nécessite une mise à jour en cas de renommage. L'approche basée sur les étiquettes semble centrée sur le système, tandis que celle basée sur les chemins d'accès est plutôt centrée sur les applications et proche de la boîte à outils des administrateurs. Les deux approches contrôlent la même réalité, mais elles structurent la Politique sont plus variées et imposent différentes méthodes de travail, que je choisis en fonction du niveau de maturité de l'équipe.
| Aspect | SELinux | AppArmor |
|---|---|---|
| Modèle de contrôle | Basé sur les étiquettes/types (Type Enforcement) | Basé sur le chemin d'accès/le profil pour chaque application |
| Portée de la politique | Ensemble de règles globales s'appliquant à l'ensemble du système | Profils liés aux processus et aux applications |
| Déplacer un fichier | Le label est conservé | Le chemin d'accès devra éventuellement être modifié |
| MLS/MCS | Disponible (séparation fine) | Indisponible |
| Isolation des conteneurs | Isolation entre l'hôte et les conteneurs et entre les conteneurs | Blindage primaire de l'hôte |
| Entrée en matière | Une courbe d'apprentissage plus raide | Plus rapide à mettre en œuvre |
Complexité et facilité d'utilisation
Je prévois la mise en place en fonction des compétences de l'équipe et de la tolérance aux erreurs de l'environnement d'exploitation. SELinux offre un niveau de détail considérable, mais exige en contrepartie une bonne compréhension des types, des rôles et des domaines, ainsi que des outils de diagnostic fiables. La vue d’ensemble améliore la cohérence, mais les règles erronées peuvent avoir des répercussions sur de nombreux services et doivent être corrigées de manière structurée. AppArmor me permet de démarrer en douceur, car je rédige des profils par service et j’attribue les violations de manière ciblée à ce service. Cette transparence réduit la frustration et me permet d’apporter des modifications rapidement et avec Vue d'ensemble mettre en production.
Modèle de menace et scénarios types
Je prends mes décisions en fonction des risques concrets auxquels je m'attaque. Ces deux mécanismes MAC permettent de réduire durablement :
- Dommages indirects liés au RCE: Un processus Web détourné ne lit pas automatiquement toutes les clés ou tous les fichiers de configuration.
- Élévation de privilèges: Même avec des droits root, les politiques empêchent tout accès non autorisé aux ressources sensibles.
- Mouvement latéral: Les processus n'ont pas accès aux ensembles de données, sockets ou périphériques voisins.
- Exfiltration: Les chemins d'accès aux fichiers et au réseau non autorisés sont bloqués ou consignés dès leur détection.
- Risques liés à la chaîne d'approvisionnement: Les binaires externes ou mis à jour restent confinés dans le bac à sable des droits définis.
Je définis ces risques au préalable, car ils déterminent la précision des profils, le niveau de détail de la journalisation et mon Acceptation des fausses alertes initiales.
Artefacts de stratégie, valeurs booléennes et profils
Pour SELinux, j'utilise la méthode éprouvée Application des types avec des modules que je déploie sous forme de paquets et avec des versions. Les variables booléennes me permettent d'activer ou de désactiver des fonctionnalités en toute sécurité (par exemple, autoriser ou non un serveur HTTP à établir des connexions réseau) sans avoir à créer une branche du module. Le choix entre ciblé et MLS/MCS-Les politiques sont définies en fonction des exigences de conformité et des besoins des clients. Avec AppArmor, je travaille avec des profils clairs, axés sur les processus, qui contrôlent avec précision les chemins d'accès aux fichiers, les capacités, ainsi que les accès réseau et DBus. Pour les chemins d'accès dynamiques, j'utilise des caractères génériques ou des répertoires abstraits, et je veille à ce que les profils restent modulaires afin que les mises à jour maintenable rester.
Fonctions : MLS/MCS et conteneurs
Pour les charges de travail modernes, je m'intéresse à la séparation des clients et à l'isolation des conteneurs. SELinux intègre les fonctionnalités MLS et MCS, c'est-à-dire des niveaux et des catégories qui organisent rigoureusement les flux d'informations et isolent automatiquement les conteneurs à l'aide d'étiquettes uniques. Cela me permet de limiter la portée des conteneurs compromis et de maintenir une séparation stricte entre les données. AppArmor protège principalement l’hôte contre les conteneurs ; une séparation nette entre les conteneurs eux-mêmes nécessite des mesures supplémentaires. Pour répondre à des exigences de conformité strictes, je mise donc sur SELinux et j’utilise MCS pour Mandants isoler de manière fiable.
Distributions et utilisations typiques
Je fais souvent mon choix en fonction de la distribution, car c'est là que l'écosystème et les outils s'intègrent le mieux. Dans les environnements RHEL, CentOS et Fedora, SELinux est souvent activé par défaut et constitue un pilier de la sécurité dans la conception du système. Ubuntu, Debian et SUSE fournissent des profils AppArmor pour les services courants, ce qui me permet d’activer rapidement la protection de manière productive. Si j’ai besoin d’une sécurité plus approfondie, j’associe la sélection MAC à Renforcement du noyau, afin de réduire encore davantage les surfaces d'attaque. Je parviens ainsi à créer une combinaison harmonieuse entre la distribution, le mécanisme MAC et Durcissement sans rupture dans la vie quotidienne.
Intégration des conteneurs et de l'orchestrateur
J'intègre systématiquement MAC dans les environnements d'exécution afin que les garanties de sécurité s'appliquent également dans le cadre de l'orchestration. Les environnements d'exécution des conteneurs respectent les profils AppArmor et les étiquettes SELinux ; via security-opts J'attribue des profils/étiquettes de manière ciblée à chaque conteneur. Dans Kubernetes, je gère les profils et les contextes dans le cadre des manifestes ou via des annotations/paramètres adaptés, afin que les déploiements restent reproductibles et vérifiables. Important : les volumes et les HostMounts doivent être correctement étiquetés ou inclus dans des profils, sinon les conteneurs échoueront au démarrage. Ma règle est la suivante : Déploiement et politique doivent être versionnés, testés et déployés ensemble afin de garantir la sécurité de la mise à l'échelle et des retours en arrière.
La gestion des directives au quotidien
Je procède par étapes, car les modifications apportées progressivement restent maîtrisables. Avec SELinux, j'utilise le mode permissif et je recourt à des outils tels que audit2allow pour déduire de manière ciblée les autorisations légitimes à partir des journaux. Ensuite, je gère les règles autorisées dans un système de versionnement et je les déploie de manière reproductible. Avec AppArmor, je commence souvent en mode « complain » jusqu’à ce qu’un profil couvre l’utilisation réelle, puis je passe en mode « enforce ». Cette approche préserve la Disponibilité des services et évite les imprévus pendant les fenêtres de maintenance.
Points d'achoppement et anti-patterns fréquents
- Désactivation aveugle: Je ne résous pas les problèmes liés aux règles de sécurité en désactivant le MAC ; je recherche la cause dans le journal et j'apporte des modifications ciblées.
- Contextes de fichiers incorrects: Avec SELinux, les étiquettes sont conservées lors d'un déplacement, mais pas en cas de processus de restauration incorrects. J'utilise des déploiements propres et relabel-routines.
- Des caractères génériques trop larges: Dans AppArmor, des caractères génériques trop larges compromettent la protection. Je commence par définir des règles strictes et je ne les élargis que dans la mesure où les données de télémétrie le justifient.
- Dérive: Les modifications manuelles effectuées en urgence sans être répercutées dans Git entraînent des incohérences. Je considère que les politiques déclaratif et automatisé.
- Mélange de LSM: Je ne combine pas SELinux et AppArmor sur le même hôte ; dans la pratique, j'utilise un mécanisme MAC principal associé à des LSM complémentaires tels que Yama/Lockdown, lorsqu'ils sont pris en charge.
- Chemins temporaires: Je prévois dès le début la mise en place de /tmp, des sockets d'exécution et des répertoires dynamiques, sinon les mises à jour ou les déploiements « blue-green » échouent.
Performances et tolérance aux pannes
Je vérifie d'abord si MAC ralentit mon débit ou retarde le démarrage de services critiques. Dans la pratique, lorsque la configuration est correcte, je ne constate pratiquement aucune perte mesurable, car les vérifications du noyau fonctionnent efficacement. Ce qui est plus important, c’est que des règles trop strictes peuvent bloquer le démarrage ou le fonctionnement de certains services jusqu’à ce que je les ajuste. C’est pourquoi une journalisation rigoureuse, une gestion claire des changements et un déploiement réfléchi doivent impérativement figurer à l’ordre du jour. C’est ainsi que je maintiens un niveau de protection élevé et que la Risques de petite taille sur le plan opérationnel, sans ralentir la plateforme.
Renforcement de la sécurité des serveurs en réseau
J'associe le MAC à des filtres réseau, au renforcement de la sécurité SSH et à des limites de processus afin d'empêcher les erreurs de s'aggraver. Les espaces de noms et les cgroups organisent les charges de travail et limitent les ressources, tandis que le MAC interdit tout ce qui n'est pas expressément autorisé. Pour une séparation plus claire des clients dans les conteneurs, j’utilise MCS sous SELinux et j’ajoute des règles d’hôte en conséquence. Je m’appuie sur Espaces de noms et cgroups, afin de structurer les couches de manière cohérente. Cette stratification permet de contenir les attaquants dans des espaces restreints Glissières de sécurité, même en cas de défaillance de certains anneaux de protection.
Conformité et audit
J'associe MAC à des stratégies d'audit afin de répondre aux exigences de manière mesurable. SELinux et AppArmor fournissent des événements précis que je collecte de manière centralisée et que je recoupe avec les informations relatives aux modifications. Pour les audits internes et externes, je documente :
- Couverture de la police: Quels sont les services en mode « Enforce » et quelles sont les exceptions ?
- Historique des modifications: Qui a modifié quelle règle, à quel moment, et dans le cadre de quelle révision ?
- Circuits d'alarme: Quels sont les événements MAC à ne pas manquer, qui réagit, comment se présente la Temps moyen nécessaire pour remédier au problème?
- Séparation des mandants: Quelles sont les catégories MCS (SELinux) attribuées, et comment sont-elles gérées ?
C'est ainsi que je mets en œuvre des mesures techniques conformes aux cadres de conformité et que je conserve les justificatifs vérifiable avant.
Aide à la décision : quel choix est le plus adapté ?
Je commence par définir les objectifs de conformité, les compétences de l'équipe et les risques opérationnels avant de choisir la voie à suivre. Si l'environnement nécessite un MLS/MCS, une isolation fine des conteneurs et une politique système cohérente, SELinux présente de nombreux avantages. Si je mise sur une mise en place rapide, des profils transparents et une attribution claire par service, c’est là qu’AppArmor dévoile tous ses atouts. Pour les environnements hybrides, j’utilise le système natif de la distribution et j’y ajoute mes propres règles avec prudence. En matière d’isolation des applications, il est intéressant de se pencher également sur Isolation des processus, afin de restreindre encore davantage les privilèges résumer.
Scénarios concrets : mise en contexte rapide
- Machines virtuelles à locataire unique: AppArmor suffit souvent, déploiement rapide, profils clairs pour chaque service.
- Hébergeur multi-locataires avec conteneurs: SELinux avec MCS pour une séparation stricte entre les conteneurs et les données.
- monolithe hérité: AppArmor comme solution intermédiaire, puis passage à SELinux lorsque l'équipe aura acquis davantage d'expérience.
- Environnement hautement réglementé: SELinux avec une politique stricte, nombre minimal de booléens, audit configuré sur „ bloquer d'abord, puis autoriser “.
- Edge/Embarqué: Profils AppArmor allégés, surcharge minimale, contrôle strict des chemins d'accès des quelques services.
Mini-étude de cas : mettre en place une pile web en toute sécurité
Je déploie NGINX, PHP-FPM et un planificateur sur une plateforme d'hébergement. Je commence par activer MAC dans le se plaindre/tolérantMode et lance le trafic en conditions réelles. Ensuite :
- Aperçu des événements: Je filtre les journaux d'audit pour ces services, j'élimine les accès non autorisés manifestes et j'interprète les événements restants.
- Création de règles: Pour SELinux, je génère des règles « allows » ciblées et je les intègre dans un module ; pour AppArmor, j'affine les profils en y ajoutant les chemins d'accès au cache, aux fichiers à télécharger et aux fichiers temporaires.
- Renouvellement de la validation: Les tests de charge vérifient le démarrage, les mises à jour progressives et les scénarios d'erreur (par exemple, la rotation des fichiers journaux, le renouvellement des certificats).
- Migration vers Enforce: J'active Enforce progressivement (Canary), je surveille les métriques et les anomalies dans les journaux.
- Exploitation: Les politiques sont intégrées dans le processus CI/CD, les modifications font l'objet de revues et de tests en préproduction. Je définis un Briser la vitre- Procédure à suivre en cas d'urgence réelle, avec un suivi rigoureux.
Bonnes pratiques issues de l'expérience sur le terrain
Je ne lance jamais les MAC à l'aveuglette, mais je commence par les observer. Les journaux reflètent l'utilisation réelle ; à partir de là, je définis des autorisations minimales et je documente les ajustements de manière exhaustive. J'intègre les politiques et les profils dans le CI/CD afin de déployer les modifications de manière vérifiable et reproductible. La surveillance met en corrélation les événements MAC avec d'autres signaux et met en évidence les anomalies. Ce cycle d'observation, d'ajustement et de vérification garantit la Qualité est élevé et comble progressivement les lacunes.
Résumé et mise en perspective
J'utilise SELinux lorsque j'ai besoin d'une séparation fine, du MCS pour les conteneurs et d'une politique système uniforme. Je choisis AppArmor lorsque la rapidité de mise en œuvre, des profils faciles à comprendre et une analyse claire des erreurs sont prioritaires. Ces deux systèmes renforcent considérablement la sécurité des serveurs Linux au-delà des droits d'accès classiques aux fichiers et limitent la portée des attaques réussies. Il reste toutefois essentiel d'assurer une maintenance rigoureuse des règles, ainsi que leur intégration dans les pare-feu, les mécanismes d'isolation et la journalisation. Je parviens ainsi, avec un effort raisonnable, à obtenir un gain de sécurité important tout en maintenant le bon fonctionnement du système. maîtrisable.
