Apakah ini pendekatan yang disarankan / valid untuk izin server file?

File server adalah fakta kehidupan di TI dan saya ingin tahu apakah ada praktik yang diterima secara umum (saya ragu untuk menggunakan kata "terbaik" di sini) untuk cara Anda membuat grup dan menerapkan izin untuk mengelola akses klien ke folder bersama di server file.

Pada pekerjaan saya saat ini, saya akhirnya mewarisi cukup banyak cara yang berbeda untuk melakukan ini mulai dari lusinan kelompok di ACL hingga menempatkan pengguna secara langsung pada sistem file. Tugas saya adalah untuk membereskan kekacauan dan menghasilkan semacam cara standar untuk mendekati ini di seluruh perusahaan (lingkungan besar, 150k personel, 90k komputer klien, 100-an server file).

Dari pemahaman saya tentang masalah ini, tampaknya Anda setidaknya membutuhkan satu grup per tingkat akses yang diperlukan per sumber daya aman. Model ini tampaknya memberikan fleksibilitas paling besar karena Anda tidak perlu menyentuh lagi izin sistem file kecuali Anda perlu mendukung level akses yang berbeda. Kelemahannya adalah Anda akan membuat lebih banyak grup daripada menggunakan kembali grup yang sama di beberapa sumber daya bersama.

Berikut adalah contoh yang menunjukkan apa yang saya maksud:

Ada bagian yang disebut "Hasil Uji" keluar pada server file bernama FILE01 dan Anda memiliki orang-orang yang membutuhkan akses hanya baca, akses baca-tulis, dan kontrol penuh. 1 sumber daya aman * 3 tingkat akses = 3 grup keamanan. Di lingkungan AD kami, kami membuat ini sebagai grup universal sehingga kami dapat dengan mudah menambahkan pengguna / grup dari salah satu domain di hutan. Karena setiap grup secara unik merujuk ke folder bersama dan tingkat akses, nama-nama grup menggabungkan potongan-potongan data "kunci" dan dengan demikian:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

Biasanya, kami juga akan menyertakan akun SISTEM bawaan dan Administrator bawaan dengan akses Kontrol Penuh juga. Setiap perubahan pada siapa yang benar-benar mendapatkan akses ke bagian ini sekarang dapat ditangani menggunakan keanggotaan grup daripada harus menyentuh ACL (baik dengan menambahkan grup "Peran" yang mewakili peran bisnis tertentu seperti Manajer, Teknisi, Analis QA, dll. Atau hanya individu) pengguna untuk akses satu kali).

Dua pertanyaan:

1) Apakah ini sebenarnya pendekatan yang direkomendasikan atau valid untuk menangani izin atau apakah saya melewatkan solusi yang lebih sederhana dan lebih elegan? Saya secara khusus tertarik pada solusi apa pun yang menggunakan pewarisan tetapi tetap mempertahankan fleksibilitas karena tidak harus kembali ACL bagian besar dari sistem file ketika ada perubahan.

2) Bagaimana Anda menangani izin server file dan struktur grup di lingkungan Anda? Poin bonus untuk mereka yang juga bekerja di lingkungan yang besar.

Pendekatan saya adalah untuk tidak menggunakan izin file tingkat direktori / file; menggunakan izin tingkat berbagi file, dan mengatur seluruh drive data sistem file server untuk Semua Orang Kontrol Penuh (yang menjadi diperdebatkan).

Selama bertahun-tahun (10+), saya telah menemukan bahwa izin NTFS lebih kompleks dan mengarah ke lebih banyak kesalahan. Jika izin ditetapkan salah, atau warisan rusak, Anda mengekspos data dan sulit untuk menemukan dan melihatnya. Plus, Anda terkena masalah memindahkan / menyalin ... pengguna memindahkan file juga memindahkan ACL file, sedangkan salinan mewarisi ACL tujuan.

Gunakan grup baca / tulis Anda sama, tetapi secara keseluruhan bagikan file menggunakan Mgmt MMC Comp. Jangan lakukan penuh ... pengguna akan menembak diri mereka sendiri dengan pengetahuan sebagian / niat terbaik.

Pendekatan itu tidak buruk. Sebagai aturan, jangan pernah menggunakan pengguna individu untuk menambahkan izin - gunakan grup. Namun kelompok dapat digunakan di seluruh sumber daya. Misalnya SDM mungkin memiliki akses RW ke file sementara MANAJER mungkin punya R. Anda juga dapat mengatur Enumerasi Berbasis Akses. Lihatlah webcast berikut:

TechNet Webcast: Seri Administrasi Windows Server 2003 (Bagian 4 dari 12): Manajemen Grup (Level 200)

Penghitungan berdasarkan akses dapat membuat hidup lebih mudah juga melihat:

Enumerasi berbasis akses

ABE dapat membantu mengurangi jumlah saham yang berbeda yang harus Anda kelola.

Pendekatan Anda pada dasarnya adalah cara saya akan mendekatinya.
Satu-satunya hal yang akan saya tambahkan adalah ini:

1) Saya akan menambah skema "peran" Anda dengan mengevaluasi apa yang mereka butuhkan di seluruh server bukan hanya pada satu server yang mungkin akan Anda hadapi dengan outlier, tetapi teori saya dengan itu adalah ketika Anda bertemu dengannya, buat grup lain. dalam pengalaman saya di mana ada satu outlier ada banyak.

2) SAYA SANGAT akan mengevaluasi kembali kebutuhan untuk grup Universal untuk semuanya ketika Anda menerima replikasi dengan mereka ketika anggota dan grup di dalam grup Universal direplikasi ke server Katalog Global sementara dengan Domain Lokal dan Global hanya grup yang direplikasi ke server katalog global. Jadi, jika Anda membuat perubahan dalam grup universal, ia memulai replikasi, sedangkan dengan global dan domain lokal tidak.

Metode Anda menggunakan grup sumber daya untuk setiap tingkat akses sudah benar. Satu-satunya hal yang saya pertimbangkan adalah menggunakan Domain Local Groups untuk sumber daya. Anda tidak perlu menggunakan Grup Universal jika Anda membuat grup sumber daya khusus server.

Kelemahan menggunakan Grup Lokal Domain untuk sumber daya adalah Anda memiliki lebih banyak grup total. Sisi positifnya adalah Anda memiliki lebih sedikit masalah dengan replikasi, seperti yang dicatat Zypher.

Pendekatan yang diusulkan tampaknya cukup solid. Satu hal yang perlu diwaspadai adalah cara Anda awalnya mengatur berbagi file. Praktik yang disarankan adalah memiliki satu saham tingkat atas, yang berisi subfolder yang kemudian Anda tetapkan izin grupnya. NTFS kemudian dapat memotong "Traverse Folder / Execute File" pada folder tingkat atas dan memberikan akses ke subfolder.

Struktur kemudian akan terlihat seperti \ servername \ sharename \ group-folder, dengan izin berbagi hanya perlu diatur pada folder "sharename", dan izin NTFS yang sebenarnya ditetapkan pada folder "folder-folder".

Server file Anda akan dapat melakukan lebih baik dengan pengaturan semacam ini juga.

Umum hal lain yang akan saya lakukan adalah memiliki konvensi penamaan untuk grup sehingga nama grup sama dengan nama folder grup (dengan FC / RW / RO ditambahkan jika diinginkan), dan menempelkan UNC ke folder ke dalam deskripsi grup (agar skrip logon Anda dapat membacanya kembali dan mengatur pemetaan drive seperti itu, dan juga agar Anda dapat lebih mudah melihat folder bersama apa yang berlaku untuk grup mana).

Praktik standar yang telah saya gunakan untuk file server Windows sejak Windows 2000 (dijelaskan dalam seri Menguasai Windows Server Mark Minasi, jadi lihat di sana untuk info lebih lanjut) adalah menggunakan grup yang lokal ke server file itu sendiri untuk bersarang.

Misalnya, pertimbangkan server file bernama KERMIT dalam domain yang disebut MUPPETS.

Katakanlah KERMIT memiliki beberapa file yang dibagikan:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Buat grup lokal untuk KERMIT untuk akses dan beri mereka izin pada sistem file persis seperti yang Anda tentukan (yaitu satu grup per tingkat akses per saham)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Karena ini adalah grup lokal, Anda dapat memasukkan grup atau pengguna lain apa pun yang Anda inginkan di dalamnya - domain grup lokal, grup global, grup universal, akun pengguna dari domain apa pun di hutan Anda. Manajemen hak sekarang bersifat lokal untuk grup server file daripada sistem file atau AD.

Ini memang menambahkan lapisan tambahan ke manajemen grup Anda, tetapi memiliki manfaat memungkinkan (misalnya) admin situs-lokal untuk mengelola server file mereka sendiri tanpa memerlukan apa pun selain hak Admin untuk server file itu. Jika Anda memiliki semacam struktur kantor cabang gabungan, di mana setiap jenis kantor melakukan hal sendiri dengan servernya, ini bisa menjadi manfaat nyata. Anda mungkin tidak ingin harus memberikan hak admin AD ke beberapa lusin admin situs lokal.

Ini juga menjaga agar AD Anda tidak berantakan dengan banyak grup (satu grup per level akses per share per server dapat bertambah dengan sangat cepat), dan meminimalkan replikasi grup antar GC. Ini memungkinkan Anda untuk memesan grup AD Anda untuk peran alih-alih izin.

Jika lingkungan Anda distandarisasi secara ketat dan semua server file identik dan direplikasi, maka ini jelas merupakan satu lagi lapisan grup yang tidak Anda butuhkan. Juga, jika Anda tahu Anda memerlukan grup AD tertentu untuk memiliki hak yang sama pada share yang ada di setiap server file tunggal, Anda akan memerlukan beberapa otomatisasi untuk mempertahankannya.

Singkatnya, semakin berbeda file server Anda satu sama lain, semakin banyak menggunakan grup mesin lokal masuk akal. Semakin mirip, semakin Anda ingin menggunakan sistem yang Anda gunakan saat ini.

Saya sedang melihat migrasi dari NetWare ke Windows Server 2008 jadi ini sudah banyak di pikiran saya belakangan ini. Server 2008 (dan sampai tingkat tertentu Server 2003R2) memiliki beberapa fitur yang sangat bagus yang sangat memudahkan transisi ini. Server 2008 hadir dengan Enumerasi Berbasis Akses di luar kotak. Ini adalah fitur yang sangat bagus yang memungkinkan pengguna hanya melihat direktori tempat mereka memiliki hak. Jika Anda memiliki saham seperti ...

\\ user-home-srv \ homes \

Tanpa ABE, pengguna akhir akan melihat puluhan / ratusan / ribuan direktori. Dengan ABE, pengguna akhir hanya akan melihat satu. Hal yang sama berlaku untuk saham yang dibagikan. Dengan ABE, Anda dapat memiliki volume yang sangat besar untuk semua direktori departemen Anda jika diinginkan, dan tidak mengirim spam kepada pengguna dengan direktori yang tidak dapat mereka masuki. Meskipun bukan masalah ACL, ini agak terkait jadi saya membawanya ke atas.

Hal lain yang tampaknya dilakukan Server 2008 lebih baik daripada versi sebelumnya adalah pewarisan ACL. Sepertinya lebih cepat menyebar ke daun perubahan ACL di atas pohon besar.

Karena warisan Netware kami, kami memiliki sejumlah besar kelompok yang diberi nama berdasarkan siapa yang ada di dalamnya, dengan beberapa di luar sana diberi nama untuk apa yang mereka berikan akses. Untuk direktori yang memiliki akses ketat, kami juga menggunakan nomenklatur "RO" "Full".

Kami memiliki volume "bersama" monolitik (masih di NetWare, tetapi kami berencana untuk menggunakannya secara monolitik ketika kami pindah ke Windows) yang merupakan volume bersama tunggal untuk semua 4.400 pekerja, dan memiliki lebih dari 3,5 juta file di dalamnya. Direktori tingkat atas adalah semua nama departemen, dan setiap departemen mengatur apa yang terjadi di dalamnya. Ada beberapa pengecualian untuk departemen yang sangat besar, mereka memiliki direktori tingkat 2 dengan ACL.

Pada pekerjaan terakhir saya, kami bahkan dapat mengatur izin sehingga karyawan SDM yang melamar pekerjaan tidak akan dapat melihat data aplikasi mereka sendiri di server mereka. Dibutuhkan beberapa filter hak-hak-warisan untuk melakukannya, yang mirip dengan tag "block inheritance" di Windows. Bagian rumit di sana adalah mendokumentasikan semua itu, tetapi berhasil .

Skenario kasus terbaik adalah memiliki setiap pengguna ditambahkan ke hanya satu grup keamanan untuk peran pekerjaan pengguna. Peran tersebut kemudian merupakan akses yang didelegasikan jika diperlukan.

Sama, folder bersama harus diberikan akses menggunakan grup keamanan "sumber", seperti contoh "FILE01-Test Results-RW" Anda. Ini akan berisi peran pekerjaan, peran departemen, atau grup lain yang berlaku.

Kelebihan dari desain ini adalah Anda mendelegasikan akses berdasarkan per-kelompok (tim, departemen, dll.), Dan bukan akses satu kali yang bisa sulit dilacak. Ketika seorang pengguna transfer ke departemen lain, Anda perlu membersihkan semua akses lama.

Kelemahannya adalah bahwa kelompok dapat disalahgunakan. Buat perbedaan yang jelas untuk apa kelompok digunakan, sehingga kelompok sumber daya yang ditugaskan untuk berbagi tidak digunakan kembali seolah-olah mereka adalah kelompok departemen, menciptakan kekacauan akses yang kusut.