Azure NetApp Files'da çift protokollü güvenlik stilini ve izin davranışlarını anlama
SMB ve NFS, kullanıcı ve grup erişimi için farklı izin modelleri kullanır. Sonuç olarak, protokol erişimi için istenen izin modeline uygun bir Azure NetApp Dosya birimi yapılandırılmalıdır. Yalnızca NFS ortamlarında karar basittir; UNIX güvenlik stillerini kullanın. Yalnızca SMB ortamları için NTFS güvenlik stillerini kullanın.
Aynı veri kümelerinde NFS ve SMB (çift protokol) gerekiyorsa, karar iki soru temelinde verilmelidir:
- Kullanıcılar izinleri en çok hangi protokolden yönetecek?
- İstenen izin yönetimi uç noktası nedir? Başka bir deyişle, kullanıcıların NFS istemcilerinden veya Windows istemcilerinden izinleri yönetmesi gerekiyor mu? Yoksa her ikisi de mi?
Birim güvenliği stilleri, ACL yönetiminin istenen stilinin belirleyici faktör olduğu izin stilleri olarak kabul edilebilir.
Not
Birim oluşturma sırasında güvenlik stilleri seçilir. Güvenlik stili seçildikten sonra değiştirilemez.
Azure NetApp Files birim güvenlik stilleri hakkında
Azure NetApp Files'da birim güvenlik stilleri için iki ana seçenek vardır:
UNIX - UNIX güvenlik stili, temel POSIX modu bitleri (Sahip/Grup/Herkes, 0755 gibi standart Okuma/Yazma/Yürütme izinleriyle erişim) ve NFSv4.x ACL'leri gibi UNIX stili izinler sağlar. POSIX ACL'leri desteklenmez.
NTFS - NTFS güvenlik stili, ACL'lerdeki ayrıntılı kullanıcı ve gruplarla ve ayrıntılı güvenlik/denetim izinleriyle standart Windows NTFS izinleriyle aynı işlevselliği sağlar.
Çift protokollü NAS ortamında yalnızca bir güvenlik izni stili etkin olabilir. Bir güvenlik stili seçmeden önce her güvenlik stili için dikkat edilmesi gereken noktaları değerlendirmeniz gerekir.
| Güvenlik stili | Dikkat edilmesi gereken noktalar |
|---|---|
| UNIX | - Windows istemcileri UNIX izin özniteliklerini yalnızca UNIX öznitelikleriyle eşleyen SMB'ler aracılığıyla ayarlayabilir (Yalnızca Okuma/Yazma/Yürütme; özel izinler yoktur). - NFSv4.x ACL'lerinde GUI yönetimi yoktur. Yönetim yalnızca nfs4_getfacl ve nfs4_setfacl komutları kullanılarak CLI aracılığıyla yapılır. - Bir dosya veya klasörde NFSv4.x ACL'leri varsa, Windows güvenlik özellikleri sekmesi bunları görüntüleyemez. |
| NTFS | - UNIX istemcileri gibi chown/chmodkomutlar aracılığıyla NFS aracılığıyla öznitelikleri ayarlayamaz. - NFS istemcileri, komutları kullanırken ls yalnızca yaklaşık NTFS izinlerini gösterir. Örneğin, bir kullanıcının Windows NTFS ACL'sinde POSIX modu bitine (dolaşma dizini gibi) açıkça çevrilemez bir izni varsa, en yakın POSIX mod bit değerine (yürütme gibi 1 ) çevrilir. |
Birim güvenlik stili seçimi, kullanıcı için ad eşlemesinin nasıl gerçekleştirileceğini belirler. Bu işlem, çift protokollü birimlerin kullanımdaki protokolden bağımsız olarak öngörülebilir izinleri nasıl koruyacağının temel parçasıdır.
Uygun birim güvenlik stillerini seçmek için karar matrisi olarak aşağıdaki tabloyu kullanın.
| Güvenlik stili | Çoğunlukla NFS | Çoğunlukla SMB | Ayrıntılı güvenlik gerekiyor |
|---|---|---|---|
| UNIX | X | - | X (NFSv4.x ACL'lerini kullanma) |
| NTFS | - | X | X |
Azure NetApp Files'da ad eşleme nasıl çalışır?
Azure NetApp Files'da yalnızca kullanıcıların kimliği doğrulanır ve eşlenir. Gruplar eşlenmez. Bunun yerine, grup üyelikleri kullanıcı kimliği kullanılarak belirlenir.
Kullanıcı bir Azure NetApp Files birimine erişmeyi denediğinde, bu girişim hizmete bir kimlik geçirir. Bu kimlik bir kullanıcı adı ve benzersiz sayısal tanımlayıcı (NFSv3 için UID numarası, NFSv4.1 için ad dizesi, SMB için SID) içerir. Azure NetApp Files, kullanıcının kimliğini doğrulamak üzere yapılandırılmış bir ad hizmetinde kimlik doğrulaması yapmak için bu kimliği kullanır.
- Sayısal kimlikler için LDAP araması, Active Directory'de kullanıcı adı aramak için kullanılır.
- Ad dizeleri kullanıcı adını aramak için LDAP araması kullanır ve istemci ve sunucu, eşleşmeyi sağlamak için NFSv4.1 için yapılandırılmış kimlik etki alanına başvurur.
- Windows kullanıcıları, Active Directory'ye yapılan standart Windows RPC çağrıları kullanılarak sorgulanır.
- Grup üyelikleri de sorgulanır ve birime yapılan sonraki isteklerde daha hızlı işlem yapmak için her şey bir kimlik bilgisi önbelleğine eklenir.
- Şu anda özel yerel kullanıcılar Azure NetApp Files ile kullanım için desteklenmemekte. Yalnızca Active Directory'deki kullanıcılar çift protokollerle kullanılabilir.
- Şu anda çift protokollü birimlerle kullanılabilen tek yerel kullanıcılar kök ve
nfsnobodykullanıcıdır.
Azure NetApp Files tarafından bir kullanıcı adının kimliği doğrulandıktan ve doğrulandıktan sonra, çift protokollü birim kimlik doğrulaması için bir sonraki adım UNIX ve Windows birlikte çalışabilirliği için kullanıcı adlarını eşlemektir.
Bir birimin güvenlik stili, Azure NetApp Files'da ad eşlemenin nasıl gerçekleştirileceğini belirler. Windows ve UNIX izin semantiği farklıdır. Ad eşlemesi gerçekleştirilemiyorsa kimlik doğrulaması başarısız olur ve istemciden bir birime erişim reddedilir. Bu durumun oluştuğu yaygın senaryolardan biri, NTFS güvenlik stiline sahip bir birime NFSv3 erişimi denendiği durumlardır. NFSv3'ten gelen ilk erişim isteği, sayısal uid olarak Azure NetApp Files'a gelir. Sayısal user1 kimliğine 1001 sahip bir kullanıcı NFSv3 bağlamasına erişmeye çalışırsa, kimlik doğrulama isteği sayısal kimlik 1001olarak ulaşır. Azure NetApp Files daha sonra sayısal kimlik 1001 alır ve bir kullanıcı adına çözüme 1001 kavuşturmaya çalışır. Birimdeki NTFS izinleri sayısal kimlik yerine Windows kullanıcı adları içereceği için, geçerli bir Windows kullanıcısına eşleme için bu kullanıcı adı gereklidir. Azure NetApp Files, kullanıcı adını aramak için yapılandırılmış ad hizmeti sunucusunu (LDAP) kullanır. Kullanıcı adı bulunamazsa kimlik doğrulaması başarısız olur ve erişim reddedilir. Bu işlem, dosyalara ve klasörlere istenmeyen erişimi önlemek için tasarım gereğidir.
Güvenlik stiline göre ad eşleme
Ad eşlemesinin Azure NetApp Files'da (Windows'un UNIX'e veya UNIX'in Windows'a) gerçekleşmesinin yönü yalnızca kullanılan protokole değil, aynı zamanda bir birimin güvenlik stiline de bağlıdır. Bir Windows istemcisi, erişime izin vermek için her zaman Bir Windows-UNIX ad eşlemesi gerektirir, ancak her zaman eşleşen bir UNIX kullanıcı adı gerekmez. Yapılandırılan ad hizmeti sunucusunda geçerli bir UNIX kullanıcı adı yoksa, Azure NetApp Files SMB bağlantıları için ilk kimlik doğrulamasına izin vermek üzere sayısal UID'sine 65534 sahip bir geri dönüş varsayılan UNIX kullanıcısı sağlar. Bundan sonra, dosya ve klasör izinleri erişimi denetler. Genellikle 65534 kullanıcıya karşılık geldiği için nfsnobody çoğu durumda erişim sınırlıdır. Buna karşılık, bir NFS istemcisinin yalnızca NTFS güvenlik stili kullanılıyorsa UNIX-Windows ad eşlemesi kullanması gerekir. Azure NetApp Files'da varsayılan Windows kullanıcısı yoktur. Bu nedenle, istekte bulunan adla eşleşen geçerli bir Windows kullanıcısı bulunamazsa erişim reddedilir.
Aşağıdaki tablo, farklı ad eşleme permütasyonlarını ve kullanımdaki protokole bağlı olarak nasıl davrandıklarını ayırır.
| Protokol | Güvenlik stili | Ad eşleme yönü | Uygulanan izinler |
|---|---|---|---|
| SMB | UNIX | Windows'ta UNIX'e | UNIX (mod bitleri veya NFSv4.x ACL'leri) |
| SMB | NTFS | Windows'ta UNIX'e | NTFS ACL'leri (Paylaşıma erişen Windows SID tabanlı) |
| NFSv3 | UNIX | Hiçbiri | UNIX (mod bitleri veya NFSv4.x ACL'ler*) |
| NFSv4.x | UNIX | UNIX kullanıcı adına sayısal kimlik | UNIX (mod bitleri veya NFSv4.x ACL'leri) |
| NFS3/4.x | NTFS | UNIX'i Windows'a | NTFS ACL'leri (eşlenmiş Windows kullanıcı SID'lerine göre) |
Not
Azure NetApp Files'daki ad eşleme kuralları şu anda yalnızca LDAP kullanılarak denetlenebilir. Hizmet içinde açık ad eşleme kuralları oluşturma seçeneği yoktur.
Çift protokollü birimlere sahip hizmetleri adlandırma
Hangi NAS protokolünün kullanıldığına bakılmaksızın, çift protokollü birimler izinleri düzgün bir şekilde işlemek için ad eşleme kavramlarını kullanır. Bu nedenle ad hizmetleri, birimlere erişim için hem SMB hem de NFS kullanan ortamlarda işlevselliğin korunmasında kritik bir rol oynar.
Ad hizmetleri, NAS birimlerine erişen kullanıcılar ve gruplar için kimlik kaynağı görevi görür. Bu işlem, hem standart etki alanı hizmetlerini hem de LDAP işlevselliğini kullanan Hem Windows hem de UNIX kullanıcıları ve grupları için bir kaynak olarak davranabilen Active Directory'yi içerir.
Ad hizmetleri zor bir gereksinim değildir, ancak Azure NetApp Files çift protokollü birimler için kesinlikle önerilir. Hizmet içinde özel yerel kullanıcılar ve gruplar oluşturma kavramı yoktur. Bu nedenle, protokoller arasında doğru kimlik doğrulaması ve doğru kullanıcı ve grup sahibi bilgilerine sahip olmak için LDAP gereklidir. Yalnızca birkaç kullanıcınız varsa ve doğru kullanıcı ve grup kimliği bilgilerini doldurmanız gerekmiyorsa LDAP ile yerel NFS kullanıcılarının çift protokollü birim işlevselliğine erişmesine izin ver seçeneğini kullanmayı göz önünde bulundurun. Bu işlevin etkinleştirilmesinin genişletilmiş grup işlevselliğini devre dışı bırakdığını unutmayın.
İstemciler, ad hizmetleri ve depolama farklı alanlarda bulunduğunda
Bazı durumlarda NAS istemcileri, depolama ve ad hizmetleriyle yalıtılmış bağlantıları olan birden çok arabirime sahip bir kesimli ağda yaşayabilir.
Bu tür örneklerden biri, depolama alanınızın Azure NetApp Files'da bulunması, NAS istemcilerinizin ve etki alanı hizmetlerinizin tümünün şirket içinde (Azure'daki merkez-uç mimarisi gibi) bulunmasıdır. Bu senaryolarda hem NAS istemcilerine hem de ad hizmetlerine ağ erişimi sağlamanız gerekir.
Aşağıdaki şekilde bu tür bir yapılandırma örneği gösterilmektedir.
Sonraki adımlar
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin