Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel bietet Sicherheitshinweise für Azure Files, einschließlich klassischer Dateifreigaben, die mit Microsoft.Storage erstellt wurden, und Dateifreigaben, die mit Microsoft.FileShares erstellt wurden. Es umfasst die Ressourcen, die Ihre Freigaben enthalten, den Kundenzugang, den Datenschutz und die operativen Kontrollen.
Sicherheitskontrollen hängen vom Ressourcenanbieter und Protokoll ab. Für einen Vergleich der unterstützten Funktionen siehe Azure Files Management Concepts.
Ressourcenisolation
Behandle das Speicherkonto als Vertrauensgrenze: Das Erstellen separater klassischer Dateifreigaben im selben Speicherkonto isoliert nicht deren Netzwerkregeln, SMB-Identitätsquelle oder Verschlüsselungsschlüsselkonfiguration. Änderungen an diesen Einstellungen auf Kontoebene betreffen alle Freigaben im Konto. Gruppieren Sie klassische Freigaben nur, wenn sie diese Steuerungen teilen können. Microsoft.FileShares umgeht diese auf der Ebene des gemeinsam genutzten Kontos bestehende Begrenzung, indem für jede Freigabe eine eigenständige Netzwerk- und Sicherheitskonfiguration bereitgestellt wird.
Schütze Client-Systeme: Ein Client mit Schreibzugriff kann Dateidaten ändern oder löschen. Halte die Betriebssysteme der Clients aktuell und schränke den lokalen Administratorzugriff ein. Verwenden Sie den Endpunktschutz, der der Client-Umgebung entspricht. Netzwerkisolation und Verschlüsselung verhindern nicht, dass ein autorisierter Client destruktive Änderungen vornimmt.
Netzwerksicherheit
Eingehender Zugriff und ausgehende Filterung
Begrenze den eingehenden Zugriff auf die Clients, die ihn benötigen: Beide Ressourcenanbieter unterstützen private Endpunkte und Service-Endpunkte mit virtuellen Netzwerkbeschränkungen. Der Zugriff auf NFS Azure-Dateifreigaben erfordert einen der folgenden Pfade. Klassische SMB- und FileREST-Clients können auch öffentliche Endpunkte mit IP-Adressregeln verwenden. Für Konfigurationsschritte siehe Netzwerk-Endpunkte konfigurieren für Azure-Dateifreigaben.
Deaktivieren Sie den öffentlichen Zugriff, wenn er nicht benötigt wird: Öffentliche Endpunkte können sicher mit Netzwerkzugriffskontrollen, Authentifizierung und Verschlüsselung verwendet werden, die dem Protokoll entsprechen. Halte den öffentlichen Zugang aktiviert, wenn deine Arbeitslasten es erfordern und dein Sicherheitsmodell es erlaubt, auch für Verbindungen über Service-Endpunkte. Das Erstellen eines privaten Endpunkts deaktiviert den öffentlichen Zugang nicht automatisch. Für klassische Shares überprüfen Sie alle Ausnahmen von vertrauenswürdigen Diensten oder Ressourceninstanzen, die nach der Deaktivierung des öffentlichen Zugangs weiterhin wirksam bleiben können. Weitere Informationen finden Sie unter Zugriff auf öffentliche Endpunkte einschränken.
Nur bei Bedarf den Zugriff auf vertrauenswürdige Dienste aktivieren: Nur für klassische Dateifreigaben verfügbar, ermöglicht die Einstellung für vertrauenswürdige Dienste unterstützten Azure-Diensten, die Netzwerkregeln des Speicherkontos zu umgehen. Aktivieren Sie es nur, wenn eine Integration diesen Zugriff benötigt. Diese Dienste müssen weiterhin autorisiert sein, um auf Ihre Dateidaten zuzugreifen.
Optionale Filterung für Service-Endpunkt-Verkehr: Wenn Clients Service-Endpunkte nutzen, um auf klassische Dateifreigaben zuzugreifen, können Sie optional eine Service-Endpunkt-Richtlinie auf ihr Subnetz anwenden. Die Richtlinie begrenzt, auf welche Speicherkonten diese Clients über Service-Endpunkte zugreifen können, wobei der Datenverkehr die Azure Firewall und Netzwerk-Virtual-Appliances umgeht. Es gilt nur für Service-Endpunkt-Verkehr und filtert keinen privaten Endpunkt-Verkehr oder andere ausgehende Pfade. Die Netzwerkregeln und Autorisierungsanforderungen des Ziels gelten weiterhin. Microsoft. FileShares unterstützt diese Richtlinien derzeit nicht. Clients in einem Subnetz mit einer Richtlinie müssen einen privaten Endpunkt nutzen, um auf Microsoft.FileShares-Freigaben zuzugreifen. Weitere Informationen finden Sie unter Service-Endpunkt-Richtlinien.
Überprüfen Sie die Protokollunterstützung vor der Nutzung eines Netzwerksicherheitsperimeters: Für klassische Shares unterscheidet sich die Perimeter-Unterstützung je nach Protokoll und Authentifizierungsmethode. Im Enforced Mode verweigert ein Perimeter den NFS-Zugriff über den öffentlichen Endpunkt, einschließlich Verkehr am Service-Endpunkt. Der Verkehr an privaten Endpunkten befindet sich außerhalb der Perimeter-Durchsetzung. Überprüfen Sie die Einschränkungen für Azure Backup und Azure-Dateisynchronisierung, bevor Sie einen Perimeter anwenden. Weitere Informationen finden Sie unter Network Security Perimeter für Azure Files.
SMB-Protokollhärtung
Diese Empfehlungen gelten für klassische SMB-Dateifreigaben.
SMB-Kanalverschlüsselung anfordern: Verschlüsselte SMB-3.x-Verbindungen verwenden. SMB 2.1 unterstützt keine Kanalverschlüsselung. Die HTTPS-Anforderung für FileREST ersetzt nicht die SMB-Verschlüsselungskonfiguration. Weitere Informationen finden Sie unter SMB-Verschlüsselung und Sicherheitseinstellungen.
Beschränken Sie Protokollversionen und Algorithmen auf diejenigen, die Ihre Clients benötigen: Verwenden Sie das sicherste SMB-Profil, das mit Ihren Workloads kompatibel ist. Überprüfen Sie den Client-Support, bevor Sie SMB 3.1.1 oder AES-256-GCM voraussetzen, da inkompatible Clients keine Verbindung herstellen können. SMB-Kanalverschlüsselung und Kerberos-Ticketverschlüsselung sind getrennte Kontrollen. Weitere Informationen finden Sie unter SMB-Sicherheitseinstellungen.
Begrenze SMB-Authentifizierungsmethoden: Nutze Kerberos für identitätsbasierten Zugriff. Wenn keine Clients eine Speicher-Konto-Schlüssel-Authentifizierung über SMB benötigen, entferne NTLMv2 nach dem Test aus den erlaubten SMB-Authentifizierungsmethoden. Diese Kontrolle gilt für SMB; sie deaktiviert den schlüsselbasierten FileREST-Zugriff nicht.
Pflegen Sie die AD DS-Zugangsdaten, wo anwendbar: Für die AD DS-Authentifizierung verwalten Sie das Passwort des Verzeichnisprinzips, das das Speicherkonto gemäß Ihrer Verzeichnisrichtlinie repräsentiert. Befolgen Sie das dokumentierte Rotationsverfahren, um das Verzeichnispasswort und den Kerberos-Schlüssel des Speicherkontos synchron zu halten. Weitere Informationen finden Sie unter Kennwort des Speicherkonto-Identitätsobjekts in AD DS aktualisieren.
NFS 4.1 Dateifreigaben
Diese Empfehlungen gelten für NFS-Dateifreigaben bei beiden Ressourcenanbietern. NFS verwendet netzwerkbasierte Authentifizierung und POSIX-Berechtigungen, nicht SMB-Identitätsbasierte Authentifizierung.
Begrenze den Zugang zu vertrauenswürdigen Netzwerken: Erlaube nur die Subnetze und privaten Verbindungen, die vom Workload benötigt werden. NFS basiert auf den vom Client präsentierten Identitäten, daher steuern Sie, welche Systeme und Administratoren diese Verbindungen nutzen können.
POSIX-Berechtigungen und Client-Identitäten verwalten: Verwenden Sie konsistente Benutzer-IDs und Gruppen-IDs über alle Clients hinweg. Beschränke Datei- und Verzeichnisberechtigungen auf Benutzer und Gruppen, die Zugriff benötigen. Azure RBAC-Berechtigungen zur Verwaltung der Azure-Ressource gewähren keinen NFS-Dateizugriff. Weitere Informationen finden Sie unter NFS-Authentifizierung und Netzwerkzugang.
Konfigurieren Sie Root-Squash, wenn mit der Arbeitslast kompatibel: Root-Squash ordnet Anfragen von UID/GID 0 einer anonymen Identität zu. Es schränkt keine anderen Identitäten ein und macht keine Freigabe schreibgeschützt. Für Einstellungen und Konfigurationsschritte für beide Ressourcenanbieter siehe Root Squashing für NFS Azure-Dateifreigaben.
Verschlüsselung während des Transports erforderlich: Beide Ressourcenanbieter unterstützen TLS über den AZNFS-Mount-Helfer. Microsoft.FileShares erfordert standardmäßig eine Verschlüsselung während des Transports. Klassische Shares verfügen über NFS-Verschlüsselungseinstellungen auf Storage-Account-Ebene. Für Standardwerte und Konfigurationslinks siehe NFS-Verschlüsselung.
Identitäts- und Zugriffsverwaltung
Azure-Ressourcenverwaltung
Nutze das Prinzip der geringsten Rechte für den Verwaltungszugriff: Gewähre Azure RBAC-Berechtigungen im kleinsten Umfang, der zum Erstellen, Konfigurieren oder Löschen von Ressourcen benötigt wird. Für klassische Freigaben können Berechtigungen auf Kontoebene jede Freigabe im Konto beeinflussen. Du kannst Microsoft.FileShares-Ressourcen unabhängig voneinander verwalten. Verwaltungsrollen und Datenzugriffsberechtigungen haben unterschiedliche Zwecke. Weitere Informationen finden Sie unter Azure-Steuerebene und -Datenebene.
Begrenze den ständigen administrativen Zugriff: Nutze Microsoft Entra Privileged Identity Management, wo es für privilegierte Azure-Rollen angemessen ist. Verlangen Sie gemäß der Richtlinie Ihrer Organisation eine Genehmigung und Multifaktor-Authentifizierung für die administrative Aktivierung. Weitere Informationen finden Sie unter Privileged Identity Management.
Identitätsbasierte Authentifizierung für SMB-Dateifreigaben
SMB-Identitätsbasierter Zugriff ist für klassische Dateifreigaben verfügbar. Ein Speicherkontoschlüssel gewährt einen breiten Datenzugriff über die Freigaben eines Kontos und identifiziert keinen einzelnen Nutzer.
Verwenden Sie eine von Ihren Clients unterstützte Identitätsquelle: Azure Files unterstützt AD DS, Microsoft Entra Domain Services und Microsoft Entra Kerberos. Ihre Kunden- und Identitätsanforderungen unterscheiden sich. Für unterstützte Szenarien und Einrichtungsanleitungen siehe Identitätsbasierte Authentifizierung für Azure Files.
Verwenden Sie verwaltete Identitäten für unterstützte Anwendungs-Workloads: Verwaltete Identitäten können SMB-Zugriff bieten, ohne Speicherkontoschlüssel zu verteilen. Überprüfen Sie die Rechen-, Client- und Authentifizierungsvoraussetzungen für Ihre Bereitstellung. Weitere Informationen finden Sie unter Zugreifen auf SMB-Freigaben mithilfe verwalteter Identitäten.
Kontoschlüssel schützen, wenn sie erforderlich sind: Beschränken Sie die Berechtigung zum Abrufen oder Regenerieren von Schlüsseln. Speichern Sie die erforderlichen Schlüssel im Azure Key Vault und rotieren Sie sie nach einer Offenlegung oder entsprechend Ihrer Richtlinie für Anmeldeinformationen. Plane die Rotation bei Clients und Integrationen, die die Schlüssel weiterhin verwenden. Weitere Informationen finden Sie unter Verwalten von Speicherkonto-Zugriffsschlüsseln.
Share-Level- und NTFS-Berechtigungen
Diese Berechtigungen gelten für klassische SMB-Dateifreigaben.
Weisen Sie Share-Level-Rollen im erforderlichen Umfang zu: Gewähren Sie Lese-, Schreib- oder Administratorzugriff nur den Identitäten, die dies benötigen. Rollenzuweisungen auf Share-Ebene vermeiden die Gewährung von Zugriff auf nicht verwandte Shares im selben Speicherkonto. Weitere Informationen finden Sie unter Zuweisen von Berechtigungen auf Freigabeebene.
Verzeichnis- und Dateiberechtigungen anwenden: Verwenden Sie Windows-ACLs, auch im Root-Verzeichnis der Share, wo erforderlich, um den Zugriff innerhalb der Freigabe zu steuern. Nutze Vererbung, um die Berechtigungen handhabbar zu halten. Sowohl Berechtigungen auf Share-Ebene als auch Windows-ACLs werden durchgesetzt. Weitere Informationen finden Sie unter Konfigurieren von Berechtigungen auf Verzeichnisebene und Dateiebene.
Einschränkung der Berechtigungsverwaltung: Begrenze erhöhte Rollen und ACL-Änderungsrechte auf Identitäten, die für die Verwaltung von Berechtigungen verantwortlich sind. Überprüfen Sie sowohl Rollenzuweisungen als auch geerbte ACLs, wenn sich die Zugriffsanforderungen ändern.
FileREST-Zugriff und SAS
FileREST-Datenzugriff ist für klassische Freigaben verfügbar. Microsoft.FileShares unterstützt derzeit keinen Zugriff auf FileREST-Daten.
Nutzen Sie OAuth für den unterstützten administrativen Datenzugriff: Microsoft Entra-Identitäten, einschließlich verwalteter Identitäten, können über FileREST auf klassische Freigaben zugreifen. Die privilegierten Rollen, die von dieser Zugriffsmethode verwendet werden, können Datei- und Verzeichnisberechtigungen umgehen und gewähren Sie sie daher nur, wenn dieser Zugriff erforderlich ist. Weitere Informationen finden Sie unter Azure Files OAuth over REST.
Begrenze SAS-Berechtigungen und Lebensdauer: Wenn ein unterstütztes Tool eine Shared-Access-Signatur (SAS) benötigt, beschränke dessen Umfang, Berechtigungen und Gültigkeitsdauer und schreibe HTTPS vor. Schützen Sie das SAS als Anmeldeinformation. SAS-Token werden nicht verwendet, um Freigaben über SMB oder NFS zu montieren. Weitere Informationen finden Sie unter Shared Access Signatures.
HTTPS für FileREST benötigen: HTTPS schützt REST-Anfragen während des Transits. SMB-Kanalverschlüsselung und NFS-TLS-Tunneling sind von der HTTPS-Anforderung getrennt. Für Konfigurationsschritte, siehe Sichere Übertragung anfordern.
Datenschutz
Verschlüsselung im Ruhezustand verstehen: Beide Ressourcenanbieter verschlüsseln Dateidaten im Ruhezustand standardmäßig mit von Microsoft verwalteten Schlüsseln. Verschlüsselung ruhender Daten schützt gespeicherte Daten; sie verhindert nicht, dass autorisierte Clients Dateien lesen oder ändern.
Verwenden Sie bei Bedarf kundenverwaltete Schlüssel: Klassische Freigaben unterstützen kundenverwaltete Schlüssel in Azure Key Vault oder Managed HSM. Microsoft. FileShares unterstützt derzeit keine vom Kunden verwalteten Schlüssel. Schützen Sie den Schlüsselspeicher, planen Sie die Schlüsselrotation und verstehen, dass der Verlust des Schlüsselzugriffs die Daten unzugänglich machen kann. Weitere Informationen finden Sie unter Von Kunden verwaltete Schlüssel für Azure Files.
Bewerten Sie die Infrastrukturverschlüsselung für anwendbare klassische Deployments: Klassische Speicherkonten können eine zusätzliche Verschlüsselungsschicht haben, wenn Ihre Compliance-Richtlinie dies erfordert. Diese Option wird bei der Kontoerstellung ausgewählt und kann danach nicht mehr geändert werden. Für unterstützte Kontotypen siehe Infrastruktur-Verschlüsselung.
Verwenden Sie Ressourcensperren zum Schutz von Verwaltungsoperationen: Eine CanNotDelete-Sperre auf der entsprechenden Azure-Ressource oder dem übergeordneten Scope kann die Löschung über den Azure Resource Manager verhindern. Sperren verhindern nicht, dass Clients Dateidaten ändern oder löschen. Bei klassischen Freigaben verhindern klassische Freigaben auch keine Löschung über FileREST-Data-Plane-APIs. Für Sperrverhalten und operative Auswirkungen siehe Azure-Ressourcen sperren.
Sicherung und Wiederherstellung
Erstellen Sie Freigabe-Snapshots entsprechend dem Wiederherstellungsbedarf: Beide Ressourcenanbieter unterstützen Freigabe-Snapshots zur Wiederherstellung früherer Dateiversionen. Legen Sie einen Zeitplan und eine Aufbewahrungsrichtlinie fest, die Ihren Wiederherstellungszielen entsprechen. Freigabe-Snapshots bleiben mit der Quellfreigabe verknüpft, sodass sie kein unabhängiges Backup bieten, wenn diese Freigabe dauerhaft gelöscht wird. Weitere Informationen finden Sie unter Freigabemomentaufnahmen für Azure Files.
Soft-Delete für klassische Shares aktivieren: Soft Delete speichert gelöschte Shares für einen konfigurierten Zeitraum. Es stellt keine einzelnen Dateien wieder her und stellt keine einzeln gelöschten Momentaufnahmen wieder her. Microsoft. FileShares unterstützt derzeit kein Soft-Delete. Weitere Informationen finden Sie unter Verhindern eines versehentlichen Löschens von Azure-Dateifreigaben.
Wählen Sie eine Backup-Lösung, die vom Protokoll unterstützt wird: Azure Backup unterstützt klassische SMB-Shares mit Momentaufnahme- und Vault-Backup-Optionen. Derzeit werden NFS-Shares mit keinem der beiden Ressourcenanbieter unterstützt. Für NFS wählen Sie eine Backup-Lösung, die das Protokoll unterstützt und Ihre Anforderungen an Aufbewahrung und Isolierung erfüllt. Informationen zur Azure Backup-Abdeckung finden Sie unter Sicherungssupport für Azure-Dateifreigaben.
Getrennte Backup-Verwaltung und Testwiederherstellung: Begrenze, wer Wiederherstellungspunkte löschen oder die Aufbewahrung ändern kann. Testen Sie die Wiederherstellung von Dateien, Berechtigungen und vollständigen Workloads. Überprüfen Sie, dass die Wiederherstellung möglich bleibt, falls Produktionszugangsdaten oder die Quellfreigabe kompromittiert werden.
Planen Sie Infrastrukturausfälle getrennt von der Datenwiederherstellung: Redundanz verbessert die Widerstandsfähigkeit gegenüber Infrastrukturausfällen, repliziert aber auch Datenänderungen. Es ersetzt keine Backups bei unerwünschten Änderungen oder Löschungen. Die verfügbaren Redundanzoptionen unterscheiden sich je nach Medienstufe und Ressourcenanbieter. Weitere Informationen finden Sie unter Azure Files-Redundanz.
Protokollierung und Überwachung
Überwachung von Verwaltungsänderungen für beide Ressourcenanbieter: Verwenden Sie das Azure Activity Log, um die Löschung von Ressourcen, Konfigurationsänderungen und Rollenzuweisungen zu überwachen. Überprüfen Sie Änderungen am öffentlichen Zugang, Netzwerkregeln, Verschlüsselungsanforderungen und Wiederherstellungskontrollen. Weitere Informationen finden Sie im Azure-Aktivitätsprotokoll.
Sammeln Sie unterstützte Datenzugriffsprotokolle: Für klassischen SMB- und FileREST-Zugriff verwenden Sie Dateiservice-Ressourcenprotokolle, um Anrufer, Autorisierungsmethoden, fehlgeschlagene Anfragen und Löschaktivitäten zu überprüfen. Sammeln Sie die von Ihrer Aufbewahrungsrichtlinie geforderten Protokolle in Log Analytics oder einem anderen unterstützten Zielort. Gehen Sie nicht davon aus, dass NFS oder Microsoft.FileShares dieselbe Abdeckung der Anforderungsprotokollierung aufweisen. Für unterstützte Operationen und Felder siehe Azure Files Monitoring Data Reference.
Korrelieren Sie Warnungen mit Client- und Identitätsprotokollen: Untersuchen Sie unerwartete Schlüsselnutzung, fehlgeschlagene Authentifizierung, Löschung von Sharen und Änderungen der Sicherheitskonfiguration. Verwenden Sie Client- und Verzeichnislogs, wenn ein Authentifizierungsfehler auftritt, bevor die Anfrage Azure Files erreicht. Leiten Sie Benachrichtigungen an das für den Workload zuständige Team weiter.
Bewerten Sie Defender for Storage für klassische Deployments: Defender for Storage bietet Bedrohungserkennung für unterstützte Speicherkonten. Überprüfen Sie die Funktions- und Protokollabdeckung Ihrer Bereitstellung; Kontoschutz bedeutet nicht, dass jede Dateioperation auf Malware gescannt wird. Weitere Informationen finden Sie unter Microsoft Defender for Storage.
Compliance und Governance
Wenden Sie Richtlinien an, die mit dem Ressourcenanbieter übereinstimmen: Verwenden Sie die Azure Policy, um die Anforderungen Ihrer Organisation zu überprüfen oder durchzusetzen, sofern der Ressourcentyp und die Eigenschaften unterstützt werden. Überprüfen Sie den Umfang und die Auswirkungen jeder Definition. Eine Richtlinie, die auf Microsoft.Storage-Speicherkonten abzielt, wertet Microsoft.FileShares-Ressourcen nicht automatisch aus. Weitere Informationen finden Sie unter Azure-Richtliniendefinitionen.
Datenbesitz und Datenanforderungen: Verwenden Sie Ressourcen-Tags, um das verantwortliche Team, die Umgebung und die Datenklassifizierung zu identifizieren. Für klassische Freigaben wirken sich Kontrollen auf Kontoebene auf alle Freigaben im Konto aus. Notieren Sie Ausnahmen und überprüfen Sie sie, wenn sich die Verantwortlichkeit für die Workload ändert.
Prüfen Sie die Konformität für die Bereitstellung: Bestätigen Sie, dass der ausgewählte Dienst, die Region, das Protokoll und die Schutzfunktionen Ihren Anforderungen entsprechen. Nutzen Sie den Microsoft Cloud Security Benchmark, um Kontrollüberprüfungen zu organisieren. Für Zertifizierungsinformationen siehe Azure Storage Compliance-Angebote.
Azure-Dateisynchronisierung
Azure-Dateisynchronisierung unterstützt klassische SMB-Shares. Es unterstützt weder NFS noch Microsoft.FileShares. Sichere sowohl die Cloud-Freigabe als auch die Windows Server-Endpunkte.
Verwenden Sie verwaltete Identitäten für unterstützte File Sync-Deployments: Folgen Sie der Managed Identity-Konfiguration für den Storage Sync Service und registrierte Server, um die Abhängigkeit von gemeinsamen Schlüsseln zu beseitigen. Weitere Informationen finden Sie unter Use managed identities with Azure-Dateisynchronisierung.
Beschränken Sie den administrativen Zugriff auf Sync-Ressourcen und Server: Verwenden Sie die erforderlichen Storage Sync-Rollen im entsprechenden Umfang. Schutz lokaler Dateiberechtigungen und der Serververwaltung, da Änderungen, die über einen Server-Endpunkt vorgenommen werden, mit der Cloud-Freigabe synchronisiert werden können. Weitere Informationen finden Sie unter Planen einer Azure-Dateisynchronisierung-Bereitstellung.