Delen via

Toegang verlenen tot Event Hubs-resources met behulp van handtekeningen voor gedeelde toegang

  • Artikel

Een Shared Access Signature (SAS) biedt u een manier om beperkte toegang te verlenen tot resources in uw Event Hubs-naamruimte. SAS bewaakt de toegang tot Event Hubs-resources op basis van autorisatieregels. Deze regels worden geconfigureerd in een naamruimte of een Event Hub. Dit artikel bevat een overzicht van het SAS-model en bekijkt best practices voor SAS.

Notitie

Dit artikel bevat informatie over het autoriseren van toegang tot Event Hubs-resources met behulp van SAS. Zie Verifiëren met SAS voor meer informatie over het verifiëren van toegang tot Event Hubs-resources met behulp van SAS.

Wat zijn handtekeningen voor gedeelde toegang?

Een Sas (Shared Access Signature) biedt gedelegeerde toegang tot Event Hubs-resources op basis van autorisatieregels. Een autorisatieregel heeft een naam, is gekoppeld aan specifieke rechten en bevat een paar cryptografische sleutels. U gebruikt de naam en sleutel van de regel via de Event Hubs-clients of in uw eigen code om SAS-tokens te genereren. Een client kan vervolgens het token doorgeven aan Event Hubs om autorisatie voor de aangevraagde bewerking te bewijzen.

SAS is een verificatiemechanisme op basis van claims met behulp van eenvoudige tokens. Wanneer u SAS gebruikt, worden sleutels nooit doorgegeven aan de kabel. Sleutels worden gebruikt om cryptografische gegevens te ondertekenen die later kunnen worden geverifieerd door de service. SAS kan worden gebruikt als een gebruikersnaam en wachtwoordschema waarbij de client direct een autorisatieregelnaam en een overeenkomende sleutel heeft. SAS kan worden gebruikt als een federatief beveiligingsmodel, waarbij de client een tijdslimiet en ondertekend toegangstoken van een beveiligingstokenservice ontvangt zonder ooit de ondertekeningssleutel in bezit te krijgen.

Notitie

Azure Event Hubs biedt ook ondersteuning voor het autoriseren van Event Hubs-resources met behulp van Microsoft Entra-id. Het autoriseren van gebruikers of toepassingen met behulp van OAuth 2.0-token dat wordt geretourneerd door Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak ten opzichte van handtekeningen voor gedeelde toegang (SAS). Met Microsoft Entra ID hoeft u de tokens niet op te slaan in uw code en potentiële beveiligingsproblemen te riskeren.

Microsoft raadt u aan om Microsoft Entra ID te gebruiken met uw Azure Event Hubs-toepassingen, indien mogelijk. Zie Toegang tot Azure Event Hubs-resource autoriseren met behulp van Microsoft Entra-id voor meer informatie.

Belangrijk

SAS-tokens (Shared Access Signatures) zijn essentieel voor het beveiligen van uw resources. Hoewel sas granulariteit biedt, verleent SAS clients toegang tot uw Event Hubs-resources. Ze mogen niet openbaar worden gedeeld. Bij het delen, indien nodig om problemen op te lossen, kunt u overwegen om een beperkte versie van logboekbestanden te gebruiken of de SAS-tokens (indien aanwezig) te verwijderen uit de logboekbestanden en ervoor te zorgen dat de schermafbeeldingen de SAS-gegevens ook niet bevatten.

Autorisatiebeleid voor gedeelde toegang

Elke Event Hubs-naamruimte en elke Event Hubs-entiteit (een Event Hub of een Kafka-onderwerp) heeft een autorisatiebeleid voor gedeelde toegang dat bestaat uit regels. Het beleid op het niveau van de naamruimte is van toepassing op alle entiteiten in de naamruimte, ongeacht hun afzonderlijke beleidsconfiguratie.

Voor elke autorisatiebeleidsregel bepaalt u drie soorten informatie: naam, bereik en rechten. De naam is een unieke naam in dat bereik. Het bereik is de URI van de betreffende resource. Voor een Event Hubs-naamruimte is het bereik de FQDN (Fully Qualified Domain Name), zoals https://<yournamespace>.servicebus.windows.net/.

De rechten die door de beleidsregel worden geboden, kunnen een combinatie zijn van:

  • Verzenden : geeft het recht om berichten naar de entiteit te verzenden
  • Luisteren : geeft het recht om berichten van de entiteit te beluisteren of te ontvangen
  • Beheren : geeft het recht om de topologie van de naamruimte te beheren, inclusief het maken en verwijderen van entiteiten. Het recht Beheren omvat de rechten voor verzenden en luisteren .

Een naamruimte- of entiteitsbeleid kan maximaal 12 regels voor gedeelde toegang bevatten, waardoor ruimte is voor de drie sets regels, die elk de basisrechten omvatten en de combinatie van Verzenden en Luisteren. Deze limiet onderstreept dat het SAS-beleidsarchief niet bedoeld is als een opslag voor gebruikers- of serviceaccounts. Als uw toepassing toegang moet verlenen tot Event Hubs-resources op basis van gebruikers- of service-identiteiten, moet deze een beveiligingstokenservice implementeren waarmee SAS-tokens worden uitgegeven na een verificatie- en toegangscontrole.

Aan een autorisatieregel wordt een primaire sleutel en een secundaire sleutel toegewezen. Deze sleutels zijn cryptografisch sterke sleutels. Verlies ze niet of lek ze niet. Ze zijn altijd beschikbaar in Azure Portal. U kunt een van de gegenereerde sleutels gebruiken en u kunt ze op elk gewenst moment opnieuw genereren. Als u een sleutel opnieuw genereert of wijzigt in het beleid, worden alle eerder uitgegeven tokens op basis van die sleutel onmiddellijk ongeldig. Doorlopende verbindingen die zijn gemaakt op basis van dergelijke tokens, blijven echter werken totdat het token verloopt.

Wanneer u een Event Hubs-naamruimte maakt, wordt automatisch een beleidsregel met de naam RootManageSharedAccessKey gemaakt voor de naamruimte. Dit beleid heeft machtigingen voor het beheren van de volledige naamruimte. Het is raadzaam deze regel als een beheerdershoofdaccount te behandelen en deze niet te gebruiken in uw toepassing. U kunt meer beleidsregels maken op het tabblad Configureren voor de naamruimte in de portal, via PowerShell of Azure CLI.

Best practices bij gebruik van SAS

Wanneer u handtekeningen voor gedeelde toegang in uw toepassingen gebruikt, moet u rekening houden met twee mogelijke risico's:

  • Als een SAS wordt gelekt, kan deze worden gebruikt door iedereen die deze verkrijgt, waardoor uw Event Hubs-resources mogelijk worden aangetast.
  • Als een SAS die aan een clienttoepassing is verstrekt, verloopt en de toepassing geen nieuwe SAS kan ophalen uit uw service, kan de functionaliteit van de toepassing worden belemmerd.

De volgende aanbevelingen voor het gebruik van handtekeningen voor gedeelde toegang kunnen helpen deze risico's te beperken:

  • Laat clients de SAS indien nodig automatisch vernieuwen: clients moeten de SAS vóór de vervaldatum vernieuwen om tijd te verlenen voor nieuwe pogingen als de service die de SAS levert niet beschikbaar is. Als uw SAS is bedoeld om te worden gebruikt voor een klein aantal onmiddellijke, kortdurende bewerkingen die naar verwachting binnen de verloopperiode worden voltooid, is het mogelijk onnodig omdat de SAS niet wordt vernieuwd. Als u echter een client hebt die regelmatig aanvragen doet via SAS, wordt de mogelijkheid van verlooptijd in het spel gebracht. De belangrijkste overweging is om de noodzaak te verdelen dat de SAS kortlevend moet zijn (zoals eerder vermeld) met de noodzaak om ervoor te zorgen dat de client vroeg genoeg verlenging aanvraagt (om onderbrekingen te voorkomen vanwege de SAS die verloopt vóór een geslaagde verlenging).
  • Wees voorzichtig met de SAS-begintijd: Als u de begintijd voor SAS instelt op nu, worden fouten mogelijk af en toe waargenomen vanwege scheeftrekken van de klok (verschillen in de huidige tijd op basis van verschillende computers), kunnen fouten af en toe worden waargenomen voor de eerste paar minuten. Over het algemeen stelt u de begintijd in op ten minste 15 minuten in het verleden. Of stel deze helemaal niet in, waardoor deze in alle gevallen onmiddellijk geldig is. Hetzelfde geldt doorgaans ook voor de verlooptijd. Houd er rekening mee dat u maximaal 15 minuten van de klok scheeftrekken in beide richtingen op elk verzoek kunt observeren.
  • Wees specifiek voor de resource die moet worden geopend: een best practice voor beveiliging is om de gebruiker de minimale vereiste bevoegdheden te bieden. Als een gebruiker alleen leestoegang tot één entiteit nodig heeft, verleent u ze leestoegang tot die ene entiteit en geen lees-/schrijf-/verwijdertoegang tot alle entiteiten. Het helpt ook de schade te verminderen als een SAS wordt aangetast omdat de SAS minder vermogen heeft in handen van een aanvaller.
  • Gebruik niet altijd SAS: Soms wegen de risico's die zijn verbonden aan een bepaalde bewerking tegen uw Event Hubs op tegen de voordelen van SAS. Voor dergelijke bewerkingen maakt u een service in de middelste laag die naar uw Event Hubs schrijft na validatie van bedrijfsregels, verificatie en controle.
  • Altijd HTTPs gebruiken: gebruik altijd Https om een SAS te maken of te distribueren. Als een SAS wordt doorgegeven via HTTP en onderschept, kan een aanvaller die een man-in-the-middle-aanval uitvoert de SAS lezen en deze vervolgens gebruiken, net zoals de beoogde gebruiker zou kunnen hebben, mogelijk gevoelige gegevens in gevaar brengen of gegevensbeschadiging door de kwaadwillende gebruiker toestaan.

Conclusie

Handtekeningen voor sharetoegang zijn handig voor het verlenen van beperkte machtigingen aan Event Hubs-resources voor uw clients. Ze zijn essentieel voor het beveiligingsmodel voor elke toepassing die Gebruikmaakt van Azure Event Hubs. Als u de aanbevolen procedures in dit artikel volgt, kunt u SAS gebruiken om meer flexibiliteit te bieden voor toegang tot uw resources, zonder de beveiliging van uw toepassing in gevaar te brengen.

Gerelateerde inhoud

Zie de volgende gerelateerde artikelen: