Beveilig uw Azure Queue Storage

Azure Queue Storage biedt message queuing tussen applicatiecomponenten. Omdat berichten vaak verwijzingen bevatten naar gevoelige bronnen - objectidentificaties, callback-URL's en applicatiestatus - moet u zowel wachtrijautorisatie als berichtinhoud afhandelen.

Note

Dit artikel behandelt beveiligingspraktijken specifiek voor Azure Queue Storage. Voor beveiligingsrichtlijnen op accountniveau, zie Secure your Azure Storage account.

Identiteits- en toegangsbeheer

  • Gebruik Microsoft Entra ID met beheerde identiteiten voor wachtrijproducenten en consumenten: Wijs de ingebouwde rollen Storage Queue Data Message Sender, Storage Queue Data Message Processor en Storage Queue Data Reader toe aan de beheerde identiteit van elke dienst die met de wachtrij interacteert. Kies de rol die bij de operatie past. Een berichtverzendende dienst zou geen processorrechten moeten hebben. Voor meer informatie, zie Toegang autoriseren tot wachtrijen met Microsoft Entra ID.

  • Beperk roltoewijzingen voor op rollen gebaseerde toegangscontrole (RBAC) tot de specifieke wachtrij: Bereik op wachtrijniveau wordt ondersteund voor de ingebouwde wachtrijgegevensrollen. Wijs toe op wachtrijniveau in plaats van op het opslagaccount wanneer een dienst toegang nodig heeft tot slechts één wachtrij in een multi-queue account.

  • Beperk SAS-tokens voor één wachtrij en specifieke berichtbewerkingen: Shared Access Signature (SAS) voor wachtrijen ondersteunt de machtigingen add, update, process en read afzonderlijk. Geef alleen wat de beller nodig heeft. Een webhook-ontvanger die gebeurtenissen in de wachtrij plaatst, zou alleen add moeten ontvangen, niet process. Zie Toegang delegeren met een handtekening voor gedeelde toegang voor meer informatie.

Gegevensbeveiliging

Berichten worden in opslag en tijdens overdracht beschermd met de encryptie- en TLS-instellingen van het account, maar de toegang ertoe wordt niet afzonderlijk geregeld anders dan via autorisatie op wachtrijniveau. Ontwerp de inhoud van berichten zo dat gevoelige gegevens niet in de wachtrij worden geconcentreerd.

  • Plaats geen geheimen of inloggegevens in wachtrijberichten: Sla geheimen op in Azure Key Vault en plaats een referentie (geheime identificatie) in het bericht. Consumenten halen het geheim tijdens de verwerking op onder hun eigen identiteit. Alles wat in een bericht wordt geplaatst, is zichtbaar voor elke principal met process of read op de wachtrij en wordt geschreven naar opslaglogs.

  • Versleutel gevoelige berichtpayloads op de applicatielaag: Voor berichten die gevoelige data moeten bevatten, versleutel de payload met een sleutel uit Key Vault voordat je in de wachtrij gaat. Dit voegt een laag toe die onafhankelijk is van de encryptie aan de opslagzijde en beperkt de blootstelling als een consument wordt gecompromitteerd. Voor meer informatie, zie Client-side encryptie voor Azure Storage.

  • Stel een redelijke time-to-live (TTL) in: Berichten blijven bestaan totdat ze verwerkt zijn, verlopen of de wachtrij leegloopt. Een lange TTL vergroot het venster waarin verouderde gevoelige gegevens kunnen worden opgehaald. Match TTL aan de verwachte verwerkingslatentie plus een veiligheidsmarge.

Logboekregistratie en bewaking

  • Schakel diagnostische instellingen in voor wachtrijoperaties: Stuur StorageRead, StorageWrite, en StorageDelete categorieën naar Log Analytics zodat individuele wachtrijoperaties controleerbaar zijn. Volg de autorisatiemethode (Entra ID, gedeelde sleutel, SAS, anoniem) om misbruik te detecteren. Voor meer informatie, zie Monitoring Azure Queue Storage.

  • Verplaats gifberichten naar een speciale gifwachtrij: Configureer je consument om berichten te detecteren die de drempel voor het aantal dequeues overschrijden en verplaats ze naar een <queue-name>-poison wachtrij voor offline onderzoek. Poison-queue accumulatie is een beveiligingssignaal, niet alleen een operationeel signaal. Raadpleeg Poison-berichten verwerken in functies die door wachtrijen worden geactiveerd voor meer informatie.

  • Waarschuwing bij toename van de ongeldigeberichtenwachtrij: Stel Azure Monitor-waarschuwingen in voor het aantal berichten in elke ongeldigeberichtenwachtrij, zodat een onverwachte toename aanleiding geeft tot onderzoek.

  • Waarschuwing bij ongebruikelijke dequeue- en deletepatronen: Pieken in DeleteMessage-bewerkingen vanuit onverwachte identiteiten, of grote hoeveelheden dequeue-activiteit zonder verdere verwerking, kunnen erop wijzen dat een aanvaller een wachtrij leegtrekt om activiteit te verbergen. Waarschuwing bij afwijkingen van het normale verkeersprofiel van de wachtrij.

Volgende stappen 

  • Laatst bijgewerkt om