Schützen Sie Ihren Azure Queue Storage

Azure Queue Storage bietet Nachrichtenwarteschlangen zwischen Anwendungskomponenten. Da Nachrichten oft Verweise auf sensible Ressourcen – Objektkennungen, Rückruf-URLs und Anwendungsstatus – enthalten, müssen Sie sowohl die Warteschlangenautorisierung als auch die Verarbeitung von Nachrichteninhalten sichern.

Note

Dieser Artikel behandelt Sicherheitspraktiken speziell für Azure Queue Storage. Für Sicherheitsratschläge auf Kontoebene siehe Secure your Azure Storage account.

Identitäts- und Zugriffsverwaltung

  • Verwenden Sie Microsoft Entra ID mit verwalteten Identitäten für Warteschlangenproduzenten und -verbraucher: Weisen Sie die integrierten Rollen Storage Queue Data Message Sender, Storage Queue Data Message Processor und Storage Queue Data Reader der verwalteten Identität jedes Dienstes zu, der mit der Warteschlange interagiert. Wählen Sie die Rolle, die zur Operation passt. Ein Nachrichtendienst sollte keine Prozessorrechte besitzen. Weitere Informationen finden Sie unter Zugriff auf Warteschlangen autorisieren mit Microsoft Entra ID.

  • Rollenzuweisungen der rollenbasierten Zugriffskontrolle (RBAC) auf die spezifische Warteschlange begrenzen: Für die integrierten Warteschlangendatenrollen wird der Warteschlangenumfang unterstützt. Weisen Sie auf Ebene der Warteschlange statt auf Ebene des Speicherkontos zu, wenn ein Dienst nur Zugriff auf eine einzige Warteschlange in einem Konto mit mehreren Warteschlangen benötigt.

  • SAS-Token auf eine einzelne Warteschlange und bestimmte Nachrichtenvorgänge beschränken: Die Shared Access Signature (SAS) für Warteschlangen unterstützt add, update, process und read als separate Berechtigungen. Gib nur das, was der Anrufer braucht. Ein Webhook-Empfänger, der Ereignisse in die Warteschlange einreiht, sollte nur add erhalten, nicht process. Weitere Informationen finden Sie unter Delegierten Zugriff mit einer Shared Access Signature (SAS).

Datenschutz

Nachrichten werden im Ruhezustand und während der Übertragung durch die Verschlüsselungs- und TLS-Einstellungen des Kontos geschützt, aber sie werden nicht individuell über die Warteschlangenautorisierung hinaus zugriffsgesteuert. Gestalten Sie Nachrichteninhalte so, dass sensible Daten nicht in der Warteschlange konzentriert werden.

  • Fügen Sie keine Geheimnisse oder Zugangsdaten in Warteschlangennachrichten ein: Speichern Sie Geheimnisse in Azure Key Vault und fügen Sie eine Referenz (Geheimniskennung) in die Nachricht ein. Nutzer rufen das Geheimnis während der Verarbeitung mit ihrer eigenen Identität ab. Alles, was in einer Nachricht platziert wird, ist für jeden Prinzipal mit process oder read auf der Warteschlange sichtbar und wird in Speicherprotokolle geschrieben.

  • Sensible Nachrichtenpayloads auf Anwendungsebene verschlüsseln: Für Nachrichten, die sensible Daten enthalten müssen, verschlüsseln Sie die Payload vor der Warteschlange mit einem Schlüssel aus dem Key Vault. Dies fügt eine Schicht hinzu, die unabhängig von der speicherseitigen Verschlüsselung ist, und begrenzt die Exposition, falls ein Verbraucher kompromittiert wird. Weitere Informationen finden Sie unter Client-seitige Verschlüsselung für Azure Storage.

  • Setzen Sie eine angemessene Time-to-Live (TTL) ein: Nachrichten bleiben bestehen, bis sie verarbeitet sind, ablaufen oder die Warteschlange entladen ist. Eine lange TTL erweitert das Zeitfenster, in dem veraltete sensible Daten abgerufen werden können. Passen Sie TTL an die erwartete Verarbeitungslatenz plus eine Sicherheitsmarge an.

Protokollierung und Überwachung

  • Aktivieren Sie Diagnoseeinstellungen für Warteschlangenvorgänge: Senden Sie die Kategorien StorageRead, StorageWrite und StorageDelete an Log Analytics, damit einzelne Warteschlangenvorgänge nachverfolgbar sind. Verfolgen Sie die Autorisierungsmethode (Entra ID, Shared Key, SAS, anonym), um Missbrauch zu erkennen. Weitere Informationen finden Sie unter Monitoring Azure Queue Storage.

  • Nicht verarbeitbare Nachrichten in eine dedizierte Warteschlange für nicht verarbeitbare Nachrichten verschieben: Konfigurieren Sie Ihren Consumer so, dass er Nachrichten erkennt, die Schwelle für Anzahl der Entfernungen aus der Warteschlange überschreiten, und verschieben Sie sie in eine <queue-name>-poison-Warteschlange für die Offline-Untersuchung. Die Ansammlung von Gift-Warteschlangen ist ein Sicherheitssignal, nicht nur ein operatives. Weitere Informationen finden Sie unter Behandeln nicht verarbeitbarer Nachrichten in warteschlangenausgelösten Funktionen.

  • Warnung über das Wachstum der Giftwarteschlange: Konfigurieren Sie Azure Monitor-Warnungen auf die Nachrichtenanzahl in jeder Giftwarteschlange, sodass unerwartetes Wachstum eine Untersuchung auslöst.

  • Warnung bei ungewöhnlichen Mustern des Entfernens aus der Warteschlange und des Löschens: Bursts von DeleteMessage-Vorgängen von unerwarteten Identitäten oder hohe Mengen reiner Aktivitäten zur Entfernung aus der Warteschlange ohne nachgelagerte Verarbeitung können darauf hindeuten, dass ein Angreifer eine Warteschlange leert, um Aktivitäten zu verbergen. Warnung bei Abweichungen vom normalen Verkehrsprofil der Warteschlange.

Nächste Schritte

  • Zuletzt aktualisiert um