Bu, dosya sunucusu izinleri için önerilen / geçerli bir yaklaşım mı?

Dosya sunucuları BT'de hayatın bir gerçeğidir ve grup oluşturduğunuzda ve paylaşılan bir klasöre istemci erişimini yönetmek için izinleri nasıl uyguladığınız konusunda genel olarak kabul edilen herhangi bir uygulama (burada "en iyi" kelimesini kullanmaktan çekinmeyin) olup olmadığını merak ediyorum bir dosya sunucusu.

Şu anki işimde, bunu ACL'lerde düzinelerce gruptan, tek tek kullanıcıları doğrudan dosya sistemine koymaya kadar, bunu yapmanın farklı yollarını karıştırmaya başladım. Görevim karışıklığı temizlemek ve buna şirket genelinde yaklaşmanın bir çeşit standartlaştırılmış yolunu bulmaktı (geniş çevre, 150k personel, 90k istemci bilgisayarlar, 100'lü dosya sunucuları).

Sorunu anladığım kadarıyla, güvenli kaynak başına gereken erişim düzeyi başına en az bir gruba ihtiyacınız var gibi görünüyor. Bu model, farklı bir erişim düzeyini desteklemeniz gerekmediği sürece dosya sistemi izinlerine tekrar dokunmanız gerekmediği için en fazla esnekliği veriyor gibi görünüyor. Dezavantajı, aynı grubu birden çok paylaşılan kaynakta yeniden kullanmaktan daha fazla grup oluşturmanızdır.

Ne demek istediğimi gösteren bir örnek:

FILE01 adlı bir dosya sunucusunda "Test Sonuçları" adlı bir paylaşım var ve salt okunur erişim, okuma-yazma erişimi ve tam denetime ihtiyaç duyan kişiler var. 1 güvenli kaynak * 3 erişim düzeyi = 3 güvenlik grubu. AD ortamımızda, bunları evrensel gruplar olarak oluştururuz, böylece ormandaki herhangi bir alandan kolayca kullanıcı / grup ekleyebiliriz. Her grup benzersiz bir şekilde paylaşılan bir klasöre ve erişim düzeyine atıfta bulunduğundan, grup adları bu "önemli" veri parçalarını içerir ve böylece izinler şunlardır:

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

Genellikle, yerleşik SYSTEM hesabını ve Tam Denetim erişimine sahip yerleşik Yöneticileri de dahil ederiz. Bu paylaşıma gerçekte kimin eriştiğine ilişkin herhangi bir değişiklik artık ACL'ye dokunmak yerine grup üyelikleri kullanılarak gerçekleştirilebilir (Yöneticiler, Teknisyenler, KG Analistleri vb. Gibi belirli iş rollerini temsil eden "Rol" grupları ekleyerek veya yalnızca bireysel olarak bir kerelik erişim için).

İki soru:

1) Bu aslında izinlerin ele alınması için önerilen veya geçerli bir yaklaşım mı yoksa daha basit, daha zarif bir çözümü mi kaçırıyorum? Özellikle kalıtım kullanan herhangi bir çözümle ilgileniyorum, ancak işler değiştiğinde dosya sistemlerinin büyük bölümlerini yeniden ACL yapmak zorunda kalmama esnekliğini hala koruyorum.

2) Ortamınızdaki dosya sunucusu izinlerini ve grup yapısını nasıl kullanıyorsunuz? Geniş ortamlarda çalışanlar için bonus puan.

Yaklaşımım dosya / dizin düzeyinde dosya izinlerini kullanmamak; dosya paylaşımı düzeyi izinlerini kullanın ve tüm sunucu dosya sistemi veri sürücüsünü Herkesin Tam Denetimi (moot haline gelen) olarak ayarlayın.

Yıllar içinde (10+), NTFS izinlerinin daha karmaşık olduğunu ve daha fazla hataya yol açtığını buldum. İzinler yanlış ayarlanırsa veya devralma bozulursa, verileri ortaya çıkarır ve bulmak ve görmek zordur. Ayrıca, taşıma / kopyalama sorununa maruz kalırsınız ... dosyaları taşıyan kullanıcılar dosyanın ACL'sini de taşırken, kopya hedef ACL'yi devralır.

Okuma / yazma gruplarınızı aynı, ancak Comp Mgmt MMC kullanarak tüm dosya paylaşımında kullanın. Tam yapmayın ... kullanıcılar kısmi bilgi / en iyi niyetlerle kendilerini vururlar.

Bu yaklaşım kötü değil. Kural olarak asla izin eklemek için tek tek kullanıcıları kullanmayın - bir grup kullanın. Ancak gruplar kaynaklarda kullanılabilir. Örneğin, İD yöneticilerin dosyalara RW erişimi olabilir, ancak YÖNETİCİLER'in R olabilir. Aşağıdaki web yayınına bir göz atın:

TechNet Web Yayını: Windows Server 2003 Yönetim Serisi (Bölüm 4/12): Grup Yönetimi (Düzey 200)

Erişim tabanlı numaralandırma hayatı da kolaylaştırabilir:

Erişim Tabanlı Numaralandırma

ABE, yönetmek zorunda olduğunuz farklı paylaşımların sayısını azaltmaya yardımcı olabilir.

Yaklaşımınız temelde ona yaklaşma şeklim.
Ekleyeceğim tek şey bunlar:

1) "Rolleri" şemanıza, muhtemelen bu aykırı değerlerle karşılaşacağınız tek bir sunucuda değil, sunucularda neye ihtiyaç duyduklarını değerlendirerek eklerdim, ama bunlarla kuramım, bunlarla karşılaştığınızda, başka bir grup oluşturun. bir aykırı değer olduğu deneyimlerime göre çok fazla var.

2) Universal grubundaki üyeler ve gruplar Global Katalog sunucularına çoğaltılırken, Universal Group içindeki üyeler ve gruplar Global Katalog sunucularına çoğaltılırken, Evrensel gruplara olan ihtiyacı her şey için GÜÇLENEN yeniden değerlendireceğim. genel katalog sunucularına çoğaltılır. Bu nedenle, evrensel bir grupta değişiklik yaparsanız, çoğaltmayı başlatırken, global ve etki alanı yerelinde değil.

Her erişim düzeyi için kaynak grubu kullanma yönteminiz doğrudur. Dikkate alacağım tek şey, Etki Alanı Yerel Grupları'nı kaynaklar için kullanmaktır. Sunucuya özgü kaynak grupları oluşturuyorsanız, Evrensel Grupları kullanmanız gerekmez.

Kaynaklar için Etki Alanı Yerel Grupları kullanmanın dezavantajı, daha fazla toplam grupla karşılaşmanızdır. Tersi, Zypher'in belirttiği gibi, çoğaltma ile ilgili daha az sorun yaşamanızdır.

Önerilen yaklaşım oldukça sağlam görünüyor. Dikkat edilmesi gereken bir şey, başlangıçta dosya paylaşımlarını ayarlama şeklidir. Önerilen uygulama, daha sonra grup izinlerini atadığınız alt klasörleri içeren tek bir üst düzey paylaşıma sahip olmaktır. NTFS daha sonra üst düzey klasördeki "Klasörü Gez / Dosya Çalıştır" ı atlayabilir ve alt klasöre erişim izni verebilir.

Yapı daha sonra \ sunucuadı \ paylaşım_adı \ grup-klasörü gibi görünecektir; paylaşım izinlerinin yalnızca "paylaşım adı" klasöründe ve gerçek NTFS izinlerinin "grup klasörü" klasöründe ayarlanması gerekir.

Dosya sunucunuz bu tür kurulumlarla da daha iyi performans gösterecektir.

Genel olarak yapacağım diğer şeyler, gruplar için grup adı grup klasörü adıyla aynı olacak şekilde bir adlandırma kuralına sahip olmaktır (istenirse FC / RW / RO eklenmişse) ve UNC'yi klasöre grup açıklamasına yapıştırın (böylece oturum açma komut dosyanız onu okuyabilir ve bu şekilde bir sürücü eşlemesi ayarlayabilir ve ayrıca hangi klasörlerin hangi gruplara uygulandığını daha kolay görebilirsiniz).

Windows 2000'den beri Windows dosya sunucusu için kullandığım standart uygulama (Mark Minasi'nin Mastering Windows Server serisinde düzenlendi, bu yüzden daha fazla bilgi için buraya bakın), iç içe yerleştirme için dosya sunucusunun kendisinde yerel olan grupları kullanmaktır.

Örneğin, MUPPETS adlı bir etki alanında KERMIT adlı bir dosya sunucusunu düşünün.

Diyelim ki KERMIT birkaç dosya paylaşımına sahip:

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

Erişim için KERMIT'te yerel gruplar oluşturun ve dosya sistemine tam olarak belirttiğiniz şekilde izin verin (ör. Paylaşım başına erişim düzeyi başına bir grup)

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

Bunlar yerel gruplar olduğu için, onlara istediğiniz diğer grupları veya kullanıcıları ekleyebilirsiniz - alan adı yerel grupları, genel gruplar, evrensel gruplar, ormanınızdaki herhangi bir alan adından kullanıcı hesapları. Hak yönetimi artık dosya sistemi veya AD yerine dosya sunucusu grupları için yereldir.

Bu, grup yönetiminize ek bir katman ekler, ancak site yerel yöneticilerinin bu dosya sunucusunun Yönetici haklarından başka bir şeye ihtiyaç duymadan kendi dosya sunucularını yönetmesine izin verme (diyelim) avantajına sahiptir. Her ofis türünün sunucularıyla kendi işini yaptığı bir tür şube ofis yapınız varsa, bu gerçek bir fayda olabilir. Birkaç düzine yerel site yöneticisine AD yönetici hakları vermek zorunda kalmayabilirsiniz.

Ayrıca, AD'nizin birçok grupla (sunucu başına paylaşım başına erişim başına bir grup çok hızlı bir şekilde toplanabilir) karışık olmasını önler ve GC'ler arasındaki grup çoğaltmasını en aza indirir. AD gruplarınızı izinler yerine roller için ayırmanıza olanak tanır.

Ortamınız titizlikle standartlaştırılmışsa ve tüm dosya sunucuları özdeş ve çoğaltılmışsa, bu kesinlikle ihtiyacınız olmayan bir grup katmandır. Ayrıca, her bir dosya sunucusunda bulunan bir paylaşımda aynı haklara sahip olmak için belirli bir AD grubuna ihtiyacınız olduğunu biliyorsanız, bunu korumak için bazı otomasyona ihtiyacınız olacaktır.

Özetle, dosya sunucularınız birbirinden ne kadar farklıysa, makine yerel grupları o kadar çok kullanılır. Ne kadar benzer olursa, o anda kullanmakta olduğunuz sistemi kullanmak istersiniz.

NetWare'den Windows Server 2008'e geçişe bakıyorum, bu son zamanlarda aklımda oldu. Server 2008 (ve bir dereceye kadar Server 2003R2) bu geçişi gerçekten kolaylaştıran bazı hoş özelliklere sahiptir. Server 2008, kutudan çıktığı sırada Access Based Enumeration ile birlikte gelir. Bu, kullanıcıların yalnızca haklarına sahip oldukları dizinleri görmelerini sağlayan çok güzel bir özelliktir. Eğer sizin gibi bir payınız varsa ...

\\ kullanıcı ev srv \ evler \

ABE olmasaydı son kullanıcı onlarca / yüzlerce / binlerce dizin görürdü. ABE ile son kullanıcı yalnızca bir tanesini görür. Aynı şey paylaşılan paylar için de geçerlidir. ABE ile dilerseniz tüm departman dizinleriniz için tek bir büyük hacme sahip olabilirsiniz ve giremedikleri dizinlerle kullanıcılarınızın halkı spam yapamazsınız. Bir ACL sorunu olmasa da, ben biraz ilgili, bu yüzden ben getirmek.

Server 2008'in önceki sürümlerinden daha iyi yaptığı başka bir şey de ACL mirası. Büyük bir ağacın tepesinde bir ACL değişiminin yaprağa yayılmasında daha hızlı görünüyor.

Netware mirasımız nedeniyle, kimin içinde bulunduğuna bağlı olarak adlandırılan çok sayıda grubumuz var, bunlardan birkaçı eriştikleri şey için adlandırıldı. Erişimi kabul eden dizinler için de "RO" "Tam" terminolojisini kullanıyoruz.

4.400 çalışanın tümü için tek paylaşılan birim olan ve üzerinde 3,5 milyondan fazla dosya bulunan tek parçalı bir "paylaşılan" birimimiz var (hala NetWare'de, ancak Windows'a taşındığımızda monolitik olmasını planlıyoruz). Üst düzey dizinlerin tümü bölüm adlarıdır ve her bölüm, içinde neler olup bittiğini düzenler. Gerçekten büyük bölümler için birkaç istisna vardır, bunlar ACL'li 2. düzey dizine sahiptir.

Son işimde izinler ayarlayabildik, böylece iş başvurusu yapan İK çalışanları sunucularında kendi uygulama verilerini göremeyeceklerdi. Bunu yapmak, Windows'taki "blok miras" etiketine benzer bazı devralma hakları filtreleri aldı. Zor kısmı hepsini belgeliyordu, ama işe yaradı .

En iyi durum senaryosu, her kullanıcının, kullanıcının iş rolü için yalnızca bir güvenlik grubuna eklenmesini sağlamaktır. Rol daha sonra gerektiğinde erişim yetkisi verilir.

Aynı şekilde, paylaşılan bir klasöre "FILE01-Test Results-RW" örneğiniz gibi "kaynak" güvenlik grupları kullanılarak erişim izni verilmelidir. Bu, iş rollerini, departman rollerini veya diğer uygulanabilir grupları içerecektir.

Bu tasarımın üst kısmı, izlemesi zor olabilecek tek seferlik erişimi değil, grup başına (ekip, bölüm vb.) Erişimi devretmenizdir. Bir kullanıcı başka bir departmana transfer olduğunda, tüm eski erişimi temizlemeniz gerekir.

Dezavantajı, grupların kötüye kullanılabilmesidir. Bir paylaşıma atanan kaynak gruplarının departman gruplarıymış gibi kullanılmamaları için karışık bir erişim karmaşası oluşturarak grupların ne için kullanıldığına ilişkin net ayrımlar yapın.