Service Bus-åtkomstkontroll med signaturer för delad åtkomst

I den här artikeln beskrivs signaturer för delad åtkomst (SAS), hur de fungerar och hur de används på ett plattformsoberoende sätt med Azure Service Bus.

SAS skyddar åtkomsten till Service Bus baserat på auktoriseringsregler som har konfigurerats antingen på ett namnområde eller en meddelandeentitet (kö eller ämne). 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 Service Bus SDK eller i din egen kod för att generera en SAS-token. En klient kan sedan skicka token till Service Bus för att bevisa auktorisering för den begärda åtgärden.

• Autentisera och auktorisera ett program med Microsoft Entra-ID för åtkomst till Azure Service Bus-entiteter.
• Autentisera en hanterad identitet med Microsoft Entra-ID för att få åtkomst till Azure Service Bus-resurser

Du kan inaktivera lokal autentisering eller SAS-nyckelautentisering för ett Service Bus-namnområde och endast tillåta Microsoft Entra-autentisering. Stegvisa instruktioner finns i Inaktivera lokal autentisering.

Översikt över SAS

Signaturer för delad åtkomst ä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 också 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ågonsin komma i besittning av signeringsnyckeln.

SAS-autentisering i Service Bus konfigureras med namngivna auktoriseringsprinciper för delad åtkomst som har associerade åtkomsträttigheter och ett par primära och sekundära kryptografiska nycklar. Nycklarna är 256-bitarsvärden i Bas 64-representation. Du kan konfigurera regler på namnområdesnivå, i Service Bus-köer och ämnen.

Signaturtoken för delad åtkomst innehåller namnet på den valda auktoriseringsprincipen, URI:n för resursen som ska nås, ett utgångs omedelbart och en krypteringssignatur för HMAC-SHA256 som beräknas över dessa fält med antingen den primära eller den sekundära kryptografiska nyckeln för den valda auktoriseringsregeln.

Auktoriseringsprinciper för delad åtkomst

Varje Service Bus-namnområde och varje Service Bus-entitet 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 just det, ett unikt namn inom det omfånget. Omfånget är enkelt nog: det är URI:n för den aktuella resursen. För ett Service Bus-namnområde är omfånget det fullständigt kvalificerade namnområdet, till exempel https://<yournamespace>.servicebus.windows.net/.

De rättigheter som tilldelas av principregeln kan vara en kombination av:

• Skicka – Ger rätt att skicka meddelanden till entiteten
• Lyssna – Ger rätt att ta emot (kö, prenumerationer) och all relaterad meddelandehantering
• Hantera – Ger rätt att hantera topologin för namnområdet, inklusive att skapa och ta bort entiteter

Rättigheten Hantera innehåller rättigheterna Skicka och lyssna.

En namnområdes- eller entitetsprincip kan innehålla upp till 12 auktoriseringsregler för delad åtkomst, vilket ger utrymme för tre uppsättningar regler, var och en omfattar de grundläggande rättigheterna och kombinationen av Skicka och lyssna. Den här gränsen är per entitet, vilket innebär att namnområdet och varje entitet kan ha upp till 12 auktoriseringsregler för delad åtkomst. 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 Service Bus 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ärnyckel. 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 Service Bus-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 Principer för delad åtkomst för namnområdet i portalen, via PowerShell eller Azure CLI.

Vi rekommenderar att du regelbundet återskapar de nycklar som används i objektet SharedAccessAuthorizationRule . De primära och sekundära nyckelplatserna finns så att du kan rotera nycklar gradvis. Om ditt program vanligtvis använder primärnyckeln kan du kopiera den primära nyckeln till det sekundära nyckelfacket och först sedan återskapa den primära nyckeln. Det nya primärnyckelvärdet kan sedan konfigureras till klientprogrammen, som har fortsatt åtkomst med den gamla primärnyckeln i det sekundära facket. När alla klienter har uppdaterats kan du återskapa den sekundära nyckeln för att slutligen dra tillbaka den gamla primärnyckeln.

Om du vet eller misstänker att en nyckel har komprometterats och du måste återkalla nycklarna kan du återskapa både PrimaryKey och SecondaryKey för en SharedAccessAuthorizationRule och ersätta dem med nya nycklar. Den här proceduren ogiltigförklarar alla token som signerats med de gamla nycklarna.

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 Service Bus-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 några 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 innan en lyckad förnyelse).
• Var försiktig med SAS-starttiden: Om du anger starttiden för SAS till nu kan det uppstå fel 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 din Service Bus fördelarna med SAS. För sådana åtgärder skapar du en mellannivåtjänst som skriver till Service Bus 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-bifoga läsa SAS och sedan använda den precis som den avsedda användaren kan ha, potentiellt kompromettera känsliga data eller tillåta skada på data av den skadliga användaren.

Konfiguration för signaturautentisering för delad åtkomst

Du kan konfigurera auktoriseringsprincipen för delad åtkomst på Service Bus-namnområden, köer eller ämnen. Det går för närvarande inte att konfigurera den i en Service Bus-prenumeration, men du kan använda regler som konfigurerats i ett namnområde eller ämne för att skydda åtkomsten till prenumerationer.

I den här bilden gäller auktoriseringsreglerna manageRuleNS, sendRuleNS och listenRuleNS för både kö Q1 och ämne T1, medan listenRuleQ och sendRuleQ endast gäller för kö Q1 och sendRuleT gäller endast för ämnet T1.

Generera en signaturtoken för delad åtkomst

Alla klienter som har åtkomst till namnet på ett auktoriseringsregelnamn och en av dess signeringsnycklar kan generera en SAS-token. Token genereras genom att skapa en sträng i följande format:

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

• se – Token upphör att gälla omedelbart. Heltal som återspeglar sekunder sedan epoken 00:00:00 UTC den 1 januari 1970 (UNIX-epok) när token upphör att gälla.

• skn - Namnet på auktoriseringsregeln.

• sr – URL-kodad URI för resursen som används.

• sig – URL-kodad HMACSHA256 signatur. Hash-beräkningen liknar följande pseudokod och returnerar base64 av binära råutdata.

  urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
  

Token innehåller de icke-hashade värdena så att mottagaren kan omkomplera hashen med samma parametrar och verifiera att utfärdaren har en giltig signeringsnyckel.

Resurs-URI:n är den fullständiga URI:n för Service Bus-resursen som åtkomsten begärs till. Till exempel, http://<namespace>.servicebus.windows.net/<entityPath> eller sb://<namespace>.servicebus.windows.net/<entityPath>, det vill säga http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

URI:n måste vara procentkodad.

Auktoriseringsregeln för delad åtkomst som används för signering måste konfigureras för den entitet som anges av den här URI:n eller av någon av dess hierarkiska överordnade. Till exempel, http://contoso.servicebus.windows.net/contosoTopics/T1 eller http://contoso.servicebus.windows.net i föregående exempel.

En SAS-token är giltig för alla resurser som är prefix med den <resourceURI> som används i signature-string.

Återskapa nycklar

Vi rekommenderar att du regelbundet återskapar de nycklar som används i auktoriseringsprincipen för delad åtkomst. De primära och sekundära nyckelplatserna finns så att du kan rotera nycklar gradvis. Om ditt program vanligtvis använder primärnyckeln kan du kopiera den primära nyckeln till det sekundära nyckelfacket och först sedan återskapa den primära nyckeln. Det nya primärnyckelvärdet kan sedan konfigureras till klientprogrammen, som har fortsatt åtkomst med den gamla primärnyckeln i det sekundära facket. När alla klienter har uppdaterats kan du återskapa den sekundära nyckeln för att slutligen dra tillbaka den gamla primärnyckeln.

Om du vet eller misstänker att en nyckel har komprometterats och du måste återkalla nycklarna kan du återskapa både den primära nyckeln och den sekundära nyckeln för en auktoriseringsprincip för delad åtkomst och ersätta dem med nya nycklar. Den här proceduren ogiltigförklarar alla token som signerats med de gamla nycklarna.

Följ dessa steg för att återskapa primära och sekundära nycklar i Azure-portalen:

1. Navigera till Service Bus-namnområdet i Azure-portalen.

2. Välj Principer för delad åtkomst på den vänstra menyn.

3. Välj principen i listan. I följande exempel är RootManageSharedAccessKey valt.

4. Om du vill återskapa primärnyckeln går du till sidan SAS-princip: RootManageSharedAccessKey och väljer Återskapa primärnyckel i kommandofältet.

   

5. Om du vill återskapa den sekundära nyckeln går du till sidan SAS-princip: RootManageSharedAccessKey och väljer ... i kommandofältet och väljer sedan Återskapa sekundär nyckel.

   

Om du använder Azure PowerShell använder du cmdleten New-AzServiceBusKey för att återskapa primära och sekundära nycklar för ett Service Bus-namnområde. Du kan också ange värden för primära och sekundära nycklar som genereras med hjälp av parametern -KeyValue .

Om du använder Azure CLI använder az servicebus namespace authorization-rule keys renew du kommandot för att återskapa primära och sekundära nycklar för ett Service Bus-namnområde. Du kan också ange värden för primära och sekundära nycklar som genereras med hjälp av parametern --key-value .

Signaturautentisering med delad åtkomst med Service Bus

Scenariot som beskrivs så här omfattar konfiguration av auktoriseringsregler, generering av SAS-token och klientauktorisering.

Ett exempel på ett Service Bus-program som illustrerar konfigurationen och använder SAS-auktorisering finns i Signaturautentisering för delad åtkomst med Service Bus.

Åtkomst till auktoriseringsregler för delad åtkomst på en entitet

Använd get/update-åtgärden i köer eller ämnen i hanteringsbiblioteken för Service Bus för att få åtkomst till/uppdatera motsvarande auktoriseringsregler för delad åtkomst. Du kan också lägga till reglerna när du skapar köer eller ämnen med hjälp av dessa bibliotek.

Använda auktorisering med signatur för delad åtkomst

Program som använder något av Service Bus SDK på något av de officiellt språk som stöds som .NET, Java, JavaScript och Python kan använda SAS-auktorisering via de niska veze som skickas till klientkonstruktorn.

Anslutningssträngar kan innehålla ett regelnamn (SharedAccessKeyName) och en regelnyckel (SharedAccessKey) eller en tidigare utfärdad token (SharedAccessSignature). När dessa finns i niska veze skickas till någon konstruktor eller fabriksmetod som accepterar en niska veze skapas och fylls SAS-tokenprovidern automatiskt.

Om du vill använda SAS-auktorisering med Service Bus-prenumerationer kan du använda SAS-nycklar som konfigurerats i ett Service Bus-namnområde eller i ett ämne.

Använd signaturen för delad åtkomst (på HTTP-nivå)

Nu när du vet hur du skapar signaturer för delad åtkomst för entiteter i Service Bus är du redo att utföra ett HTTP POST:

POST https://<yournamespace>.servicebus.windows.net/<yourentity>/messages
Content-Type: application/json
Authorization: SharedAccessSignature sr=https%3A%2F%2F<yournamespace>.servicebus.windows.net%2F<yourentity>&sig=<yoursignature from code above>&se=1438205742&skn=KeyName
ContentType: application/atom+xml;type=entry;charset=utf-8

Kom ihåg att detta fungerar för allt. Du kan skapa SAS för en kö, ett ämne eller en prenumeration.

Om du ger en avsändare eller klient en SAS-token har de inte nyckeln direkt och de kan inte ångra hashen för att hämta den. Därför har du kontroll över vad de kan komma åt och hur länge. En viktig sak att komma ihåg är att om du ändrar den primära nyckeln i principen så ogiltigförklaras alla signaturer för delad åtkomst som skapats från den.

Använd signaturen för delad åtkomst (på AMQP-nivå)

I föregående avsnitt såg du hur du använder SAS-token med en HTTP POST-begäran för att skicka data till Service Bus. Som du vet kan du komma åt Service Bus med hjälp av Advanced Message Queuing Protocol (AMQP) som är det föredragna protokollet att använda av prestandaskäl, i många scenarier. SAS-tokenanvändningen med AMQP beskrivs i dokumentet AMQP Claim-Based Security Version 1.0 som är i arbetsutkast sedan 2013 men som stöds av Azure idag.

Innan du börjar skicka data till Service Bus måste utgivaren skicka SAS-token i ett AMQP-meddelande till en väldefinierad AMQP-nod med namnet $cbs (du kan se den som en "speciell" kö som används av tjänsten för att hämta och verifiera alla SAS-token). Utgivaren måste ange fältet ReplyTo i AMQP-meddelandet. Det är noden där tjänsten svarar utgivaren med resultatet av tokenverifieringen (ett enkelt mönster för begäran/svar mellan utgivare och tjänst). Den här svarsnoden skapas "i farten" och talar om "dynamiskt skapande av fjärrnod" enligt beskrivningen i AMQP 1.0-specifikationen. När du har kontrollerat att SAS-token är giltig kan utgivaren gå vidare och börja skicka data till tjänsten.

Följande steg visar hur du skickar SAS-token med AMQP-protokollet med hjälp av biblioteket AMQP.NET Lite . Det är användbart om du inte kan använda den officiella Service Bus SDK (till exempel på WinRT, .NET Compact Framework, .NET Micro Framework och Mono) som utvecklas i C#. Det här biblioteket är användbart för att förstå hur anspråksbaserad säkerhet fungerar på AMQP-nivå, eftersom du såg hur det fungerar på HTTP-nivå (med en HTTP POST-begäran och SAS-token som skickas i rubriken "Auktorisering"). Om du inte behöver så djup kunskap om AMQP kan du använda den officiella Service Bus SDK:t på något av de språk som stöds, till exempel .NET, Java, JavaScript, Python och Go, vilket gör det åt dig.

C#

/// <summary>
/// Send claim-based security (CBS) token
/// </summary>
/// <param name="shareAccessSignature">Shared access signature (token) to send</param>
private bool PutCbsToken(Connection connection, string sasToken)
{
    bool result = true;
    Session session = new Session(connection);

    string cbsClientAddress = "cbs-client-reply-to";
    var cbsSender = new SenderLink(session, "cbs-sender", "$cbs");
    var cbsReceiver = new ReceiverLink(session, cbsClientAddress, "$cbs");

    // construct the put-token message
    var request = new Message(sasToken);
    request.Properties = new Properties();
    request.Properties.MessageId = Guid.NewGuid().ToString();
    request.Properties.ReplyTo = cbsClientAddress;
    request.ApplicationProperties = new ApplicationProperties();
    request.ApplicationProperties["operation"] = "put-token";
    request.ApplicationProperties["type"] = "servicebus.windows.net:sastoken";
    request.ApplicationProperties["name"] = Fx.Format("amqp://{0}/{1}", sbNamespace, entity);
    cbsSender.Send(request);

    // receive the response
    var response = cbsReceiver.Receive();
    if (response == null || response.Properties == null || response.ApplicationProperties == null)
    {
        result = false;
    }
    else
    {
        int statusCode = (int)response.ApplicationProperties["status-code"];
        if (statusCode != (int)HttpStatusCode.Accepted && statusCode != (int)HttpStatusCode.OK)
        {
            result = false;
        }
    }

    // the sender/receiver might be kept open for refreshing tokens
    cbsSender.Close();
    cbsReceiver.Close();
    session.Close();

    return result;
}

Metoden PutCbsToken() tar emot anslutningen (AMQP-anslutningsklassinstansen som tillhandahålls av AMQP .NET Lite-biblioteket) som representerar TCP-anslutningen till tjänsten och parametern sasToken som är SAS-token som ska skickas.

Därefter skapar utgivaren två AMQP-länkar för att skicka SAS-token och ta emot svaret (valideringsresultatet för token) från tjänsten.

AMQP-meddelandet innehåller en uppsättning egenskaper och mer information än ett enkelt meddelande. SAS-token är meddelandets brödtext (med konstruktorn). Egenskapen "ReplyTo" är inställd på nodnamnet för att ta emot valideringsresultatet på mottagarlänken (du kan ändra namnet om du vill och det skapas dynamiskt av tjänsten). De tre sista egenskaperna för program/anpassade egenskaper används av tjänsten för att ange vilken typ av åtgärd den måste utföra. Som beskrivs i CBS-utkastspecifikationen måste de vara åtgärdsnamnet ("put-token"), typen av token (i det här fallet en servicebus.windows.net:sastoken) och "namnet" på den målgrupp som token gäller för (hela entiteten).

När utgivaren har skickat SAS-token på avsändarlänken måste utgivaren läsa svaret på mottagarlänken. Svaret är ett enkelt AMQP-meddelande med en programegenskap med namnet "statuskod" som kan innehålla samma värden som en HTTP-statuskod.

Rättigheter som krävs för Service Bus-åtgärder

I följande tabell visas de åtkomsträttigheter som krävs för olika åtgärder på Service Bus-resurser.

Nästa steg

I följande ämnen kan du lära dig mer om Service Bus-meddelanden.

• Service Bus-köer, ämnen och prenumerationer
• Använd Service Bus-köer
• Använd Service Bus ämnen och prenumerationer