Grundlegendes zum Dualprotokollsicherheitsstil und Berechtigungsverhalten in Azure NetApp-Dateien
SMB und NFS verwenden unterschiedliche Berechtigungsmodelle für den Benutzer- und Gruppenzugriff. Daher muss ein Azure NetApp File Volume so konfiguriert werden, dass das gewünschte Berechtigungsmodell für den Protokollzugriff berücksichtigt wird. Für NFS-only-Umgebungen ist die Entscheidung einfach – verwenden Sie UNIX-Sicherheitsstile. Verwenden Sie für SMB-only-Umgebungen NTFS-Sicherheitsstile.
Wenn NFS und SMB auf denselben Datasets (Dual-Protocol) erforderlich sind, sollte die Entscheidung auf der Grundlage von zwei Fragen getroffen werden:
- Welches Protokoll werden Benutzer berechtigungen am häufigsten verwalten?
- Was ist der gewünschte Berechtigungsverwaltungsendpunkt? Mit anderen Worten: Benötigen Benutzer die Möglichkeit, Berechtigungen von NFS-Clients oder Windows-Clients zu verwalten? Oder beides?
Volumensicherheitsstile können wirklich als Berechtigungsstile betrachtet werden, wobei der gewünschte Stil der ACL-Verwaltung der entscheidende Faktor ist.
Hinweis
Sicherheitsstile werden bei der Volumenerstellung ausgewählt. Nachdem der Sicherheitsstil ausgewählt wurde, kann er nicht mehr geändert werden.
Informationen zu Azure NetApp Files-Volumensicherheitsstilen
Es gibt zwei Standard Optionen für Volumensicherheitsstile in Azure NetApp-Dateien:
UNIX - Der UNIX-Sicherheitsstil bietet UNIX-StilBerechtigungen , z. B. einfache POSIX-Modus-Bits (Besitzer/Gruppe/Jeder Zugriff mit Standardberechtigungen für Lese-/Schreibzugriff/Execute, z. B. 0755) und NFSv4.x ACLs. POSIX ACLs werden nicht unterstützt.
NTFS – Der NTFS-Sicherheitsstil bietet identische Funktionen wie standardmäßige Windows NTFS-Berechtigungen mit granularen Benutzer- und Gruppen in ACLs und detaillierten Sicherheits-/Überwachungsberechtigungen.
In einer DUAL-Protokoll-NAS-Umgebung kann nur ein Sicherheitsberechtigungsstil aktiv sein. Sie sollten Überlegungen für jeden Sicherheitsstil auswerten, bevor Sie einen auswählen.
| Sicherheitsstil | Überlegungen |
|---|---|
| UNIX | - Windows-Clients können nur UNIX-Berechtigungsattribute über SMBs festlegen, die UNIX-Attributen zugeordnet sind (nur Lese-/Schreibzugriff/Execute; keine speziellen Berechtigungen). - NFSv4.x ACLs besitzen keine GUI-Verwaltung. Die Verwaltung erfolgt nur über CLI mithilfe von nfs4_getfacl und nfs4_setfacl Befehlen. – Wenn eine Datei oder ein Ordner ÜBER NFSv4.x ACLs verfügt, kann die Registerkarte "Windows-Sicherheitseigenschaften" sie nicht anzeigen. |
| NTFS | - UNIX-Clients können Attribute nicht über NFS über Befehle wie chown/chmod. – NFS-Clients zeigen bei Verwendung von ls Befehlen nur ungefähre NTFS-Berechtigungen an. Wenn ein Benutzer beispielsweise über eine Berechtigung in einer Windows NTFS-ACL verfügt, die nicht sauber in ein POSIX-Modus-Bit übersetzt werden kann (z. B. das Traverse-Verzeichnis), wird er in den nächstgelegenen POSIX-Modus-Bitwert übersetzt (z1. B. für die Ausführung). |
Die Auswahl des Volumensicherheitsstils bestimmt, wie die Namenszuordnung für einen Benutzer ausgeführt wird. Bei diesem Vorgang handelt es sich um den Kern der Art und Weise, wie duale Protokollvolumes vorhersagbare Berechtigungen unabhängig vom verwendeten Protokoll Standard beibehalten.
Verwenden Sie die folgende Tabelle als Entscheidungsmatrix, um die richtigen Volumensicherheitsformatvorlagen auszuwählen.
| Sicherheitsstil | Meist NFS | Meist SMB | Bedarf an granularer Sicherheit |
|---|---|---|---|
| UNIX | X | - | X (mit NFSv4.x ACLs) |
| NTFS | - | X | X |
Funktionsweise der Namenszuordnung in Azure NetApp-Dateien
In Azure NetApp Files werden nur Benutzer authentifiziert und zugeordnet. Gruppen werden nicht zugeordnet. Stattdessen werden Gruppenmitgliedschaften mithilfe der Benutzeridentität bestimmt.
Wenn ein Benutzer versucht, auf ein Azure NetApp Files-Volume zuzugreifen, übergibt dieser Versuch eine Identität an den Dienst. Diese Identität enthält einen Benutzernamen und einen eindeutigen numerischen Bezeichner (UID-Nummer für NFSv3, Namenszeichenfolge für NFSv4.1, SID für SMB). Azure NetApp Files verwendet diese Identität, um sich bei einem konfigurierten Namensdienst zu authentifizieren, um die Identität des Benutzers zu überprüfen.
- Die LDAP-Suche nach numerischen IDs wird verwendet, um einen Benutzernamen in Active Directory nachzuschlagen.
- Namenszeichenfolgen verwenden die LDAP-Suche, um einen Benutzernamen nachzuschlagen, und der Client und der Server konsultieren die konfigurierte ID do Standard für NFSv4.1, um die Übereinstimmung sicherzustellen.
- Windows-Benutzer werden mithilfe standardmäßiger Windows RPC-Aufrufe an Active Directory abgefragt.
- Gruppenmitgliedschaften werden ebenfalls abgefragt, und alles wird einem Anmeldeinformationscache hinzugefügt, um die Verarbeitung bei nachfolgenden Anforderungen an das Volume zu beschleunigen.
- Derzeit werden benutzerdefinierte lokale Benutzer für die Verwendung mit Azure NetApp Files nicht unterstützt. Nur Benutzer in Active Directory können mit dualen Protokollen verwendet werden.
- Derzeit sind die einzigen lokalen Benutzer, die mit Dualprotokollvolumes verwendet werden können, stamm und der
nfsnobodyBenutzer.
Nachdem ein Benutzername von Azure NetApp Files authentifiziert und überprüft wurde, ist der nächste Schritt für die Dualprotokoll-Volumeauthentifizierung die Zuordnung von Benutzernamen für UNIX und Windows-Interoperabilität.
Der Sicherheitsstil eines Volumes bestimmt, wie eine Namenszuordnung in Azure NetApp Files stattfindet. Die Semantik für Windows- und UNIX-Berechtigungen unterscheidet sich. Wenn keine Namenszuordnung ausgeführt werden kann, schlägt die Authentifizierung fehl, und der Zugriff auf ein Volume von einem Client wird verweigert. Ein häufiges Szenario, in dem diese Situation auftritt, ist, wenn der NFSv3-Zugriff auf ein Volume mit NTFS-Sicherheitsstil versucht wird. Die anfängliche Zugriffsanforderung von NFSv3 stammt aus Azure NetApp Files als numerische UID. Wenn ein Mit einer numerischen ID 1001 benannter user1 Benutzer versucht, auf den NFSv3-Mount zuzugreifen, wird die Authentifizierungsanforderung als numerische ID 1001eintreffen. Azure NetApp Files verwendet dann numerische ID 1001 und versucht, einen Benutzernamen aufzulösen 1001 . Dieser Benutzername ist für die Zuordnung zu einem gültigen Windows-Benutzer erforderlich, da die NTFS-Berechtigungen für das Volume Windows-Benutzernamen anstelle einer numerischen ID enthalten. Azure NetApp Files verwendet den konfigurierten Namendienstserver (LDAP), um nach dem Benutzernamen zu suchen. Wenn der Benutzername nicht gefunden werden kann, schlägt die Authentifizierung fehl, und der Zugriff wird verweigert. Dieser Vorgang ist beabsichtigt, um unerwünschten Zugriff auf Dateien und Ordner zu verhindern.
Namenszuordnung basierend auf dem Sicherheitsstil
Die Richtung, in der die Namenszuordnung in Azure NetApp Files (Windows zu UNIX oder UNIX zu Windows) erfolgt, hängt nicht nur vom verwendeten Protokoll ab, sondern auch vom Sicherheitsstil eines Volumes. Ein Windows-Client erfordert immer eine Windows-zu-UNIX-Namenszuordnung, um den Zugriff zu ermöglichen, benötigt aber nicht immer einen passenden UNIX-Benutzernamen. Wenn kein gültiger UNIX-Benutzername im konfigurierten Namensdienstserver vorhanden ist, stellt Azure NetApp Files einen Fallbackstandard-UNIX-Benutzer mit der numerischen UID bereit 65534 , um die anfängliche Authentifizierung für SMB-Verbindungen zuzulassen. Danach steuern Datei- und Ordnerberechtigungen den Zugriff. Da 65534 der Zugriff in der Regel dem Benutzer entspricht, ist der nfsnobody Zugriff in den meisten Fällen eingeschränkt. Umgekehrt muss ein NFS-Client nur dann eine UNIX-zu-Windows-Namenszuordnung verwenden, wenn der NTFS-Sicherheitsstil verwendet wird. Windows-Standardbenutzer in Azure NetApp-Dateien ist nicht vorhanden. Wenn ein gültiger Windows-Benutzer, der dem anfordernden Namen entspricht, nicht gefunden werden kann, wird der Zugriff verweigert.
In der folgenden Tabelle werden die unterschiedlichen Namenszuordnungs-Permutationen und das Verhalten je nach verwendeten Protokollen unterteilt.
| Protokoll | Sicherheitsstil | Richtung der Namenszuordnung | Angewendete Berechtigungen |
|---|---|---|---|
| SMB | UNIX | Windows zu UNIX | UNIX (Mode-Bits oder NFSv4.x ACLs) |
| SMB | NTFS | Windows zu UNIX | NTFS-ACLs (basierend auf der Windows-SID, die auf die Freigabe zugreift) |
| NFSv3 | UNIX | Keine | UNIX (Mode-Bits oder NFSv4.x ACLs*) |
| NFSv4.x | UNIX | Numerische ID für UNIX-Benutzername | UNIX (Mode-Bits oder NFSv4.x ACLs) |
| NFS3/4.x | NTFS | UNIX zu Windows | NTFS-ACLs (basierend auf zugeordneter Windows-Benutzer-SID) |
Hinweis
Namenszuordnungsregeln in Azure NetApp-Dateien können derzeit nur mithilfe von LDAP gesteuert werden. Es gibt keine Möglichkeit, explizite Namenszuordnungsregeln innerhalb des Diensts zu erstellen.
Namendienste mit Dualprotokollvolumes
Unabhängig davon, welches NAS-Protokoll verwendet wird, verwenden Dual-Protocol-Volumes Namenszuordnungskonzepte, um Berechtigungen ordnungsgemäß zu verarbeiten. Daher spielen Namensdienste eine wichtige Rolle bei der Standard taining-Funktionalität in Umgebungen, die sowohl SMB als auch NFS für den Zugriff auf Volumes verwenden.
Namensdienste dienen als Identitätsquellen für Benutzer und Gruppen, die auf NAS-Volumes zugreifen. Dieser Vorgang umfasst Active Directory, das sowohl als Quelle für Windows- als auch UNIX-Benutzer und -Gruppen fungieren kann, die sowohl standard do Standard-Dienste als auch LDAP-Funktionen verwenden.
Name services aren't a hard requirement but highly recommended for Azure NetApp Files dual-protocol volumes. Es gibt kein Konzept der Erstellung von benutzerdefinierten lokalen Benutzern und Gruppen innerhalb des Diensts. Daher ist LDAP erforderlich, um eine ordnungsgemäße Authentifizierung und genaue Benutzer- und Gruppenbesitzerinformationen über Protokolle hinweg zu erhalten. Wenn Sie nur über eine Handvoll Benutzer verfügen und keine genauen Benutzer- und Gruppenidentitätsinformationen auffüllen müssen, sollten Sie die Verwendung der lokalen NFS-Benutzer mit LDAP für den Zugriff auf eine Dual-Protokoll-Volumefunktionalität in Betracht ziehen. Beachten Sie, dass durch aktivieren dieser Funktion die erweiterte Gruppenfunktionalität deaktiviert wird.
Wenn Sich Clients, Namendienste und Speicher in verschiedenen Bereichen befinden
In einigen Fällen können NAS-Clients in einem segmentierten Netzwerk mit mehreren Schnittstellen leben, die isolierte Verbindungen mit den Speicher- und Namensdiensten aufweisen.
Ein solches Beispiel ist, wenn sich Ihr Speicher in Azure NetApp-Dateien befindet, während Ihre NAS-Clients und Standard Dienste lokal gespeichert sind (z. B. eine Hub-Spoke-Architektur in Azure). In diesen Szenarien müssen Sie Sowohl den NAS-Clients als auch den Namendiensten Netzwerkzugriff gewähren.
Die folgende Abbildung zeigt ein Beispiel für diese Art von Konfiguration.
