Řízení přístupu ke službě Service Bus pomocí sdílených přístupových podpisů

Tento článek popisuje sdílené přístupové podpisy (SAS), jak fungují a jak je používat v prostředí azure Service Bus nezávislém na platformě.

SAS chrání přístup ke službě Service Bus na základě autorizačních pravidel nakonfigurovaných v oboru názvů nebo entitě zasílání zpráv (fronta nebo téma). Autorizační pravidlo má název, je přidružený ke konkrétním právem a má dvojici kryptografických klíčů. K vygenerování tokenu SAS použijete název a klíč pravidla prostřednictvím sady Service Bus SDK nebo ve vlastním kódu. Klient pak může předat token službě Service Bus, aby prokázal autorizaci požadované operace.

• Ověřte a autorizujete aplikaci pomocí ID Microsoft Entra pro přístup k entitě služby Azure Service Bus.
• Ověření spravované identity pomocí ID Microsoft Entra pro přístup k prostředkům služby Azure Service Bus

Pro obor názvů služby Service Bus můžete zakázat ověřování pomocí místního klíče nebo klíče SAS a povolit pouze ověřování Microsoft Entra. Podrobné pokyny najdete v tématu Zakázání místního ověřování.

Přehled SAS

Sdílené přístupové podpisy jsou autorizační mechanismus založený na deklarací identity pomocí jednoduchých tokenů. Když použijete SAS, klíče se nikdy nepředají na drátu. Klíče se používají k kryptograficky podepisující informace, které může služba později ověřit. SAS se dá použít podobně jako uživatelské jméno a schéma hesla, ve kterém má klient okamžitý přístup k názvu autorizačního pravidla a odpovídající klíč. Sas se dá použít také podobně jako model federovaného zabezpečení, kde klient obdrží časově omezený a podepsaný přístupový token ze služby tokenů zabezpečení, aniž by se vůbec dostal do vlastnictví podpisového klíče.

Ověřování SAS ve službě Service Bus je nakonfigurované s pojmenovanými zásadami autorizace sdíleného přístupu s přidruženými přístupovými právy a párem primárních a sekundárních kryptografických klíčů. Klíče jsou 256bitové hodnoty v reprezentaci Base 64. Pravidla můžete nakonfigurovat na úrovni oboru názvů ve frontách a tématech služby Service Bus.

Token sdíleného přístupového podpisu obsahuje název zvolené zásady autorizace, identifikátor URI prostředku, ke kterému se přistupuje, okamžitá vypršení platnosti a kryptografický podpis HMAC-SHA256 vypočítaný přes tato pole pomocí primárního nebo sekundárního kryptografického klíče zvoleného autorizačního pravidla.

Zásady autorizace sdíleného přístupu

Každý obor názvů služby Service Bus a každá entita služby Service Bus má zásady autorizace sdíleného přístupu tvořené pravidly. Zásady na úrovni oboru názvů platí pro všechny entity v oboru názvů bez ohledu na jejich konfiguraci jednotlivých zásad.

Pro každé pravidlo zásad autorizace se rozhodnete o třech informacích: název, rozsah a práva. Název je jenom takový, jedinečný název v rámci tohoto oboru. Rozsah je dostatečně snadný: jedná se o identifikátor URI daného prostředku. Pro obor názvů služby Service Bus je oborem plně kvalifikovaný obor názvů, například https://<yournamespace>.servicebus.windows.net/.

Práva udělená pravidlem zásad mohou být kombinací:

• Odeslat – uděluje právo odesílat zprávy entitě.
• Naslouchání – uděluje právo přijímat (fronty, odběry) a veškeré související zpracování zpráv.
• Správa – uděluje právo spravovat topologii oboru názvů, včetně vytváření a odstraňování entit.

Práva Spravovat zahrnuje práva Pro odesílání a naslouchání.

Zásady oboru názvů nebo entit mohou obsahovat až 12 pravidel autorizace sdíleného přístupu, které poskytují prostor pro tři sady pravidel, z nichž každá pokrývá základní práva a kombinaci funkce Odeslat a naslouchat. Toto omezení platí pro každou entitu, což znamená, že obor názvů a každá entita může mít až 12 pravidel autorizace sdíleného přístupu. Tento limit podtrhuje, že úložiště zásad SAS není určené jako úložiště účtů uživatele nebo služby. Pokud vaše aplikace potřebuje udělit přístup ke službě Service Bus na základě identit uživatelů nebo služeb, měla by implementovat službu tokenů zabezpečení, která po ověření a kontrole přístupu vydává tokeny SAS.

Autorizačnímu pravidlu se přiřadí primární klíč a sekundární klíč. Tyto klíče jsou kryptograficky silné klíče. Neztraťte je nebo je nevraťte – budou vždy k dispozici na webu Azure Portal. Můžete použít některý z vygenerovaných klíčů a můžete je kdykoli znovu vygenerovat. Pokud v zásadách znovu vygenerujete nebo změníte klíč, všechny dříve vydané tokeny založené na daném klíči se okamžitě stanou neplatnými. Probíhající připojení vytvořená na základě těchto tokenů však nadále fungují, dokud nevyprší platnost tokenu.

Při vytváření oboru názvů služby Service Bus se pro obor názvů automaticky vytvoří pravidlo zásady s názvem RootManageSharedAccessKey . Tato zásada má oprávnění Spravovat pro celý obor názvů. Doporučujeme, abyste s tímto pravidlem zacházeli jako s kořenovým účtem pro správu a nepoužívejte ho ve vaší aplikaci. Další pravidla zásad můžete vytvořit na kartě Zásady sdíleného přístupu pro obor názvů na portálu prostřednictvím PowerShellu nebo Azure CLI.

Doporučujeme pravidelně generovat klíče použité v objektu SharedAccessAuthorizationRule . Sloty primárního a sekundárního klíče existují, abyste klíče mohli postupně otáčet. Pokud vaše aplikace obecně používá primární klíč, můžete primární klíč zkopírovat do slotu sekundárního klíče a pak primární klíč znovu vygenerovat. Novou hodnotu primárního klíče je pak možné nakonfigurovat do klientských aplikací, které mají nepřetržitý přístup pomocí starého primárního klíče v sekundárním slotu. Po aktualizaci všech klientů můžete sekundární klíč znovu vygenerovat, aby se nakonec vyřadil starý primární klíč.

Pokud víte nebo máte podezření, že je klíč napadený a musíte klíče odvolat, můžete znovu vygenerovat primární klíč i sekundární klíč sdíleného přístupového ověřovacího pravidla a nahradit ho novými klíči. Tento postup zneplatní všechny tokeny podepsané starými klíči.

Osvědčené postupy při používání SAS

Když ve svých aplikacích používáte sdílené přístupové podpisy, musíte mít na paměti dvě potenciální rizika:

• Pokud dojde k úniku sdíleného přístupového podpisu, může ho použít kdokoli, kdo ho získá, což může potenciálně ohrozit vaše prostředky služby Service Bus.
• Pokud vyprší platnost sdíleného přístupového podpisu poskytnutého klientské aplikaci a aplikace nemůže načíst nový SAS z vaší služby, může to bránit funkce aplikace.

Následující doporučení pro používání sdílených přístupových podpisů vám můžou pomoct zmírnit tato rizika:

• Požádejte klienty, aby sas v případě potřeby automaticky prodloužili: Klienti by měli sas prodloužit před vypršením platnosti, aby bylo možné provést opakované pokusy, pokud služba poskytující SAS není k dispozici. Pokud se má sas použít pro několik okamžitých krátkodobých operací, u které se očekává dokončení v rámci období vypršení platnosti, může to být zbytečné, protože se očekává prodloužení sdíleného přístupového podpisu. Pokud však máte klienta, který pravidelně provádí požadavky prostřednictvím SAS, pak do hry přichází možnost vypršení platnosti. Klíčovým aspektem je vyvážit nutnost, aby sas byl krátkodobý (jak už bylo uvedeno dříve) s nutností zajistit, aby klient před úspěšným obnovením požadoval obnovení dostatečně brzy (aby se zabránilo přerušení kvůli vypršení platnosti SAS před úspěšným prodloužením platnosti).
• Buďte opatrní s časem spuštění SAS: Pokud nastavíte čas spuštění SAS na tuto chvíli, pak kvůli nerovnoměrné distribuci hodin (rozdíly v aktuálním čase podle různých počítačů), může se v prvních několika minutách občas zobrazovat selhání. Obecně platí, že počáteční čas bude v minulosti alespoň 15 minut. Nebo ho vůbec nenastavujte, aby byl platný okamžitě ve všech případech. Totéž platí i pro dobu vypršení platnosti. Mějte na paměti, že v libovolném požadavku můžete pozorovat až 15 minut nerovnoměrné distribuce hodin.
• Buďte specifická pro přístup k prostředku: Osvědčeným postupem zabezpečení je poskytnout uživateli minimální požadovaná oprávnění. Pokud uživatel potřebuje přístup jen pro čtení k jedné entitě, udělte mu přístup pro čtení k této jediné entitě, a ne ke čtení, zápisu nebo odstranění přístupu ke všem entitám. Pomáhá také zmenšit poškození v případě ohrožení sdíleného přístupového podpisu, protože sas má v rukou útočníka méně výkonu.
• Nepoužívejte vždy SAS: Někdy rizika spojená s konkrétní operací u služby Service Bus převáží výhody SAS. Pro takové operace vytvořte službu střední vrstvy, která zapisuje do služby Service Bus po ověření obchodního pravidla, ověřování a auditování.
• Vždy používejte protokolY HTTPs: K vytvoření nebo distribuci sdíleného přístupového podpisu vždy používejte https. Pokud se SAS předává přes protokol HTTP a zachytí se, útočník provádějící připojení man-in-the-middle dokáže sas přečíst a pak ho použít stejně jako zamýšlený uživatel, potenciálně ohrozit citlivá data nebo umožnit poškození dat škodlivým uživatelem.

Konfigurace ověřování pomocí sdíleného přístupového podpisu

Zásady autorizace sdíleného přístupu můžete nakonfigurovat v oborech názvů, frontách nebo tématech služby Service Bus. Konfigurace předplatného služby Service Bus se v současné době nepodporuje, ale k zabezpečení přístupu k předplatným můžete použít pravidla nakonfigurovaná v oboru názvů nebo tématu.

Na tomto obrázku platí pravidla autorizace manageRuleNS, sendRuleNS a listenRuleNS pro frontu Q1 i téma T1, zatímco listenRuleQ a sendRuleQ platí jenom pro frontu Q1 a sendRuleT platí jenom pro téma T1.

Vygenerování tokenu sdíleného přístupového podpisu

Každý klient, který má přístup k názvu autorizačního pravidla a jeden z jeho podpisových klíčů, může vygenerovat token SAS. Token se vygeneruje tak, že vytvoří řetězec v následujícím formátu:

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

• se - Platnost tokenu vyprší okamžitě. Celé číslo odrážející sekundy od epochy 00:00:00 UTC 1. ledna 1970 (UNIX epocha) při vypršení platnosti tokenu.

• skn - Název autorizačního pravidla.

• sr – Identifikátor URI zakódovaný adresou URL prostředku, ke kterému se přistupuje.

• sig – HMACSHA256 podpis kódovaný adresou URL. Výpočet hodnoty hash vypadá podobně jako následující pseudokód a vrátí base64 nezpracovaného binárního výstupu.

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

Token obsahuje hodnoty, které nejsou hashovány, aby příjemce mohl hodnotu hash překompilovat stejnými parametry a ověřit, že vystavitel má platný podpisový klíč.

Identifikátor URI prostředku je úplný identifikátor URI prostředku služby Service Bus, ke kterému se má získat přístup. Například, http://<namespace>.servicebus.windows.net/<entityPath> nebo sb://<namespace>.servicebus.windows.net/<entityPath>, to znamená http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

Identifikátor URI musí být kódovaný v procentech.

Pravidlo autorizace sdíleného přístupu použité k podepisování musí být nakonfigurováno pro entitu určenou tímto identifikátorem URI nebo některým z jeho hierarchických nadřazených prvků. Například http://contoso.servicebus.windows.net/contosoTopics/T1 nebo http://contoso.servicebus.windows.net v předchozím příkladu.

Token SAS je platný pro všechny prostředky s předponou použitou <resourceURI> v nástroji signature-string.

Opětovné vygenerování klíčů

Doporučujeme pravidelně znovu vygenerovat klíče použité v zásadách autorizace sdíleného přístupu. Sloty primárního a sekundárního klíče existují, abyste klíče mohli postupně otáčet. Pokud vaše aplikace obecně používá primární klíč, můžete primární klíč zkopírovat do slotu sekundárního klíče a pak primární klíč znovu vygenerovat. Novou hodnotu primárního klíče je pak možné nakonfigurovat do klientských aplikací, které mají nepřetržitý přístup pomocí starého primárního klíče v sekundárním slotu. Po aktualizaci všech klientů můžete sekundární klíč znovu vygenerovat, aby se nakonec vyřadil starý primární klíč.

Pokud víte nebo máte podezření, že dojde k ohrožení zabezpečení klíče a budete muset klíče odvolat, můžete znovu vygenerovat primární i sekundární klíč zásad autorizace sdíleného přístupu a nahradit je novými klíči. Tento postup zneplatní všechny tokeny podepsané starými klíči.

Pokud chcete znovu vygenerovat primární a sekundární klíče na webu Azure Portal, postupujte takto:

1. Na webu Azure Portal přejděte do oboru názvů služby Service Bus.

2. V nabídce vlevo vyberte Zásady sdíleného přístupu.

3. Ze seznamu vyberte zásadu. V následujícím příkladu je vybrán RootManageSharedAccessKey .

4. Pokud chcete primární klíč vygenerovat znovu, na stránce Zásady SAS: RootManageSharedAccessKey vyberte na panelu příkazů znovu vygenerovat primární klíč .

   

5. Chcete-li znovu vygenerovat sekundární klíč, na stránce Zásady SAS: RootManageSharedAccessKey vyberte ... z panelu příkazů a pak vyberte Znovu vygenerovat sekundární klíč.

   

Pokud používáte Azure PowerShell, použijte rutinu New-AzServiceBusKey k opětovnému vygenerování primárních a sekundárních klíčů pro obor názvů služby Service Bus. Pomocí parametru -KeyValue můžete také zadat hodnoty primárních a sekundárních klíčů, které se generují.

Pokud používáte Azure CLI, pomocí az servicebus namespace authorization-rule keys renew příkazu vygenerujte primární a sekundární klíče pro obor názvů služby Service Bus. Pomocí parametru --key-value můžete také zadat hodnoty primárních a sekundárních klíčů, které se generují.

Ověřování pomocí sdíleného přístupového podpisu pomocí služby Service Bus

Scénář popsaný následujícím způsobem zahrnuje konfiguraci autorizačních pravidel, generování tokenů SAS a autorizaci klientů.

Ukázku aplikace Service Bus, která znázorňuje konfiguraci a používá autorizaci SAS, najdete v tématu Ověřování pomocí sdíleného přístupového podpisu ve službě Service Bus.

Přístup k pravidlům autorizace sdíleného přístupu u entity

Pomocí operace get/update ve frontách nebo tématech v knihovnách pro správu služby Service Bus můžete získat nebo aktualizovat odpovídající autorizační pravidla sdíleného přístupu. Pravidla můžete přidat také při vytváření front nebo témat pomocí těchto knihoven.

Používání autorizace sdíleného přístupového podpisu

Aplikace využívající některou sadu Service Bus SDK v libovolném oficiálně podporovaném jazyce, jako je .NET, Java, JavaScript a Python, můžou využívat autorizaci SAS prostřednictvím připojovací řetězec předávaných konstruktoru klienta.

Připojovací řetězce můžou obsahovat název pravidla (SharedAccessKeyName) a klíč pravidla (SharedAccessKey) nebo dříve vydaný token (SharedAccessSignature). Pokud se nacházejí v připojovací řetězec předány libovolnému konstruktoru nebo metodě továrny, která přijímá připojovací řetězec, poskytovatel tokenu SAS se automaticky vytvoří a vyplní.

Pokud chcete používat autorizaci SAS s předplatnými služby Service Bus, můžete použít klíče SAS nakonfigurované v oboru názvů služby Service Bus nebo v tématu.

Používání sdíleného přístupového podpisu (na úrovni HTTP)

Teď, když víte, jak vytvořit sdílené přístupové podpisy pro všechny entity ve službě Service Bus, jste připraveni provést 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

Nezapomeňte, že to funguje pro všechno. Sas můžete vytvořit pro frontu, téma nebo předplatné.

Pokud odesílateli nebo klientovi udělíte token SAS, nemají klíč přímo a nemůžou hodnotu hash vrátit zpět a získat ho. Proto máte kontrolu nad tím, k čemu mají přístup a jak dlouho. Důležité je pamatovat na to, že pokud změníte primární klíč v zásadách, všechny sdílené přístupové podpisy vytvořené z této zásady se zneplatní.

Používání sdíleného přístupového podpisu (na úrovni AMQP)

V předchozí části jste viděli, jak použít token SAS s požadavkem HTTP POST pro odesílání dat do služby Service Bus. Jak víte, můžete ke službě Service Bus přistupovat pomocí protokolu AMQP (Advanced Message Queuing Protocol), který je upřednostňovaným protokolem pro použití z důvodů výkonu v mnoha scénářích. Použití tokenu SAS s AMQP je popsáno v dokumentu zabezpečení založeného na deklarací identity AMQP verze 1.0 , která je v funkčním konceptu od roku 2013, ale azure ji dnes podporuje.

Než začnete odesílat data do služby Service Bus, musí vydavatel odeslat token SAS uvnitř zprávy AMQP do dobře definovaného uzlu AMQP s názvem $cbs (můžete ho vidět jako "speciální" frontu používanou službou k získání a ověření všech tokenů SAS). Vydavatel musí zadat pole Odpovědět do zprávy AMQP; je to uzel, ve kterém služba odpoví vydavateli s výsledkem ověření tokenu (jednoduchý vzor žádosti a odpovědi mezi vydavatelem a službou). Tento uzel odpovědi se vytvoří "za běhu" a hovoří o dynamickém vytváření vzdáleného uzlu, jak popisuje specifikace AMQP 1.0. Po kontrole platnosti tokenu SAS může vydavatel pokračovat a začít odesílat data do služby.

Následující kroky ukazují, jak odeslat token SAS s protokolem AMQP pomocí knihovny AMQP.NET Lite . Je užitečné, pokud nemůžete používat oficiální sadu SDK služby Service Bus (například pro WinRT, .NET Compact Framework, .NET Micro Framework a Mono) vyvíjenou v jazyce C#. Tato knihovna vám pomůže pochopit, jak funguje zabezpečení na základě deklarací identity na úrovni AMQP, jak funguje na úrovni HTTP (s požadavkem HTTP POST a tokenem SAS odeslaným v hlavičce Autorizace). Pokud nepotřebujete takové hluboké znalosti o AMQP, můžete použít oficiální sadu SERVICE Bus SDK v libovolném z podporovaných jazyků, jako je .NET, Java, JavaScript, Python a Go, které to udělá za vás.

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

Metoda PutCbsToken() obdrží připojení (instanci třídy připojení AMQP, jak poskytuje knihovna AMQP .NET Lite), která představuje připojení TCP ke službě a parametr sasToken , který je token SAS k odeslání.

Dále vydavatel vytvoří dva odkazy AMQP pro odeslání tokenu SAS a přijetí odpovědi (výsledek ověření tokenu) ze služby.

Zpráva AMQP obsahuje sadu vlastností a více informací než jednoduchá zpráva. Token SAS je tělo zprávy (pomocí jeho konstruktoru). Vlastnost ReplyTo je nastavená na název uzlu pro příjem výsledku ověření na odkazu příjemce (pokud chcete změnit jeho název a služba ho vytvoří dynamicky). Služba používá poslední tři vlastnosti aplikace nebo vlastní vlastnosti k označení typu operace, kterou musí provést. Jak je popsáno ve specifikaci konceptu CBS, musí to být název operace ("put-token"), typ tokenu (v tomto případě a servicebus.windows.net:sastoken) a "název" cílové skupiny , na kterou se token vztahuje (celá entita).

Po odeslání tokenu SAS na odkaz odesílatele musí vydavatel přečíst odpověď na odkazu příjemce. Odpověď je jednoduchá zpráva AMQP s vlastností aplikace s názvem status-code , která může obsahovat stejné hodnoty jako stavový kód HTTP.

Práva vyžadovaná pro provoz služby Service Bus

Následující tabulka uvádí přístupová práva požadovaná pro různé operace s prostředky služby Service Bus.

Další kroky

Pokud se o přenosu zpráv přes Service Bus chcete dozvědět víc, pročtěte si následující témata.

• Fronty, témata a odběry služby Service Bus
• Jak používat fronty Service Bus
• Jak používat témata a odběry Service Bus