Inzicht in beveiligingsstijl en machtigingsgedrag met twee protocollen in Azure NetApp Files
SMB en NFS gebruiken verschillende machtigingsmodellen voor gebruikers- en groepstoegang. Als gevolg hiervan moet een Azure NetApp File-volume worden geconfigureerd om het gewenste machtigingsmodel voor protocoltoegang te respecteren. Voor NFS-omgevingen is de beslissing eenvoudig: gebruik UNIX-beveiligingsstijlen. Gebruik NTFS-beveiligingsstijlen voor alleen SMB-omgevingen.
Als NFS en SMB op dezelfde gegevenssets (dual-protocol) vereist zijn, moet de beslissing worden genomen op basis van twee vragen:
- Welk protocol beheren gebruikers de meeste machtigingen?
- Wat is het gewenste eindpunt voor machtigingsbeheer? Met andere woorden, hebben gebruikers de mogelijkheid nodig om machtigingen van NFS-clients of Windows-clients te beheren? Of beide?
Volumebeveiligingsstijlen kunnen echt worden beschouwd als machtigingsstijlen, waarbij de gewenste stijl van ACL-beheer de beslissingsfactor is.
Notitie
Beveiligingsstijlen worden gekozen bij het maken van volumes. Zodra de beveiligingsstijl is gekozen, kan deze niet meer worden gewijzigd.
Over azure NetApp Files-volumebeveiligingsstijlen
Er zijn twee hoofdopties voor volumebeveiligingsstijlen in Azure NetApp Files:
UNIX : de UNIX-beveiligingsstijl biedt machtigingen in UNIX-stijl, zoals eenvoudige POSIX-modus-bits (toegang tot eigenaar/groep/iedereen met standaard machtigingen voor lezen/schrijven/uitvoeren, zoals 0755) en NFSv4.x ACL's. POSIX-ACL's worden niet ondersteund.
NTFS - De NTFS-beveiligingsstijl biedt identieke functionaliteit als standaard Windows NTFS-machtigingen, met gedetailleerde gebruikers en groepen in ACL's en gedetailleerde beveiligings-/controlemachtigingen.
In een NAS-omgeving met twee protocollen kan slechts één beveiligingsmachtigingsstijl actief zijn. U moet overwegingen evalueren voor elke beveiligingsstijl voordat u er een kiest.
| Beveiligingsstijl | Overwegingen |
|---|---|
| UNIX | - Windows-clients kunnen alleen UNIX-machtigingskenmerken instellen via SMBs die worden toegewezen aan UNIX-kenmerken (alleen lezen/schrijven/uitvoeren; geen speciale machtigingen). - NFSv4.x ACL's hebben geen GUI-beheer. Beheer wordt alleen uitgevoerd via CLI met behulp van nfs4_getfacl en nfs4_setfacl opdrachten. - Als een bestand of map NFSv4.x ACL's bevat, kunnen deze niet worden weergegeven op het tabblad Beveiligingseigenschappen van Windows. |
| NTFS | - UNIX-clients kunnen geen kenmerken via NFS instellen via opdrachten zoals chown/chmod. - NFS-clients geven alleen geschatte NTFS-machtigingen weer wanneer u opdrachten gebruikt ls . Als een gebruiker bijvoorbeeld een machtiging heeft in een Windows NTFS-ACL die niet schoon kan worden vertaald in een POSIX-modus-bit (zoals doorkruisingsmap), wordt deze omgezet in de dichtstbijzijnde POSIX-modus-bits waarde (zoals 1 voor uitvoering). |
De selectie van de volumebeveiligingsstijl bepaalt hoe de naamtoewijzing voor een gebruiker wordt uitgevoerd. Deze bewerking is het kernstuk van hoe volumes met twee protocollen voorspelbare machtigingen onderhouden, ongeacht het protocol dat wordt gebruikt.
Gebruik de volgende tabel als beslissingsmatrix voor het selecteren van de juiste volumebeveiligingsstijlen.
| Beveiligingsstijl | Meestal NFS | Meestal SMB | Behoefte aan gedetailleerde beveiliging |
|---|---|---|---|
| UNIX | X | - | X (met NFSv4.x ACL's) |
| NTFS | - | X | X |
Hoe naamtoewijzing werkt in Azure NetApp Files
In Azure NetApp Files worden alleen gebruikers geverifieerd en toegewezen. Groepen worden niet toegewezen. In plaats daarvan worden groepslidmaatschappen bepaald met behulp van de gebruikersidentiteit.
Wanneer een gebruiker probeert toegang te krijgen tot een Azure NetApp Files-volume, wordt een identiteit doorgegeven aan de service. Deze identiteit bevat een gebruikersnaam en unieke numerieke id (UID-nummer voor NFSv3, naamtekenreeks voor NFSv4.1, SID voor SMB). Azure NetApp Files gebruikt die identiteit om te verifiëren bij een geconfigureerde naamservice om de identiteit van de gebruiker te verifiëren.
- LDAP-zoekopdrachten voor numerieke id's worden gebruikt om een gebruikersnaam in Active Directory op te zoeken.
- Naamreeksen gebruiken LDAP-zoekopdrachten om een gebruikersnaam op te zoeken en de client en server raadplegen het geconfigureerde id-domein voor NFSv4.1 om ervoor te zorgen dat deze overeenkomen.
- Windows-gebruikers worden opgevraagd met behulp van standaard Windows RPC-aanroepen naar Active Directory.
- Groepslidmaatschappen worden ook opgevraagd en alles wordt toegevoegd aan een referentiecache voor snellere verwerking bij volgende aanvragen naar het volume.
- Op dit moment worden aangepaste lokale gebruikers niet ondersteund voor gebruik met Azure NetApp Files. Alleen gebruikers in Active Directory kunnen worden gebruikt met dubbele protocollen.
- Momenteel zijn de enige lokale gebruikers die kunnen worden gebruikt met volumes met twee protocollen root en de
nfsnobodygebruiker.
Nadat een gebruikersnaam is geverifieerd en gevalideerd door Azure NetApp Files, is de volgende stap voor volumeverificatie met twee protocollen de toewijzing van gebruikersnamen voor UNIX- en Windows-interoperabiliteit.
De beveiligingsstijl van een volume bepaalt hoe een naamtoewijzing plaatsvindt in Azure NetApp Files. Semantiek voor Windows- en UNIX-machtigingen verschillen. Als een naamtoewijzing niet kan worden uitgevoerd, mislukt de verificatie en wordt de toegang tot een volume vanaf een client geweigerd. Een veelvoorkomend scenario waarin deze situatie zich voordoet, is wanneer NFSv3-toegang wordt geprobeerd naar een volume met NTFS-beveiligingsstijl. De eerste toegangsaanvraag van NFSv3 komt uit op Azure NetApp Files als een numerieke UID. Als een gebruiker met de naam user1 met een numerieke id 1001 probeert toegang te krijgen tot de NFSv3-koppeling, komt de verificatieaanvraag binnen als numerieke id 1001. Azure NetApp Files gebruikt vervolgens een numerieke id 1001 en probeert om te worden omgezet 1001 in een gebruikersnaam. Deze gebruikersnaam is vereist voor toewijzing aan een geldige Windows-gebruiker, omdat de NTFS-machtigingen op het volume Windows-gebruikersnamen bevatten in plaats van een numerieke id. Azure NetApp Files gebruikt de geconfigureerde naamserviceserver (LDAP) om te zoeken naar de gebruikersnaam. Als de gebruikersnaam niet kan worden gevonden, mislukt de verificatie en wordt de toegang geweigerd. Deze bewerking is standaard bedoeld om ongewenste toegang tot bestanden en mappen te voorkomen.
Naamtoewijzing op basis van beveiligingsstijl
De richting waarin de naamtoewijzing plaatsvindt in Azure NetApp Files (Windows naar UNIX of UNIX naar Windows) is niet alleen afhankelijk van het protocol dat wordt gebruikt, maar ook de beveiligingsstijl van een volume. Voor een Windows-client is altijd een Windows-naar-UNIX-naamtoewijzing vereist om toegang toe te staan, maar er is niet altijd een overeenkomende UNIX-gebruikersnaam nodig. Als er geen geldige UNIX-gebruikersnaam aanwezig is op de geconfigureerde naamserviceserver, biedt Azure NetApp Files een standaard-UNIX-terugvalgebruiker met de numerieke UID om 65534 initiële verificatie voor SMB-verbindingen toe te staan. Daarna beheren bestands- en mapmachtigingen de toegang. Omdat 65534 in het algemeen overeenkomt met de gebruiker, is de toegang in de nfsnobody meeste gevallen beperkt. Omgekeerd hoeft een NFS-client alleen een UNIX-naar-Windows-naamtoewijzing te gebruiken als de NTFS-beveiligingsstijl wordt gebruikt. Er is geen standaard Windows-gebruiker in Azure NetApp Files. Als een geldige Windows-gebruiker die overeenkomt met de aangevraagde naam niet kan worden gevonden, wordt de toegang geweigerd.
In de volgende tabel worden de verschillende permutaties voor naamtoewijzingen onderverdeeld en hoe ze zich gedragen, afhankelijk van het protocol dat wordt gebruikt.
| Protocol | Beveiligingsstijl | Naamtoewijzingsrichting | Toegepaste machtigingen |
|---|---|---|---|
| MKB | UNIX | Windows naar UNIX | UNIX (modus-bits of NFSv4.x ACL's) |
| MKB | NTFS | Windows naar UNIX | NTFS-ACL's (op basis van Windows SID die toegang heeft tot share) |
| NFSv3 | UNIX | Geen | UNIX (modus-bits of NFSv4.x ACL's*) |
| NFSv4.x | UNIX | Numerieke id voor UNIX-gebruikersnaam | UNIX (modus-bits of NFSv4.x ACL's) |
| NFS3/4.x | NTFS | UNIX naar Windows | NTFS-ACL's (gebaseerd op toegewezen Windows-gebruikers-SID) |
Notitie
Regels voor naamtoewijzing in Azure NetApp Files kunnen momenteel alleen worden beheerd met LDAP. Er is geen optie om expliciete naamtoewijzingsregels te maken binnen de service.
Naamservices met volumes met twee protocollen
Ongeacht welk NAS-protocol wordt gebruikt, maken volumes met dubbele protocollen gebruik van naamtoewijzingsconcepten om machtigingen correct te verwerken. Daarom spelen naamservices een belangrijke rol bij het onderhouden van functionaliteit in omgevingen die zowel SMB als NFS gebruiken voor toegang tot volumes.
Naamservices fungeren als identiteitsbronnen voor gebruikers en groepen die toegang hebben tot NAS-volumes. Deze bewerking omvat Active Directory, die kan fungeren als een bron voor zowel Windows- als UNIX-gebruikers en -groepen met behulp van zowel standaarddomeinservices als LDAP-functionaliteit.
Naamservices zijn geen harde vereiste, maar worden ten zeerste aanbevolen voor Azure NetApp Files-volumes met twee protocollen. Er is geen concept van het maken van aangepaste lokale gebruikers en groepen binnen de service. Als zodanig is LDAP een noodzaak om de juiste verificatie en nauwkeurige gegevens van gebruikers- en groepseigenaars in protocollen te hebben. Als u slechts een handvol gebruikers hebt en u geen nauwkeurige gebruikers- en groepsidentiteitsgegevens hoeft in te vullen, kunt u overwegen om lokale NFS-gebruikers met LDAP toegang te geven tot een volumefunctionaliteit met twee protocollen. Houd er rekening mee dat als u deze functionaliteit inschakelt, de uitgebreide groepsfunctionaliteit wordt uitgeschakeld.
Wanneer clients, naamservices en opslag zich in verschillende gebieden bevinden
In sommige gevallen kunnen NAS-clients zich in een gesegmenteerd netwerk bevinden met meerdere interfaces met geïsoleerde verbindingen met de opslag- en naamservices.
Een dergelijk voorbeeld is als uw opslag zich in Azure NetApp Files bevindt, terwijl uw NAS-clients en domeinservices zich allemaal on-premises bevinden (zoals een hub-spoke-architectuur in Azure). In deze scenario's moet u netwerktoegang bieden tot zowel de NAS-clients als de naamservices.
In de volgende afbeelding ziet u een voorbeeld van dat soort configuratie.
