Quelle est la signification et la différence entre sujet, utilisateur et principal?


173

Dans le contexte des cadres de sécurité, quelques termes surviennent couramment sujet , utilisateur et principal , dont je n'ai pas pu trouver une définition claire et la différence entre eux.

Alors, que signifient exactement ces termes, et pourquoi ces distinctions de sujet et de principal sont-elles nécessaires?

Réponses:


277

Celles-ci sont hiérarchiques dans la mesure où le genre, l'espèce et l'individu sont hiérarchiques.

  • Sujet - Dans un contexte de sécurité, un sujet est toute entité qui demande l'accès à un objet . Ce sont des termes génériques utilisés pour désigner la chose qui demande l'accès et la chose contre laquelle la demande est faite. Lorsque vous vous connectez à une application, vous êtes le sujet et l'application est l'objet. Quand quelqu'un frappe à votre porte, le visiteur est le sujet qui demande l'accès et votre maison est l'objet dont l'accès est demandé.
  • Principal - Un sous-ensemble de sujet qui est représenté par un compte, un rôle ou un autre identifiant unique. Lorsque nous arrivons au niveau des détails d'implémentation, les principaux sont les clés uniques que nous utilisons dans les listes de contrôle d'accès. Ils peuvent représenter des utilisateurs humains, des automatismes, des applications, des connexions, etc.
  • Utilisateur - Un sous-ensemble de principal faisant généralement référence à un opérateur humain. La distinction s'estompe avec le temps car les mots «utilisateur» ou «ID utilisateur» sont généralement remplacés par «compte». Cependant, lorsque vous avez besoin de faire la distinction entre la grande classe de choses qui sont des mandants et le sous-ensemble de ceux-ci qui sont des opérateurs interactifs conduisant des transactions de manière non déterministe, "utilisateur" est le mot juste.

Le sujet / objet hérite des mêmes termes que ceux utilisés dans la grammaire. Dans une phrase, le sujet est l'acteur et l'objet est la chose sur laquelle on agit. En ce sens, l'utilisation existe depuis avant l'invention des ordinateurs. Dans un contexte de sécurité, un sujet est tout ce qui peut faire une demande. Comme indiqué ci-dessus, cela ne doit pas être limité à la sécurité informatique et est donc une classification très large. Ce qui est intéressant, c'est que le sujet implique un objet. Sans objet, il n'y a pas de sujet.

Les directeurs sont ce à quoi les sujets se résolvent. Lorsque vous présentez votre carte de crédit, vous êtes le sujet et le numéro de compte est le principal. Dans d'autres contextes, votre identifiant d'utilisateur ou votre identification émise par l'État est votre principal. Mais les directeurs peuvent être associés à de nombreux types de sujets qui ne sont pas des personnes. Lorsque des applications font des demandes pour des fonctions au niveau du système, le mandant peut être le signataire d'un module de code exécutable signé mais même dans ce cas, l'utilisateur qui dirige la demande est toujours le sujet.

L'utilisateur est plus spécifique que le sujet ou le principal en ce qu'il fait généralement référence à un opérateur interactif. C'est pourquoi nous avons une interface utilisateur graphique et non une interface graphique principale. Un utilisateur est une instance de sujet qui se résout en un principal . Un seul utilisateur peut se résoudre à n'importe quel nombre de principaux, mais on s'attend à ce que tout principal soit résolu en un seul utilisateur (en supposant que les gens respectent l'exigence de ne pas partager d'ID). Dans l'exemple ci - dessus, le signataire d'un module de code exécutable est certainement pas l'utilisateur, mais il est un principe valide. L'opérateur interactif essayant de charger le module est l'utilisateur.

Comme indiqué dans les commentaires, même les sources faisant autorité ne sont pas d'accord sur ces termes. J'ai recherché le NIST, le SANS, l'IEEE, le MITRE et plusieurs sources «quasi-faisant autorité» telles que les guides d'examen de sécurité lors de la préparation de cette réponse. Aucune source unique que j'ai trouvée qui était au moins quasi-faisant autorité ne couvrait les trois termes et tous différaient considérablement dans leur utilisation. C'est mon point de vue sur la façon dont les termes doivent être utilisés, mais d'un point de vue pratique, lorsque vous vous penchez sur un manuel au milieu de la nuit, les définitions ont tendance à être ce que le vendeur ou l'auteur dit qu'elles sont. Espérons que les réponses fournies ici fourniront suffisamment d'informations pour naviguer dans les eaux et analyser tout document de sécurité utilisant ces termes.


3
Quel est l'avantage de décomposer les choses en sujet, principal, utilisateur, sa complexité supplémentaire, quel avantage retirons-nous de cette complexité supplémentaire?
ams le

19
La possibilité de choisir le bon niveau de spécificité. C'est le même avantage que nous tirons de la possibilité de faire la distinction entre une destination et une file d'attente ou un sujet. La possibilité de choisir entre différents niveaux de spécificité dans une taxonomie permet une précision d'expression qui communique mieux l'intention d'un écrivain à un lecteur. Lors de la programmation, nous avons le luxe / la malédiction que le CPU interprète nos instructions d'une seule manière et nous sommes obligés d'utiliser son niveau de précision. Mais dans le langage humain, nous avons besoin de nuances et de précision pour transmettre le sens efficacement.
T.Rob

1
T.Rob, génial, mais pourriez-vous clarifier "Utilisateur - sous-ensemble du principal"? Si Jean est le sujet et "compte # 123" est son principal, l'utilisateur est qui? Y a-t-il deux John's? Puisque Genre> Espèce> Individu est de plus en plus spécifique, John (utilisateur) devrait être plus spécifique que John (sujet). Ou est-ce que je manque quelque chose?
jaune moelleux du

1
Considérez deux principaux où # 123 est John et # 124 fait référence à un compte de service. Nous voulons probablement traiter ces différentes choses en ce qui concerne la politique de mot de passe, la capacité de connexion, etc. Les principaux de type «utilisateur» sont soumis à la complexité des mots de passe et les politiques d'expiration alors que les principaux de type «compte de service» peuvent même ne pas avoir de mot de passe. Lorsque nous commençons à catégoriser les types de mandants, nous créons des sous-ensembles. Est ce que ça aide? Ou ai-je simplement remué plus de boue?
T.Rob

Oui, ça aide. Alors, concrètement, des corrections à ce qui suit? Vous voudrez peut-être le copier et le coller dans un éditeur comme Notepad ++ et mettre un saut de ligne avant chaque John (SO interdit les sauts de ligne dans les commentaires): John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER John (human) SUBJECT > username_1 PRINCIPAL > smartcard_1 USER John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
mellow-yellow


19

Je pense que la terminologie est tirée de JAAS .

Lorsqu'une application utilise l'authentification JAAS pour authentifier l'utilisateur (ou une autre entité telle qu'un service), un sujet est créé en conséquence. Le but du sujet est de représenter l'utilisateur authentifié. Un sujet est composé d'un ensemble de principaux , où chaque principal représente une identité pour cet utilisateur. Par exemple, un sujet peut avoir un nom principal ("Susan Smith") et un numéro de sécurité sociale principal ("987-65-4321"), distinguant ainsi ce sujet des autres sujets.


2
J'ai déjà vu cette définition, elle est trop dense, pouvez-vous nous en dire plus, en particulier en quoi un utilisateur est différent d'un mandant, pourquoi le terme sujet est utilisé et pas seulement utilisateur. Si ces termes ont une signification au-delà de JAAS, je veux vraiment me familiariser avec cette signification, si ces termes sont des inventions de JAAS, alors je suppose que les ingénieurs Sun qui l'ont créé ont choisi de mauvais noms pour ce que ces concepts signifient. J'ai posé ces questions à plusieurs programmeurs et je n'ai pas pu obtenir de réponses claires, chacun semble avoir une compréhension différente de ces termes.
ams le

On dirait qu'un directeur n'est qu'une façon d'identifier un sujet. En d'autres termes, n'importe quel Principal pourrait théoriquement servir de clé primaire sur votre base de données utilisateur.
Platinum Azure

3
Le lexique est antérieur à JAAS de loin. JAAS n'en réutilise qu'une partie et parfois de manière non standard. Une partie du problème qui a soulevé cette question est que les concepts sont appris à partir des contextes dans lesquels la terminologie est utilisée, puis réutilisés de manière légèrement différente. Lorsque les sources faisant autorité sont difficiles à trouver ou simplement ignorées, les significations dérivent avec le temps. Lorsqu'il s'agit de sécurité où la précision est une exigence absolue, cette dérive vers l'ambiguïté dégrade notre capacité à construire et à mettre en œuvre des conceptions sécurisées.
T.Rob

@ T.Rob vous donne des titres papier ou des références faisant autorité que vous pouvez partager.
ams le

Malheureusement, même les sources faisant autorité ne sont pas d'accord. SANS ne définit pas du tout le principal ou le sujet bit.ly/hl4rUP et NIST bit.ly/fE7NJs définit le sujet spécifiquement comme une personne. D'autres sources «faisant autorité» sont également vagues, ce qui, compte tenu de l'importance de la clarté dans ce domaine, est plutôt décevant. L'IEE a un glossaire, mais vous ne pouvez le lire qu'avec une adhésion ou un abonnement, il a donc une utilisation limitée dans une discussion avec un large public. Je fondais ma réponse en partie sur le guide d'examen CISSP de Shon Harris.
T.Rob

12

Le sujet est l'entité qui demande un service. Cela peut être un utilisateur ou un processus. C'est probablement pour cette raison que le nom Sujet a été choisi à la place de l'utilisateur.

Lorsqu'un sujet tente d'accéder à un service, il doit d'abord être authentifié. L'authentification réussie se termine par le chargement des principaux de sécurité pour ce sujet. Par exemple, dans un système de contrôle d'accès basé sur les rôles, un utilisateur authentifié (connecté) aura généralement deux principaux - userId et roleId. Dans de tels systèmes, les privilèges (c'est-à-dire qui peut accéder à quoi) sont spécifiés à la fois pour les rôles et pour les utilisateurs. Pendant l'autorisation (c.-à-d. Vérifier si le service demandé doit être autorisé), le système de sécurité vérifie l'accessibilité par rapport aux deux principaux.

Par conséquent, du point de vue de l'autorisation, les principaux sont les entités réelles pour lesquelles l'accès est autorisé ou interdit. Le sujet est juste un utilisateur / thread / processus qui contient certains principaux.


Quel est l'avantage d'avoir plusieurs principes par sujet?
ams le

6
Je peux penser à deux avantages: (1) Considérez l'utilisateur Alice avec les principaux UserId ("Alice"), Role ("Manager"), Department ("Sales") accédant à un service (l'objet). Le contrôle d'accès au service peut alors être spécifié comme «Autoriser pour le rôle (Manager)» ou «Interdire pour le service (Ventes)» etc. au lieu de spécifier si Alice peut y accéder ou non. Ce type de système de contrôle d'accès est plus facile à gérer car l'administrateur de sécurité n'a pas besoin de spécifier les privilèges d'accès pour TOUS les utilisateurs pour TOUS les services.
rahulmohan

4
(2) Dans un système d'entreprise, les utilisateurs doivent généralement être authentifiés auprès de plusieurs systèmes avant qu'un service composite puisse être exécuté. Il se peut que chacun de ces systèmes ait ses propres mécanismes de contrôle d'accès nécessitant des détails différents - un système utilise SSN et un autre utilise userId. Ainsi, le même sujet doit posséder les deux principes pour accéder aux deux
rahulmohan

1
J'ai le sentiment que 99% de la confusion avec cette terminologie pourrait être résolue avec une phrase du type «un directeur est fondamentalement un groupe».
Trejkaz

1
?! ... pourquoi dites-vous qu'un directeur est un groupe?
Rafael le

10

Comme T.Rob l'a expliqué, Subject est toute entité qui demande l'accès à un objet. À partir de là, j'ai trouvé un commentaire sur le code javax.security.auth.Subject que j'ai trouvé TRÈS utile et facile à comprendre:

"Les sujets peuvent potentiellement avoir plusieurs identités. Chaque identité est représentée comme un principal dans le sujet. Les principaux lient simplement les noms à un sujet. Par exemple, un sujet qui se trouve être une personne, Alice, peut avoir deux principaux: un qui lie" Alice Bar ", le nom sur son permis de conduire, au sujet, et un autre qui lie," 999-99-9999 ", le numéro sur sa carte d'étudiant, au sujet. Les deux directeurs font référence au même sujet même si chacun a un nom différent. "

J'espère que ça aide.


7

Voici le lien pour l'explication ci-dessous à partir de la documentation Oracle JAVA SE.

Sujets, principaux, authentification et informations d'identification Pour autoriser l'accès aux ressources, les applications doivent d'abord authentifier la source de la demande. Le cadre JAAS définit le terme sujet pour représenter la source d'une demande. Un sujet peut être n'importe quelle entité, telle qu'une personne ou un service. Un sujet est représenté par javax.security.auth.Subject classe .

L'authentification représente le processus par lequel l'identité d'un sujet est vérifiée et doit être effectuée de manière sécurisée; sinon, un auteur peut se faire passer pour d’autres pour avoir accès à un système. L'authentification implique généralement que le sujet démontre une forme de preuve pour prouver son identité. Ces preuves peuvent être des informations que seul le sujet connaîtrait ou détiendrait (comme un mot de passe ou une empreinte digitale), ou il peut s'agir d'informations que seul le sujet pourrait produire (comme des données signées à l'aide d'une clé privée).

Une fois authentifié, un sujet est rempli avec les identités associées, ou principaux (de type java.security.Principal ). Un sujet peut avoir plusieurs directeurs. Par exemple, une personne peut avoir un nom principal ("John Doe") et un principal SSN ("123-45-6789"), qui la distinguent des autres sujets.

En plus des principaux associés, un sujet peut posséder des attributs liés à la sécurité, qui sont appelés informations d' identification . Un justificatif d'identité peut contenir des informations utilisées pour authentifier le sujet auprès de nouveaux services. Ces informations d'identification incluent les mots de passe, les tickets Kerberos et les certificats de clé publique. Les informations d'identification peuvent également contenir des données permettant au sujet d'effectuer certaines activités. Les clés cryptographiques, par exemple, représentent des informations d'identification qui permettent au sujet de signer ou de crypter des données. Les classes d'informations d'identification publiques et privées ne font pas partie de l'API J2SE principale. Toute classe peut donc représenter un justificatif.


Bien que je sois d'accord avec la réponse de T.Rob, celle d'Aram - qui dit "un sujet peut être n'importe quelle entité" - fait allusion à ERM: le modèle entité-relation qui sous-tend la plupart des bases de données. Dans ce modèle, "entité" correspond à "sujet" dans le contexte de la sécurité, mais selon ce que vous modélisez, il peut s'agir du principal (compte bancaire, n ° SSN) ou de l'utilisateur (John Smith), comme suggéré dans Marinus ' répondre. Wikipédia: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
mellow-yellow

0

selon rahulmohan , je pense, avant que l'authentification ne soit soumise, après que l'authentification soit pricipale, par différence de sens, un sujet peut avoir plusieurs

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.