Jakie jest znaczenie i różnica między podmiotem, użytkownikiem i zleceniodawcą?


173

W kontekście ram bezpieczeństwa, kilka terminów powszechnie występują zastrzeżeniem , użytkownika i głównego , którego nie byłem w stanie znaleźć jasnej definicji, a różnica między nimi.

Więc co dokładnie oznaczają te terminy i dlaczego potrzebne są te rozróżnienia na temat i zasadę ?

Odpowiedzi:


277

Są one hierarchiczne w taki sam sposób, w jaki rodzaj, gatunek i jednostka są hierarchiczne.

  • Temat - w kontekście zabezpieczeń podmiot to dowolna jednostka żądająca dostępu do obiektu . Są to ogólne terminy używane do określenia rzeczy żądającej dostępu i przedmiotu, przeciwko któremu żądanie jest skierowane. Kiedy logujesz się do aplikacji, jesteś podmiotem, a aplikacja jest obiektem. Kiedy ktoś puka do twoich drzwi, osoba prosi o dostęp, a twój dom jest obiektem.
  • Principal - podzbiór podmiotu reprezentowany przez konto, rolę lub inny unikalny identyfikator. Kiedy dochodzimy do poziomu szczegółów implementacji, podmioty główne są unikalnymi kluczami, których używamy na listach kontroli dostępu. Mogą reprezentować ludzi, automatyzację, aplikacje, połączenia itp.
  • Użytkownik - podzbiór nazwy głównej zwykle odnoszący się do operatora. Rozróżnienie z czasem się zaciera, ponieważ słowa „użytkownik” lub „identyfikator użytkownika” są często używane zamiennie ze słowami „konto”. Jednak gdy trzeba dokonać rozróżnienia między szeroką klasą rzeczy, które są zleceniodawcami, a podzbiorem tych, które są operatorami interaktywnymi sterującymi transakcjami w sposób niedeterministyczny, „użytkownik” jest właściwym słowem.

Przedmiot / obiekt dziedziczy z tych samych terminów, które są używane w gramatyce. W zdaniu podmiot jest aktorem, a przedmiot jest przedmiotem. W tym sensie zastosowanie istniało już przed wynalezieniem komputerów. W kontekście bezpieczeństwa podmiotem jest wszystko, co może zgłosić żądanie. Jak wspomniano powyżej, nie musi to ograniczać się do bezpieczeństwa IT, a więc jest to bardzo szeroka klasyfikacja. Interesujące jest to, że podmiot implikuje przedmiot. Bez przedmiotu nie ma podmiotu.

Podmioty decydują się na dyrektorów. Kiedy przedstawiasz swoją kartę kredytową, jesteś podmiotem, a numer konta jest głównym. W innych kontekstach Twój identyfikator użytkownika lub identyfikator wydany przez stan jest Twoim mocodawcą. Ale dyrektorzy mogą być kojarzeni z wieloma typami podmiotów, które nie są ludźmi. Gdy aplikacje żądają funkcji na poziomie systemu, podmiot zabezpieczeń może być sygnatariuszem podpisanego modułu kodu wykonywalnego, ale nawet w tym przypadku podmiot kierujący żądaniem nadal jest podmiotem.

Użytkownik jest bardziej szczegółowy niż temat lub podmiot główny, ponieważ zwykle odnosi się do operatora interaktywnego. Dlatego mamy graficzny interfejs użytkownika, a nie graficzny interfejs główny. Użytkownik jest instancją podmiotu, która jest rozpoznawana jako zleceniodawca . Pojedynczy użytkownik może rozstrzygać sprawę na dowolną liczbę podmiotów głównych, ale oczekuje się, że każdy podmiot główny będzie rozstrzygany na jednego użytkownika (zakładając, że ludzie przestrzegają wymogu nieudostępniania identyfikatorów). W powyższym przykładzie osoba podpisująca wykonywalny moduł kodu zdecydowanie nie jest użytkownikiem, ale jest prawidłową jednostką zabezpieczeń. Interaktywnym operatorem próbującym załadować moduł jest użytkownik.

Jak zauważono w komentarzach, nawet autorytatywne źródła nie zgadzają się na te warunki. Przygotowując tę ​​odpowiedź, przeszukałem NIST, SANS, IEEE, MITER i kilka „quasi-autorytatywnych” źródeł, takich jak przewodniki po egzaminach bezpieczeństwa. Żadne znalezione przeze mnie źródło, które było przynajmniej quasi-autorytatywne, nie obejmowało wszystkich trzech terminów i wszystkie różniły się znacząco pod względem ich użycia. Oto moje podejście do tego, jak należy używać tych terminów, ale z praktycznego punktu widzenia, kiedy przeglądasz instrukcję w środku nocy, definicje wydają się być takie, jakie są podane przez sprzedawcę lub autora. Miejmy nadzieję, że odpowiedzi tutaj zapewnią wystarczający wgląd w nawigację po wodach i przeanalizowanie dowolnego dokumentu bezpieczeństwa przy użyciu tych terminów.


3
Jaka jest korzyść z rozbicia rzeczy na podmiot, zleceniodawcę, użytkownika, jego dodatkowa złożoność, jakie korzyści daje ta dodatkowa złożoność?
rano

19
Możliwość doboru odpowiedniego poziomu specyficzności. Jest to ta sama korzyść, jaką zyskujemy, odróżniając miejsce docelowe od kolejki lub tematu. Możliwość wyboru między różnymi poziomami szczegółowości taksonomii pozwala na precyzyjne sformułowanie, które lepiej przekazuje czytelnikowi zamiary pisarza. Podczas programowania mamy ten luksus / przekleństwo, że procesor będzie interpretował nasze instrukcje tylko w jeden sposób i jesteśmy zmuszeni używać jego poziomu precyzji. Ale w ludzkim języku potrzebujemy niuansów i precyzji, aby skutecznie przekazać znaczenie.
T.Rob

1
T.Rob, super, ale czy mógłbyś wyjaśnić „Użytkownik - podzbiór głównych”? Jeśli tematem jest Jan, a jego głównym podmiotem jest „konto nr 123”, to kim jest użytkownik? Czy są dwa John's? Ponieważ Rodzaj> Gatunek> Osobnik jest coraz bardziej specyficzny, Jan (użytkownik) powinien być bardziej szczegółowy niż Jan (podmiot). A może coś mi brakuje?
żółto-żółty

1
Rozważmy dwa podmioty główne, gdzie nr 123 to Jan, a numer 124 odnosi się do konta usługi. Prawdopodobnie chcielibyśmy potraktować te różne kwestie, takie jak polityka haseł, możliwość logowania, itp. Podmioty główne typu „użytkownik” podlegają zasadom złożoności i wygasania hasła, podczas gdy podmioty typu „konto serwisowe” mogą nawet nie mieć hasła. Kiedy zaczynamy kategoryzować typy podmiotów głównych, tworzymy podzbiory. To pomaga? A może po prostu porobiłem więcej błota?
T.Rob

Tak, to pomaga. A więc konkretnie, jakieś poprawki do poniższych? Możesz skopiować i wkleić go do edytora, takiego jak Notepad ++ i umieścić podział wiersza przed każdym Johnem (SO zabrania łamania wierszy w komentarzach): 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
łagodny żółty


19

Myślę, że terminologia pochodzi z JAAS .

Gdy aplikacja używa uwierzytelniania JAAS do uwierzytelnienia użytkownika (lub inny podmiot, takich jak usługi), Temat jest tworzony w wyniku. Celem podmiotu jest reprezentowanie uwierzytelnionego użytkownika. Podmiot składa się z zestawu podmiotów głównych , przy czym każdy podmiot główny reprezentuje tożsamość tego użytkownika. Na przykład Podmiot może mieć imię i nazwisko Główny („Susan Smith”) i Główny Numer Ubezpieczenia Społecznego („987-65-4321”), co odróżnia go od innych Podmiotów.


2
Widziałem już tę definicję, jest zbyt gęsta, czy możesz ją rozwinąć, zwłaszcza, jak różni się użytkownik od dyrektora, dlaczego używany jest termin podmiot, a nie tylko użytkownik. Jeśli te terminy mają znaczenie poza JAAS, bardzo chcę się z nimi zapoznać, jeśli te terminy są wynalazkami JAAS, to myślę, że Inżynierowie Słońca, którzy je stworzyli, wybrali kiepskie nazwy dla tego, co oznaczają te pojęcia. Zadałem to pytanie wielu programistom i nie byłem w stanie uzyskać jasnych odpowiedzi, każdy z nich wydaje się mieć inne zrozumienie tych terminów.
AMS

Wydaje się, że zleceniodawca to tylko jeden ze sposobów identyfikacji podmiotu. Innymi słowy, każdy zleceniodawca mógłby teoretycznie służyć jako klucz podstawowy w bazie danych użytkowników.
Platinum Azure,

3
Leksykon wyprzedza JAAS z daleka. JAAS po prostu wykorzystuje część z nich ponownie i czasami w niestandardowy sposób. Częścią problemu, który zrodził to pytanie, jest to, że koncepcje są wyuczane z kontekstów, w których terminologia jest używana, a następnie ponownie wykorzystywana na nieco inne sposoby. Kiedy trudno jest znaleźć wiarygodne źródła lub po prostu je zignorować, znaczenia zmieniają się w czasie. Jeśli chodzi o bezpieczeństwo, gdzie precyzja jest absolutnym wymogiem, ta tendencja do niejednoznaczności degraduje naszą zdolność do tworzenia i wdrażania bezpiecznych projektów.
T.Rob

@ T.Rob czy masz tytuły artykułów lub autorytatywne referencje, którymi możesz się podzielić.
rano,

Niestety, nawet autorytatywne źródła się z tym nie zgadzają. SANS nie definiuje główny przedmiot lub wcale bit.ly/hl4rUP i NIST bit.ly/fE7NJs definiuje przedmiot specjalnie jako osoby. Inne „autorytatywne” źródła są podobnie niejasne, co biorąc pod uwagę znaczenie jasności w tej dziedzinie, jest raczej rozczarowujące. IEE ma glosariusz, ale możesz go czytać tylko z członkostwem lub subskrypcją, więc ma ograniczone zastosowanie w dyskusjach z szerokim gronem odbiorców. Oparłem swoją odpowiedź częściowo na Przewodniku egzaminacyjnym CISSP Shona Harrisa.
T.Rob

12

Podmiot to podmiot żądający usługi. Może to być użytkownik lub proces. Prawdopodobnie dlatego zamiast nazwy użytkownika wybrano nazwę Temat.

Kiedy podmiot próbuje uzyskać dostęp do usługi, musi najpierw zostać uwierzytelniony. Pomyślne uwierzytelnienie kończy się załadowaniem podmiotów zabezpieczeń dla tego podmiotu. Na przykład w systemie kontroli dostępu opartym na rolach uwierzytelniony (zalogowany) użytkownik ma zwykle dwa podmioty - userId i roleId. W takich systemach uprawnienia (tj. Kto ma do czego dostęp) są określone zarówno dla ról, jak i dla użytkowników. Podczas autoryzacji (tj. Sprawdzania, czy żądana usługa powinna być dozwolona), system bezpieczeństwa sprawdzi dostępność względem obu podmiotów.

Dlatego z punktu widzenia autoryzacji, jednostki główne to rzeczywiste podmioty, dla których dostęp jest dozwolony lub zabroniony. Temat jest po prostu użytkownikiem / wątkiem / procesem, który przechowuje niektóre podmioty.


Jaka jest korzyść z posiadania wielu zasad na przedmiot?
rano

6
Przychodzą mi do głowy dwie korzyści: (1) Rozważmy użytkownika Alice z identyfikatorem użytkownika („Alice”), rolą („menedżer”), działem („sprzedaż”) uzyskującym dostęp do usługi (obiektu). Kontrolę dostępu do usługi można następnie określić jako „Zezwól na rolę (menedżer)” lub „Zabroń dla działu (sprzedaży)” itp. Zamiast określać, czy Alicja ma do niej dostęp, czy nie. Tego rodzaju systemy kontroli dostępu są łatwiejsze w zarządzaniu, ponieważ administrator bezpieczeństwa nie musi określać uprawnień dostępu dla WSZYSTKICH użytkowników do WSZYSTKICH usług.
rahulmohan

4
(2) W systemie przedsiębiorstwa użytkownicy zwykle muszą zostać uwierzytelnieni w wielu systemach, zanim będzie można wykonać jakąś usługę złożoną. Może się zdarzyć, że każdy z tych systemów ma własne mechanizmy kontroli dostępu wymagające innych danych - jeden system używa SSN, a inny userId. Tak więc ten sam podmiot powinien mieć oba główne zasady, aby mieć dostęp do obu
rahulmohan,

1
Mam wrażenie, że 99% pomyłki z tą terminologią można by rozwiązać jednym zdaniem w stylu „dyrektor to w zasadzie grupa”.
Trejkaz

1
?! ... dlaczego mówisz, że zleceniodawca to grupa?
Rafael,

10

Jak wyjaśnił T.Rob, podmiot to każda jednostka, która żąda dostępu do obiektu. Od tego momentu znalazłem komentarz na temat kodu javax.security.auth.Subject, który uważam za BARDZO przydatny i łatwy do zrozumienia:

„Podmioty mogą potencjalnie mieć wiele tożsamości. Każda tożsamość jest reprezentowana jako Główny podmiot w Podmiocie. Strony główne po prostu wiążą nazwy z Podmiotem. Na przykład Podmiot, który jest osobą, Alicja, może mieć dwóch Głównych: jeden, który wiąże” Alice Bar ”, imię i nazwisko na jej prawie jazdy, do Przedmiotu i drugie, które wiąże„ 999-99-9999 ”, numer na jej legitymacji studenckiej, do Przedmiotu. Obaj dyrektorzy odnoszą się do tego samego przedmiotu, chociaż każdy z nich ma inną nazwę ”.

Mam nadzieję, że to pomoże.


7

To jest łącze do poniższego wyjaśnienia z dokumentacji Oracle JAVA SE.

Podmioty, podmioty, uwierzytelnianie i poświadczenia Aby autoryzować dostęp do zasobów, aplikacje muszą najpierw uwierzytelnić źródło żądania. Struktura JAAS definiuje termin podmiot, który ma reprezentować źródło żądania. Podmiotem może być dowolny podmiot, taki jak osoba lub usługa. Temat jest reprezentowany przez klasę javax.security.auth.Subject .

Uwierzytelnianie reprezentuje proces, za pomocą którego tożsamość podmiotu jest weryfikowana i musi być przeprowadzane w bezpieczny sposób; w przeciwnym razie sprawca może podszywać się pod innych, aby uzyskać dostęp do systemu. Uwierzytelnienie zazwyczaj wiąże się z przedstawieniem przez podmiot pewnego rodzaju dowodów w celu udowodnienia swojej tożsamości. Takimi dowodami mogą być informacje, które tylko podmiot prawdopodobnie znałby lub miał (takie jak hasło lub odcisk palca), lub mogą to być informacje, które może przedstawić tylko podmiot (na przykład dane podpisane przy użyciu klucza prywatnego).

Po uwierzytelnieniu podmiot jest wypełniany powiązanymi tożsamościami lub podmiotami głównymi (typu java.security.Principal ). Przedmiot może mieć wielu Dyrektorów. Na przykład osoba może mieć imię i nazwisko głównego („Jan Kowalski”) i głównego numeru SSN („123-45-6789”), co odróżnia ją od innych Podmiotów.

Oprócz powiązanych jednostek głównych, podmiot może posiadać atrybuty związane z zabezpieczeniami, które nazywane są referencjami . Poświadczenie może zawierać informacje używane do uwierzytelnienia podmiotu w nowych usługach. Takie poświadczenia obejmują hasła, bilety Kerberos i certyfikaty kluczy publicznych. Poświadczenia mogą również zawierać dane, które umożliwiają podmiotowi wykonywanie określonych czynności. Na przykład klucze kryptograficzne reprezentują poświadczenia, które umożliwiają podmiotowi podpisywanie lub szyfrowanie danych. Klasy referencji publicznych i prywatnych nie są częścią podstawowego interfejsu API J2SE. Dlatego każda klasa może reprezentować referencje.


Chociaż zgadzam się z odpowiedzią T.Rob, ta z Aram - która mówi, że „podmiotem może być każdy byt” - wskazuje na ERM: model encji-relacji, na którym opiera się większość baz danych. W tym modelu „podmiot” odpowiada „podmiotowi” w kontekście bezpieczeństwa, ale w zależności od tego, co modelujesz, może to być zleceniodawca (konto bankowe, numer SSN) lub użytkownik (Jan Kowalski), zgodnie z sugestią Marinus ' odpowiedź. Wikipedia: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
mellow-yellow

0

według rahulmohana , myślę, że zanim uwierzytelnienie jest subjet, po uwierzytelnieniu jest pricipal, w przeciwieństwie do tego, subjet może mieć wiele

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.