Azure Storage-Konten

Ein Azure Storage Account ist die grundlegende Ressource, die Ihnen Zugriff auf die zentralen Azure-Speicherdienste bietet: Blob Storage (Objektspeicher), Azure Files (verwaltete Dateifreigaben), Queue Storage (Nachrichtenwarteschlangen), Table Storage (NoSQL-Schlüssel-Wert-Speicher) und Azure Data Lake Storage Gen2 (hierarchischer Namespace für Analysen). Ein einzelner Storage Account kann all diese Dienste gleichzeitig hosten und stellt in Azure einen eindeutigen Namespace bereit — der Kontoname wird Bestandteil der URL jedes darin enthaltenen Objekts.

Azure bietet mehrere Typen von Storage Accounts: Standard general-purpose v2 (GPv2) — der empfohlene Typ für die meisten Szenarien; unterstützt alle Speicherdienste und Redundanzoptionen bei Standardleistung. Premium block blobs — SSD-basierter Speicher für Szenarien, die eine sehr niedrige Latenz bei Blob-Storage-Vorgängen erfordern. Premium file shares — SSD-basierte Azure-Files-Freigaben für Workloads mit hohen IOPS, etwa Datenbanken oder Home-Verzeichnisse. Premium page blobs — SSD-Speicher für Betriebssystem- und Datenträger von Azure-VMs (Managed Disks verwenden diesen im Hintergrund). Beginnen Sie bei den meisten Anwendungsfällen mit einem Standard-GPv2-Konto.

Azure repliziert Ihre Daten automatisch, um sie vor Hardwarefehlern zu schützen. Die vier Redundanzoptionen sind: LRS (Locally Redundant Storage) — drei synchrone Kopien innerhalb eines einzelnen Rechenzentrums. ZRS (Zone-Redundant Storage) — drei synchrone Kopien über drei Verfügbarkeitszonen in einer Region verteilt. GRS (Geo-Redundant Storage) — LRS in der primären Region plus asynchrone Replikation in eine sekundäre Region (LRS). GZRS (Geo-Zone-Redundant Storage) — ZRS in der primären Region plus asynchrone Replikation in eine sekundäre Region. Mehr Redundanz bedeutet höhere Datenbeständigkeit und höhere Kosten.

Wählen Sie die Redundanzstufe auf Grundlage Ihrer Anforderungen an RTO, RPO und Budget: LRS — am günstigsten, Datenbeständigkeit von 11 Neunen, kein Schutz vor dem Ausfall eines Rechenzentrums. Verwenden Sie diese Option für Entwicklungs- und Testumgebungen oder Daten, die Sie neu erstellen können. ZRS — schützt vor dem Ausfall eines Rechenzentrums und eignet sich gut für Produktionsdaten in einer einzelnen Region. GRS/GZRS — schützt vor dem Ausfall einer gesamten Azure-Region; die Daten werden asynchron in die gekoppelte Region repliziert. Für geschäftskritische Daten, die einen regionalen Katastrophenfall überstehen müssen, sind GRS oder GZRS trotz der zusätzlichen Kosten die geeignete Wahl.

Azure Storage bietet zwei Leistungsstufen: Standard — basiert auf Festplattenlaufwerken (HDD) und eignet sich für die meisten Workloads bei geringeren Kosten pro GB. Premium — basiert auf Solid-State-Laufwerken (SSD) und wurde für latenzempfindliche Szenarien entwickelt, die I/O im einstelligen Millisekundenbereich erfordern. Standard-Speicher wird pro gespeichertem GB abgerechnet; Premium ist pro GB teurer, bietet jedoch eine gleichmäßige und vorhersehbare Leistung. Für Webressourcen, Backups, Protokolle und Archivierung ist Standard geeignet. Für VMs mit I/O-intensiven Datenbanken oder Dateifreigaben, auf die Desktopbenutzer zugreifen, ist Premium die bessere Wahl.

Namen von Storage Accounts müssen in ganz Azure global eindeutig sein (da sie Bestandteil eines öffentlichen DNS-Namens wie mystorageacct.blob.core.windows.net sind). Namen müssen 3 bis 24 Zeichen lang sein und dürfen nur Kleinbuchstaben und Ziffern enthalten — keine Bindestriche, Unterstriche oder Großbuchstaben. Da Namen global eindeutig sein müssen, sind allgemeine Wörter und Markennamen bereits vergeben. Eine bewährte Vorgehensweise besteht darin, ein Unternehmenspräfix, die Umgebung (prod/dev) und den Zweck (store/media) zu kombinieren und bei Bedarf ein zufälliges Suffix anzuhängen: z. B. contosoprodmedia7x2.

Jeder Storage Account verfügt über zwei 512-Bit-Zugriffsschlüssel, die vollständigen administrativen Zugriff auf alle Inhalte des Kontos gewähren. Behandeln Sie diese Schlüssel wie Passwörter — speichern Sie sie in Azure Key Vault und nicht im Code oder in Konfigurationsdateien. Azure generiert zwei Schlüssel, damit Sie eine Schlüsselrotation ohne Ausfallzeit durchführen können: Aktualisieren Sie Ihre Anwendungen so, dass sie Schlüssel 2 verwenden, generieren Sie anschließend Schlüssel 1 neu, stellen Sie dann die Anwendungen auf Schlüssel 1 um und generieren Sie danach Schlüssel 2 neu. Für eine feiner abgestufte Zugriffskontrolle verwenden Sie anstelle der Hauptschlüssel Shared Access Signatures (SAS) oder Azure RBAC.

Azure RBAC (Role-Based Access Control) ist die empfohlene Methode, um den Zugriff auf Speicherdaten zu autorisieren, ohne Schlüssel weiterzugeben. Weisen Sie die Rolle Storage Blob Data Reader für schreibgeschützten Zugriff auf Blob Storage oder Storage Blob Data Contributor für Lese- und Schreibzugriff zu. Diese Rollen werden Entra ID-Benutzern, Gruppen oder verwalteten Identitäten zugewiesen. Dadurch ist der Zugriff an eine authentifizierte Identität statt an ein gemeinsam genutztes Geheimnis gebunden. Die RBAC-Autorisierung für Storage ist für die Dienste Blob, Queue und Table verfügbar (nicht für File — dort werden SMB/NFS-Protokolle mit eigenen Zugriffskontrollen verwendet).

Standardmäßig akzeptieren Storage Accounts Verbindungen aus jedem Netzwerk. Beschränken Sie den Zugriff in Produktionsumgebungen mithilfe der Storage Account Firewall: Erlauben Sie nur bestimmte öffentliche IP-Bereiche oder Subnetze virtueller Netzwerke. Für die höchstmögliche Sicherheit deaktivieren Sie den öffentlichen Internetzugriff vollständig und verwenden einen Private Endpoint — eine private IP-Adresse innerhalb Ihres VNet, die den Datenverkehr über das private Azure-Backbone zum Storage Account leitet, ohne ihn jemals im öffentlichen Internet verfügbar zu machen. Private Endpoints sind der empfohlene Ansatz für Storage Accounts mit vertraulichen oder regulierten Daten.

Azure Storage bietet integrierte Datenschutzfunktionen zum Schutz vor versehentlichem Löschen: Blob soft delete — gelöschte Blobs und Versionen werden für einen konfigurierbaren Zeitraum (1–365 Tage) aufbewahrt und können ohne Wiederherstellung aus einem Backup zurückgeholt werden. Blob versioning — jede Überschreibung erstellt eine neue Version, sodass Sie jede vorherige Version eines Blobs wiederherstellen können. Container soft delete — versehentlich gelöschte Container können wiederhergestellt werden. Diese Funktionen sind standardmäßig deaktiviert und sollten für Produktions-Storage Accounts aktiviert werden, die wichtige Daten enthalten, die nicht anderweitig gesichert sind.

Azure Monitor erfasst automatisch Metriken für jeden Storage Account: insgesamt genutzte Kapazität, Anzahl der Transaktionen, eingehende und ausgehende Bytes sowie die End-to-End-Latenz. Sie können diese Metriken im Blatt Insights des Azure-Portals für Ihren Storage Account anzeigen. Dort stehen vorgefertigte Diagramme zu Kapazität, Verfügbarkeit und Leistung bereit. Für eine detaillierte Zugriffsüberwachung aktivieren Sie Storage Diagnostic Logs, um jeden Lese-, Schreib- und Löschvorgang an einem Protokollziel aufzuzeichnen — nützlich für Sicherheitsuntersuchungen und Compliance-Berichte.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie Folgendes gelernt: Ein Storage Account ist die zentrale Ressource für alle Azure-Speicherdienste und wird durch einen global eindeutigen Namen identifiziert, Redundanzoptionen — LRS, ZRS, GRS und GZRS — bieten bei steigenden Kosten ein immer höheres Maß an Datenbeständigkeit, und der Zugriff sollte über RBAC und private Endpunkte kontrolliert werden, statt die Hauptzugriffsschlüssel weiterzugeben. Als Nächstes beschäftigen wir uns ausführlich mit Blob Storage — dem Objektspeicher von Azure für unstrukturierte Daten.