주제, 사용자 및 교장의 의미와 차이점은 무엇입니까?


173

보안 프레임 워크의 맥락에서, 몇 가지 용어는 일반적으로 발생하는 주제 , 사용자주요 내가 명확한 정의와 그들 사이의 차이를 찾을 수 없어 어느를.

그렇다면이 용어들은 정확히 무엇을 의미하며, 왜 이러한 주제교장의 구별이 필요한가?

답변:


277

이들은 속, 종 및 개인이 계층적인 방식으로 계층 적입니다.

  • 주제 - 보안 컨텍스트에서 주제는 에 대한 액세스를 요청하는 엔티티 객체 . 액세스를 요청하는 것과 요청이 이루어진 것을 나타내는 데 사용되는 일반적인 용어입니다. 응용 프로그램에 로그온하면 대상이되고 응용 프로그램이 개체입니다. 누군가가 당신의 문을 두드리면 방문자는 접근을 요청하는 대상이고 당신의 집은 객체 접근이 요청됩니다.
  • 교장 - 계정, 역할 또는 기타 고유 식별자로 표시되는 주제 의 하위 집합입니다 . 구현 세부 사항 수준에 도달하면 보안 주체는 액세스 제어 목록에서 사용하는 고유 키입니다. 인간 사용자, 자동화, 응용 프로그램, 연결 등을 나타낼 수 있습니다.
  • 사용자 - 일반적으로 휴먼 오퍼레이터를 지칭하는 프린시 펄의 서브 세트입니다 . "user"또는 "user ID"라는 단어는 일반적으로 "account"와 상호 교환되므로 시간이 지남에 따라 구분이 흐리게 표시됩니다. 그러나 주체 인 광범위한 클래스 와 대화식 연산자가 비 결정적 방식으로 트랜잭션을 수행하는 이들 중 일부를 구별해야하는 경우 "사용자"가 올바른 단어입니다.

주제 / 객체는 문법에서 사용 된 것과 동일한 용어를 상속합니다. 문장에서 주제는 배우이고 대상은 행동하는 것입니다. 이런 의미에서 컴퓨터가 발명되기 전부터 사용되었습니다. 보안 컨텍스트에서 주제는 요청을 할 수있는 모든 것입니다. 위에서 언급했듯이 이는 IT 보안에만 국한 될 필요가 없으며 매우 광범위한 분류입니다. 흥미로운 것은 주제가 대상을 암시한다는 것입니다. 물체가 없으면 주제가 없습니다.

교장은 주제를 해결합니다. 신용 카드를 제시 할 때 당신은 주제이며 계좌 번호는 교장입니다. 다른 상황에서는 사용자 ID 또는 주에서 발행 한 신원이 본인의 주체입니다. 그러나 교장은 사람이 아닌 많은 유형의 주제와 관련 될 수 있습니다. 응용 프로그램이 시스템 레벨 기능에 대한 요청을하는 경우, 프린시 펄은 서명 된 실행 가능 코드 모듈의 서명자 일 수 있지만이 경우에도 요청을 수행하는 사용자는 여전히 주제입니다.

사용자는 일반적으로 대화식 운영자를 참조한다는 점에서 주제 또는 보안 주체보다 더 구체적입니다. 그렇기 때문에 그래픽 사용자 인터페이스가 아닌 그래픽 사용자 인터페이스가 있습니다. 사용자는의 인스턴스 대상 A와 해결합니다 교장 . 단일 사용자는 여러 보안 주체로 해결할 수 있지만 모든 사용자는 단일 사용자로 해결할 것으로 예상됩니다 (사람들이 ID를 공유하지 않아야한다는 요구 사항을 준수한다고 가정). 위의 예에서, 실행 코드 모듈의 서명자는 확실히 없는 사용자, 그러나 그것은 이다 유효한 주요. 모듈을로드하려고하는 대화식 연산자는 사용자입니다.

의견에서 언급했듯이 권위있는 출처 조차도이 용어에 동의하지 않습니다. 이 응답을 준비하는 동안 NIST, SANS, IEEE, MITER 및 보안 시험 가이드와 같은 몇 가지 "지정 인증"소스를 검색했습니다. 적어도 준 권위적 인 것으로 밝혀진 단일 소스는 세 용어를 모두 다루었으며 사용법에서 크게 달랐습니다. 이것은 용어를 어떻게 사용 해야하는지 에 대한 나의 견해 이지만, 한밤중에 매뉴얼을 숙독 할 때 실제적인 관점에서 볼 때 정의는 공급 업체 또는 작가가 말한대로하는 경향이 있습니다. 여기서 응답이 물을 탐색하고 이러한 용어를 사용하여 보안 문서를 구문 분석하는 데 충분한 통찰력을 제공하기를 바랍니다.


3
Subject, Principal, User, 추가 복잡성으로 나누는 것의 이점은 무엇입니까?이 추가 복잡성으로 인해 어떤 이점이 있습니까?
ams

19
적절한 수준의 특이성을 선택할 수있는 능력. 목적지와 대기열 또는 주제를 구별 할 수 있다는 이점이 있습니다. 분류법에서 다른 수준의 특이성을 선택할 수있는 능력은 작가의 의도를 독자에게 더 잘 전달하는 표현의 정확성을 허용합니다. 프로그래밍 할 때 CPU가 명령어를 한 가지 방식으로 만 해석 할 수 있다는 사치 / 저주가 있으며, 정확한 수준으로 사용해야합니다. 그러나 인간 언어로 의미를 효율적으로 전달하려면 뉘앙스와 정밀함이 필요합니다.
T.Rob

1
T.Rob, 굉장하지만 "사용자-프린시 펄의 서브 세트"를 명확히 할 수 있습니까? John이 주제이고 "계정 # 123"이 그의 주체 인 경우 사용자는 누구입니까? 두 요한이 있습니까? 속> 종> 개인이 점점 더 구체적이되기 때문에 John (사용자)은 John (대상)보다 더 구체적이어야합니다. 아니면 뭔가 빠졌습니까?
부드러운 노랑

1
# 123이 John이고 # 124가 서비스 계정을 나타내는 두 가지 원칙을 고려하십시오. 우리는 아마도 암호 정책, 로그인 기능 등과 같은 것들에 대해 이들을 다르게 취급하고 싶을 것입니다. 'user'유형의 프린시 펄은 암호 복잡성 및 만기 정책의 영향을받는 반면 'service account'유형의 프린시 펄은 암호를 가지고 있지 않을 수도 있습니다. 프린시 펄 유형 분류를 시작하면 서브 세트가 작성됩니다. 도움이 되나요? 아니면 방금 진흙을 더 많이 did습니까?
T.Rob

예, 도움이됩니다. 구체적으로 다음에 대한 수정 사항이 있습니까? 메모장 ++와 같은 편집기에 복사하여 붙여 넣고 각 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 인증을 사용하여 사용자 (또는 서비스와 같은 다른 엔티티)를 인증하면 주제가 결과로 작성됩니다. 주체의 목적은 인증 된 사용자를 나타내는 것입니다. 주제는 Principals 세트로 구성되며 , 각 Principal은 해당 사용자의 ID를 나타냅니다. 예를 들어, 주체는 교장 ( "Susan Smith")과 사회 보장 번호 교장 ( "987-65-4321")을 가질 수 있으므로이 주체를 다른 주체와 구별 할 수 있습니다.


2
나는이 정의가 너무 조밀 한 것을 본 적이있다. 특히 사용자가 교장과 어떻게 다른지, 왜 주제가 용어가 아닌 왜 사용자가 아닌가? 이 용어가 JAAS 이상의 의미를 지니고 있다면 그 의미에 익숙해지기를 원합니다.이 용어가 JAAS의 발명품이라면이 개념을 만든 Sun 엔지니어가 이러한 개념의 의미에 상관없이 잘못된 이름을 선택했다고 생각합니다. 나는이 질문에 꽤 많은 프로그래머에게 물었고 명확한 대답을 얻지 못했습니다. 모두이 용어에 대해 다른 이해를 가지고있는 것 같습니다.
ams

교장은 주제를 식별하는 한 가지 방법 인 것 같습니다. 다시 말해, 모든 교장은 이론적으로 사용자 데이터베이스의 기본 키 역할을 할 수 있습니다.
Platinum Azure

3
어휘집은 JAAS보다 오래 전입니다. JAAS는 일부 표준을 비표준 방식으로 재사용합니다. 이 질문을 유발 한 문제의 일부는 개념이 사용 된 상황에서 개념을 학습 한 다음 약간 다른 방식으로 재사용한다는 것입니다. 권위있는 출처를 찾기가 어렵거나 단순히 무시할 때 그 의미는 시간이 지남에 따라 변합니다. 정확성이 절대적인 요구 사항 인 보안의 경우, 모호함을 향한 이러한 편차는 보안 설계를 구축하고 구현하는 능력을 저하시킵니다.
T.Rob

@ T.Rob은 공유 할 수있는 논문 제목이나 권위있는 참고 자료를 제공합니다.
ams

불행히도 권위있는 출처조차도 동의하지 않습니다. SANS는 교장 또는 주제를 전혀 bit.ly/hl4rUP으로 정의하지 않으며 NIST bit.ly/fE7NJ 는 주제를 구체적으로 사람으로 정의합니다. 이 분야에서 명확성의 중요성을 고려하면 다소 실망스러운 다른 "권한있는"출처도 모호하다. IEE에는 용어집이 있지만 회원이나 구독을 통해서만 읽을 수 있으므로 광범위한 청중과의 토론에 제한적으로 사용됩니다. 나는 Shon Harris의 CISSP Exam Guide에 부분적으로 응답했다.
T.Rob

12

Subject 는 서비스를 요청하는 엔티티입니다. 사용자 또는 프로세스 일 수 있습니다. 아마도 이것이 사용자 대신 Subject라는 이름이 선택된 이유 일 것입니다.

주체가 서비스에 액세스하려고 할 때 먼저 주체를 인증해야합니다. 성공적인 인증 은 해당 주제에 대한 보안 사용자 를로드하는 것으로 끝납니다 . 예를 들어, 역할 기반 액세스 제어 시스템에서 인증 된 (로그인 된) 사용자는 일반적으로 userId 및 roleId의 두 프린시 펄을 갖습니다. 이러한 시스템에서 권한 (즉, 무엇에 액세스 할 수있는 사람)이 역할과 사용자 모두에 대해 지정됩니다. 인증 중에 (즉, 요청 된 서비스의 허용 여부 확인) 보안 시스템은 두 보안 사용자에 대한 액세스 가능성을 확인합니다.

따라서 권한 부여 관점에서 보안 주체는 액세스가 허용되거나 허용되지 않는 실제 엔터티입니다. 주제는 일부 주체를 보유한 사용자 / 스레드 / 프로세스입니다.


과목당 여러 원칙을 갖는 것의 이점은 무엇입니까?
ams

6
나는 두 가지 이점을 생각할 수있다. (1) 서비스 (오브젝트)에 액세스하는 주체 UserId ( "Alice"), Role ( "Manager"), Department ( "Sales")를 가진 사용자 Alice를 고려하십시오. 그러면 서비스 액세스 제어를 Alice가 액세스 할 수 있는지 여부를 지정하는 대신 "역할 허용 (관리자)"또는 "부서 (판매) 허용 안함"등으로 지정할 수 있습니다. 보안 관리자는 모든 서비스에 대해 모든 사용자에게 액세스 권한을 지정할 필요가 없기 때문에 이러한 종류의 액세스 제어 시스템은 관리하기가 더 쉽습니다.
rahulmohan

4
(2) 엔터프라이즈 시스템에서 사용자는 일반적으로 일부 복합 서비스를 실행하기 전에 여러 시스템으로 인증을 받아야합니다. 각 시스템에는 서로 다른 세부 정보가 필요한 자체 액세스 제어 메커니즘이있을 수 있습니다. 한 시스템은 SSN을 사용하고 다른 시스템은 userId를 사용합니다. 따라서 동일한 주체가 두 교장 모두에 접근 할 수 있도록 교장 모두를 소유해야합니다.
rahulmohan

1
나는이 용어에 대한 혼동의 99 %가 "주체는 기본적으로 그룹"이라는 선을 따라 한 문장으로 해결 될 수 있다는 느낌을받습니다.
Trejkaz

1
?! ... 교장이 그룹이라고 말하는 이유는 무엇입니까?
Rafael

10

T.Rob이 설명했듯이 Subject는 객체에 대한 액세스를 요청하는 엔티티입니다. 그 시점부터 나는 매우 유용하고 이해하기 쉬운 javax.security.auth.Subject 코드에 대한 의견을 찾았습니다.

"주체는 잠재적으로 다수의 신원을 가질 수 있습니다. 각 신원은 주제 내에서 교장으로 표시됩니다. 교장은 단순히 이름을 주제에 바인드합니다. 예를 들어 사람이되는 주제 인 Alice는 두 명의 교장을 가질 수 있습니다. 하나는" 운전 면허증의 이름 인 Alice Bar "와 학생 식별 카드의 번호"999-99-9999 "를 피험자에 바인딩하는 또 다른 이름입니다. 두 교장은 각각 동일한 주제를 나타냅니다. 이름이 다릅니다. "

도움이 되길 바랍니다.


7

이것은 Oracle JAVA SE Documentation의 아래 설명에 대한 링크 입니다.

주제, 프린시 펄, 인증 및 신임 정보 자원에 대한 액세스 권한을 부여하려면 애플리케이션이 먼저 요청 소스를 인증해야합니다. JAAS 프레임 워크는 요청 소스를 나타내는 주제 라는 용어를 정의합니다 . 피험자는 사람이나 서비스와 같은 모든 개체 일 수 있습니다. 주제는 javax.security.auth.Subject 클래스로 표시됩니다 .

인증 은 주체의 신원이 확인되는 과정을 나타내며 안전한 방식으로 수행되어야합니다. 그렇지 않으면 가해자가 다른 사람을 사칭하여 시스템에 액세스 할 수 있습니다. 인증은 일반적으로 신원을 증명하기 위해 어떤 형태의 증거를 보여주는 주체와 관련됩니다. 이러한 증거는 피험자 만 알고 있거나 가질 수있는 정보 (예 : 암호 또는 지문)이거나 피험자 만 생성 할 수있는 정보 (예 : 개인 키를 사용하여 서명 된 데이터) 일 수 있습니다.

인증되면 주제는 연관된 ID 또는 프린시 펄 ( java.security.Principal 유형 ) 로 채워집니다 . 피험자는 많은 교장을 가질 수 있습니다. 예를 들어, 사람은 이름 (Principal) ( "John Doe")과 SSN Principal ( "123-45-6789")을 가질 수 있으며, 이는 다른 주제와 구별됩니다.

연관된 프린시 펄 외에, 주제는 보안 관련 속성을 소유 할 수 있으며이를 신임 정보 라고합니다 . 자격 증명에는 새로운 서비스에 대한 주제를 인증하는 데 사용되는 정보가 포함될 수 있습니다. 이러한 자격 증명에는 암호, Kerberos 티켓 및 공개 키 인증서가 포함됩니다. 자격 증명에는 주체가 특정 활동을 수행 할 수있는 데이터가 포함될 수도 있습니다. 예를 들어, 암호화 키는 주체가 데이터에 서명하거나 암호화 할 수있는 자격 증명을 나타냅니다. 공개 및 개인 자격 증명 클래스는 핵심 J2SE API의 일부가 아닙니다. 따라서 모든 클래스는 자격 증명을 나타낼 수 있습니다.


비록 T.Rob의 답변에 동의하지만, "주체는 어떤 주체 일 수도 있습니다"라고 말하는 Aram의 답변은 대부분의 데이터베이스를 뒷받침하는 Entity-Relationship Model 인 ERM에 있습니다. 이 모델에서 "엔터티"는 보안의 맥락에서 "대상"에 해당하지만 모델링 대상에 따라 Marinus에서 제안한대로 주체 (은행 계좌, SSN 번호) 또는 사용자 (존 스미스) 일 수 있습니다. ' 대답. Wikipedia : en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
부드러운 노란색

0

rahulmohan에 따르면, 나는 인증이 서브 젯 이전에, 인증이 pricipal 후에, 차이 적으로 서브 젯은 많은 pricipal을 가질 수 있다고 생각한다

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.