Modèle de mandat de contrôle d'accès (MAC): présentation et applications

Modèle de contrôle d'accès obligatoire (MAC) - une méthode de contrôle d'accès avec un ensemble fixe d'autorisations. Généralement, ce MAC est utilisé dans des systèmes avec des exigences de sécurité élevées et est au service de divers organismes d'application de la loi et organisations associés à des secrets d'État ou officiels.

Modèle MAC

Le MAC, bien qu'il soit contenu dans de nombreux articles et documents, est le plus souvent mentionné avec désinvolture et sous la forme d'une sauce épicée pour quelque chose comme une brève mention de MLS dans SELinux. Comme beaucoup limitent leur amitié avec SELinux en utilisant la recette « comment désactiver SELinux », le MAC l'honore souvent aussi. Par conséquent, d'abord brièvement sur MAC.

Si vous connaissez le modèle, vous pouvez passer directement à la section suivante.

Idée principale

Le modèle de sécurité abstrait mis en œuvre dans le MAC classique (comme le savent les responsables de l'application des lois) est le suivant (image classique illustrant le modèle Bell-Lapadula ):


Le modèle MAC est intrinsèquement une implémentation «électronique» d'un workflow papier «secret». Le MAC a les «acteurs» suivants:

• Hiérarchie des niveaux d'accès traités dans le système (généralement enregistrés dans le système d'exploitation). Pour plus de commodité, il est souvent spécifié sous forme de nombres non signés (de 0 à une valeur limitée par l'implémentation). Dans ce cas, pour comparer les niveaux d'accès (supérieur / inférieur / égal), les opérations arithmétiques les plus simples sont utilisées (égal, moins, plus).
• Objet avec un niveau de secret. Tout fichier, répertoire dans le système de fichiers, cellule ou enregistrement dans la table de base de données, table dans la base de données, la base de données elle-même, paquet réseau, etc. L'objet reçoit n'importe quelle valeur de la hiérarchie des niveaux d'accès. Pour l'objet, il est permis d'augmenter le niveau de secret (passer à une valeur de niveau supérieure à celle actuelle). Une diminution du niveau de secret n'est catégoriquement pas autorisée (bien que cela soit tout à fait possible à l'aide de certaines astuces).
• Sujet avec niveau d'accès. Processus d'une application ou d'une session utilisateur (essentiellement également le processus d'application). L'étiquette de niveau d'accès est héritée du sujet par tous les objets créés par ce sujet.

La valeur du niveau d'accès du sujet ou du niveau de sécurité de l'objet est généralement appelée terme «niveau obligatoire», «étiquette obligatoire» ou simplement «étiquette» (dans STCSEC, ce terme est appelé «niveau de classification hiérarchique»). Simple, vaste et presque sans ambiguïté.

Un contrôle d'autorisation est effectué à chaque constat de l'accès du sujet à l'objet protégé par le MAC. Dans ce cas, le modèle de contrôle d'accès des informations d'identification est généralement utilisé en conjonction avec d'autres mécanismes de contrôle d'accès, par exemple le DAC (modèle UNIX et ACL POSIX). Dans ce cas, le MAC est vérifié en dernier. D'abord, l'accès est vérifié par DAC (comme le moins sécurisé), puis par MAC.

Lors de la vérification de l'éligibilité de l'accès du sujet à l'objet selon le modèle obligatoire, les combinaisons suivantes sont possibles:

1. L'étiquette d'identification du sujet est égale à l'étiquette d'identification de l'objet. Dans ce cas, le sujet est autorisé à lire et à modifier l'objet.
2. L’étiquette d’identification du sujet est plus élevée que l’étiquette d’identification de l’objet. Le sujet n'est autorisé qu'à lire l'objet: il le voit, mais ne peut pas le changer.
3. L'étiquette d'informations d'identification du sujet est inférieure à l'étiquette d'informations d'identification de l'objet. Le sujet est formellement autorisé à créer un objet avec une note d'identification plus élevée (ce que l'on appelle "augmenter le niveau de secret de l'objet"). En pratique, le sujet n'a pas la capacité technique d'effectuer cette opération (il "ne voit tout simplement" pas l'objet variable, par exemple un fichier ou un répertoire avec des fichiers).

En MAC également, il existe une «catégorie» (dans la terminologie STCSEC, ce terme est appelé «catégories non hiérarchiques»). Les catégories dans MAC sont facultatives. En pratique, l'implémentation des catégories MAC permet de contrôler les accès "horizontaux" entre les différents services de l'organisation. Dans ce cas, les employés, malgré un niveau obligatoire, n'auront accès qu'aux catégories d'objets auxquels ils ont accès selon leur étiquette.

Limitations et vulnérabilités

MAC a ses limites et ses fonctionnalités:

1. Les utilisateurs du système ne peuvent pas déterminer indépendamment l'accès des sujets aux objets. De l'arsenal complet du contrôle d'accès aux objets dans le MAC, il n'y a qu'une étiquette d'identification et une catégorie d'informations d'identification associées à cet objet. La gestion de l'accès des sujets aux objets n'est effectuée que par les administrateurs.
2. Si l'utilisateur souhaite modifier l'étiquette d'identification de l'objet dont il est l'auteur, il doit alors accéder à la session d'étiquette cible. Cela est dû au fait que l'utilisateur ne peut pas spécifier l'étiquette à volonté, mais peut uniquement passer l'étiquette à l'objet "par héritage". Dans le même temps, l'utilisateur ne peut travailler que dans une session d'une seule étiquette d'identification.
3. Étant donné que le MAC est utilisé en conjonction avec d'autres modèles de contrôle d'accès, des collisions surviennent: il n'est parfois pas si facile de savoir dans quelle «couche» de l'accès au système de sécurité refusé. Un «réglage fin» de toutes les couches de protection est requis.
4. En plus des paramètres d'accès via la boîte à outils MAC, une politique de sécurité est requise. Il doit décrire la signification des valeurs spécifiques des informations d'identification (en dehors du MAC), quels objets sont protégés, quels sujets ont le droit d'accéder. Sans une réglementation convenue, MAC seul ne fournira pas d'amélioration de la sécurité.
5. Utilisation de MAC dans une infrastructure de réseau distribué. L'approche traditionnelle pour configurer le MAC est localement, manuellement, avec l'aide d'un administrateur conformément aux instructions. Il existe des solutions qui vous permettent d'implémenter un stockage MAC géré de manière centralisée (comme ALD), mais elles ont leurs propres caractéristiques et difficultés de construction.

Conception d'une application MAC

Malgré toutes les limites du modèle, pour ceux qui travaillent avec le secteur public, et en particulier avec les organismes d'application de la loi, la question de la création d'applications avec la prise en charge d'un modèle de contrôle d'accès obligatoire est plus pertinente que jamais. Du coup, demain tu devras supporter le MAC dans ton produit?

À première vue, il semble que le modèle soit primitif et sa mise en œuvre soit aussi simple que cinq cents, mais il y a une mise en garde: le client qui définit les exigences pour l'utilisation du modèle d'informations d'identification a en tête, tout d'abord, un outil de sécurité des informations certifié. Les informations véritablement secrètes, jusqu'aux secrets d'État, seront traitées dans une telle IP, et il sera très difficile de certifier son propre développement au niveau requis. La solution à cette situation consiste à utiliser une infrastructure certifiée prenant en charge MAC.

Donc, ce que nous avons dans l'ensemble:

Voyons maintenant comment utiliser cette infrastructure lors du développement d'une application pour préserver les fonctions de contrôle d'accès au niveau de l'infrastructure.

Pour que l'application puisse bénéficier du mécanisme d'étiquetage obligatoire du système d'exploitation, les conditions suivantes doivent être remplies:

• Les utilisateurs de l'application doivent être enregistrés dans le référentiel des utilisateurs du système d'exploitation. Au minimum, il doit y avoir un identifiant qui vous permet de mapper de manière unique l'utilisateur de l'application à l'utilisateur du système d'exploitation (il s'agit généralement de la connexion).
• Les utilisateurs de l'application au niveau du mécanisme MAC du système d'exploitation doivent être configurés avec des autorisations d'identification pour des informations d'identification spécifiques (plages d'informations d'identification).

Du point de vue de l'application de bureau, le scénario utilisateur est le suivant:

1. L'utilisateur entre dans l'OS sous son échographie personnelle dans le mode de l'étiquette dont il a besoin. Lance l'application. Le processus de demande hérite de l'étiquette d'identification.
2. L'application interagit avec la base de données sur PostgreSQL, affichant, par exemple, uniquement les enregistrements des tables de base de données avec l'étiquette d'identification actuelle.

Du point de vue de l'application serveur qui fournit des services Web, le scénario utilisateur est conceptuellement proche, bien qu'il semble un peu plus compliqué:

1. L'utilisateur entre dans l'OS sous son échographie personnelle dans le mode de l'étiquette dont il a besoin. Il lance un navigateur avec prise en charge MAC, dans notre exemple, Mozilla Firefox (un navigateur «normal» ne fonctionnera pas à ces fins). Le processus du navigateur hérite des informations d'identification.
2. L'utilisateur demande l'adresse de ressource de l'application avec prise en charge des informations d'identification. Le navigateur forme une demande en y ajoutant une marque d'identification.
3. La demande est traitée par un serveur Web prenant en charge les informations d'identification, dans notre exemple, Apache Http Server. Le serveur Web (dont le processus fonctionne en mode d'informations d'identification minimales) lit l'étiquette d'informations d'identification de la demande, trouve l'application de gestionnaire et démarre son processus avec la balise d'informations d'identification transmise.
4. L'application interagit avec la base de données PostgreSQL, relayant l'étiquette des informations d'identification dans les requêtes.

La présence de MAC dans le système d'exploitation impose des restrictions assez sérieuses sur l'architecture de l'application. Le fait que dans un système d'exploitation sans modèle de contrôle d'accès aux informations d'identification semble trivial dans un système d'exploitation avec un MAC peut apporter de nombreuses surprises à toute l'équipe de développement. Surtout au chef de projet. Par conséquent, l'architecture d'une application compatible MAC doit être créée avant le début du développement. Le chef de projet avec le MAC doit insister pour que la conception soit faite par l'équipe architecturale avant tout mouvement vers la mise en œuvre.

Bien entendu, pour le développement d'applications simples (utilitaires ou applications, en raison de leur spécificité neutre pour MAC), de nombreux conseils ne sont tout simplement pas utiles. Si l'application est quelque chose de plus complexe qu'une application locale mono-utilisateur qui lit un fichier et écrit le résultat de son travail dans un fichier, il est conseillé de bien comprendre les "pièges".

Nous avons compilé des recettes pour la conception d'une application avec prise en charge MAC, formulées sur la base de notre propre expérience. Derrière eux, il y a des nuits blanches, un flux continu de tickets de test, des milliers d'heures de débogage d'une application qui, par le bon sens, devrait fonctionner correctement, mais pour une raison quelconque ne fonctionne pas comme ça. Les recettes sont décrites sous la forme la plus simple et neutre par rapport à la technologie et aux outils, et si possible équipées de schémas pour améliorer la perception. C'est parti!

Comment éviter MAC quand il ne peut plus être évité

Lors de la conception d'une application avec MAC, vous pouvez utiliser une solution architecturale très simple, qui au final vous fera économiser beaucoup de nerfs et de temps. Un paramètre doit être ajouté à la configuration de l'application qui indique à l'application si le modèle de contrôle d'accès des informations d'identification pour cette installation est activé ou non. Dans tous les endroits de l'application où l'interaction avec l'infrastructure MAC a lieu ou où la fonction commerciale de l'application nécessite une vérification d'étiquette, vous devez d'abord vérifier la valeur de ce paramètre. Si le MAC est désactivé en fonction de celui-ci, l'application ignore toutes les règles de logique métier conçues pour tester les fonctions compatibles MAC.

En termes de coûts de main-d'œuvre, vous devrez consacrer plus de temps à la mise en œuvre de chaque fonction de l'application avec prise en charge MAC. Vous devrez déboguer et tester la même fonctionnalité dans le mode sans étiquette d'identification, de sorte que le coût des tests augmentera.

Grâce à cette solution, il est possible de fournir l'application (et toute l'équipe de développement), qui est forcée de fonctionner dans l'environnement MAC, les avantages suivants:

• Application multiplateforme (limitée uniquement par les capacités des langages de programmation) et son indépendance par rapport à l'exécution.
• La possibilité d'utiliser des outils de virtualisation modernes (par exemple, Docker) pour l'automatisation.
• Facilité de tester et de déboguer des fonctionnalités qui ne sont pas directement liées au MAC.

Recommandations :

Ajoutez l'option pour activer / désactiver la prise en charge des informations d'identification dans l'application.

Dans tous les endroits nécessitant une interaction avec le MAC, tout d'abord, vérifiez la valeur du paramètre.

Lors du débogage et des tests, il est nécessaire de déboguer (du côté de l'équipe de développement) et de tester (du côté de l'équipe de test) les deux modes de l'application.

Diviser et conquérir

Une autre étape de conception importante qui doit être achevée avant le début du développement est la séparation des modules dans lesquels le support MAC est requis des modules dans lesquels ce mécanisme de contrôle d'accès n'est pas requis. L'utilisation d'un modèle de contrôle d'accès aux informations d'identification complique presque toujours la logique métier d'une application.

Il s'agit de la même infrastructure, dont l'abstraction est très difficile, et parfois impossible. Par conséquent, l'application doit être divisée en modules et, pour chaque module, analyser le besoin de prise en charge MAC. Peut-être est-ce dans votre cas qu'il suffit de prendre en charge le MAC dans un seul module, et cela n'a aucun sens à cause de ce module pour compliquer l'ensemble de l'application?
Si nous considérons un certain module abstrait (ou la totalité de l'application, si la division de l'application en modules n'est pas requise), les paradigmes suivants sont possibles:

• L'étiquette minimale. Le module traite les données dans le mode d'étiquette obligatoire minimale (l'étiquette minimale dans laquelle les processus du système d'exploitation fonctionnent - par exemple, 0 étiquette obligatoire) ou sans étiquette obligatoire.
• Une étiquette. Le module fonctionne avec les données d'une seule étiquette obligatoire au-dessus de l'étiquette minimale obligatoire (toute étiquette autre que celle dans laquelle les processus du système d'exploitation fonctionnent).
• Plusieurs balises. Le module fonctionne avec les données de plusieurs étiquettes obligatoires à la fois (à la fois l'étiquette dans laquelle les processus OS fonctionnent et d'autres étiquettes autres que l'étiquette de processus OS).

Les modules d'application avec différents paradigmes de traitement des informations d'identification ne devraient pas trop se connaître. Sinon, elle est lourde d'émergence de problèmes importants et imprévisibles concernant les conflits d'accès à divers objets, etc. L'idée d'une connectivité minimale pour les modules est évidente. Dans le cas de travailler avec MAC, vous devez être particulièrement vigilant et surveiller toutes les «connexions» des modules.
Ensuite, nous considérons plus en détail les fonctionnalités de conception avec trois paradigmes pour le traitement des informations d'identification. Pour ce faire, nous avons esquissé la classification du simple au complexe. Cette classification est purement pratique et appliquée. Il procède de différences intuitivement tangibles dans le développement de divers modules et, dans la pratique, a montré son efficacité.

Classification des modules par modes de traitement MAC

«BRING IT ON»: fonctionnement du module en mode minimum d'identification

Motivation pour implémenter ce mécanisme dans le module:

• Le module traite des informations qui, en principe, ne peuvent pas être traitées dans le système avec d'autres informations d'identification, et ne nécessite pas de privilèges de lecture / écriture spéciaux.
• Le module est étroitement lié à l'infrastructure du système d'exploitation, ce qui limite son fonctionnement dans le mode d'étiquette obligatoire, qui est différent du minimum.

Le module fonctionnant dans ce mode doit vérifier les informations d'identification du processus. Si le libellé du processus dans lequel ce module s'exécute est différent du minimum (par exemple, il ne correspond pas au libellé obligatoire 0), toutes les opérations (à l'exception de la visualisation) doivent être interdites au niveau de la logique métier de l'application. Autrement dit, nous ne pouvons tout simplement pas autoriser l'utilisateur à utiliser ce module s'il est venu nous voir lors d'une session avec un libellé d'identification différent de zéro.

Exemples de cas pratiques pour lesquels l'utilisation du mode d'étiquetage minimal obligatoire convient:

• Gérez les comptes d'utilisateurs dans le magasin d'applications. Par exemple, si l'application conserve son propre enregistrement d'échographie dans un fichier ou une base de données. Toutes les données liées à la sécurité et au contrôle d'accès de l'application doivent être stockées dans le mode d'informations d'identification minimales, sinon le modèle de sécurité de l'application "s'effondrera" simplement lorsque l'application s'exécutera en mode de marque d'informations d'identification. Pour cette raison, toutes les applications système s'exécutent strictement sous les informations d'identification minimales.
• Gestion des droits d'accès. Par exemple, si l'application implémente son propre modèle de contrôle d'accès au niveau de la logique métier.
• Gérez les paramètres de configuration des applications qui devraient être disponibles sous toutes les informations d'identification.
• Gestion des comptes sous OS. Si l'application doit gérer des attributs du KM dans le système d'exploitation, toutes les opérations doivent être effectuées strictement sous la marque d'identification minimale.

«HURT ME PLENTY»: fonctionnement du module en mode single credential

Ce cas est un peu plus compliqué, mais à bien des égards similaire au cas avec une note d'identification minimale. Du point de vue de l'utilisateur, travailler avec l'application ne change pas grand-chose: tout de même les listes familières d'enregistrements, de cartes et d'opérations «View», «Edit» et «Save». La seule différence est que dans ce mode, l'utilisateur ne voit que les enregistrements qui correspondent à la marque d'identification de sa session en cours.

Une option limitée peut également être développée: le module capture la valeur du paramètre «étiquette d'identification par défaut». Dans ce cas, le fonctionnement du module n'est possible qu'avec l'étiquette d'identification spécifiée, mais cette option est plus facile à implémenter.

Ce cas peut être utile dans les cas suivants:

• Il y avait une erreur dans l'architecture lors de la conception du module (les fonctionnalités de traitement des enregistrements dans le MAC n'étaient pas définies), et il n'y a pas de temps ni de ressources pour tout réécrire.
• La prise en charge du modèle de contrôle d'accès des informations d'identification est introduite dans une application déjà opérationnelle, et conformément aux exigences, il est nécessaire d'assurer le travail avec une étiquette supérieure au minimum dans le système d'exploitation. Oui, c'est le cas lorsque le responsable vient à vous et vous informe avec plaisir que nous avons gagné le concours et que nous mettrons en œuvre notre décision au «nom du service secret» !
• Il n'y a aucune raison de mettre en œuvre une prise en charge complète du traitement simultané des enregistrements de plusieurs informations d'identification. Il n'est pas nécessaire de traiter simultanément les enregistrements de plusieurs informations d'identification à la fois.
• L'application fonctionne en mode mono-utilisateur.

Du point de vue de la mise en œuvre, ce cas n'est pas très simple, car il nous faut:

• Sélectionnez uniquement les enregistrements qui correspondent à l'étiquette obligatoire actuelle, car selon le modèle Bell-Lapadula, l'utilisateur verra les enregistrements de l'étiquette obligatoire actuelle et toutes les étiquettes obligatoires situées plus bas dans la hiérarchie.
• Vérifiez la marque d'identification avant d'effectuer toute opération pour modifier l'enregistrement. Si vous essayez d'apporter une modification à une entrée avec une étiquette d'informations d'identification différente d'une étiquette d'informations d'identification pour une session, l'opération doit être abandonnée.

Lorsque vous effectuez des opérations dans le module, il est recommandé de vérifier l'étiquette des informations d'identification du processus de demande en cours avec l'étiquette des informations d'identification par défaut. Si l'étiquette des informations d'identification du module ne correspond pas à l'étiquette des informations d'identification de la session, l'utilisateur ne doit pas être autorisé à effectuer l'opération.

Exemples de cas pratiques pour lesquels l'utilisation du mode d'étiquette d'identification unique convient:

• . , ( , ..). , . .
• . , , ( ) . «» , « », «» .

«NIGHTMARE!»:

Ce mode de fonctionnement n'est utile que si, dans une session avec le module, nous devons afficher des informations sur toutes les informations d'identification situées sous les informations d'identification de la session en cours dans la hiérarchie.

Lors de la conception, il est nécessaire de décrire les exigences fonctionnelles du module, et dans les détails de chaque exigence fonctionnelle, d'indiquer la liste des interactions en termes de modèle obligatoire (les options possibles sont discutées ci-dessous dans la section «Interaction entre l'application et l'environnement»). Cela mettra en évidence certains concepts généraux d'interaction avec l'infrastructure concernant les balises obligatoires. De plus, ces informations seront extrêmement utiles pour évaluer la complexité du développement et des tests supplémentaires.

En termes d'implémentation de l'interface utilisateur, les modèles suivants sont couramment utilisés:

• (, ) ( ). , .
• / / , .
• / ( ).

Un autre ensemble de processus métier dépend de la complexité de la logique métier du module et des spécificités du traitement des données. Par exemple, vous pouvez filtrer la collection d'enregistrements par étiquette d'informations d'identification. Vous pouvez afficher l'étiquette d'enregistrement d'informations d'identification dans l'interface.

L'étendue des combinaisons est énorme, tout comme l'espace pour l'apparition d'erreurs. Par conséquent, il n'est pas recommandé de traiter les enregistrements avec une balise d'identification différente dans le même cas utilisateur en présence d'une logique métier. Toute opération de collecte d'enregistrements doit être effectuée avec une indication explicite des informations d'identification communes à l'ensemble de la collection. Traité la troisième marque, puis la seconde, etc.

Pour mettre en œuvre un tel régime, il est nécessaire de prévoir les fonctions suivantes:

• La fonction obtient l'étiquette d'identification du processus de demande en cours (session utilisateur).
• Fonction d'obtention d'une marque d'identification pour un enregistrement (s'il s'agit de travailler avec un enregistrement dans la base de données) ou d'un fichier (s'il s'agit de traiter des fichiers).
• Fonction de réception de l'étiquette d'identification des enregistrements / fichiers de la base de données dans la collection.

Exemples de cas pratiques pour lesquels le mode d'informations d'identification multiples convient:

1. Rapports Pour implémenter ce cas, nous devons accumuler un maximum d'informations sur le système, qui est disponible pour une session avec l'étiquette obligatoire actuelle.
2. Le magazine. Dans ce cas, une interface est développée pour visualiser toutes les opérations disponibles pour la visualisation avec la possibilité de filtrer, y compris par étiquette d'identification.

Interaction environnementale

Une application dans un environnement MAC interagit avec une liste spécifique de composants qui l'entourent. Schématiquement selon les caractéristiques de l'interaction, ils peuvent être classés comme suit:

• Système d'exploitation:
  
  • Paramètres du modèle d'informations d'identification:
    
    • La hiérarchie des étiquettes obligatoires OS;
    • Autorisations obligatoires (plages d'étiquettes qu'un utilisateur spécifique peut utiliser) Utilisateurs du système d'exploitation.
  • Stockage des informations d'identification de l'utilisateur
  • Authentification dans le système d'exploitation (y compris la prise en compte des informations d'identification);
  • Autres mécanismes de contrôle d'accès (POSIX ACL discrétionnaire, UNIX, etc.);
  • Travailler avec FS;
  • Gestion des processus;
  • Travailler avec un réseau;
• Logiciels tiers sans prise en charge MAC;
• Logiciels tiers avec prise en charge MAC:
  
  • SGBD (par exemple PostgreSQL):
    
    • Objets de base de données (cellules, lignes, colonnes, schémas, tableaux, bases de données, clusters, séquences, fonctions, etc.).
• Utilisateur

Nous considérerons les nuances d'interaction avec chacun des composants séparément.

Interaction d'une application compatible MAC avec le système d'exploitation

MAC est très «satisfait» de ses difficultés à définir des règles d'accès dans le système de fichiers. Par exemple, la part du lion des erreurs dans les applications MAC est liée au fait que l'application ne voit pas le fichier dans le mode de marque d'identification actuel, mais le fichier existe dans l'autre mode de marque d'identification (un niveau supérieur).

Qu'attendons-nous du système d'exploitation en termes de MAC?

Si notre application fonctionne en mode multi-utilisateurs, elle devra probablement demander des informations sur les comptes d'utilisateurs dont elle traite les données. Cela est nécessaire pour prendre en charge le contrôle d'accès utilisateur. Par conséquent, l'application devra demander au système d'exploitation des informations sur les informations d'identification de l'utilisateur. Si le KM de l'utilisateur dans le système d'exploitation est contrôlé par notre application, nous devons non seulement lire les informations sur le KM, mais également gérer les attributs du KM.

Les flux d'interactions les plus probables entre le système d'exploitation et l'application sont présentés dans le diagramme:

Interaction d'une application compatible MAC avec un logiciel tiers sans prise en charge MAC

La plupart des applications pouvant être utilisées dans un système d'exploitation avec un MAC ne savent pas comment traiter un MAC.

Par conséquent, lors de l'organisation d'une telle interaction, il est nécessaire d'émuler une étiquette d'informations d'identification lors du transfert de données ou de la demande du processus d'une telle application. Ceci est réalisé par la «stratification» du flux de données en canaux séparés, dont chacun est logiquement conçu pour les données avec une certaine étiquette obligatoire. Il est strictement interdit de mélanger de telles données; elles doivent passer par des files d'attente, des canaux séparés et presque par des fils séparés de paires torsadées vers des interfaces réseau. La validité de l'implémentation «logique» de la séparation des données par MAC est également un sujet controversé, par conséquent, le plus souvent, repose sur la conscience du client et du développeur d'application.

La possibilité d'utiliser une application sans MAC par une application s'exécutant en mode MAC dépend de la méthode d'interaction sélectionnée, de ses spécificités et des fonctionnalités de mise en œuvre du traitement des données entrantes dans l'application.

Interaction d'une application compatible MAC avec un logiciel tiers avec prise en charge MAC

Dans le cas d'une interaction avec un logiciel prenant en charge MAC, notre application doit clairement pouvoir lire l'étiquette du processus qui fait la demande et effectuer l'opération conformément au modèle de contrôle d'accès obligatoire. Une application qui interagit avec un tel logiciel n'est nécessaire que pour répondre aux demandes adressées à une application / un processus tiers à partir d'un processus portant la marque d'identification appropriée.

PostgresSQL est un exemple d'application populaire avec prise en charge complète des étiquettes obligatoires. Dans certaines variantes de livraison de ce SGBD, la prise en charge complète de MAC est implémentée pour certains systèmes d'exploitation dotés de mécanismes MAC, par exemple:

• Astra Linux: PostgreSQL, fourni avec la version du kit de distribution de SE.
• SELinux: extension sepgsql.

PostgreSQL vous permet de séparer les données par des étiquettes d'identification (il existe toujours un support pour les catégories d'informations d'identification, mais nous sommes intéressés par les étiquettes) aux niveaux suivants:

• Au niveau du cluster.
• Au niveau de la base de données de cluster.
• Au niveau du schéma de la base de données de cluster.
• Au niveau de la table du schéma de base de données de cluster.
• Au niveau de la colonne de la table de schéma de base de données du cluster.
• Au niveau de l'enregistrement de la table de schéma de base de données du cluster.

En conséquence, dans la mise en œuvre de MAC, nous obtenons une telle «poupée gigogne»: chaque niveau «parent» impose ses propres restrictions à tous les niveaux «enfant». Par conséquent, lors de la mise en œuvre d'une interaction avec chaque application similaire avec prise en charge complète de MAC, il est nécessaire de prendre en compte ses spécificités de travail. Il n'y a pas de recettes universelles.

Interopérabilité utilisateur d'une application compatible MAC

Peu importe à quel point cet aspect d'interaction peut paraître étrange par rapport à ceux considérés précédemment, il est impossible de ne pas s'y attarder. Après tout, c'est pour l'utilisateur que les applications avec support MAC sont le plus souvent construites, non?

Une application avec prise en charge MAC n'est pratiquement pas différente de celle sans MAC en termes d'interface utilisateur dans tous les modes, à l'exception du mode de travail simultané avec plusieurs informations d'identification.

Sur l'exemple des applications web courantes aujourd'hui, les cas suivants se trouvent le plus souvent:

Conclusions

Nous avons examiné plusieurs aspects du développement d'une application avec prise en charge MAC. Il est bien sûr difficile de prévoir tous les cas. La plupart des fonctionnalités du modèle d'informations d'identification dépendent de l'implémentation disponible pour une utilisation dans le système d'exploitation sélectionné.

La prise en charge de l'application MAC n'est pas une «fonctionnalité» supplémentaire de l'application. Il s'agit d'une solution architecturale sérieuse qui nécessite une planification et une conception. La plus grande «douleur» pour le concepteur d'une application compatible MAC:

• interaction avec l'infrastructure du système d'exploitation (système de fichiers, interactions réseau, démarrage des processus avec l'étiquette d'identification souhaitée au cas où l'application serait exécutée sur le serveur);
• interaction avec un logiciel d'application avec prise en charge MAC intégrée (par exemple, SGBD);
• interaction de l'utilisateur concernant le traitement correct des opérations compatibles MAC.

C'est tout pour l'instant! Les ajouts, l'expérience personnelle et les commentaires sur l'article sont les bienvenus!