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

10

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.

— David Archer
sumber

Pertanyaan yang sangat menarik. +1 untuk deskripsi yang baik. Layak dibaca.

— John aka hot2use

5

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.

— James Risto
sumber

Saya juga menggunakan pendekatan ini dan saya pikir itu bekerja dengan baik untuk usaha kecil dan menengah di mana persyaratan aksesnya tidak terlalu detail.

— Kevin Kuphal

+1 Ini adalah pendekatan baru dan menarik. Jika saya memahami Anda dengan benar, Anda akan menetapkan ACL pada bagian alih-alih pada NTFS dan hanya membuat setiap "sumber daya" bagiannya sendiri. Ini akan meminggirkan masalah pemindahan / penyalinan serta membuat perubahan izin dengan cepat dan tidak menyakitkan karena Anda tidak perlu menyentuh semua file / folder jika Anda perlu melakukan perubahan. Dikombinasikan dengan beberapa penggunaan kreatif DFS untuk sumber daya bersarang, pendekatan ini memiliki beberapa keuntungan yang jelas.

— David Archer

7

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.

— Jim B
sumber

Jim, "jebakan" utama yang saya khawatirkan adalah dengan menggunakan kembali kelompok yang sama di beberapa sumber daya, tidak ada cara untuk menjawab "Sumber daya apa yang dimiliki kelompok X memiliki akses?" tanpa memeriksa setiap sumber daya di lingkungan (maaf jika saya sedikit abstrak di sini). Selain itu, Anda akhirnya perlu ACL kembali sistem file jika grup lain juga membutuhkan akses ke file.

— David Archer

@ David, sebenarnya itu tidak sepenuhnya benar: saat Anda menamai grup sumber daya dengan nama deskriptif, Anda dapat pergi ke grup peran (misalnya Manajer) dan memeriksa grup milik siapa (katakanlah FileServer01_HR_RO dan FileServer01_Mgmt_RW). Tentu saja, model ini harus ketat dengan penamaan dan mengikuti standar keanggotaan grup. Tapi tidak ketat dalam hal ini atau model lain akan berakhir berantakan.

— curropar

@curropar: Sudah 7 tahun tetapi saya / pikir / apa yang saya bicarakan adalah jika Anda benar-benar menempatkan grup Peran langsung pada ACL sumber daya itu akan bermasalah. Kami benar-benar akhirnya tidak menggunakan grup peran sama sekali dalam proyek yang saya kerjakan yang memicu pertanyaan asli karena semuanya otomatis. Pengguna akan meminta akses ke grup sumber daya secara langsung menggunakan formulir web online dan pemilik sumber daya (pelaku bisnis) bertanggung jawab untuk menyetujui / menolak permintaan tersebut.

— David Archer

Itu masuk akal; dan bahkan jika ini adalah 7 tahun, saya sedang mencari model untuk server file saya, dan posting ini naik di pencarian Google, jadi saya berkomentar untuk pengunjung masa depan, untuk berjaga-jaga;)

— curropar

1

@curropar Sepertinya saya tidak pernah menjawab pertanyaan bertahun-tahun yang lalu. Sejauh audit berjalan, Anda harus tetap mengaudit setiap sumber daya karena sebaliknya bukan audit yang valid.

— Jim B

2

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.

— Zypher
sumber

Setuju dengan # 1. Bagian peran dari sistem adalah opsional, tetapi memang membuat manajemen lebih mudah. Pada grup Universal, saya memiliki beberapa kekhawatiran tentang lalu lintas replikasi tetapi mengingat bahwa keanggotaan grup kami berubah cukup lambat (mungkin 1000 grup dimodifikasi sehari?), Itu belum menjadi masalah. Domain Lokal sepertinya berfungsi karena mereka dapat memuat pengguna untuk domain apa pun di hutan.

— David Archer

Hanya untuk menindaklanjuti ini: Kami akhirnya mengonversi grup ke Domain Lokal dan itu bekerja dengan baik selama sekitar 6 bulan. LALU ketika kami memiliki persyaratan untuk mengatur lingkungan pemulihan bencana dan memiliki file server dari satu domain diatur sebagai replika untuk server file dari domain lain, kami akhirnya harus kembali ke grup Universal karena jika tidak, server DR tidak bisa t menginterpretasikan izin tersebut (karena server DR tidak berada dalam domain yang sama dengan server file sumber dan grup lokal domain).

— David Archer

1

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.

— Carl C
sumber

Tidak yakin saya memahami Domain Grup lokal yang membutuhkan lebih banyak grup total dibandingkan grup Universal karena saya masih membutuhkan 1 per sumber daya aman per tingkat akses. Saya setuju dengan tidak menerima replikasi sehingga saya mungkin melihat mengubah mereka di beberapa titik di masa depan (harus menjadi operasi yang cukup sederhana).

— David Archer

1

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).

— Maximus Minimus
sumber

Yup, kami menempatkan UNC dalam deskripsi karena batasan panjang nama grup AD. Di lingkungan produksi saya, nama grup mencerminkan jalur UNC lengkap ke folder dengan garis miring terbalik dikonversi menjadi garis putus-putus. Jika namanya terlalu besar untuk dicocokkan, kami memotong bagian ujungnya (sebelum akhiran -RW atau -RO) dan meletakkan angka tambahan 3 digit mulai dari 001. Bukan pendekatan yang paling sederhana tetapi konsisten dan cukup mudah untuk menanyakan AD.

— David Archer

1

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.

— Chris Doherty
sumber

0

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 .

— sysadmin1138
sumber

Saya telah menggunakan ABE sebelumnya dalam keterlibatan sebelumnya tetapi keluhan utama adalah bahwa menyembunyikan keberadaan sumber daya (folder) dari pengguna yang tidak dapat mengaksesnya akhirnya membuat mereka lebih sulit untuk benar-benar meminta akses jika itu adalah sesuatu yang mereka memiliki kebutuhan yang sah untuk masuk. Di lingkungan saya saat ini, kami memiliki server NAS berbasis Linux ini sehingga ABE bukan pilihan di sini.

— David Archer

0

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.

— spoulson
sumber

Setuju tentang skenario terbaik akan memiliki pengetahuan dan keterlibatan yang cukup dengan bisnis untuk dapat memetakan peran pekerjaan untuk setiap "jenis" pengguna tetapi di lingkungan saya (perusahaan global, 150k + pengguna) itu tidak realistis untuk mengharapkan para pebisnis untuk menghabiskan waktu yang dibutuhkan untuk memetakannya. Kami pada dasarnya pergi ke rute lain dengan hanya akses satu kali tetapi kami mengotomatiskan seluruh proses sehingga tidak membebani TI.

— David Archer

Mengenai perpindahan dan "membersihkan" akses lama, sekali lagi, kami mengotomatiskan proses dan tanggung jawab diberikan kepada pemilik sumber daya untuk secara berkala meninjau dan meminta penghapusan akses bagi orang-orang yang tidak lagi harus memiliki akses. "Bergerak" di lingkungan kita biasanya tidak melibatkan penghapusan akses ke sumber daya karena siapa yang lebih baik daripada pemilik sumber daya untuk mengetahui apakah orang ini masih membutuhkan akses atau tidak di posisi baru mereka?

— David Archer

Mencoba memetakan pengguna 150 ribu dan peran mereka merupakan indikasi bahwa perusahaan tidak melakukan penelitian sebelum berkembang ke ukuran itu. Jelas, jauh lebih mudah untuk memiliki kerangka kerja sebelum pertumbuhan yang luas.

— spoulson