Auktorisera åtkomst till Event Hubs-resurser med signaturer för delad åtkomst

En signatur för delad åtkomst (SAS) ger dig 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. Dessa regler konfigureras antingen på ett namnområde eller en händelsehubb. Den här artikeln innehåller en översikt över SAS-modellen och granskar metodtips för 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. Du använder 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 med enkla token. När du använder SAS skickas aldrig nycklar på kabeln. Nycklar används för att kryptografiskt signera information som senare kan verifieras av tjänsten. SAS kan användas på liknande sätt som ett användarnamn och lösenordsschema där klienten omedelbart har ett namn på auktoriseringsregeln och en matchande nyckel. SAS kan användas på liknande sätt som en federerad säkerhetsmodell, där klienten tar emot en tidsbegränsad och signerad åtkomsttoken från en säkerhetstokentjänst utan att någon gång komma i besittning av signeringsnyckeln.

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 kommer alltid att vara 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 hantera behörigheter för hela namnområdet. Vi rekommenderar att du behandlar den här regeln som ett administrativt rotkonto och inte använder den i ditt program. Du kan skapa fler principregler på fliken Konfigurera 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 måste du vara medveten om två potentiella risker:

• Om en SAS läcker ut kan den användas av alla som hämtar 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 i god tid 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 att användas för ett litet antal omedelbara, kortvariga åtgärder som förväntas slutföras inom förfalloperioden kan det vara onödigt eftersom SAS inte förväntas förnyas. Men om du har en klient som rutinmässigt skickar begäranden via SAS kommer möjligheten att upphöra att gälla. 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 observeras tillfälligt under de första minuterna på grund av klocksnedvridning (skillnader i aktuell tid enligt olika datorer). I allmänhet anger du 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 klocksnedvridning i båda riktningarna på alla begäranden.
• Var specifik med den resurs som ska nås: En metod för säkerhet är att ge användaren den lägsta behörighet som krävs. Om en användare bara behöver läsåtkomst till en enda entitet ger du dem läsbehörighet till den enskilda entiteten och inte läs-/skriv-/borttagningsåtkomst till alla entiteter. Det hjälper också till att minska skadan om en SAS komprometteras eftersom SAS har mindre ström 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 ha, potentiellt kompromettera känsliga data eller tillåta dataskada av den skadliga användaren.

Slutsats

Signaturer för delningså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:

• Autentisera begäranden till Azure Event Hubs med signaturer för delad åtkomst
• Autentisera begäranden till Azure Event Hubs från ett program med hjälp av Microsoft Entra-ID
• Autentisera en hanterad identitet med Microsoft Entra-ID för åtkomst till Event Hubs-resurser