Memahami gaya keamanan protokol ganda dan perilaku izin di Azure NetApp Files
SMB dan NFS menggunakan model izin yang berbeda untuk akses pengguna dan grup. Akibatnya, volume Azure NetApp File harus dikonfigurasi untuk mematuhi model izin yang diinginkan untuk akses protokol. Untuk lingkungan khusus NFS, keputusannya sederhana - gunakan gaya keamanan UNIX. Untuk lingkungan khusus SMB, gunakan gaya keamanan NTFS.
Jika NFS dan SMB pada himpunan data yang sama (protokol ganda) diperlukan, maka keputusan harus dibuat berdasarkan dua pertanyaan:
- Protokol apa yang paling banyak akan dikelola pengguna?
- Apa titik akhir manajemen izin yang diinginkan? Dengan kata lain, apakah pengguna memerlukan kemampuan untuk mengelola izin dari klien NFS atau klien Windows? Atau keduanya?
Gaya keamanan volume benar-benar dapat dianggap sebagai gaya izin, di mana gaya manajemen ACL yang diinginkan adalah faktor penentu.
Catatan
Gaya keamanan dipilih pada pembuatan volume. Setelah gaya keamanan dipilih, gaya keamanan tidak dapat diubah.
Tentang gaya keamanan volume Azure NetApp Files
Ada dua pilihan utama untuk gaya keamanan volume di Azure NetApp Files:
UNIX - Gaya keamanan UNIX menyediakan izin gaya UNIX, seperti bit mode POSIX dasar (akses Pemilik/Grup/Semua Orang dengan izin Baca/Tulis/Jalankan standar, seperti 0755) dan ACL NFSv4.x. ACL POSIX tidak didukung.
NTFS - Gaya keamanan NTFS menyediakan fungsionalitas yang identik sebagai izin Windows NTFS standar, dengan pengguna dan grup terperinci dalam ACL dan izin keamanan/audit terperinci.
Dalam lingkungan NAS protokol ganda, hanya satu gaya izin keamanan yang dapat aktif. Anda harus mengevaluasi pertimbangan untuk setiap gaya keamanan sebelum memilihnya.
| Gaya Keamanan | Pertimbangan |
|---|---|
| UNIX | - Klien Windows hanya dapat mengatur atribut izin UNIX melalui SMB yang memetakan ke atribut UNIX (Baca/Tulis/Jalankan saja; tidak ada izin khusus). - ACL NFSv4.x tidak memiliki manajemen GUI. Manajemen dilakukan hanya melalui CLI menggunakan perintah nfs4_getfacl dan nfs4_setfacl. - Jika file atau folder memiliki ACL NFSv4.x, tab properti keamanan Windows tidak dapat menampilkannya. |
| NTFS | - Klien UNIX tidak dapat mengatur atribut melalui NFS melalui perintah seperti chown/chmod. - Klien NFS hanya menunjukkan perkiraan izin NTFS saat menggunakan ls perintah. Misalnya, jika pengguna memiliki izin di Windows NTFS ACL yang tidak dapat diterjemahkan dengan bersih ke dalam bit mode POSIX (seperti direktori melintasi), itu diterjemahkan ke dalam nilai mode-bit POSIX terdekat (seperti 1 untuk dieksekusi). |
Pemilihan gaya keamanan volume menentukan bagaimana pemetaan nama untuk pengguna dilakukan. Operasi ini adalah bagian inti dari bagaimana volume protokol ganda mempertahankan izin yang dapat diprediksi terlepas dari protokol yang digunakan.
Gunakan tabel berikut sebagai matriks keputusan untuk memilih gaya keamanan volume yang tepat.
| Gaya Keamanan | Sebagian besar NFS | Sebagian besar SMB | Kebutuhan akan keamanan terperinci |
|---|---|---|---|
| UNIX | X | - | X (menggunakan ACL NFSv4.x) |
| NTFS | - | X | X |
Cara kerja pemetaan nama di Azure NetApp Files
Di Azure NetApp Files, hanya pengguna yang diautentikasi dan dipetakan. Grup tidak dipetakan. Sebagai gantinya, keanggotaan grup ditentukan dengan menggunakan identitas pengguna.
Saat pengguna mencoba mengakses volume Azure NetApp Files, upaya tersebut meneruskan identitas ke layanan. Identitas tersebut mencakup nama pengguna dan pengidentifikasi numerik unik (nomor UID untuk NFSv3, string nama untuk NFSv4.1, SID untuk SMB). Azure NetApp Files menggunakan identitas tersebut untuk mengautentikasi terhadap layanan nama yang dikonfigurasi untuk memverifikasi identitas pengguna.
- Pencarian LDAP untuk ID numerik digunakan untuk mencari nama pengguna di Direktori Aktif.
- String nama menggunakan pencarian LDAP untuk mencari nama pengguna dan klien dan server berkonsultasi dengan domain ID yang dikonfigurasi untuk NFSv4.1 untuk memastikan kecocokan.
- Pengguna Windows dikueri menggunakan panggilan RPC Windows standar ke Direktori Aktif.
- Keanggotaan grup juga dikueri, dan semuanya ditambahkan ke cache kredensial untuk pemrosesan yang lebih cepat pada permintaan berikutnya ke volume.
- Saat ini, pengguna lokal kustom tidak didukung untuk digunakan dengan Azure NetApp Files. Hanya pengguna di Direktori Aktif yang dapat digunakan dengan protokol ganda.
- Saat ini, satu-satunya pengguna lokal yang dapat digunakan dengan volume protokol ganda adalah root dan
nfsnobodypengguna.
Setelah nama pengguna diautentikasi dan divalidasi oleh Azure NetApp Files, langkah selanjutnya untuk autentikasi volume protokol ganda adalah pemetaan nama pengguna untuk interoperabilitas UNIX dan Windows.
Gaya keamanan volume menentukan bagaimana pemetaan nama berlangsung di Azure NetApp Files. Semantik izin Windows dan UNIX berbeda. Jika pemetaan nama tidak dapat dilakukan, autentikasi gagal, dan akses ke volume dari klien ditolak. Skenario umum di mana situasi ini terjadi adalah ketika akses NFSv3 dicoba ke volume dengan gaya keamanan NTFS. Permintaan akses awal dari NFSv3 datang ke Azure NetApp Files sebagai UID numerik. Jika pengguna bernama user1 dengan ID 1001 numerik mencoba mengakses pemasangan NFSv3, permintaan autentikasi tiba sebagai ID 1001numerik . Azure NetApp Files kemudian mengambil ID 1001 numerik dan mencoba mengatasi 1001 nama pengguna. Nama pengguna ini diperlukan untuk pemetaan ke pengguna Windows yang valid, karena izin NTFS pada volume akan berisi nama pengguna Windows alih-alih ID numerik. Azure NetApp Files akan menggunakan server layanan nama (LDAP) yang dikonfigurasi untuk mencari nama pengguna. Jika nama pengguna tidak dapat ditemukan, autentikasi gagal, dan akses ditolak. Operasi ini dirancang untuk mencegah akses yang tidak diinginkan ke file dan folder.
Pemetaan nama berdasarkan gaya keamanan
Arah di mana pemetaan nama terjadi di Azure NetApp Files (Windows ke UNIX, atau UNIX ke Windows) tidak hanya bergantung pada protokol yang digunakan tetapi juga gaya keamanan volume. Klien Windows selalu memerlukan pemetaan nama Windows-ke-UNIX untuk mengizinkan akses, tetapi tidak selalu memerlukan nama pengguna UNIX yang cocok. Jika tidak ada nama pengguna UNIX yang valid di server layanan nama yang dikonfigurasi, Azure NetApp Files menyediakan pengguna UNIX default fallback dengan UID 65534 numerik untuk memungkinkan autentikasi awal untuk koneksi SMB. Setelah itu, izin file dan folder akan mengontrol akses. Karena 65534 umumnya sesuai dengan nfsnobody pengguna, akses dibatasi dalam banyak kasus. Sebaliknya, klien NFS hanya perlu menggunakan pemetaan nama UNIX-ke-Windows jika gaya keamanan NTFS sedang digunakan. Tidak ada pengguna Windows default di Azure NetApp Files. Dengan demikian, jika pengguna Windows yang valid yang cocok dengan nama yang meminta tidak dapat ditemukan, akses akan ditolak.
Tabel berikut memecah permutasi pemetaan nama yang berbeda dan bagaimana mereka berperilaku tergantung pada protokol yang digunakan.
| Protokol | Gaya Keamanan | Arah pemetaan nama | Izin diterapkan |
|---|---|---|---|
| SMB | UNIX | Windows ke UNIX | UNIX (mode-bits atau NFSv4.x ACL) |
| SMB | NTFS | Windows ke UNIX | ACL NTFS (berdasarkan Windows SID yang mengakses berbagi) |
| NFSv3 | UNIX | Tidak | UNIX (mode-bit atau NFSv4.x ACL*) |
| NFSv4.x | UNIX | ID Numerik ke nama pengguna UNIX | UNIX (mode-bits atau NFSv4.x ACL) |
| NFS3/4.x | NTFS | UNIX ke Windows | ACL NTFS (berdasarkan SID pengguna Windows yang dipetakan) |
Catatan
Aturan pemetaan nama di Azure NetApp Files saat ini hanya dapat dikontrol dengan menggunakan LDAP. Tidak ada opsi untuk membuat aturan pemetaan nama eksplisit dalam layanan.
Layanan nama dengan volume protokol ganda
Terlepas dari protokol NAS apa yang digunakan, volume protokol ganda menggunakan konsep pemetaan nama untuk menangani izin dengan benar. Dengan demikian, layanan nama memainkan peran penting dalam mempertahankan fungsionalitas di lingkungan yang menggunakan SMB dan NFS untuk akses ke volume.
Layanan nama bertindak sebagai sumber identitas untuk pengguna dan grup yang mengakses volume NAS. Operasi ini mencakup Direktori Aktif, yang dapat bertindak sebagai sumber untuk pengguna dan grup Windows dan UNIX menggunakan layanan domain standar dan fungsionalitas LDAP.
Layanan nama bukan persyaratan yang sulit tetapi sangat disarankan untuk volume protokol ganda Azure NetApp Files. Tidak ada konsep pembuatan pengguna dan grup lokal kustom dalam layanan. Dengan demikian, untuk memiliki autentikasi yang tepat dan informasi pemilik pengguna dan grup yang akurat di seluruh protokol, LDAP adalah kebutuhan. Jika Anda hanya memiliki beberapa pengguna dan Anda tidak perlu mengisi informasi identitas pengguna dan grup yang akurat, pertimbangkan untuk menggunakan fungsionalitas Izinkan pengguna NFS lokal dengan LDAP untuk mengakses fungsionalitas volume protokol ganda. Perlu diingat bahwa mengaktifkan fungsionalitas ini menonaktifkan fungsionalitas grup yang diperluas.
Ketika klien, layanan nama, dan penyimpanan berada di area yang berbeda
Dalam beberapa kasus, klien NAS mungkin tinggal di jaringan tersegmentasi dengan beberapa antarmuka yang memiliki koneksi terisolasi ke layanan penyimpanan dan nama.
Salah satu contohnya adalah jika penyimpanan Anda berada di Azure NetApp Files, sementara klien NAS dan layanan domain Anda semuanya berada di lokal (seperti arsitektur hub-spoke di Azure). Dalam skenario tersebut, Anda harus menyediakan akses jaringan ke klien NAS dan layanan nama.
Gambar berikut menunjukkan contoh konfigurasi semacam itu.
