Service Bus toegangsbeheer met Shared Access Signatures

In dit artikel wordt sas (Shared Access Signatures), hoe ze werken en hoe u deze op een platform-agnostische manier gebruikt.

SAS biedt toegang tot Service Bus op basis van autorisatieregels. Deze zijn geconfigureerd voor een naamruimte of een berichtenentiteit (wachtrij of onderwerp). Een autorisatieregel heeft een naam, is gekoppeld aan specifieke rechten en bevat twee cryptografische sleutels. U gebruikt de naam en sleutel van de regel via de Service Bus SDK of in uw eigen code om een SAS-token te genereren. Een client kan het token vervolgens doorgeven aan Service Bus om autorisatie voor de aangevraagde bewerking te bewijzen.

Overzicht van SAS

Shared Access Signatures zijn een op claims gebaseerd autorisatiemechanisme met behulp van eenvoudige tokens. Met SAS worden sleutels nooit doorgegeven aan de kabel. Sleutels worden gebruikt om informatie cryptografisch te ondertekenen die later kan worden geverifieerd door de service. SAS kan worden gebruikt als een gebruikersnaam en wachtwoordschema waarbij de client direct in bezit is van een autorisatieregelnaam en een overeenkomende sleutel. SAS kan ook worden gebruikt als een federatief beveiligingsmodel, waarbij de client een tijdsbegrensd en ondertekend toegang token van een beveiliging tokenservice ontvangt zonder ooit in bezit te komen van de ondertekeningssleutel.

SAS-verificatie in Service Bus is geconfigureerd met de naam Autorisatiebeleid voor gedeelde toegang met bijbehorende toegangsrechten en een paar primaire en secundaire cryptografische sleutels. De sleutels zijn 256-bits waarden in de Base64-weergave. U kunt regels configureren op naamruimteniveau, op Service Bus wachtrijen en onderwerpen.

Het Shared Access Signature-token bevat de naam van het gekozen autorisatiebeleid, de URI van de resource die moet worden gebruikt, een direct verlopend token en een cryptografische HMAC-SHA256-handtekening die via deze velden wordt berekend met behulp van de primaire of secundaire cryptografische sleutel van de gekozen autorisatieregel.

Autorisatiebeleid voor gedeelde toegang

Elke Service Bus naamruimte en elke Service Bus entiteit heeft een autorisatiebeleid voor gedeelde toegang dat bestaat uit regels. Het beleid op naamruimteniveau is van toepassing op alle entiteiten binnen de naamruimte, ongeacht hun afzonderlijke beleidsconfiguratie.

Voor elke autorisatiebeleidsregel bepaalt u drie soorten informatie: naam, bereik en rechten. De naam is precies dat; een unieke naam binnen dat bereik. Het bereik is eenvoudig genoeg: het is de URI van de resource in kwestie. Voor een Service Bus is het bereik de volledig gekwalificeerde naamruimte, zoals https://<yournamespace>.servicebus.windows.net/ .

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

• Verzenden: verleent het recht om berichten naar de entiteit te verzenden
• Luisteren: verleent het recht om te ontvangen (wachtrij, abonnementen) en alle gerelateerde berichtverwerking
• Beheren: verleent het recht om de topologie van de naamruimte te beheren, inclusief het maken en verwijderen van entiteiten

Het recht Beheren omvat de rechten Verzenden en Ontvangen.

Een naamruimte- of entiteitsbeleid kan maximaal 12 regels voor gedeelde toegangsautorisatie hebben, wat ruimte biedt voor drie sets regels, die elk betrekking hebben op de basisrechten en de combinatie van Verzenden en Luisteren. Deze limiet onderstreept dat het SAS-beleidsopslag niet is bedoeld als een gebruikers- of serviceaccountopslag. Als uw toepassing toegang moet verlenen tot Service Bus op basis van gebruikers- of service-identiteiten, moet deze een beveiligingstokenservice implementeren die SAS-tokens uit geeft na een verificatie- en toegangscontrole.

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

Wanneer u een Service Bus maakt, wordt automatisch een beleidsregel met de naam RootManageSharedAccessKey gemaakt voor de naamruimte. Dit beleid heeft beheermachtigingen voor de hele naamruimte. Het is raadzaam om deze regel als een beheerdersaccount te behandelen en deze niet te gebruiken in uw toepassing. U kunt aanvullende 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 gebruikt in uw toepassingen, 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 Service Bus worden gecompromitteerd.
• Als een SAS die aan een clienttoepassing wordt geleverd, verloopt en de toepassing geen nieuwe SAS kan ophalen uit uw service, kan de functionaliteit van de toepassing worden beperkt.

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

• Laat clients indien nodig de SAS automatisch vernieuwen: clients moeten de SAS ruim vóór de vervaldatum vernieuwen, zodat er tijd is voor nieuwe stappen als de service die de SAS levert niet beschikbaar is. Als uw SAS is bedoeld om te worden gebruikt voor een klein aantal onmiddellijke, kortstondige bewerkingen die naar verwachting binnen de verloopperiode worden voltooid, is deze mogelijk niet nodig omdat de SAS naar verwachting niet wordt vernieuwd. Als u echter een client hebt die regelmatig aanvragen doet via SAS, komt de kans op verloop in het spel. De belangrijkste overweging is om een balans te vinden tussen de noodzaak van een korte duur van de SAS (zoals eerder vermeld) en de noodzaak om ervoor te zorgen dat de client verlenging vroeg genoeg aanvraagt (om onderbrekingen te voorkomen als gevolg van het verlopen van de SAS voordat de verlenging is geslaagd).
• Wees voorzichtig met de SAS-begintijd: als u de begintijd voor SAS nu in stelt, kunnen er vanwege scheefheid in de klok (verschillen in de huidige tijd op basis van verschillende computers) af en toe fouten worden waargenomen in de eerste paar minuten. Stel over het algemeen 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 over het algemeen ook voor de verlooptijd. Houd er wel voor dat u bij elke aanvraag maximaal 15 minuten aan klokverschil in beide richtingen kunt observeren.
• Wees specifiek voor de resource die moet worden gebruikt: een beveiligingsbeleid dat best practice is om de gebruiker de minimaal vereiste bevoegdheden te bieden. Als een gebruiker alleen leestoegang tot één entiteit nodig heeft, verleent u hem/haar 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 kracht heeft in handen van een aanvaller.
• Gebruik niet altijd SAS: Soms wegen de risico's die gepaard gaan met een bepaalde bewerking met 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 na validatie, verificatie en controle van bedrijfsregels.
• Altijd HTTPs gebruiken: gebruik altijd Https om een SAS te maken of te distribueren. Als een SAS wordt doorgegeven via HTTP en wordt onderschept, kan een aanvaller die een man-in-the-middle-attach maakt, de SAS lezen en vervolgens gebruiken zoals de beoogde gebruiker had kunnen doen, waardoor gevoelige gegevens mogelijk in gevaar komen of gegevens door de kwaadwillende gebruiker kunnen worden beschadiging.

Configuratie voor Shared Access Signature verificatie

U kunt het autorisatiebeleid voor gedeelde toegang configureren Service Bus naamruimten, wachtrijen of onderwerpen. Het configureren op een Service Bus wordt momenteel niet ondersteund, maar u kunt regels gebruiken die zijn geconfigureerd voor een naamruimte of onderwerp om de toegang tot abonnementen te beveiligen.

In deze afbeelding zijn de autorisatieregels manageRuleNS, sendRuleNS en listenRuleNS van toepassing op zowel wachtrij Q1 als onderwerp T1, terwijl listenRuleQ en sendRuleQ alleen van toepassing zijn op wachtrij Q1 en sendRuleT alleen van toepassing is op onderwerp T1.

Een Shared Access Signature-token genereren

Elke client die toegang heeft tot de naam van een autorisatieregel en een van de ondertekeningssleutels, kan een SAS-token genereren. Het token wordt gegenereerd door een tekenreeks in de volgende indeling te maken:

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

• se - Token verloopt direct. Het gehele getal reflecteert seconden sinds het tijdvak op 1 januari 00:00:00 UTC 1970 (UNIX epoche) wanneer het token verloopt.

• skn - Naam van de autorisatieregel.

• sr - URL-gecodeerde URI van de resource die wordt gebruikt.

• sig - Met URL gecodeerde HMACSHA256-handtekening. De hash-berekening lijkt op de volgende pseudocode en retourneert base64 aan onbewerkte binaire uitvoer.

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

Het token bevat de niet-gehashte waarden, zodat de ontvanger de hash opnieuw kan aanvullen met dezelfde parameters, om te controleren of de vergever in bezit is van een geldige ondertekeningssleutel.

De resource-URI is de volledige URI van de Service Bus resource waarvoor toegang wordt geclaimd. Bijvoorbeeld of http://<namespace>.servicebus.windows.net/<entityPath> ; dat wil sb://<namespace>.servicebus.windows.net/<entityPath> http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3 zeggen: .

De URI moet procentgecodeerd zijn.

De autorisatieregel voor gedeelde toegang die wordt gebruikt voor ondertekening, moet worden geconfigureerd op de entiteit die is opgegeven door deze URI of door een van de hiërarchische boven- en boven- en achternaam. Bijvoorbeeld of http://contoso.servicebus.windows.net/contosoTopics/T1 http://contoso.servicebus.windows.net in het vorige voorbeeld.

Een SAS-token is geldig voor alle resources met het voorvoegsel dat <resourceURI> wordt gebruikt in de signature-string .

Sleutels opnieuw maken

Het wordt aanbevolen de sleutels die worden gebruikt in het autorisatiebeleid voor gedeelde toegang periodiek opnieuw te maken. De primaire en secundaire sleutelsleuven bestaan, zodat u sleutels geleidelijk kunt roteren. Als uw toepassing doorgaans de primaire sleutel gebruikt, kunt u de primaire sleutel kopiëren naar de secundaire sleutelsleuf en vervolgens alleen de primaire sleutel opnieuw maken. De waarde van de nieuwe primaire sleutel kan vervolgens worden geconfigureerd in de clienttoepassingen, die nog steeds toegang hebben met behulp van de oude primaire sleutel in de secundaire sleuf. Zodra alle clients zijn bijgewerkt, kunt u de secundaire sleutel opnieuw maken om ten slotte de oude primaire sleutel uit te stellen.

Als u weet of vermoedt dat een sleutel is gecompromitteerd en u de sleutels moet intrekken, kunt u zowel de primaire sleutel als de secundaire sleutel van een shared access-autorisatiebeleid opnieuw maken, zodat u deze kunt vervangen door nieuwe sleutels. Met deze procedure worden alle tokens die zijn ondertekend met de oude sleutels ongeldig gemaakt.

Shared Access Signature verificatie met Service Bus

Het scenario dat als volgt wordt beschreven, omvat de configuratie van autorisatieregels, het genereren van SAS-tokens en clientautorisatie.

Zie Verificatie met Service Bus voor een voorbeeld van een Service Bus Service Bus toepassing die de configuratie illustreert en Shared Access Signature SAS-autorisatie gebruikt.

Toegang krijgen tot autorisatieregels voor gedeelde toegang voor een entiteit

Gebruik de bewerking get/update voor wachtrijen of onderwerpen in van de beheerbibliotheken voor Service Bus toegang te krijgen tot/bijwerken van de bijbehorende shared access-autorisatieregels. U kunt de regels ook toevoegen bij het maken van de wachtrijen of onderwerpen met behulp van deze bibliotheken.

Autorisatie Shared Access Signature gebruiken

Toepassingen die gebruikmaken van een van de Service Bus SDK in een van de officieel ondersteunde talen, zoals .NET, Java, JavaScript en Python, kunnen gebruikmaken van SAS-autorisatie via de verbindingsreeksen die worden doorgegeven aan de client constructor.

Verbindingsreeksen kunnen een regelnaam (SharedAccessKeyName) en regelsleutel (SharedAccessKey) of een eerder uitgegeven token (SharedAccessSignature) bevatten. Wanneer deze aanwezig zijn in de connection string doorgegeven aan een constructor- of factorymethode die een connection string accepteert, wordt de SAS-tokenprovider automatisch gemaakt en ingevuld.

Als u SAS-autorisatie wilt gebruiken met Service Bus-abonnementen, kunt u SAS-sleutels gebruiken die zijn geconfigureerd op een Service Bus-naamruimte of in een onderwerp.

Gebruik de Shared Access Signature (op HTTP-niveau)

Nu u weet hoe u Shared Access Signatures kunt maken voor entiteiten in Service Bus, bent u klaar om een HTTP POST uit te voeren:

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

Vergeet niet dat dit voor alles werkt. U kunt SAS maken voor een wachtrij, onderwerp of abonnement.

Als u een afzender of client een SAS-token geeft, hebben ze de sleutel niet rechtstreeks en kunnen ze de hash niet omkeren om deze te verkrijgen. Als zodanig hebt u controle over wat ze kunnen openen en hoe lang. Het is belangrijk om te onthouden dat als u de primaire sleutel in het beleid wijzigt, alle Shared Access Signatures die op basis van het beleid worden gemaakt, ongeldig worden gemaakt.

Gebruik de Shared Access Signature (op AMQP-niveau)

In de vorige sectie hebt u gezien hoe u het SAS-token gebruikt met een HTTP POST-aanvraag voor het verzenden van gegevens naar de Service Bus. Zoals u weet, kunt u toegang krijgen tot Service Bus met behulp van de Advanced Message Queueing Protocol (AMQP) die in veel scenario's het voorkeursprotocol is dat moet worden gebruikt om prestatieredenen. Het gebruik van SAS-tokens met AMQP wordt beschreven in het document AMQP Claim-Based Security Version 1.0 dat al sinds 2013 in gebruik is, maar momenteel wordt ondersteund door Azure.

Voordat gegevens naar Service Bus worden verzendt, moet de uitgever het SAS-token in een AMQP-bericht verzenden naar een goed gedefinieerd AMQP-knooppunt met de naam $cbs (u kunt het zien als een 'speciale' wachtrij die door de service wordt gebruikt om alle SAS-tokens te verkrijgen en te valideren). De uitgever moet het veld ReplyTo opgeven in het AMQP-bericht; dit is het knooppunt waarin de service antwoordt op de uitgever met het resultaat van de tokenvalidatie (een eenvoudig aanvraag-/antwoordpatroon tussen uitgever en service). Dit antwoord-knooppunt wordt 'on-the-fly' gemaakt en gesproken over het dynamisch maken van een extern knooppunt, zoals beschreven in de AMQP 1.0-specificatie. Nadat is gecontroleerd of het SAS-token geldig is, kan de uitgever verder gaan en beginnen met het verzenden van gegevens naar de service.

De volgende stappen laten zien hoe u het SAS-token met het AMQP-protocol verzendt met behulp van de AMQP.NET Lite-bibliotheek. Dit is handig als u de officiële Service Bus SDK (bijvoorbeeld op WinRT, .NET Compact Framework, .NET Micro Framework en Mono) niet kunt gebruiken voor het ontwikkelen in C # . Deze bibliotheek is natuurlijk handig om te begrijpen hoe beveiliging op basis van claims werkt op AMQP-niveau, omdat u hebt gezien hoe het werkt op HTTP-niveau (met een HTTP POST-aanvraag en het SAS-token verzonden binnen de header Autorisatie). Als u niet zo veel kennis over AMQP nodig hebt, kunt u de officiële Service Bus SDK gebruiken in een van de ondersteunde talen, zoals .NET, Java, JavaScript, Python en Go. Dit doet u voor u.

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;
}

De methode ontvangt de verbinding (AMQP-verbindingsklasse-instantie zoals geleverd door de PutCbsToken() AMQP .NET Lite-bibliotheek) die de TCP-verbinding met de service vertegenwoordigt en de sasToken-parameter die het SAS-token is dat moet worden verzenden.

Vervolgens maakt de uitgever twee AMQP-koppelingen voor het verzenden van het SAS-token en het ontvangen van het antwoord (het validatieresultaat van het token) van de service.

Het AMQP-bericht bevat een set eigenschappen en meer informatie dan een eenvoudig bericht. Het SAS-token is de body van het bericht (met behulp van de constructor). De eigenschap ReplyTo is ingesteld op de naam van het knooppunt voor het ontvangen van het validatieresultaat op de ontvangerkoppeling (u kunt de naam wijzigen als u wilt en deze wordt dynamisch gemaakt door de service). De laatste drie toepassings-/aangepaste eigenschappen worden door de service gebruikt om aan te geven wat voor soort bewerking deze moet uitvoeren. Zoals beschreven in de CONCEPT-specificatie van DEVS, moeten deze de bewerkingsnaam ('put-token'), het type token (in dit geval een ) en de 'naam' van de doelgroep zijn waarop het token van toepassing is servicebus.windows.net:sastoken (de hele entiteit).

Nadat het SAS-token op de afzenderkoppeling is verzonden, moet de uitgever het antwoord op de ontvangerkoppeling lezen. Het antwoord is een eenvoudig AMQP-bericht met een toepassings-eigenschap met de naam 'statuscode' die dezelfde waarden kan bevatten als een HTTP-statuscode.

Vereiste rechten voor Service Bus bewerkingen

In de volgende tabel ziet u de toegangsrechten die vereist zijn voor verschillende bewerkingen op Service Bus resources.

Volgende stappen

Zie de volgende onderwerpen voor meer informatie over de Service Bus-berichtenservice

• Service Bus-wachtrijen, -onderwerpen en -abonnementen
• Service Bus-wachtrijen gebruiken
• Service Bus-onderwerpen en -abonnementen gebruiken