サブジェクト、ユーザー、プリンシパルの意味と違いは何ですか?


173

セキュリティフレームワークのコンテキストでは、サブジェクトユーザープリンシパルなどのいくつかの用語が一般的に使用されますが、明確な定義とそれらの違いを見つけることができませんでした。

だから、正確にこれらの用語の意味を行うと、なぜこれらの区別されている主題プリンシパルが必要?

回答:


277

これらは、属、種、個体が階層的であるように階層的です。

  • サブジェクト -セキュリティコンテキストでは、サブジェクトオブジェクトへのアクセスを要求するエンティティです。これらは、アクセスを要求するものと要求に対して行われるものを表すために使用される一般的な用語です。アプリケーションにログオンすると、あなたが主体となり、アプリケーションがオブジェクトになります。誰かがあなたのドアをノックすると、訪問者はアクセスを要求する主体であり、あなたの家はアクセスが要求されるオブジェクトです。
  • プリンシパル - アカウント、ロール、またはその他の一意の識別子によって表されるサブジェクトのサブセット。実装の詳細レベルに到達すると、プリンシパルはアクセス制御リストで使用する一意のキーです。これらは、人間のユーザー、自動化、アプリケーション、接続などを表す場合があります。
  • ユーザー - 通常は人間のオペレーターを指すプリンシパルのサブセット。「ユーザー」または「ユーザーID」という単語は一般に「アカウント」に置き換えられるため、時間の経過とともに区別が曖昧になります。ただし、プリンシパルであるものと、それらのサブセットを非決定論的な方法でトランザクションを駆動するインタラクティブなオペレーターであるものと区別する必要がある場合、「ユーザー」が正しい言葉です。

サブジェクト/オブジェクトは、文法で使用されるのと同じ用語を継承します。文では、主語は俳優で、主語は演じられるものです。この意味で、コンピューターが発明される前から使用されています。セキュリティコンテキストでは、サブジェクトは要求を行うことができるすべてのものです。上記のように、これはITセキュリティに限定される必要はないため、非常に広い分類になります。興味深いのは、主語が目的を意味するということです。オブジェクトがなければ、主題はありません。

プリンシパルは、被験者が解決するものです。クレジットカードを提示すると、あなたが主体となり、口座番号が本人となります。他のコンテキストでは、ユーザーIDまたは州発行のIDがプリンシパルです。しかし、プリンシパルは、人間ではない多くのタイプのサブジェクトに関連付けることができます。アプリケーションがシステムレベルの機能を要求する場合、プリンシパルは署名された実行可能コードモジュールの署名者である場合がありますが、その場合でも、要求を駆動するユーザーが対象になります。

ユーザーは、主に対話型のオペレーターを指すという点で、件名や主体よりも具体的です。これが、グラフィカルプリンシパルインターフェースではなく、グラフィカルユーザーインターフェースがある理由です。ユーザーは、プリンシパルに解決されるサブジェクトのインスタンスです。1人のユーザーは任意の数のプリンシパルに解決できますが、すべてのプリンシパルは1人のユーザーに解決されることが予想されます(IDを共有しないという要件を人々が遵守していると想定)。上記の例では、実行可能コードモジュールの署名者は間違いなくユーザーではありませ、有効なプリンシパルです。モジュールをロードしようとする対話式オペレーターはユーザーです。

コメントに記載されているように、信頼できる情報源でさえこれらの条件に同意していません。この応答を準備している間、私はNIST、SANS、IEEE、MITRE、およびセキュリティ試験ガイドなどのいくつかの「準信頼できる」情報源を検索しました。少なくとも準信頼できるものであると私が見つけた単一の情報源は、3つすべての用語をカバーしておらず、それらの使用法はすべて大幅に異なっていました。これは、用語がどのように私のテイクである必要があります使用することが、実用上の観点から、あなたが夜中に取扱説明書を熟読の上にされている場合、定義はベンダーやライターは、彼らが言う何でもする傾向があります。うまくいけば、ここでの応答が水をナビゲートし、これらの用語を使用してセキュリティドキュメントを解析するのに十分な洞察を提供することを願っています。


3
サブジェクト、プリンシパル、ユーザーに分解するとどのような利点がありますか?その追加の複雑さこの追加の複雑さから得られる利点は何ですか?
AMS

19
適切なレベルの特異性を選択する機能。これは、宛先とキューまたはトピックを区別できることから得られる利点と同じです。分類法で異なるレベルの特異性を選択する機能により、ライターの意図をリーダーに伝えるコミュニケーションの精度を高めることができます。プログラミング時には、CPUが命令を一方向にのみ解釈するという贅沢な呪いがあり、そのレベルの精度を使用せざるを得ません。しかし、人間の言語では、意味を効率的に伝えるためにニュアンスと正確さが必要です。
T.Rob

1
T.Rob、素晴らしいですが、「ユーザー-プリンシパルのサブセット」を明確にできますか?ジョンが件名で「アカウント#123」が彼のプリンシパルである場合、ユーザーは誰ですか。ジョンは2人いますか?Genus> Species> Individualはますます具体的であるため、John(ユーザー)はJohn(対象)よりも具体的である必要があります。それとも何か不足していますか?
mellow-yellow

1
#123がJohnで、#124がサービスアカウントを指す2つのプリンシパルを考えます。パスワードポリシー、ログイン機能などの点で、これらを異なる方法で処理する必要があります。「ユーザー」タイプのプリンシパルはパスワードの複雑さと有効期限ポリシーの影響を受けますが、「サービスアカウント」タイプのプリンシパルはパスワードを持たない場合もあります。プリンシパルのタイプの分類を開始すると、サブセットを作成します。それは役に立ちますか?それとも泥をかき混ぜたか?
T.Rob

はい、それは役立ちます。だから、具体的には、以下の修正はありますか?それをコピーしてNotepad ++のようなエディターに貼り付け、各Johnの前に改行を入れることができます(SOはコメントに改行を許可しません): 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

用語はJAASから取ったものだと思います。

アプリケーションがJAAS認証を使用してユーザー(またはサービスなどの他のエンティティ)を認証すると、結果としてサブジェクトが作成されます。サブジェクトの目的は、認証されたユーザーを表すことです。サブジェクトは一連のプリンシパルで構成され、各プリンシパルはそのユーザーのIDを表します。たとえば、サブジェクトの名前はプリンシパル( "スーザンスミス")と社会保障番号のプリンシパル( "987-65-4321")にすることができるため、このサブジェクトを他のサブジェクトと区別できます。


2
私は以前にこの定義を見ましたが、その密度が高すぎます。特に、ユーザーとプリンシパルとの違い、ユーザーだけでなくサブジェクトという用語が使用される理由について詳しく説明できますか。これらの用語がJAASを超えた意味を持つ場合、その意味に精通したいと思います。これらの用語がJAASの発明である場合、これらの概念を作成したSunエンジニアは、これらの概念が意味するものには何でもない名前を選んだと思います。私はかなりの数のプログラマーにこの質問をしてきましたが、明確な答えを得ることができませんでした。誰もがこれらの用語について異なる理解を持っているようです。
AMS

プリンシパルはサブジェクトを識別するための1つの方法にすぎないようです。言い換えれば、どのプリンシパルも理論的にはユーザーデータベースの主キーとして機能する可能性があります。
Platinum Azure

3
レキシコンは、JAASよりもずっと前から存在しています。JAASはその一部を再利用するだけで、時には非標準的な方法で再利用します。この質問のきっかけとなった問題の一部は、用語が使用されているコンテキストから概念が学習され、わずかに異なる方法で再利用されていることです。信頼できる情報源を見つけるのが難しい、または単に無視されている場合、意味は時間とともにドリフトします。精度が絶対要件であるセキュリティに関しては、このあいまいさへのドリフトは、安全な設計を構築および実装する当社の能力を低下させます。
T.Rob

@ T.Robは、共有できる論文のタイトル、または信頼できる参照を提供します。
AMS

残念ながら、権威ある情報源でさえ意見が異なります。SANSはプリンシパルまたはサブジェクトをまったく定義していません。bit.ly / hl4rUPおよびNIST bit.ly/fE7NJsはサブジェクトを特定の人物として定義しています。他の「信頼できる」情報源も同様に曖昧であり、この分野での明確さの重要性を考えると、かなりがっかりしています。IEEには用語集がありますが、メンバーシップまたはサブスクリプションでしか読むことができないため、幅広い聴衆とのディスカッションでの使用は制限されています。回答の一部は、Shon HarrisのCISSP Exam Guideに基づいていました。
T.Rob

12

サブジェクトは、サービスを要求するエンティティです。これは、ユーザーまたはプロセスです。おそらくそれが、ユーザーではなくサブジェクトという名前が選ばれた理由です。

サブジェクトがサービスにアクセスしようとするとき、サブジェクトは最初に認証される必要があります。認証が成功すると、そのサブジェクトのセキュリティプリンシパルがロードされます。たとえば、役割ベースのアクセス制御システムでは、認証された(ログインした)ユーザーには通常、userIdとroleIdの2つのプリンシパルがあります。そのようなシステムでは、特権(つまり、誰が何にアクセスできるか)は、ロールとユーザーの両方に指定されます。承認中(つまり、要求されたサービスを許可する必要があるかどうかのチェック)、セキュリティシステムは両方のプリンシパルに対するアクセス可能性をチェックします。

したがって、承認の観点から見ると、プリンシパルはアクセスが許可または拒否される実際のエンティティです。サブジェクトは、いくつかのプリンシパルを保持するユーザー/スレッド/プロセスです。


主題ごとに複数の原則を持つことの利点は何ですか?
AMS

6
(1)プリンシパルUserId( "Alice")、Role( "Manager")、Department( "Sales")を持つユーザーAliceがサービス(オブジェクト)にアクセスするとします。サービスのアクセス制御は、Aliceがアクセスできるかどうかを指定する代わりに、「Allow for Role(Manager)」や「Disallow for Department(Sales)」などとして指定できます。このような種類のアクセス制御システムは、セキュリティ管理者がすべてのサービスのすべてのユーザーにアクセス権限を指定する必要がないため、管理が簡単です。
rahulmohan

4
(2)エンタープライズシステムでは、複合サービスを実行する前に、ユーザーは通常複数のシステムで認証される必要があります。これらのシステムのそれぞれに、異なる詳細を必要とする独自のアクセス制御メカニズムがある場合があります。1つのシステムはSSNを使用し、別のシステムはuserIdを使用します。したがって、同じサブジェクトが両方にアクセスするには、両方のプリンシパルを所有している必要があります
rahulmohan

1
この用語の混乱の99%は、「プリンシパルは基本的にグループである」という言葉に沿って1文で解決できると感じています。
トレイカズ2013年

1
?!...プリンシパルがグループであると言うのはなぜですか?
ラファエル

10

T.Robが説明したように、Subjectはオブジェクトへのアクセスを要求するエンティティです。その時点から、私はjavax.security.auth.Subjectコードに関するコメントを見つけました。非常に便利で理解しやすいコードです。

「サブジェクトは複数のアイデンティティを持つ可能性があります。各アイデンティティはサブジェクト内のプリンシパルとして表されます。プリンシパルは単にサブジェクトに名前をバインドします。たとえば、人であるサブジェクトのアリスは2つのプリンシパルを持つ可能性があります。彼女の運転免許証上の名前である「アリスバー」とサブジェクトの別の名前、および「999-99-9999」(彼女の学生IDカード上の番号)をサブジェクトにバインドします。どちらのプリンシパルも、それぞれが同じサブジェクトを参照します別の名前です。」

それが役に立てば幸い。


7

これは、Oracle JAVA SEドキュメントからの以下の説明へのリンクです。

サブジェクト、プリンシパル、認証、および資格情報リソースへのアクセスを承認するには、まずアプリケーションがリクエストのソースを認証する必要があります。JAASフレームワークでは、リクエストのソースを表すサブジェクトという用語を定義しています。サブジェクトは、個人やサービスなどの任意のエンティティです。サブジェクトは、javax.security.auth.Subjectクラスによって表されます

認証は、サブジェクトのIDが検証されるプロセスを表し、安全な方法で実行する必要があります。そうでなければ、加害者はシステムにアクセスするために他人になりすます可能性があります。認証には通常、サブジェクトがその身元を証明する何らかの形の証拠を示すことが含まれます。そのような証拠は、対象だけが知っているまたは持っている可能性が高い情報(パスワードや指紋など)、または対象だけが生成できる情報(秘密キーを使用した署名付きデータなど)の場合があります。

認証されると、サブジェクトには関連するIDまたはプリンシパルjava.security.Principalタイプ)が入力されます。サブジェクトは多くのプリンシパルを持つことができます。たとえば、人には、プリンシパル( "John Doe")とSSNプリンシパル( "123-45-6789")という名前があり、他のサブジェクトと区別されます。

サブジェクトは、関連付けられたプリンシパルに加えて、資格情報と呼ばれるセキュリティ関連の属性を所有する場合があります。クレデンシャルには、新しいサービスの対象を認証するために使用される情報が含まれる場合があります。このような資格情報には、パスワード、Kerberosチケット、および公開鍵証明書が含まれます。資格情報には、サブジェクトが特定のアクティビティを実行できるようにするデータが含まれている場合もあります。たとえば、暗号化キーは、サブジェクトがデータに署名または暗号化できるようにする資格情報を表します。パブリックおよびプライベートの資格情報クラスは、コアJ2SE APIの一部ではありません。したがって、どのクラスでも資格を表すことができます。


T.Robの回答には同意しますが、これはAramからのものであり、「サブジェクトは任意のエンティティである可能性があります」とERMをほのめかしています。ほとんどのデータベースを支えるエンティティリレーションシップモデルです。そのモデルでは、セキュリティのコンテキストで「エンティティ」は「サブジェクト」に対応しますが、モデリングする内容によっては、Marinusで提案されているように、プリンシパル(銀行口座、SSN#)またはユーザー(John Smith)になる場合があります。 '答え。ウィキペディア: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
mellow-yellow

0

rahulmohanによると、私は、認証がサブジェットになる前、認証がプリンシパルになった後、本質的に、サブジェットは多くのプリンシパルを持つことができると思います

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.