Anleitungen zum Storage Account erklären die Azure-Speichergrundlage, die von vielen Automatisierungs- und Reporting-Beispielen verwendet wird. Ein Storage Account wird oft für Exporte, Runbook-Artefakte, Zwischendateien oder langlaufende Workflows benötigt, die einen dauerhaften Speicherort außerhalb des lokalen Geräts brauchen.
Entscheide vor dem Erstellen der Ressource, ob der Storage Account zu einem temporären Lab, einem wiederverwendbaren Demo-Tenant oder einem produktionsnahen Reporting-Setup gehört. Diese Entscheidung beeinflusst Namensgebung, Region, Zugriffsmodell, Lifecycle-Regeln und wie sorgfältig du den öffentlichen Zugriff einschränken solltest. Für die meisten Intune-Lab-Workflows ist ein privater Storage Account in derselben Region wie die übrigen Azure-Ressourcen der sicherste Standard.
Notiere nach dem Deployment den Namen des Storage Accounts, die Container-Namen und das von der zugehörigen Automatisierung verwendete Berechtigungsmodell. Wenn eine spätere Anleitung Skripte, Reports oder exportierte Intune-Daten hochlädt, lässt sich anhand dieser Angaben viel leichter überprüfen, ob der richtige Workflow an die richtige Stelle schreibt.
Storage Account
- Melde dich am Azure-Portal an
- Suche nach Storage Account und wähle den Dienst Storage accounts aus
- Klicke oben auf + Create
- Wähle das Abonnement, die Ressourcengruppe und die Region aus und gib einen Namen für das Konto ein.
- Klicke auf Review + create und create
Du solltest dir auch alle anderen Einstellungen ansehen. (Für eine Produktionsumgebung wird beispielsweise empfohlen, den Speicher in ein Netzwerk zu legen, die Verschlüsselung über kundenseitig verwaltete Schlüssel zu aktivieren sowie den Datenschutz zu konfigurieren.)
Um einen Container zu erstellen, klicke auf + Container und gib einen Namen ein
Die richtige Leistungsstufe und Redundanz wählen
Wenn du einen Storage Account erstellst, der Win32-App-Payloads, Skripte, benutzerdefinierte Intune-Compliance-Frameworks oder Remediation-Pakete hosten soll, sind die Konfigurationsentscheidungen, die du beim Erstellen triffst, später nur schwer zu ändern. Die Leistungsstufe Standard mit General Purpose v2 (GPv2) ist für nahezu jeden Intune-bezogenen Workload der richtige Standard, da sie die niedrigsten Kosten pro GB, vollen Funktionsumfang mit Lifecycle-Management und Zugriff auf die Zugriffsebenen Cool und Archive bietet. Premium-Block-Blob-Konten sind nur für Workloads sinnvoll, die einstellige Millisekunden-Leselatenz benötigen, was bei einem einmaligen Geräte-Download selten erforderlich ist.
In Bezug auf Redundanz hält Locally-Redundant Storage (LRS) drei synchrone Kopien innerhalb eines einzigen Rechenzentrums und ist die günstigste Option. Zone-Redundant Storage (ZRS) verteilt Kopien auf drei Verfügbarkeitszonen in derselben Region und wird immer dann empfohlen, wenn ein Ausfall eines einzelnen Rechenzentrums Geräteanmeldungen oder App-Installationen blockieren würde. Geo-Redundant Storage (GRS oder GZRS) repliziert asynchron in eine gepaarte Region und eignet sich für Compliance-Baselines oder signierte Installer-Payloads, die du nach einer regionalen Katastrophe nicht erneut hochladen kannst.
Das Konto vor der ersten Nutzung härten
Bevor du einen Container in Betrieb nimmst, deaktiviere den öffentlichen Blob-Zugriff auf Kontoebene, erzwinge TLS 1.2 oder höher als minimale Transportversion und schalte die Shared-Key-Autorisierung zugunsten von Microsoft Entra ID-Identitäten ab, wo immer dein Tooling dies unterstützt. Die Kombination dieser drei Einstellungen eliminiert die häufigsten Exfiltrationsmuster – anonyme Container-Enumeration, Man-in-the-Middle-Angriffe mit herabgestufter Verschlüsselung und in öffentlichen Repositories veröffentlichte Kontoschlüssel.
Aktiviere Soft Delete für Blobs und Container mit einem Aufbewahrungsfenster von 14 bis 30 Tagen und schalte die Blob-Versionierung ein, damit ein versehentliches Überschreiben einer signierten MSI oder eines Remediation-Skripts ohne Wiederherstellung aus einem separaten Backup rückgängig gemacht werden kann. Aktiviere für Payloads, die aus Intune-Zuweisungs-URLs referenziert werden, zusätzlich den Change Feed, sodass du einen unveränderlichen Audit-Trail jeder PUT- und DELETE-Operation hast – das ist von unschätzbarem Wert, wenn du untersuchst, warum ein Gerät plötzlich eine erwartete Installation nicht mehr erhält.
Zugriff für Intune und Geräte gewähren
Von Intune verwaltete Geräte authentifizieren sich nicht mit einer Unternehmensidentität bei Azure Storage. Die zwei praktischen Optionen sind zeitlich begrenzte User-Delegation-SAS-Tokens, die zum Deployment-Zeitpunkt von einer Azure Function oder Logic App generiert werden, oder anonymer Lesezugriff auf einen eng begrenzten Container, der nur nicht sensible, signierte Payloads enthält. Bevorzuge für alles Proprietäre immer den SAS-Ansatz, setze die SAS-Lebensdauer auf das kürzeste Intervall, das langsame Verbindungen noch ermöglicht, den Download abzuschließen, und beschränke das Token auf die Berechtigung read sowie einen bestimmten IP-Bereich, wenn Geräte hinter einem bekannten Egress-Proxy sitzen.