Apa arti dan perbedaan antara subjek, pengguna dan kepala sekolah?


173

Dalam konteks kerangka kerja keamanan, beberapa istilah umum terjadi pada subjek , pengguna dan prinsipal , di mana saya belum dapat menemukan definisi yang jelas dan perbedaan di antara mereka.

Jadi, apa sebenarnya arti istilah-istilah ini, dan mengapa perbedaan pokok dan pokok ini diperlukan?

Jawaban:


277

Ini bersifat hierarkis dengan cara genus, spesies, dan individu bersifat hierarkis.

  • Subjek - Dalam konteks keamanan, subjek adalah entitas apa pun yang meminta akses ke objek . Ini adalah istilah umum yang digunakan untuk menunjukkan hal yang meminta akses dan hal yang ditentang oleh permintaan. Ketika Anda masuk ke suatu aplikasi Anda adalah subjek dan aplikasi adalah objek. Ketika seseorang mengetuk pintu Anda, pengunjung adalah subjek yang meminta akses dan rumah Anda adalah objek yang diminta aksesnya.
  • Principal - Subset subjek yang diwakili oleh akun, peran, atau pengidentifikasi unik lainnya. Ketika kita sampai ke tingkat detail implementasi, kepala sekolah adalah kunci unik yang kita gunakan dalam daftar kontrol akses. Mereka dapat mewakili pengguna manusia, otomatisasi, aplikasi, koneksi, dll.
  • Pengguna - Subset dari prinsipal biasanya mengacu pada operator manusia. Perbedaannya kabur dari waktu ke waktu karena kata-kata "pengguna" atau "ID pengguna" biasanya dipertukarkan dengan "akun". Namun, ketika Anda perlu membuat perbedaan antara kelas luas dari hal-hal yang prinsipal dan bagian dari hal ini yang merupakan operator interaktif yang mendorong transaksi secara non-deterministik, "pengguna" adalah kata yang tepat.

Subjek / Objek mewarisi dari istilah yang sama seperti yang digunakan dalam tata bahasa. Dalam sebuah kalimat subjek adalah aktor dan objeknya adalah tindakan yang dilakukan. Dalam hal ini penggunaannya telah ada sejak sebelum komputer ditemukan. Dalam konteks keamanan, subjek adalah apa saja yang dapat membuat permintaan. Seperti disebutkan di atas, ini tidak perlu terbatas pada keamanan TI dan juga klasifikasi yang sangat luas. Yang menarik adalah bahwa subjek menyiratkan objek. Tanpa objek, tidak ada subjek.

Kepala sekolah adalah tujuan penyelesaian masalah. Ketika Anda menunjukkan kartu kredit Anda, Anda adalah subjek dan nomor rekening adalah prinsipal. Dalam konteks lain ID pengguna Anda atau identifikasi yang dikeluarkan negara adalah prinsip Anda. Tetapi kepala sekolah dapat dikaitkan dengan banyak jenis subjek yang bukan orang. Ketika aplikasi membuat permintaan untuk fungsi-fungsi tingkat sistem, prinsipal dapat menandatangani modul kode yang dapat dieksekusi yang ditandatangani tetapi bahkan dalam kasus itu pengguna yang mengarahkan permintaan masih menjadi subjek.

Pengguna lebih spesifik daripada subjek atau kepala sekolah karena biasanya mengacu pada operator interaktif. Itulah sebabnya kami memiliki Antarmuka Pengguna grafis dan bukan Antarmuka Utama Grafis. Pengguna adalah turunan dari subjek yang diselesaikan ke kepala sekolah . Seorang pengguna tunggal dapat menyelesaikan sejumlah prinsipal tetapi prinsipal mana pun diharapkan menyelesaikan untuk satu pengguna (dengan asumsi orang mematuhi persyaratan untuk tidak berbagi ID). Dalam contoh di atas, penandatangan modul kode yang dapat dieksekusi jelas bukan pengguna, tetapi merupakan prinsipal yang valid. Operator interaktif yang mencoba memuat modul adalah pengguna.

Seperti disebutkan dalam komentar, bahkan sumber otoritatif tidak menyetujui persyaratan ini. Saya mencari NIST, SANS, IEEE, MITER dan beberapa sumber "semu-otoritatif" seperti panduan ujian keamanan sambil mempersiapkan tanggapan ini. Tidak ada satu pun sumber yang saya temukan yang setidaknya quasi-authoritative mencakup ketiga istilah dan semuanya berbeda secara signifikan dalam penggunaannya. Ini adalah pendapat saya tentang bagaimana istilah harus digunakan tetapi dari sudut pandang praktis, ketika Anda meneliti manual di tengah malam, definisi cenderung menjadi apa pun yang dikatakan oleh vendor atau penulis. Semoga tanggapan di sini akan memberikan wawasan yang cukup untuk menavigasi perairan dan mengurai dokumen keamanan menggunakan istilah ini.


3
Apa manfaat memecah hal-hal menjadi Subjek, Kepala Sekolah, Pengguna, kompleksitas ekstra manfaat apa yang kita dapatkan dari kompleksitas ekstra ini?
ams

19
Kemampuan untuk memilih tingkat spesifisitas yang tepat. Ini adalah manfaat yang sama dengan yang kita peroleh karena mampu membedakan antara tujuan versus antrian atau topik. Kemampuan untuk memilih antara berbagai tingkat spesifisitas dalam taksonomi memungkinkan ketepatan ekspresi yang lebih baik mengkomunikasikan maksud penulis kepada pembaca. Ketika pemrograman kita memiliki kemewahan / kutukan bahwa CPU akan menginterpretasikan instruksi kita hanya dalam satu cara dan kita dipaksa untuk menggunakan tingkat ketepatannya. Namun dalam bahasa manusia kita membutuhkan nuansa dan ketelitian untuk menyampaikan makna secara efisien.
T.Rob

1
T.Rob, luar biasa, tetapi bisakah Anda mengklarifikasi "Pengguna - subset prinsipal"? Jika John adalah subjek dan "akun # 123" adalah prinsipalnya, pengguna adalah siapa? Apakah ada dua milik John? Karena Genus> Spesies> Individu semakin spesifik, John (pengguna) harus lebih spesifik daripada John (subjek). Atau apakah saya melewatkan sesuatu?
kuning mellow

1
Pertimbangkan dua kepala sekolah di mana # 123 adalah John dan # 124 mengacu pada akun layanan. Kami mungkin ingin memperlakukan perbedaan ini mengenai hal-hal seperti kebijakan kata sandi, kemampuan masuk, dll. Kepala sekolah tipe 'pengguna tunduk pada kompleksitas kata sandi dan kebijakan kedaluwarsa sedangkan kepala sekolah tipe' akun layanan 'bahkan mungkin tidak memiliki kata sandi. Ketika kami mulai mengkategorikan jenis-jenis pokok kami membuat subset. Apakah itu membantu? Atau apakah saya hanya mengaduk lebih banyak lumpur?
T.Rob

Ya, itu membantu. Jadi, secara konkret, ada koreksi untuk yang berikut? Anda mungkin ingin menyalin dan menempelkannya ke editor seperti Notepad ++ dan meletakkan linebreak di depan setiap John (SO melarang linebreak dalam komentar): 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

Saya pikir terminologi diambil dari JAAS .

Ketika aplikasi menggunakan otentikasi JAAS untuk mengotentikasi pengguna (atau entitas lain seperti layanan), Subjek dibuat sebagai hasilnya. Tujuan Subjek adalah untuk mewakili pengguna yang diautentikasi. Subjek terdiri dari sekumpulan Principal , di mana masing-masing Principal mewakili identitas untuk pengguna tersebut. Misalnya, Subjek dapat memiliki nama Kepala Sekolah ("Susan Smith") dan Kepala Nomor Jaminan Sosial ("987-65-4321"), sehingga membedakan Subjek ini dari Subjek lain.


2
Saya telah melihat definisi ini sebelumnya, terlalu padat, dapatkah Anda menguraikannya, terutama bagaimana pengguna berbeda dari kepala sekolah, mengapa istilah subjek digunakan dan bukan hanya pengguna. Jika istilah-istilah ini memiliki makna di luar JAAS saya sangat ingin menjadi akrab dengan makna itu, jika istilah-istilah ini adalah penemuan JAAS maka saya kira Insinyur Matahari yang menciptakannya memilih nama-nama miskin untuk apa pun arti konsep-konsep ini. Saya telah mengajukan beberapa pertanyaan kepada programer ini dan belum bisa mendapatkan jawaban yang jelas, setiap orang tampaknya memiliki pemahaman yang berbeda tentang istilah-istilah ini.
ams

Sepertinya Kepala Sekolah hanyalah salah satu cara untuk mengidentifikasi Subjek. Dengan kata lain, setiap Kepala Sekolah secara teoritis dapat berfungsi sebagai kunci utama pada basis data pengguna Anda.
Platinum Azure

3
Leksikon mendahului JAAS dengan tembakan panjang. JAAS hanya menggunakan kembali sebagian dan kadang-kadang dengan cara yang tidak standar. Bagian dari masalah yang mendorong pertanyaan ini adalah bahwa konsep dipelajari dari konteks di mana terminologi digunakan dan kemudian digunakan kembali dengan cara yang sedikit berbeda. Ketika sumber-sumber resmi sulit ditemukan atau diabaikan, maknanya melayang seiring waktu. Ketika datang ke keamanan di mana presisi adalah persyaratan mutlak penyimpangan ini menuju ambiguitas menurunkan kemampuan kita untuk membangun dan menerapkan desain yang aman.
T.Rob

@ T.Rob, apakah Anda memiliki judul makalah, atau referensi resmi yang dapat Anda bagikan.
ams

Sayangnya, bahkan sumber yang berwenang tidak setuju. SANS tidak mendefinisikan pokok atau subjek sama sekali bit.ly/hl4rUP dan NIST bit.ly/fE7NJs mendefinisikan subjek secara khusus sebagai pribadi. Sumber-sumber "otoritatif" lainnya juga tidak jelas yang, mengingat pentingnya kejelasan dalam bidang ini, agak mengecewakan. IEE memiliki glosarium tetapi Anda hanya dapat membacanya dengan keanggotaan atau berlangganan sehingga penggunaannya terbatas dalam diskusi dengan khalayak luas. Saya mendasarkan respons saya sebagian pada Panduan Ujian CISSP Shon Harris.
T.Rob

12

Subjek adalah entitas yang meminta layanan. Ini bisa menjadi pengguna atau proses. Mungkin itu sebabnya nama Subjek dipilih alih-alih pengguna.

Ketika subjek mencoba mengakses layanan, subjek harus diautentikasi terlebih dahulu. Otentikasi yang berhasil berakhir dengan memuat Prinsip Keamanan untuk Subjek itu. Misalnya, dalam sistem Kontrol Akses Berbasis Peran, pengguna yang terotentikasi (masuk) biasanya akan memiliki dua prinsipal - userId dan roleId. Dalam sistem seperti itu, hak istimewa (yaitu siapa yang dapat mengakses apa) ditentukan untuk peran dan pengguna. Selama otorisasi (yaitu memeriksa apakah layanan yang diminta harus diizinkan), sistem keamanan akan memeriksa aksesibilitas terhadap kedua prinsipal.

Oleh karena itu, dari perspektif otorisasi, pelaku adalah entitas aktual yang aksesnya diizinkan atau tidak diizinkan. Subjek hanyalah pengguna / utas / proses yang menampung beberapa pelaku.


Apa manfaatnya memiliki banyak prinsip per subjek?
ams

6
Saya dapat memikirkan dua manfaat: (1) Pertimbangkan pengguna Alice dengan prinsipal UserId ("Alice"), Peran ("Manajer"), Departemen ("Penjualan") mengakses layanan (Objek). Kontrol akses layanan kemudian dapat ditetapkan sebagai "Izinkan untuk Peran (Manajer)" atau "Larang untuk Departemen (Penjualan)" dll. Alih-alih menentukan apakah Alice dapat mengaksesnya atau tidak. Sistem kontrol akses semacam itu lebih mudah dikelola karena administrator keamanan tidak perlu menentukan hak akses untuk SEMUA pengguna untuk SEMUA layanan.
rahulmohan

4
(2) Dalam sistem perusahaan, pengguna biasanya harus disahkan dengan beberapa sistem sebelum beberapa layanan komposit dapat dijalankan. Bisa terjadi bahwa masing-masing sistem memiliki mekanisme kontrol aksesnya sendiri yang membutuhkan detail berbeda - satu sistem menggunakan SSN, dan yang lainnya menggunakan userId. Jadi subjek yang sama harus memiliki kedua kepala sekolah untuk mengakses keduanya
rahulmohan

1
Saya merasa 99% kebingungan dengan terminologi ini dapat diselesaikan dengan satu kalimat di sepanjang baris, "seorang kepala sekolah pada dasarnya adalah sebuah kelompok".
Trejkaz

1
?! ... mengapa Anda mengatakan Kepala Sekolah adalah Grup?
Rafael

10

Seperti yang dijelaskan T.Rob, Subjek adalah setiap entitas yang meminta akses ke suatu objek. Mulai dari titik itu saya menemukan komentar di javax.security.auth.Subject code yang saya temukan sangat berguna dan mudah dimengerti:

"Subjek mungkin memiliki banyak identitas. Setiap identitas diwakili sebagai Kepala Sekolah dalam Subjek. Kepala sekolah hanya mengikat nama pada Subjek. Sebagai contoh, Subjek yang kebetulan adalah seseorang, Alice, mungkin memiliki dua Kepala Sekolah: satu yang mengikat" Alice Bar ", nama pada SIM-nya, ke Subjek, dan lain yang mengikat," 999-99-9999 ", nomor pada kartu identitas muridnya, ke Subjek. Kedua Kepala Sekolah merujuk ke Subjek yang sama meskipun masing-masing memiliki nama yang berbeda. "

Semoga ini bisa membantu.


7

Ini adalah tautan untuk eksplorasi di bawah ini dari Dokumentasi Oracle JAVA SE.

Subjek, Kepala Sekolah, Otentikasi, dan Kredensial Untuk mengesahkan akses ke sumber daya, aplikasi harus terlebih dahulu mengautentikasi sumber permintaan. Kerangka kerja JAAS mendefinisikan istilah subjek untuk mewakili sumber permintaan. Subjek dapat berupa entitas apa pun, seperti orang atau layanan. Subjek diwakili oleh javax.security.auth.Subject kelas .

Otentikasi merupakan proses di mana identitas subjek diverifikasi, dan harus dilakukan dengan cara yang aman; jika tidak, pelaku dapat menyamar sebagai orang lain untuk mendapatkan akses ke suatu sistem. Otentikasi biasanya melibatkan subjek yang menunjukkan beberapa bentuk bukti untuk membuktikan identitasnya. Bukti tersebut dapat berupa informasi yang hanya mungkin diketahui atau dimiliki subjek (seperti kata sandi atau sidik jari), atau mungkin informasi yang hanya dapat dihasilkan oleh subjek (seperti data yang ditandatangani menggunakan kunci pribadi).

Setelah diautentikasi, Subjek diisi dengan identitas terkait, atau Prinsipal (dari tipe java.security.Principal ). Subjek mungkin memiliki banyak Kepala Sekolah. Misalnya, seseorang dapat memiliki nama Kepala Sekolah ("John Doe") dan Kepala Sekolah SSN ("123-45-6789"), yang membedakannya dari Subjek lain.

Selain Prinsipal terkait, Subjek dapat memiliki atribut terkait keamanan, yang disebut sebagai kredensial . Kredensial dapat berisi informasi yang digunakan untuk mengautentikasi subjek ke layanan baru. Kredensial tersebut mencakup kata sandi, tiket Kerberos, dan sertifikat kunci publik. Kredensial juga dapat berisi data yang memungkinkan subjek melakukan aktivitas tertentu. Kunci kriptografi, misalnya, mewakili kredensial yang memungkinkan subjek untuk menandatangani atau mengenkripsi data. Kelas kredensial publik dan pribadi bukan bagian dari inti J2SE API. Kelas apa pun, oleh karena itu, dapat mewakili kredensial.


Meskipun saya setuju dengan jawaban T.Rob, jawaban dari Aram ini - yang mengatakan "subjek boleh berupa entitas apa saja" - mengisyaratkan ERM: Model Entity-Relationship yang menopang sebagian besar basis data. Dalam model itu, "entitas" sesuai dengan "subjek" dalam konteks keamanan, tetapi tergantung pada apa yang Anda modelkan, itu bisa menjadi pokok (rekening bank, SSN #) atau pengguna (John Smith), seperti yang disarankan dalam Marinus jawaban Wikipedia: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
mellow-yellow

0

menurut rahulmohan , saya pikir, sebelum Otentikasi ditaklukkan, setelah Otentikasi adalah pricipal, dalam perbedaan rasa, seorang penakluk mungkin memiliki banyak pricipal

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.