Signaturauktorisering för delad åtkomst för Event Hubs

En signatur för delad åtkomst (SAS) är ett sätt att bevilja begränsad åtkomst till resurser i ditt Event Hubs-namnområde. SAS skyddar åtkomsten till Event Hubs-resurser baserat på auktoriseringsregler. Du konfigurerar dessa regler på antingen ett namnområde eller en händelsehubb. Den här artikeln innehåller en översikt över SAS-modellen och granskar bästa praxis för SAS.

Kommentar

Den här artikeln beskriver auktorisering av åtkomst till Event Hubs-resurser med hjälp av SAS. Mer information om hur du autentiserar åtkomst till Event Hubs-resurser med sas finns i Autentisera med SAS.

Vad är signaturer för delad åtkomst?

En signatur för delad åtkomst (SAS) ger delegerad åtkomst till Event Hubs-resurser baserat på auktoriseringsregler. En auktoriseringsregel har ett namn, är associerad med specifika rättigheter och har ett par kryptografiska nycklar. Använd regelns namn och nyckel via Event Hubs-klienterna eller i din egen kod för att generera SAS-token. En klient kan sedan skicka token till Event Hubs för att bevisa auktorisering för den begärda åtgärden.

SAS är en anspråksbaserad auktoriseringsmekanism som använder enkla token. När du använder SAS skickar du aldrig nycklar via nätverket. I stället använder du nycklar för att kryptografiskt signera information som tjänsten senare kan verifiera. Du kan använda SAS som liknar ett användarnamn och lösenordsschema där klienten omedelbart har ett namn på auktoriseringsregeln och en matchande nyckel. Du kan också använda SAS som liknar en federerad säkerhetsmodell, där klienten tar emot en tidsbegränsad och signerad åtkomsttoken från en säkerhetstokentjänst utan att någonsin komma i besittning av signeringsnyckeln.

Kommentar

Azure Event Hubs stöder även auktorisering till Event Hubs-resurser med hjälp av Microsoft Entra ID. Att auktorisera användare eller program med OAuth 2.0-token som returneras av Microsoft Entra ID ger överlägsen säkerhet och användarvänlighet för signaturer för delad åtkomst (SAS). Med hjälp av Microsoft Entra ID behöver du inte lagra token i koden och riskera potentiella säkerhetsrisker.

Microsoft rekommenderar att du använder Microsoft Entra-ID med dina Azure Event Hubs-program när det är möjligt. Mer information finns i Auktorisera åtkomst till Azure Event Hubs-resurs med hjälp av Microsoft Entra-ID.

Viktigt!

SAS-token är viktiga för att skydda dina resurser. SAS ger klienter åtkomst till dina Event Hubs-resurser samtidigt som de ger kornighet. Dela dem inte offentligt. När du delar, om det behövs av felsökningsskäl, bör du överväga att använda en reducerad version av alla loggfiler eller ta bort SAS-token (om de finns) från loggfilerna. Kontrollera att skärmbilderna inte heller innehåller SAS-informationen.

Auktoriseringsprinciper för delad åtkomst

Varje Event Hubs-namnområde och varje Event Hubs-entitet (en händelsehubb eller ett Kafka-ämne) har en auktoriseringsprincip för delad åtkomst som består av regler. Principen på namnområdesnivå gäller för alla entiteter i namnområdet, oavsett deras enskilda principkonfiguration.

För varje auktoriseringsprincipregel bestämmer du dig för tre informationsdelar: namn, omfång och rättigheter. Namnet är ett unikt namn i det omfånget. Omfånget är URI:n för den aktuella resursen. För ett Event Hubs-namnområde är omfånget det fullständigt kvalificerade domännamnet (FQDN), till exempel https://<yournamespace>.servicebus.windows.net/.

De rättigheter som tillhandahålls av principregeln kan vara en kombination av:

  • Skicka – Ger rätt att skicka meddelanden till entiteten
  • Lyssna – Ger rätt att lyssna eller ta emot meddelanden från entiteten
  • Hantera – Ger rätt att hantera topologin för namnområdet, inklusive skapande och borttagning av entiteter. Rättigheten Hantera innehåller rättigheterna Skicka och lyssna.

En namnrymds- eller entitetsprincip kan innehålla upp till 12 auktoriseringsregler för delad åtkomst, vilket ger utrymme för de tre regeluppsättningarna, som var och en täcker de grundläggande rättigheterna och kombinationen av Skicka och lyssna. Den här gränsen understryker att SAS-principarkivet inte är avsett att vara ett användar- eller tjänstkontoarkiv. Om ditt program behöver bevilja åtkomst till Event Hubs-resurser baserat på användar- eller tjänstidentiteter bör det implementera en tjänst för säkerhetstoken som utfärdar SAS-token efter en autentiserings- och åtkomstkontroll.

En auktoriseringsregel tilldelas en primärnyckel och en sekundär nyckel. Dessa nycklar är kryptografiskt starka nycklar. Tappa inte bort dem eller läcka dem. De är alltid tillgängliga i Azure-portalen. Du kan använda någon av de genererade nycklarna och du kan återskapa dem när som helst. Om du återskapar eller ändrar en nyckel i principen blir alla tidigare utfärdade token baserat på den nyckeln omedelbart ogiltiga. Pågående anslutningar som skapats baserat på sådana token fortsätter dock att fungera tills token upphör att gälla.

När du skapar ett Event Hubs-namnområde skapas automatiskt en principregel med namnet RootManageSharedAccessKey för namnområdet. Den här principen har behörigheter för att hantera hela namnområdet. Behandla den här regeln som ett administrativt rotkonto och använd det inte i ditt program. Du kan skapa fler principregler i fliken Configure för namnområdet i portalen, via PowerShell eller Azure CLI.

Metodtips när du använder SAS

När du använder signaturer för delad åtkomst i dina program bör du vara medveten om två potentiella risker:

  • Om en SAS läcker kan alla som hämtar den använda den, vilket potentiellt kan äventyra dina Event Hubs-resurser.
  • Om en SAS som tillhandahålls till ett klientprogram upphör att gälla och programmet inte kan hämta en ny SAS från din tjänst kan programmets funktioner hindras.

Följande rekommendationer för att använda signaturer för delad åtkomst kan bidra till att minska dessa risker:

  • Låt klienterna förnya SAS automatiskt om det behövs: Klienter bör förnya SAS långt före förfallodatum för att ge tid för återförsök om tjänsten som tillhandahåller SAS inte är tillgänglig. Om din SAS är avsedd för ett litet antal omedelbara, kortvariga åtgärder som förväntas slutföras inom förfalloperioden kan förnyelsen vara onödig. Men om du har en klient som gör rutinmässiga begäranden via SAS, kan möjligheten till utgångsdatum bli relevant. Det viktigaste är att balansera behovet av att SAS är kortlivat (som tidigare nämnts) med behovet av att säkerställa att klienten begär förnyelse tillräckligt tidigt (för att undvika avbrott på grund av att SAS upphör att gälla före en lyckad förnyelse).
  • Var försiktig med SAS-starttiden: Om du anger starttiden för SAS till nu kan fel uppstå tillfälligt under de första minuterna på grund av klocksnedvridning (skillnader i aktuell tid enligt olika datorer). I allmänhet bör du sätta starttiden till minst 15 minuter tidigare. Eller ange det inte alls, vilket gör det giltigt omedelbart i alla fall. Samma sak gäller vanligtvis även för förfallotiden. Kom ihåg att du kan observera upp till 15 minuters klockavvikelse i båda riktningarna vid varje begäran.
  • Var specifik med den resurs som ska nås: En metod för säkerhet är att ge användarna den lägsta behörighet som krävs. Om en användare bara behöver läsåtkomst till en enda entitet, ge dem läsbehörighet till den enskilda entiteten och inte läs-, skriv- eller raderingsåtkomst till alla entiteter. Den här metoden hjälper också till att minska skadan om en SAS komprometteras eftersom SAS har mindre makt i händerna på en angripare.
  • Använd inte alltid SAS: Ibland överväger riskerna med en viss åtgärd mot dina händelsehubbar fördelarna med SAS. För sådana åtgärder skapar du en mellannivåtjänst som skriver till dina händelsehubbar efter validering, autentisering och granskning av affärsregler.
  • Använd alltid HTTPS: Använd alltid HTTPS för att skapa eller distribuera en SAS. Om en SAS skickas via HTTP och fångas upp kan en angripare som utför en man-in-the-middle-attack läsa SAS och sedan använda den precis som den avsedda användaren kan, potentiellt kompromettera känsliga data eller tillåta dataskada av den skadliga användaren.

Slutsats

Signaturer för delad åtkomst är användbara för att ge begränsade behörigheter till Event Hubs-resurser till dina klienter. De är en viktig del av säkerhetsmodellen för alla program som använder Azure Event Hubs. Om du följer de metodtips som anges i den här artikeln kan du använda SAS för att ge större flexibilitet för åtkomst till dina resurser, utan att äventyra säkerheten för ditt program.

Relaterat innehåll

Se följande relaterade artiklar:

  • Last updated on