Model Mandat Akses Kontrol (MAC): Tinjauan Umum dan Aplikasi Aplikasi

Mandatory Access Control (MAC) model - metode kontrol akses dengan seperangkat izin yang tetap. Biasanya, MAC ini digunakan dalam sistem dengan persyaratan keamanan tinggi dan melayani berbagai lembaga penegakan hukum dan organisasi yang terkait dengan rahasia negara atau resmi.

Model MAC

MAC, meskipun terkandung dalam banyak artikel dan bahan, paling sering disebutkan dengan santai dan dalam bentuk saus pedas untuk sesuatu seperti penyebutan singkat MLS di SELinux. Karena banyak membatasi pertemanan mereka dengan SELinux menggunakan resep " cara menonaktifkan SELinux ", MAC juga sering menghargainya. Karena itu, pertama singkat tentang MAC.

Jika Anda terbiasa dengan modelnya, Anda dapat langsung menuju ke bagian selanjutnya.

Ide utama

Model keamanan abstrak yang diterapkan dalam MAC klasik (seperti yang diketahui oleh petugas penegak hukum) adalah sebagai berikut (gambar klasik yang menggambarkan model Bell-Lapadula ):


Model MAC secara inheren merupakan implementasi "elektronik" dari alur kerja "rahasia" kertas. MAC memiliki "aktor" berikut:

• Hirarki tingkat akses yang diproses dalam sistem (biasanya terdaftar di OS). Untuk kenyamanan, seringkali ditentukan dalam bentuk angka yang tidak ditandatangani (dari 0 hingga nilai yang dibatasi oleh implementasi). Dalam hal ini, untuk membandingkan tingkat akses (lebih tinggi / lebih rendah / sama), operasi aritmatika yang paling sederhana digunakan (sama, lebih sedikit, lebih banyak).
• Obyek dengan tingkat kerahasiaan. Setiap file, direktori dalam sistem file, sel atau catatan dalam tabel database, tabel dalam database, database itu sendiri, paket jaringan, dll. Objek diberi nilai apa pun dari hierarki tingkat akses. Untuk objek, diizinkan untuk meningkatkan level kerahasiaan (ubah ke nilai level yang lebih tinggi dari yang sekarang). Penurunan tingkat kerahasiaan secara kategoris tidak diperbolehkan (meskipun cukup layak dengan bantuan trik tertentu).
• Subjek dengan tingkat akses. Proses aplikasi atau sesi pengguna (pada dasarnya juga proses aplikasi). Label tingkat akses diwarisi dari subjek oleh semua objek yang dibuat oleh subjek ini.

Nilai tingkat akses subjek atau tingkat kerahasiaan objek biasanya disebut istilah "level wajib", "label wajib" atau sekadar "label" (dalam STCSEC istilah ini disebut "tingkat klasifikasi hierarkis"). Sederhana, luas dan hampir tidak ambigu.

Pemeriksaan otorisasi dilakukan pada setiap fakta akses subjek ke objek yang dilindungi oleh MAC. Dalam hal ini, model kontrol akses kredensial biasanya digunakan bersama dengan mekanisme kontrol akses lainnya, misalnya, DAC (model UNIX dan POSIX ACL). Dalam hal ini, MAC diperiksa terakhir. Pertama, akses diperiksa oleh DAC (sebagai yang paling tidak aman), dan kemudian oleh MAC.

Saat memeriksa kelayakan akses subjek ke objek sesuai dengan model wajib, kombinasi berikut dimungkinkan:

1. Label kredensial subjek sama dengan label kredensial objek. Dalam hal ini, subjek diperbolehkan membaca dan memodifikasi objek.
2. Label kredensial subjek lebih tinggi dari label kredensial objek. Subjek hanya diperbolehkan membaca objek: dia melihatnya, tetapi tidak bisa mengubahnya.
3. Label kredensial subjek lebih rendah dari label kredensial objek. Subjek secara resmi diizinkan untuk membuat objek dengan tanda kredensial yang lebih tinggi (yang disebut "tingkatkan tingkat kerahasiaan objek"). Dalam praktiknya, subjek tidak memiliki kemampuan teknis untuk melakukan operasi ini (ia hanya "tidak melihat" objek variabel, misalnya, file atau direktori dengan file).

Juga di MAC ada yang namanya "kategori" (dalam terminologi STCSEC istilah ini disebut "kategori non-hierarkis"). Kategori dalam MAC adalah opsional. Dalam praktiknya, implementasi kategori MAC digunakan untuk kontrol akses "horizontal" antara berbagai departemen organisasi. Dalam hal ini, karyawan, meskipun satu tingkat wajib, hanya akan mendapatkan akses ke kategori objek yang mereka miliki akses sesuai dengan label mereka.

Keterbatasan dan Kerentanan

MAC memiliki keterbatasan dan fitur-fiturnya:

1. Pengguna sistem tidak dapat secara independen menentukan akses subjek ke objek. Dari seluruh persenjataan kontrol akses objek di MAC, hanya ada label kredensial dan kategori kredensial yang terkait dengan objek ini. Akses subjek ke objek hanya dikendalikan oleh administrator.
2. Jika pengguna ingin mengubah label kredensial objek yang penulisnya adalah dia, maka ia perlu pergi ke sesi label target. Hal ini disebabkan oleh fakta bahwa pengguna tidak dapat menentukan label sesuka hati, tetapi hanya bisa meneruskan label ke objek "dengan warisan." Pada saat yang sama, pengguna hanya dapat bekerja dalam sesi satu label kredensial.
3. Karena MAC digunakan bersama dengan model kontrol akses lainnya, tumbukan timbul: kadang-kadang tidak mudah untuk menemukan di mana "lapisan" akses sistem keamanan ditolak. Diperlukan "penyetelan" tipis semua lapisan perlindungan.
4. Selain pengaturan akses melalui toolkit MAC, diperlukan kebijakan keamanan. Ini harus menggambarkan apa nilai spesifik kredensial artinya (ini di luar MAC), objek mana yang dilindungi, subyek mana yang memiliki hak untuk mengakses. Tanpa peraturan yang disepakati, MAC saja tidak akan memberikan peningkatan keamanan.
5. Menggunakan MAC dalam infrastruktur jaringan terdistribusi. Pendekatan tradisional untuk mengkonfigurasi MAC secara lokal, secara manual, dengan bantuan administrator sesuai dengan instruksi. Ada solusi yang memungkinkan Anda untuk menerapkan penyimpanan MAC yang dikelola secara terpusat (seperti ALD), tetapi mereka memiliki karakteristik dan kesulitan konstruksi sendiri.

Merancang Aplikasi MAC

Terlepas dari semua keterbatasan model, bagi mereka yang bekerja dengan sektor publik, dan terutama dengan lembaga penegak hukum, masalah membangun aplikasi dengan dukungan untuk model kontrol akses wajib lebih relevan dari sebelumnya. Tiba-tiba, besok Anda harus mendukung MAC pada produk Anda?

Sekilas, tampaknya model itu primitif dan implementasinya sesederhana lima sen, tetapi ada satu peringatan: pelanggan, yang menetapkan persyaratan untuk penggunaan model kredensial, telah memikirkan, pertama-tama, alat perlindungan informasi bersertifikat. Informasi yang benar-benar rahasia, hingga rahasia negara, akan diproses dalam IP semacam itu, dan akan sangat sulit untuk menyatakan pengembangannya sendiri ke tingkat yang disyaratkan. Jalan keluar dari situasi ini adalah dengan menggunakan infrastruktur bersertifikat yang mendukung MAC.

Jadi apa yang kita miliki di set:

Sekarang, mari kita lihat bagaimana Anda dapat menggunakan infrastruktur ini ketika mengembangkan aplikasi untuk mempertahankan fungsi kontrol akses di tingkat infrastruktur.

Agar aplikasi dapat memanfaatkan mekanisme label wajib dari sistem operasi, kondisi berikut ini harus dipenuhi:

• Pengguna aplikasi harus terdaftar dalam penyimpanan pengguna sistem operasi. Minimal, harus ada beberapa pengidentifikasi yang memungkinkan Anda memetakan pengguna aplikasi secara unik ke pengguna sistem operasi (biasanya ini adalah login).
• Pengguna aplikasi di tingkat mekanisme MAC sistem operasi harus dikonfigurasikan dengan izin kredensial untuk kredensial tertentu (rentang kredensial).

Dari sudut pandang aplikasi desktop, skenario pengguna adalah sebagai berikut:

1. Pengguna memasuki OS di bawah USG pribadinya dalam mode label yang ia butuhkan. Meluncurkan aplikasi. Proses aplikasi mewarisi label kredensial.
2. Aplikasi berinteraksi dengan database pada PostgreSQL, menampilkan, misalnya, hanya catatan tabel database dengan label kredensial saat ini.

Dari sudut pandang aplikasi server yang menyediakan layanan web, skenario pengguna secara konseptual dekat, meskipun terlihat sedikit lebih rumit:

1. Pengguna memasuki OS di bawah USG pribadinya dalam mode label yang ia butuhkan. Ini meluncurkan browser dengan dukungan MAC, dalam contoh kami, Mozilla Firefox (browser "normal" tidak akan berfungsi untuk tujuan ini). Proses browser mewarisi kredensial.
2. Pengguna meminta alamat sumber daya aplikasi dengan dukungan kredensial. Browser membentuk permintaan dengan menambahkan tanda kredensial untuk itu.
3. Permintaan diproses oleh server web dengan dukungan kredensial, dalam contoh kami, Apache Http Server. Server web (proses yang beroperasi dalam mode kredensial minimum) membaca label kredensial permintaan, menemukan aplikasi penangan dan memulai prosesnya dengan tag kredensial diteruskan.
4. Aplikasi berinteraksi dengan database PostgreSQL, menyampaikan label kredensial dalam kueri.

Kehadiran MAC di sistem operasi memberlakukan pembatasan yang cukup serius pada arsitektur aplikasi. Fakta bahwa dalam OS tanpa model kontrol akses kredensial tampaknya sepele dalam OS dengan MAC dapat membawa banyak kejutan bagi seluruh tim pengembangan. Terutama kepada manajer proyek. Oleh karena itu, arsitektur aplikasi yang mendukung MAC harus dibangun sebelum pengembangan dimulai. Manajer proyek dengan MAC harus bersikeras bahwa desain dilakukan oleh tim arsitektur sebelum ada gerakan menuju implementasi.

Tentu saja, untuk pengembangan aplikasi sederhana (utilitas atau aplikasi, karena spesifisitasnya netral terhadap MAC), banyak tip tidak berguna. Jika aplikasi tersebut adalah sesuatu yang lebih kompleks daripada aplikasi lokal pengguna tunggal yang membaca file dan menulis hasil kerjanya ke file, disarankan untuk memahami dengan jelas "perangkap".

Kami telah menyusun resep untuk merancang aplikasi dengan dukungan MAC, diformulasikan berdasarkan pengalaman kami sendiri. Di belakang mereka ada malam-malam tanpa tidur, aliran tiket yang terus-menerus dari pengujian, ribuan jam debugging aplikasi yang, pada dasarnya, harus bekerja dengan benar, tetapi untuk beberapa alasan tidak berfungsi seperti itu. Resep dijelaskan dalam bentuk teknologi dan alat yang paling sederhana dan netral, dan jika mungkin dilengkapi dengan skema untuk meningkatkan persepsi. Ayo pergi!

Cara menghindari MAC saat itu tidak bisa lagi dihindari

Saat merancang aplikasi dengan MAC, Anda dapat menggunakan satu solusi arsitektur yang sangat sederhana, yang pada akhirnya akan menghemat banyak keberanian dan waktu. Parameter harus ditambahkan ke konfigurasi aplikasi yang memberi tahu aplikasi apakah model kontrol akses kredensial untuk instalasi ini diaktifkan atau tidak. Di semua tempat aplikasi di mana interaksi dengan infrastruktur MAC terjadi, atau fungsi bisnis aplikasi memerlukan verifikasi label, Anda harus terlebih dahulu memeriksa nilai parameter ini. Jika MAC dinonaktifkan sesuai dengan itu, maka aplikasi mengabaikan semua aturan logika bisnis yang dirancang untuk menguji fungsi yang kompatibel dengan MAC.

Dalam hal biaya tenaga kerja, Anda harus menghabiskan waktu tambahan untuk mengimplementasikan setiap fungsi aplikasi dengan dukungan MAC. Anda perlu melakukan debug dan menguji fungsi yang sama dalam mode tanpa label kredensial, sehingga biaya pengujian akan meningkat.

Karena solusi ini, dimungkinkan untuk menyediakan aplikasi (dan seluruh tim pengembangan), yang dipaksa untuk berfungsi di lingkungan MAC, keuntungan-keuntungan berikut:

• Aplikasi lintas platform (hanya dibatasi oleh kemampuan bahasa pemrograman) dan kemandiriannya dari runtime.
• Kemampuan untuk menggunakan alat virtualisasi modern (misalnya, Docker) untuk otomatisasi.
• Kemudahan fitur pengujian dan debugging yang tidak terkait langsung dengan MAC.

Rekomendasi :

Tambahkan opsi untuk mengaktifkan / menonaktifkan dukungan untuk kredensial dalam aplikasi.

Di semua tempat yang membutuhkan interaksi dengan MAC, pertama-tama, periksa nilai parameter.

Ketika debugging dan pengujian, perlu untuk men-debug (di sisi tim pengembangan) dan menguji (di sisi tim uji) kedua mode aplikasi.

Bagilah dan taklukkan

Langkah desain penting lainnya yang harus diselesaikan sebelum dimulainya pengembangan adalah pemisahan modul di mana dukungan MAC diperlukan dari modul di mana mekanisme kontrol akses ini tidak diperlukan. Menggunakan model kontrol akses kredensial hampir selalu menyulitkan logika bisnis suatu aplikasi.

Ini adalah infrastruktur yang sama, abstrak dari yang sangat sulit, dan kadang-kadang tidak mungkin. Oleh karena itu, aplikasi harus dibagi menjadi beberapa modul, dan untuk setiap modul, analisis kebutuhan akan dukungan MAC. Mungkin dalam kasus Anda itu cukup untuk mendukung MAC hanya dalam satu modul, dan tidak ada gunanya karena modul ini mempersulit seluruh aplikasi?
Jika kita mempertimbangkan modul abstrak tertentu (atau seluruh aplikasi, jika pembagian aplikasi ke dalam modul tidak diperlukan), paradigma berikut mungkin terjadi:

• Label minimum. Modul memproses data dalam mode label wajib minimum (label minimum di mana OS memproses operasi - misalnya, 0 label wajib) atau tanpa label wajib.
• Satu label. Modul ini bekerja dengan data hanya satu label wajib di atas label wajib minimum (label apa pun selain label tempat OS beroperasi).
• Beberapa tag. Modul ini bekerja dengan data dari beberapa label wajib sekaligus (baik label di mana proses OS beroperasi, dan label lain selain label proses OS).

Modul aplikasi dengan paradigma pemrosesan kredensial yang berbeda seharusnya tidak terlalu tahu tentang satu sama lain. Kalau tidak, itu penuh dengan munculnya masalah besar dan tak terduga tentang konflik akses ke berbagai objek, dll. Gagasan konektivitas minimal untuk modul jelas. Dalam hal bekerja dengan MAC, Anda harus sangat waspada dan memantau semua "koneksi" modul.
Selanjutnya, kami mempertimbangkan lebih detail fitur desain dengan tiga paradigma untuk memproses kredensial. Untuk melakukan ini, kami membuat sketsa klasifikasi dari sederhana ke kompleks. Klasifikasi ini murni praktis dan diterapkan. Ini hasil dari perbedaan yang terlihat secara intuitif dalam pengembangan berbagai modul, dan dalam praktiknya telah menunjukkan efektivitasnya.

Klasifikasi modul berdasarkan mode pemrosesan MAC

“BRING IT ON”: operasi modul dalam mode kredensial minimum

Motivasi untuk menerapkan mekanisme ini dalam modul:

• Modul memproses informasi yang, pada prinsipnya, tidak dapat diproses dalam sistem dengan kredensial lain, dan tidak memerlukan hak baca / tulis khusus.
• Modul ini terhubung erat dengan infrastruktur OS, yang membatasi fungsinya dalam mode label wajib, yang berbeda dari minimum.

Modul yang beroperasi dalam mode ini harus memeriksa kredensial proses. Jika label proses di mana modul ini berjalan berbeda dari minimum (misalnya, itu tidak sama dengan label wajib 0), semua operasi (kecuali untuk melihat) harus dilarang pada tingkat logika bisnis aplikasi. Artinya, kami mungkin tidak mengizinkan pengguna untuk menggunakan modul ini jika ia mendatangi kami dalam sesi label kredensial selain nol.

Contoh kasus praktis yang cocok dengan penggunaan mode label wajib minimum:

• Kelola akun pengguna di toko aplikasi. Misalnya, jika aplikasi menyimpan catatan ultrasound dalam file atau database. Semua data yang terkait dengan keamanan dan kontrol akses aplikasi harus disimpan dalam mode kredensial minimum, jika tidak, model keamanan aplikasi hanya akan "hancur" ketika aplikasi berjalan dalam mode tanda kredensial. Karena alasan ini, semua aplikasi sistem dijalankan secara ketat di bawah kredensial minimum.
• Manajemen Hak Akses. Misalnya, jika aplikasi mengimplementasikan model kontrol aksesnya sendiri pada level logika bisnis.
• Kelola pengaturan konfigurasi aplikasi yang harus tersedia di bawah semua kredensial.
• Manajemen Akun di OS. Jika aplikasi perlu mengelola atribut KM di OS, semua operasi harus dilakukan secara ketat di bawah tanda kredensial minimum.

"HURT ME PLENTY": operasi modul dalam mode kredensial tunggal

Kasus ini sedikit lebih rumit, tetapi dalam banyak hal mirip dengan kasus dengan tanda kredensial minimum. Dari sudut pandang pengguna, bekerja dengan aplikasi tidak banyak berubah: semua daftar catatan yang sama, kartu dan operasi "Lihat", "Edit" dan "Simpan". Satu-satunya perbedaan adalah bahwa dalam mode ini pengguna hanya melihat catatan yang sesuai dengan tanda kredensial sesi saat ini.

Opsi terbatas juga dapat dikembangkan: modul menangkap nilai parameter "label kredensial default". Dalam hal ini, pengoperasian modul hanya dimungkinkan dengan label kredensial yang ditentukan, tetapi opsi ini lebih mudah diterapkan.

Kasus ini dapat bermanfaat dalam kasus-kasus berikut:

• Ada kesalahan dalam arsitektur ketika merancang modul (fitur pemrosesan catatan di MAC tidak diletakkan), dan tidak ada waktu atau sumber daya untuk menulis ulang semuanya.
• Dukungan untuk model kontrol akses kredensial diperkenalkan ke dalam aplikasi yang sudah berfungsi, dan sesuai dengan persyaratan, perlu untuk memastikan bekerja dengan label di atas minimum dalam OS. Ya, ini adalah kasus ketika kepala datang kepada Anda dan memberi tahu Anda dengan senang hati bahwa kami memenangkan kontes dan akan menerapkan keputusan kami dalam "nama departemen rahasia" !
• Tidak ada alasan untuk menerapkan dukungan penuh untuk pemrosesan simultan catatan berbagai kredensial. Tidak perlu untuk memproses secara bersamaan catatan beberapa kredensial sekaligus.
• Aplikasi beroperasi dalam mode satu pengguna.

Dari sudut pandang implementasi, kasus ini tidak terlalu sederhana, karena kita perlu:

• Pilih hanya rekaman yang sesuai dengan label wajib saat ini, karena menurut model Bell-Lapadula, pengguna akan melihat catatan dari label wajib saat ini dan semua label wajib yang berada di bawah hierarki.
• Periksa tanda kredensial sebelum melakukan operasi apa pun untuk memodifikasi catatan. Jika Anda mencoba untuk membuat perubahan ke entri dengan label kredensial yang berbeda dari label kredensial untuk sesi, operasi harus dibatalkan.

Saat melakukan operasi dalam modul, disarankan untuk memeriksa label kredensial proses aplikasi saat ini dengan label kredensial default. Jika label kredensial modul tidak cocok dengan label kredensial sesi, maka pengguna tidak boleh melakukan operasi.

Contoh kasus praktis yang cocok dengan penggunaan mode label kredensial tunggal:

• . , ( , ..). , . .
• . , , ( ) . «» , « », «» .

«NIGHTMARE!»:

Mode operasi ini hanya berguna jika dalam satu sesi dengan modul kita perlu menampilkan informasi tentang semua kredensial yang terletak di bawah kredensial sesi saat ini dalam hierarki.

Ketika merancang, perlu untuk menggambarkan persyaratan fungsional untuk modul, dan dalam rincian masing-masing persyaratan fungsional, menunjukkan daftar interaksi dalam hal model wajib (opsi yang mungkin dibahas di bawah ini di bagian "Interaksi antara aplikasi dan lingkungan"). Ini akan menyoroti beberapa konsep umum interaksi dengan infrastruktur terkait tag wajib. Juga, informasi ini akan sangat berguna untuk menilai kompleksitas pengembangan dan pengujian lebih lanjut.

Dalam hal implementasi antarmuka pengguna, pola berikut umum digunakan:

• (, ) ( ). , .
• / / , .
• / ( ).

Set lebih lanjut dari proses bisnis tergantung pada kompleksitas logika bisnis dari modul dan spesifikasi pemrosesan data. Misalnya, Anda bisa memfilter koleksi catatan dengan label kredensial. Anda dapat menampilkan label rekaman kredensial di antarmuka.

Cakupan kombinasi sangat besar, seperti ruang untuk kesalahan muncul. Oleh karena itu, tidak disarankan untuk memproses catatan dengan tag kredensial berbeda dalam kasus pengguna yang sama di hadapan logika bisnis apa pun. Setiap operasi dengan koleksi catatan harus dilakukan dengan indikasi eksplisit kredensial yang umum untuk seluruh koleksi. Memproses tanda ketiga, lalu yang kedua, dll.

Untuk menerapkan rezim seperti itu, perlu untuk meletakkan fungsi-fungsi berikut:

• Fungsi mendapatkan label kredensial dari proses aplikasi saat ini (sesi pengguna).
• Fungsi mendapatkan tanda kredensial untuk catatan (jika itu adalah masalah bekerja dengan catatan di database) atau file (jika itu adalah pertanyaan pemrosesan file).
• Fungsi menerima label kredensial dari catatan / file database dalam koleksi

Contoh kasus praktis yang cocok dengan mode kredensial ganda:

1. Pelaporan Untuk menerapkan kasus ini, kita perlu mengakumulasi maksimum informasi pada sistem, yang tersedia untuk sesi dengan label wajib saat ini.
2. Majalah. Dalam hal ini, antarmuka dikembangkan untuk melihat semua yang tersedia untuk melihat operasi dengan kemampuan untuk memfilter, termasuk oleh label kredensial.

Interaksi Lingkungan

Aplikasi dalam lingkungan MAC berinteraksi dengan daftar komponen tertentu di sekitarnya. Secara skematis sesuai dengan fitur interaksi, mereka dapat diklasifikasikan sebagai berikut:

• Sistem operasi:
  
  • Parameter model kredensial:
    
    • Hirarki label wajib OS;
    • Izin wajib (rentang label yang dapat digunakan pengguna tertentu) pengguna OS.
  • Penyimpanan kredensial pengguna
  • Otentikasi di OS (termasuk mempertimbangkan kredensial akun);
  • Mekanisme kontrol akses lainnya (discretionary POSIX ACL, UNIX, dll.);
  • Bekerja dengan FS;
  • Manajemen proses;
  • Bekerja dengan jaringan;
• Perangkat lunak pihak ketiga tanpa dukungan MAC;
• Perangkat lunak pihak ketiga dengan dukungan MAC:
  
  • DBMS (mis. PostgreSQL):
    
    • Objek basis data (sel, baris, kolom, skema, tabel, basis data, kelompok, urutan, fungsi, dll.).
• Pengguna

Kami akan mempertimbangkan nuansa interaksi dengan masing-masing komponen secara terpisah.

Interaksi aplikasi yang kompatibel dengan MAC dengan sistem operasi

MAC sangat "senang" dengan kesulitannya dalam menetapkan aturan akses dalam sistem file. Misalnya, bagian terbesar kesalahan dalam aplikasi MAC terhubung dengan fakta bahwa aplikasi tidak melihat file dalam mode tanda kredensial saat ini, tetapi file tersebut ada dalam mode tanda kredensial lain (satu tingkat lebih tinggi).

Apa yang kita harapkan dari sistem operasi dalam hal MAC?

Jika aplikasi kami berfungsi dalam mode multi-pengguna, maka mungkin perlu meminta informasi tentang akun pengguna yang datanya diproses. Ini diperlukan untuk mendukung kontrol akses pengguna. Oleh karena itu, aplikasi perlu meminta informasi dari OS tentang kredensial pengguna. Jika KM pengguna di OS dikendalikan oleh aplikasi kita, maka kita tidak hanya perlu membaca informasi tentang KM, tetapi juga mengelola atribut KM.

Aliran interaksi yang paling mungkin antara OS dan aplikasi ditunjukkan dalam diagram:

Interaksi aplikasi yang kompatibel dengan MAC dengan perangkat lunak pihak ketiga tanpa dukungan MAC

Sebagian besar aplikasi yang dapat digunakan dalam OS dengan MAC tidak tahu bagaimana memproses MAC.

Karena itu, ketika mengatur interaksi seperti itu, diperlukan untuk meniru label kredensial ketika mentransfer data atau meminta proses aplikasi semacam itu. Ini diwujudkan dengan "stratifikasi" aliran data ke saluran yang terpisah, masing-masing dirancang secara logis untuk data dengan label wajib tertentu. Sangat dilarang untuk mencampurkan data tersebut, mereka harus melalui antrian, saluran, dan hampir terpisah melalui kabel yang terpisah dari pasangan bengkok ke antarmuka jaringan. Validitas implementasi "logis" dari pemisahan data oleh MAC juga merupakan masalah kontroversial, oleh karena itu, paling sering terletak pada hati nurani pelanggan dan pengembang aplikasi.

Kemampuan untuk menggunakan aplikasi tanpa MAC oleh aplikasi yang berjalan dalam mode MAC tergantung pada metode interaksi yang dipilih, spesifikasinya, dan fitur implementasi dari pemrosesan data yang masuk dalam aplikasi.

Interaksi aplikasi yang kompatibel dengan MAC dengan perangkat lunak pihak ketiga dengan dukungan MAC

Dalam hal interaksi dengan perangkat lunak dengan dukungan MAC, aplikasi kita harus jelas dapat membaca label proses yang membuat permintaan dan melakukan operasi sesuai dengan model kontrol akses wajib. Aplikasi yang berinteraksi dengan perangkat lunak tersebut hanya diperlukan untuk memenuhi permintaan aplikasi / proses pihak ketiga dari suatu proses dengan tanda kredensial yang benar.

Contoh aplikasi populer dengan dukungan penuh untuk label wajib adalah PostgresSQL. Dalam varian tertentu pengiriman DBMS ini, dukungan penuh untuk MAC diimplementasikan untuk beberapa OS dengan mekanisme MAC, misalnya:

• Astra Linux: PostgreSQL, yang dilengkapi dengan versi SE distribusi kit.
• SELinux: ekstensi sepgsql.

PostgreSQL memungkinkan Anda untuk memisahkan data dengan label kredensial (masih ada dukungan untuk kategori kredensial, tetapi kami tertarik pada label) pada level berikut:

• Di tingkat cluster.
• Di tingkat basis data klaster.
• Pada tingkat skema database cluster.
• Di tingkat tabel skema basis data klaster.
• Di tingkat kolom tabel skema database cluster.
• Pada tingkat catatan tabel skema database cluster.

Akibatnya, dalam implementasi MAC, kami mendapatkan "boneka bersarang" seperti itu: setiap level "induk" memaksakan batasannya sendiri pada semua level "anak". Oleh karena itu, ketika menerapkan interaksi dengan setiap aplikasi yang serupa dengan dukungan penuh untuk MAC, perlu untuk mempertimbangkan spesifik kerjanya. Tidak ada resep universal.

Interoperabilitas Pengguna dari Aplikasi yang Kompatibel dengan MAC

Betapapun anehnya aspek interaksi ini dibandingkan dengan yang dipertimbangkan sebelumnya, mustahil untuk tidak memikirkannya. Lagipula, itu untuk pengguna bahwa aplikasi dengan dukungan MAC paling sering dibangun, bukan?

Aplikasi dengan dukungan MAC praktis tidak berbeda dari yang tanpa MAC dalam hal antarmuka pengguna di semua mode, kecuali untuk mode kerja simultan dengan banyak kredensial.

Pada contoh aplikasi web yang umum saat ini, kasus-kasus berikut paling sering ditemukan:

Kesimpulan

Kami melihat beberapa aspek dalam mengembangkan aplikasi dengan dukungan MAC. Tentu saja sulit memperkirakan semua kasus. Sebagian besar fitur model kredensial tergantung pada implementasi yang tersedia untuk digunakan di OS yang dipilih.

Dukungan untuk aplikasi MAC bukanlah “fitur” tambahan dari aplikasi. Ini adalah solusi arsitektur serius yang memerlukan perencanaan dan desain. "Rasa sakit" terbesar bagi perancang aplikasi yang kompatibel dengan MAC:

• interaksi dengan infrastruktur OS (sistem file, interaksi jaringan, memulai proses dengan label kredensial yang diinginkan jika aplikasi dijalankan di server);
• interaksi dengan perangkat lunak aplikasi dengan dukungan MAC bawaan (misalnya, DBMS);
• interaksi pengguna mengenai pemrosesan yang benar dari operasi yang kompatibel dengan MAC.

Itu saja untuk sekarang! Tambahan, pengalaman pribadi dan komentar pada artikel ini disambut baik!