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

Den här artikeln beskriver signaturer för delad åtkomst (SAS), hur de fungerar och hur du använder dem på ett plattformsoberoende sätt.

SAS skyddar åtkomsten till Service Bus baserat på auktoriseringsregler. De konfigureras 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 kan använda 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 att bevisa auktoriseringen för den begärda åtgärden.

Översikt över SAS

Signaturer för delad åtkomst är en anspråksbaserad auktoriseringsmekanism som använder enkla token. Med hjälp av 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 schema för användarnamn och lösenord där klienten har omedelbar tillgång till ett auktoriseringsregelnamn och en matchande nyckel. SAS kan också användas på liknande sätt som en federerad säkerhetsmodell, där klienten får en tidsbegränsad och signerad åtkomsttoken från en säkerhetstokentjänst utan att någon gång behöva ha signeringsnyckeln.

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

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

Auktoriseringsprinciper för delad åtkomst

Varje Service Bus och varje entitet Service Bus har en princip för auktorisering 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 uppgifter: namn, omfång och rättigheter. Namnet är just det; ett unikt namn inom det omfånget. Omfånget är tillräckligt enkelt: det är URI:en för resursen i fråga. För ett Service Bus-namnområde är omfånget det fullständigt kvalificerade namnområdet, till exempel https://<yournamespace>.servicebus.windows.net/ .

Rättigheter som omfattas av principregeln kan vara en kombination av:

• "Skicka" – det vill säga rättigheten att skicka meddelanden till entiteten
• "Lyssna" – Ger rätt att ta emot (kö, prenumerationer) och all relaterad meddelandehantering
• "Hantera" – Rättigheten att hantera namnområdets topologi, inklusive att skapa och ta bort entiteter

Rättigheten "Hantera" innehåller behörigheterna "Skicka" och "Ta emot".

En namnområdes- eller entitetsprincip kan innehålla upp till 12 regler för auktorisering för delad åtkomst, vilket ger utrymme för tre uppsättningar regler som var och en täcker grundläggande rättigheter och kombinationen av Skicka och lyssna. Den här gränsen visar att SAS-principlagret 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 säkerhetstokentjänst som utfärdar SAS-token efter en autentisering och åtkomstkontroll.

En auktoriseringsregel tilldelas en primärnyckel och en sekundär nyckel. Det här är kryptografiskt starka nycklar. Tappa inte bort dem eller läck dem – de kommer alltid att vara tillgängliga i Azure Portal. 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 baserade 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 Service Bus namnområdet 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 ytterligare 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äcks kan den användas av alla som får 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 tjänsten kan programmets funktioner hindras.

Följande rekommendationer för att använda signaturer för delad åtkomst kan hjälpa dig att minska dessa risker:

• Låt klienterna förnya SAS automatiskt om det behövs: Klienterna bör förnya SAS i en bra tid innan den upphör att gälla, 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 regelbundet gör begäranden via SAS gäller risken för förfallotid. Det viktigaste att beakta är att balansera behovet av att SAS är kortvarigt (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 fel observeras tillfälligt under de första minuterna på grund av klockfördrång (skillnader i aktuell tid beroende på olika datorer). I allmänhet anger du starttiden till minst 15 minuter i det förflutna. Eller ange den inte alls, vilket gör den giltig direkt i samtliga fall. Samma gäller vanligtvis även för förfallotiden. Kom ihåg att du kan observera upp till 15 minuters fördrurning i endera riktningen på en begäran.
• Var specifik för den resurs som ska användas: En bra säkerhetspraxis är att ge användaren minsta nödvändiga behörigheter. Om en användare bara behöver läsbehörighet till en enda entitet ger du dem läsbehörighet till den enda entiteten och inte läs-/skriv-/borttagningsåtkomst till alla entiteter. Det hjälper också till att minska skadorna om en SAS komprometteras eftersom SAS har mindre kraft i händerna på en angripare.
• Använd inte alltid SAS: Ibland uppväger riskerna som är associerade med en viss åtgärd Event Hubs fördelarna med SAS. För sådana åtgärder skapar du en mellannivåtjänst som skriver till Event Hubs efter validering, autentisering och granskning av affärsregel.
• 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-anslutning läsa SAS:en och sedan använda den precis som den avsedda användaren kan ha gjort, potentiellt äventyra känsliga data eller tillåta att data skadas av den skadliga användaren.

Konfiguration för autentisering med signatur för delad åtkomst

Du kan konfigurera auktoriseringsprincipen för delad åtkomst Service Bus för namnområden, köer eller ämnen. Konfiguration av den på Service Bus prenumeration stöds för närvarande inte, men du kan använda regler som konfigurerats på 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ön Q1 och ämnet T1, medan listenRuleQ och sendRuleQ endast gäller för kön Q1 och sendRuleT gäller endast för ämnet T1.

Generera en token för signatur för delad åtkomst

Alla klienter som har åtkomst till namnet på en auktoriseringsregel 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 direkt. Heltal återspeglar sekunder sedan epoken den 1 januari 00:00:00 UTC 1970 (UNIX epok) när token upphör att gälla.

• skn – Namnet på auktoriseringsregeln.

• sr – URL-kodad URI för den resurs 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 icke-hashvärdena så att mottagaren kan kompilera om hashen med samma parametrar, vilket verifierar att utfärdaren har en giltig signeringsnyckel.

Resurs-URI är den fullständiga URI:en Service Bus resurs som åtkomsten begärts till. Till exempel eller http://<namespace>.servicebus.windows.net/<entityPath> ; det vill säga sb://<namespace>.servicebus.windows.net/<entityPath> http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3 .

URI:en måste vara procentkodad.

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

En SAS-token är giltig för alla resurser med prefixet <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 nyckelfacken finns så att du kan rotera nycklar gradvis. Om ditt program vanligtvis använder den primära nyckeln kan du kopiera primärnyckeln till den sekundära nyckelplatsen och först sedan återskapa den primära nyckeln. Det nya primärnyckelvärdet kan sedan konfigureras i klientprogrammen, som har fortsatt åtkomst med hjälp av den gamla primärnyckeln på den sekundära platsen. När alla klienter har uppdaterats kan du återskapa den sekundära nyckeln för att slutligen dra tillbaka den gamla primära nyckeln.

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 genom att ersätta dem med nya nycklar. Den här proceduren gör alla token signerade med de gamla nycklarna ogiltiga.

Autentisering med signatur för delad åtkomst med Service Bus

Scenariot som beskrivs nedan omfattar konfiguration av auktoriseringsregler, generering av SAS-token och klientauktorisering.

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

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

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

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

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

Anslutningssträngar kan innehålla ett regelnamn (SharedAccessKeyName) och regelnyckel (SharedAccessKey) eller en tidigare utfärdad token (SharedAccessSignature). När de finns i anslutningssträngen som skickas till en konstruktor eller fabriksmetod som accepterar en anslutningssträng, skapas och fylls SAS-tokenprovidern i automatiskt.

Om du vill använda SAS-Service Bus prenumerationer kan du använda SAS-nycklar som konfigurerats på en Service Bus 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 alla entiteter i Service Bus, är du redo att utföra en 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 återställa 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 ogiltigförklaras eventuella 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 Service Bus med hjälp av Advanced Message Queueing 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 i dag.

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 "särskild" kö som används av tjänsten för att hämta och validera alla SAS-token). Utgivaren måste ange fältet ReplyTo i AMQP-meddelandet. Det här är den nod 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 AMQP.NET Lite. Detta ä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 naturligtvis användbart för att förstå hur anspråksbaserad säkerhet fungerar på AMQP-nivå, som du såg hur det fungerar på HTTP-nivå (med en HTTP POST-begäran och SAS-token som skickas i rubriken "Authorization" (Auktorisering). Om du inte behöver så djupgående kunskap om AMQP kan du använda den officiella Service Bus SDK:n 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 may be kept open for refreshing tokens
    cbsSender.Close();
    cbsReceiver.Close();
    session.Close();

    return result;
}

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

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

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

När du 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 "status-code" 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