Який сенс та відмінність між предметом, користувачем та принципом?

У контексті систем безпеки часто зустрічаються декілька термінів, суб'єкт , користувач та головний , з яких я не зміг знайти чіткого визначення та різниці між ними.

Отже, що саме означають ці терміни і для чого потрібні ці розмежування предмета та основної ?

Вони є ієрархічними таким чином, як рід, види та індивід є ієрархічними.

• Тема - У контексті безпеки суб'єктом є будь-яка сутність, яка запитує доступ до об'єкта . Це загальні терміни, які використовуються для позначення речі, яка вимагає доступу, і речі, проти якої зроблено запит. Коли ви входите в програму, ви є суб'єктом, і програма є об'єктом. Коли хтось стукає у вашу двері, відвідувач - це суб’єкт, який запитує доступ, а ваш будинок - об’єкт, про який вимагається доступ.
• Основний - підмножина теми, яка представлена ​​обліковим записом, роллю чи іншим унікальним ідентифікатором. Коли ми доходимо до рівня деталізації реалізації, принципи - це унікальні ключі, які ми використовуємо у списках контролю доступу. Вони можуть представляти користувачів користувачів, автоматизацію, програми, з'єднання тощо.
• Користувач - підмножина головного, що зазвичай відноситься до оператора людини. Відмінність з часом розмивається, оскільки слова "користувач" або "ідентифікатор користувача" зазвичай замінюються на "обліковий запис". Однак, коли вам потрібно зробити відмінність між широким класом речей, які є головними, та їх підмножиною, що є інтерактивними операторами, що керують транзакціями недетермінованим способом, "користувач" - це правильне слово.

Предмет / Об'єкт успадковується з тих же термінів, що і в граматиці. У реченні суб'єктом є актор, а предметом є те, на що діяли. У цьому сенсі використання існує вже з тих пір, поки не були винайдені комп'ютери. У контексті безпеки суб'єктом є все, що може зробити запит. Як зазначалося вище, це не повинно обмежуватись інформаційною безпекою, тому це дуже широка класифікація. Цікавим є те, що предмет передбачає предмет. Без об’єкта немає і предмета.

Директори - це те, на що вирішуються суб'єкти. Під час пред'явлення вашої кредитної картки ви є суб’єктом, а номер рахунку є основним. В інших контекстах ваш головний ідентифікатор користувача або ідентифікатор, виданий державою. Але директори можуть бути пов'язані з багатьма типами предметів, які не є людьми. Коли додатки надсилають запити на функції системного рівня, довіритель може бути підписником підписаного виконуваного модуля коду, але навіть у цьому випадку користувач, що керує запитом, все ще є суб'єктом.

Користувач більш конкретний, ніж суб'єкт або головний, оскільки зазвичай він посилається на інтерактивного оператора. Ось чому ми маємо графічний інтерфейс користувача, а не графічний основний інтерфейс. Користувач - це екземпляр суб'єкта, який вирішує принцип . Один користувач може вирішувати будь-яку кількість головних принципів, але, як очікується, будь-який головний користувач може використовуватись для одного користувача (якщо люди дотримуються вимоги не ділитися ідентифікаторами) У наведеному вище прикладі підписник модуля виконуваного коду, безумовно, не є користувачем, але він є дійсним головним. Інтерактивний оператор, який намагається завантажити модуль - це користувач.

Як зазначається в коментарях, навіть авторитетні джерела не згодні з цими умовами. Я шукав NIST, SANS, IEEE, MITER та декілька "квазіавторитетних" джерел, таких як посібники з іспитів з безпеки, готуючи цю відповідь. Жодне джерело, яке я виявив, що було принаймні квазіавторитетним, не охоплювало б усіх трьох термінів, і всі вони суттєво відрізнялися за своїм використанням. Це мій погляд на те, як слід використовувати терміни, але з практичної точки зору, коли ви переглядаєте посібник посеред ночі, визначення, як правило, є незалежним від того, хто каже або продавець. Сподіваємось, хоча відповіді тут дадуть достатню інформацію для навігації у водах та аналізу будь-якого документа безпеки, використовуючи ці умови.

Подивіться на мою карту концепції аутентифікації :

Я думаю, що термінологія взята з JAAS .

Коли програма використовує аутентифікацію JAAS для аутентифікації користувача (або іншого об'єкта, такого як служба), в результаті створюється Тема . Метою Теми є представлення автентифікованого користувача. Тема складається з набору Принцип , де кожен Принцип представляє особу для цього користувача. Наприклад, Суб'єкт може мати ім'я Головний ("Сьюзен Сміт") та головний номер соціального захисту ("987-65-4321"), тим самим відрізняючи цей Предмет від інших Суб'єктів.

Суб'єкт - це організація, яка запитує послугу. Це може бути користувач або процес. Можливо, саме тому ім'я Subject було вибрано замість користувача.

Коли суб'єкт намагається отримати доступ до послуги, його потрібно спершу пройти автентифікацію. Успішна автентифікація закінчується завантаженням принципів безпеки для цього предмета. Наприклад, у системі управління доступом на основі ролей, у автентифікованого (входу в систему) користувача зазвичай є два принципи - userId і roleId. У таких системах привілеї (тобто хто може отримати доступ до них) визначаються як для ролей, так і для користувачів. Під час авторизації (тобто перевірки, чи потрібно дозволена послуга) система безпеки перевірятиме на доступність обох керівників.

Отже, з точки зору авторизації, принципали - це фактичні суб'єкти, до яких доступ дозволений або заборонений. Тема - це лише користувач / потік / процес, який містить деякі принципи.

Як пояснив T.Rob, Subject - це будь-яка сутність, яка запитує доступ до об'єкта. Починаючи з цього моменту, я знайшов коментар до javax.security.auth.Subject code, який я вважав ДУЖЕ корисним та зрозумілим:

"Суб'єкти потенційно можуть мати декілька ідентичностей. Кожна ідентичність представлена ​​як Принцип у Темі. Принципи просто прив'язують імена до Суб'єкта. Наприклад, Суб'єкт, який трапляється особою, Аліса, може мати два Принципи: один, який пов'язує" Alice Bar ", ім'я на її водійському посвідченні на Subject, та інше, що пов'язує" 999-99-9999 "номер, який є на її ідентифікаційному посвідченні студента, на Subject. Обидва директори посилаються на один і той же предмет, хоча кожен має іншу назву ".

Сподіваюся, це допомагає.

Це посилання для пояснення нижче з документації Oracle JAVA SE.

Суб'єкти, Принципи, Аутентифікація та Уповноважені дані Для того, щоб дозволити доступ до ресурсів, додаткам спочатку потрібно автентифікувати джерело запиту. Рамка JAAS визначає термін, що підлягає представленню джерела запиту. Суб'єктом може бути будь-яка організація, наприклад, людина чи служба. Предмет представлений класом javax.security.auth.Subject .

Автентифікація являє собою процес, за допомогою якого підтверджується особа суб'єкта, і він повинен бути виконаний у безпечному порядку; в іншому випадку винний може видавати себе за інших, щоб отримати доступ до системи. Аутентифікація зазвичай включає суб'єкта, який демонструє певну форму доказів для підтвердження своєї ідентичності. Такі докази можуть бути інформацією, яку суб'єкт може знати або мати (наприклад, пароль або відбиток пальців), або це може бути інформація, яку може отримати суб'єкт (наприклад, підписані дані за допомогою приватного ключа).

Після автентифікації суб'єкт заповнюється пов’язаними особами або Принципами (типу java.security.Principal ). Тема може мати багато керівників. Наприклад, людина може мати прізвище Principal ("Джон Доу") та SSN Principal ("123-45-6789"), які відрізняють його від інших Суб'єктів.

Окрім пов’язаних Принципалів, Суб'єкт може володіти атрибутами, пов'язаними з безпекою, які називаються обліковими записами . Довірительна інформація може містити інформацію, яка використовується для автентифікації суб'єкта для нових послуг. Такі облікові дані включають паролі, квитки Kerberos та сертифікати відкритого ключа. Акредитиви також можуть містити дані, які дозволяють суб'єкту здійснювати певні дії. Наприклад, криптографічні ключі представляють облікові дані, які дозволяють суб'єкту підписувати або шифрувати дані. Громадські та приватні облікові класи не є частиною основного API J2SE. Отже, будь-який клас може представляти собою обліковий запис.

на думку rahulmohan, я думаю, до того, як автентифікація буде subjet, після аутентифікації є прибутковою, в різницю сенса, у subjet може бути багато pricipal