Partilhar via

Controle de acesso do Service Bus com assinaturas de acesso compartilhado

  • Artigo

Este artigo discute as Assinaturas de Acesso Compartilhado (SAS), como elas funcionam e como usá-las de forma independente de plataforma com o Barramento de Serviço do Azure.

O SAS protege o acesso ao Service Bus com base em regras de autorização configuradas em um namespace ou em uma entidade de mensagens (fila ou tópico). Uma regra de autorização tem um nome, está associada a direitos específicos e carrega um par de chaves criptográficas. Você usa o nome e a chave da regra por meio do SDK do Service Bus ou em seu próprio código para gerar um token SAS. Um cliente pode então passar o token para o Service Bus para provar a autorização para a operação solicitada.

Nota

O Barramento de Serviço do Azure dá suporte à autorização de acesso a um namespace do Barramento de Serviço e suas entidades usando a ID do Microsoft Entra. Autorizar usuários ou aplicativos usando o token OAuth 2.0 retornado pelo Microsoft Entra ID oferece segurança superior e facilidade de uso em relação às assinaturas de acesso compartilhado (SAS). As chaves SAS não têm controle de acesso refinado, são difíceis de gerenciar/girar e não têm os recursos de auditoria para associar seu uso a um usuário ou entidade de serviço específica. Por estas razões, recomendamos o uso do Microsoft Entra ID.

A Microsoft recomenda usar a ID do Microsoft Entra com seus aplicativos do Barramento de Serviço do Azure quando possível. Para obter mais informações, consulte os seguintes artigos:

Você pode desabilitar a autenticação de chave local ou SAS para um namespace do Service Bus e permitir apenas a autenticação do Microsoft Entra. Para obter instruções passo a passo, consulte Desativar a autenticação local.

Visão geral do SAS

As Assinaturas de Acesso Compartilhado são um mecanismo de autorização baseado em declarações que usa tokens simples. Quando você usa SAS, as chaves nunca são passadas no fio. As chaves são usadas para assinar criptograficamente informações que podem ser verificadas posteriormente pelo serviço. O SAS pode ser usado de forma semelhante a um esquema de nome de usuário e senha em que o cliente está na posse imediata de um nome de regra de autorização e uma chave correspondente. O SAS também pode ser usado de forma semelhante a um modelo de segurança federado, em que o cliente recebe um token de acesso assinado e limitado por tempo de um serviço de token de segurança sem nunca entrar em posse da chave de assinatura.

A autenticação SAS no Service Bus é configurada com políticas de autorização de acesso compartilhado nomeadas com direitos de acesso associados e um par de chaves criptográficas primárias e secundárias. As chaves são valores de 256 bits na representação de Base 64. Você pode configurar regras no nível do namespace, em filas e tópicos do Barramento de Serviço.

Nota

Essas chaves são cadeias de caracteres de texto simples usando uma representação Base 64 e não devem ser decodificadas antes de serem usadas.

O token de Assinatura de Acesso Compartilhado contém o nome da política de autorização escolhida, o URI do recurso que será acessado, um instante de expiração e uma assinatura criptográfica HMAC-SHA256 computada nesses campos usando a chave criptográfica primária ou secundária da regra de autorização escolhida.

Políticas de autorização de acesso compartilhado

Cada namespace do Service Bus e cada entidade do Service Bus tem uma política de autorização de acesso compartilhado composta de regras. A política no nível do namespace se aplica a todas as entidades no namespace, independentemente de sua configuração de política individual.

Para cada regra de política de autorização, você decide sobre três informações: nome, escopo e direitos. O nome é exatamente isso, um nome único dentro desse escopo. O escopo é bastante fácil: é o URI do recurso em questão. Para um namespace do Service Bus, o escopo é o namespace totalmente qualificado, como https://<yournamespace>.servicebus.windows.net/.

Os direitos conferidos pela regra de apólice podem ser uma combinação de:

  • Enviar - Concede o direito de enviar mensagens à entidade
  • Ouvir - Concede o direito de receber (fila, assinaturas) e todo o tratamento de mensagens relacionado
  • Gerenciar - Concede o direito de gerenciar a topologia do namespace, incluindo a criação e exclusão de entidades

O direito Gerenciar inclui os direitos Enviar e Ouvir.

Um namespace ou política de entidade pode conter até 12 regras de Autorização de Acesso Compartilhado, fornecendo espaço para três conjuntos de regras, cada um cobrindo os direitos básicos e a combinação de Enviar e Ouvir. Esse limite é por entidade, o que significa que o namespace e cada entidade podem ter até 12 regras de Autorização de Acesso Compartilhado. Esse limite sublinha que o repositório de políticas SAS não se destina a ser um armazenamento de conta de usuário ou de serviço. Se seu aplicativo precisar conceder acesso ao Service Bus com base em identidades de usuário ou serviço, ele deverá implementar um serviço de token de segurança que emita tokens SAS após uma verificação de autenticação e acesso.

Uma regra de autorização recebe uma Chave Primária e uma Chave Secundária. Essas chaves são chaves criptograficamente fortes. Não os perca ou vaze - eles sempre estarão disponíveis no portal do Azure. Você pode usar qualquer uma das chaves geradas e pode regenerá-las a qualquer momento. Se você regenerar ou alterar uma chave na política, todos os tokens emitidos anteriormente com base nessa chave se tornarão instantaneamente inválidos. No entanto, as conexões contínuas criadas com base nesses tokens continuam a funcionar até que o token expire.

Quando você cria um namespace do Service Bus, uma regra de política chamada RootManageSharedAccessKey é criada automaticamente para o namespace. Esta política tem permissões de Gerenciar para todo o namespace. É recomendável que você trate essa regra como uma conta raiz administrativa e não a use em seu aplicativo. Você pode criar mais regras de política na guia Políticas de acesso compartilhado para o namespace no portal, via PowerShell ou CLI do Azure.

Recomendamos que você regenere periodicamente as chaves usadas no objeto SharedAccessAuthorizationRule . Os slots de chave primária e secundária existem para que você possa girar as teclas gradualmente. Se o seu aplicativo geralmente usa a chave primária, você pode copiar a chave primária para o slot de chave secundária e só então regenerar a chave primária. O novo valor de chave primária pode então ser configurado nos aplicativos cliente, que têm acesso contínuo usando a chave primária antiga no slot secundário. Depois que todos os clientes forem atualizados, você poderá regenerar a chave secundária para finalmente aposentar a chave primária antiga.

Se você souber ou suspeitar que uma chave está comprometida e tiver que revogá-las, poderá regenerar a PrimaryKey e a SecondaryKey de uma SharedAccessAuthorizationRule, substituindo-as por novas chaves. Este procedimento invalida todos os tokens assinados com as chaves antigas.

Práticas recomendadas ao usar SAS

Ao usar assinaturas de acesso compartilhado em seus aplicativos, você precisa estar ciente de dois riscos potenciais:

  • Se uma SAS for vazada, ela poderá ser usada por qualquer pessoa que a obtenha, o que pode comprometer os recursos do Service Bus.
  • Se uma SAS fornecida a um aplicativo cliente expirar e o aplicativo não conseguir recuperar uma nova SAS do seu serviço, a funcionalidade do aplicativo poderá ser prejudicada.

As seguintes recomendações para o uso de assinaturas de acesso compartilhado podem ajudar a reduzir esses riscos:

  • Fazer com que os clientes renovem automaticamente o SAS, se necessário: Os clientes devem renovar o SAS bem antes da expiração, para dar tempo para novas tentativas se o serviço que fornece o SAS não estiver disponível. Se o seu SAS se destina a ser usado para algumas operações imediatas e de curta duração que se espera que sejam concluídas dentro do período de expiração, isso pode ser desnecessário, pois não se espera que o SAS seja renovado. No entanto, se você tem um cliente que está rotineiramente fazendo solicitações via SAS, então a possibilidade de expiração entra em jogo. A principal consideração é equilibrar a necessidade de o SAS ser de curta duração (como dito anteriormente) com a necessidade de garantir que o cliente está solicitando a renovação com antecedência suficiente (para evitar interrupções devido ao SAS expirar antes de uma renovação bem-sucedida).
  • Tenha cuidado com a hora de início do SAS: Se você definir a hora de início do SAS para agora, devido à distorção do relógio (diferenças na hora atual de acordo com máquinas diferentes), você poderá ver falhas intermitentemente nos primeiros minutos. Em geral, defina a hora de início para ser de pelo menos 15 minutos no passado. Ou não o defina de todo, o que o tornará válido imediatamente em todos os casos. O mesmo se aplica, em geral, também ao prazo de validade. Lembre-se de que você pode observar até 15 minutos de inclinação do relógio em qualquer direção em qualquer solicitação.
  • Seja específico com o recurso a ser acessado: uma prática recomendada de segurança é fornecer ao usuário os privilégios mínimos necessários. Se um usuário só precisar de acesso de leitura a uma única entidade, conceda-lhe acesso de leitura a essa única entidade e não acesso de leitura/gravação/exclusão a todas as entidades. Também ajuda a diminuir o dano se um SAS for comprometido porque o SAS tem menos poder nas mãos de um atacante.
  • Nem sempre use o SAS: às vezes, os riscos associados a uma operação específica em relação ao Service Bus superam os benefícios do SAS. Para essas operações, crie um serviço de camada intermediária que grave no Service Bus após a validação, autenticação e auditoria da regra de negócios.
  • Sempre use HTTPs: Sempre use Https para criar ou distribuir uma SAS. Se uma SAS for passada sobre HTTP e intercetada, um invasor que executa uma conexão man-in-the-middle é capaz de ler a SAS e, em seguida, usá-la exatamente como o usuário pretendido poderia ter, potencialmente comprometendo dados confidenciais ou permitindo a corrupção de dados pelo usuário mal-intencionado.

Configuração para autenticação de Assinatura de Acesso Compartilhado

Você pode configurar a Política de Autorização de Acesso Compartilhado em namespaces, filas ou tópicos do Service Bus. Atualmente, não há suporte para configurá-lo em uma assinatura do Service Bus, mas você pode usar regras configuradas em um namespace ou tópico para proteger o acesso às assinaturas.

Diagrama que mostra um namespace de exemplo com algumas regras de autorização.

Nesta figura, as regras de autorização manageRuleNS, sendRuleNS e listenRuleNS aplicam-se à fila Q1 e ao tópico T1, enquanto listenRuleQ e sendRuleQ se aplicam apenas à fila Q1 e sendRuleT se aplicam apenas ao tópico T1.

Gerar um token de assinatura de acesso compartilhado

Qualquer cliente que tenha acesso ao nome de uma regra de autorização, nome e uma de suas chaves de assinatura pode gerar um token SAS. O token é gerado pela criação de uma cadeia de caracteres no seguinte formato:

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

  • se - Expiração instantânea do token. Inteiro refletindo segundos desde a época 00:00:00 UTC em 1 de janeiro de 1970 (época UNIX) quando o token expira.

  • skn - Nome da regra de autorização.

  • sr - URI codificado por URL do recurso que está sendo acessado.

  • sig - Assinatura de HMACSHA256 codificada por URL. O cálculo do hash é semelhante ao seguinte pseudocódigo e devolve um valor base64 na saída binária não processada.

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

Importante

Para obter exemplos de geração de um token SAS usando diferentes linguagens de programação, consulte Gerar token SAS.

O token contém os valores não hash para que o destinatário possa recalcular o hash com os mesmos parâmetros ao verificar se o emissor está na posse de uma chave de assinatura válida.

O URI do recurso é o URI completo do recurso do Service Bus ao qual o acesso é reivindicado. Por exemplo, http://<namespace>.servicebus.windows.net/<entityPath> ou sb://<namespace>.servicebus.windows.net/<entityPath>seja, http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

O URI deve ser codificado em porcentagem.

A regra de autorização de acesso compartilhado usada para assinatura deve ser configurada na entidade especificada por esse URI ou por um de seus pais hierárquicos. Por exemplo, http://contoso.servicebus.windows.net/contosoTopics/T1 ou http://contoso.servicebus.windows.net no exemplo anterior.

Um token SAS é válido para todos os recursos prefixados com o <resourceURI> usado no signature-string.

Regenerar chaves

Recomendamos que você regenere periodicamente as chaves usadas na Política de Autorização de Acesso Compartilhado. Os slots de chave primária e secundária existem para que você possa girar as teclas gradualmente. Se o seu aplicativo geralmente usa a chave primária, você pode copiar a chave primária para o slot de chave secundária e só então regenerar a chave primária. O novo valor de chave primária pode então ser configurado nos aplicativos cliente, que têm acesso contínuo usando a chave primária antiga no slot secundário. Depois que todos os clientes forem atualizados, você poderá regenerar a chave secundária para finalmente aposentar a chave primária antiga.

Se souber ou suspeitar que uma chave está comprometida e tiver de revogar as chaves, pode regenerar a chave primária e a chave secundária de uma Política de Autorização de Acesso Partilhado, substituindo-as por novas chaves. Este procedimento invalida todos os tokens assinados com as chaves antigas.

Para regenerar chaves primárias e secundárias no portal do Azure, siga estas etapas:

  1. Navegue até o namespace do Service Bus no portal do Azure.

  2. Selecione Políticas de acesso compartilhado no menu à esquerda.

  3. Selecione a política na lista. No exemplo a seguir, RootManageSharedAccessKey está selecionado.

  4. Para regenerar a chave primária, na página SAS Policy: RootManageSharedAccessKey , selecione Regenerar chave primária na barra de comandos.

    Captura de tela que mostra como regenerar uma chave primária.

  5. Para regenerar a chave secundária, na página SAS Policy: RootManageSharedAccessKey, selecione ... na barra de comandos e, em seguida, selecione Regenerar chave secundária.

    Captura de ecrã da página Política SAS com as opções Regenerar selecionadas.

Se você estiver usando o Azure PowerShell, use o New-AzServiceBusKey cmdlet para regenerar chaves primárias e secundárias para um namespace do Service Bus. Você também pode especificar valores para chaves primárias e secundárias que estão sendo geradas, usando o -KeyValue parâmetro.

Se você estiver usando a CLI do Azure, use o az servicebus namespace authorization-rule keys renew comando para regenerar chaves primárias e secundárias para um namespace do Service Bus. Você também pode especificar valores para chaves primárias e secundárias que estão sendo geradas, usando o --key-value parâmetro.

Autenticação de assinatura de acesso compartilhado com o Service Bus

O cenário descrito a seguir inclui configuração de regras de autorização, geração de tokens SAS e autorização de cliente.

Para obter um exemplo de um aplicativo do Service Bus que ilustra a configuração e usa a autorização SAS, consulte Autenticação de assinatura de acesso compartilhado com o Service Bus.

Regras de Autorização de Acesso Compartilhado de Acesso em uma entidade

Use a operação get/update em filas ou tópicos nas bibliotecas de gerenciamento do Service Bus para acessar/atualizar as Regras de Autorização de Acesso Compartilhado correspondentes. Você também pode adicionar as regras ao criar as filas ou tópicos usando essas bibliotecas.

Utilizar a autorização de Assinatura de Acesso Partilhado

Os aplicativos que usam qualquer SDK do Service Bus em qualquer uma das linguagens oficialmente suportadas, como .NET, Java, JavaScript e Python, podem usar a autorização SAS por meio das cadeias de conexão passadas para o construtor cliente.

As cadeias de conexão podem incluir um nome de regra (SharedAccessKeyName) e uma chave de regra (SharedAccessKey) ou um token emitido anteriormente (SharedAccessSignature). Quando eles estão presentes na cadeia de conexão passada para qualquer construtor ou método de fábrica que aceita uma cadeia de conexão, o provedor de token SAS é criado e preenchido automaticamente.

Para usar a autorização SAS com assinaturas do Service Bus, você pode usar chaves SAS configuradas em um namespace do Service Bus ou em um tópico.

Utilizar a Assinatura de Acesso Partilhado (ao nível do HTTP)

Agora que você sabe como criar assinaturas de acesso compartilhado para quaisquer entidades no Service Bus, está pronto para executar um 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

Lembre-se, isso funciona para tudo. Você pode criar SAS para uma fila, tópico ou assinatura.

Se você der a um remetente ou cliente um token SAS, ele não terá a chave diretamente e não poderá reverter o hash para obtê-lo. Como tal, você tem controle sobre o que eles podem acessar e por quanto tempo. Uma coisa importante a lembrar é que, se você alterar a chave primária na política, todas as Assinaturas de Acesso Compartilhado criadas a partir dela serão invalidadas.

Utilizar a Assinatura de Acesso Partilhado (ao nível do AMQP)

Na seção anterior, você viu como usar o token SAS com uma solicitação HTTP POST para enviar dados para o Service Bus. Como você sabe, você pode acessar o Service Bus usando o AMQP (Advanced Message Queuing Protocol), que é o protocolo preferencial a ser usado por motivos de desempenho, em muitos cenários. O uso do token SAS com AMQP é descrito no documento AMQP Claim-Based Security Version 1.0 que está em rascunho de trabalho desde 2013, mas é suportado pelo Azure atualmente.

Antes de começar a enviar dados para o Service Bus, o editor deve enviar o token SAS dentro de uma mensagem AMQP para um nó AMQP bem definido chamado $cbs (você pode vê-lo como uma fila "especial" usada pelo serviço para adquirir e validar todos os tokens SAS). O editor deve especificar o campo ReplyTo dentro da mensagem AMQP, é o nó no qual o serviço responde ao editor com o resultado da validação do token (um padrão simples de solicitação/resposta entre editor e serviço). Este nó de resposta é criado "on the fly", falando sobre "criação dinâmica de nó remoto", conforme descrito pela especificação AMQP 1.0. Depois de verificar se o token SAS é válido, o editor pode avançar e começar a enviar dados para o serviço.

As etapas a seguir mostram como enviar o token SAS com o protocolo AMQP usando a biblioteca AMQP.NET Lite . É útil se você não puder usar o SDK oficial do Service Bus (por exemplo, no WinRT, .NET Compact Framework, .NET Micro Framework e Mono) desenvolvendo em C#. Essa biblioteca é útil para ajudar a entender como a segurança baseada em declarações funciona no nível AMQP, como você viu como ela funciona no nível HTTP (com uma solicitação HTTP POST e o token SAS enviado dentro do cabeçalho "Autorização"). Se você não precisa de um conhecimento tão profundo sobre AMQP, você pode usar o SDK oficial do Service Bus em qualquer uma das linguagens suportadas, como .NET, Java, JavaScript, Python e Go, que farão isso por você.

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

O PutCbsToken() método recebe a conexão (instância de classe de conexão AMQP, conforme fornecido pela biblioteca AMQP .NET Lite) que representa a conexão TCP com o serviço e o parâmetro sasToken que é o token SAS a ser enviado.

Nota

É importante que a conexão seja criada com o mecanismo de autenticação SASL definido como ANONYMOUS (e não o padrão PLAIN com nome de usuário e senha usados quando você não precisa enviar o token SAS).

Em seguida, o editor cria dois links AMQP para enviar o token SAS e receber a resposta (o resultado da validação do token) do serviço.

A mensagem AMQP contém um conjunto de propriedades e mais informações do que uma simples mensagem. O token SAS é o corpo da mensagem (usando seu construtor). A propriedade "ReplyTo" é definida como o nome do nó para receber o resultado da validação no link do recetor (você pode alterar seu nome, se desejar, e ele será criado dinamicamente pelo serviço). As três últimas propriedades de aplicativo/personalizadas são usadas pelo serviço para indicar que tipo de operação ele tem que executar. Conforme descrito pela especificação preliminar do CBS, eles devem ser o nome da operação ("put-token"), o tipo de token (neste caso, a servicebus.windows.net:sastoken) e o "nome" do público ao qual o token se aplica (a entidade inteira).

Depois que o editor envia o token SAS no link do remetente, o editor deve ler a resposta no link do destinatário. A resposta é uma mensagem AMQP simples com uma propriedade de aplicativo chamada "status-code" que pode conter os mesmos valores de um código de status HTTP.

Direitos necessários para operações do Service Bus

A tabela a seguir mostra os direitos de acesso necessários para várias operações em recursos do Service Bus.

Operação Reivindicação Necessária Escopo da reivindicação
Espaço de nomes
Configurar regra de autorização em um namespace Gerir Qualquer endereço de namespace
Registo de Serviços
Enumerar políticas privadas Gerir Qualquer endereço de namespace
Começar a ouvir em um namespace Escutar Qualquer endereço de namespace
Enviar mensagens para um ouvinte em um namespace Enviar Qualquer endereço de namespace
Fila
Criar uma fila Gerir Qualquer endereço de namespace
Eliminar uma fila Gerir Qualquer endereço de fila válido
Enumerar filas Gerir /$Resources/Filas
Obter a descrição da fila Gerir Qualquer endereço de fila válido
Configurar regra de autorização para uma fila Gerir Qualquer endereço de fila válido
Enviar para a fila Enviar Qualquer endereço de fila válido
Receber mensagens de uma fila Escutar Qualquer endereço de fila válido
Abandonar ou concluir mensagens depois de receber a mensagem no modo peek-lock Escutar Qualquer endereço de fila válido
Adiar uma mensagem para recuperação posterior Escutar Qualquer endereço de fila válido
Carta morta uma mensagem Escutar Qualquer endereço de fila válido
Obter o estado associado a uma sessão de fila de mensagens Escutar Qualquer endereço de fila válido
Definir o estado associado a uma sessão de fila de mensagens Escutar Qualquer endereço de fila válido
Agendar uma mensagem para entrega posterior Escutar Qualquer endereço de fila válido
Tópico
Criar um tópico Gerir Qualquer endereço de namespace
Excluir um tópico Gerir Qualquer endereço de tópico válido
Enumerar tópicos Gerir /$Resources/Tópicos
Obter a descrição do tópico Gerir Qualquer endereço de tópico válido
Configurar regra de autorização para um tópico Gerir Qualquer endereço de tópico válido
Enviar para o tópico Enviar Qualquer endereço de tópico válido
Subscrição
Criar uma subscrição Gerir Qualquer endereço de namespace
Eliminar subscrição Gerir .. /myTopic/Assinaturas/mySubscription
Enumerar assinaturas Gerir .. /myTopic/Assinaturas
Obter descrição da subscrição Gerir .. /myTopic/Assinaturas/mySubscription
Abandonar ou concluir mensagens depois de receber a mensagem no modo peek-lock Escutar .. /myTopic/Assinaturas/mySubscription
Adiar uma mensagem para recuperação posterior Escutar .. /myTopic/Assinaturas/mySubscription
Carta morta uma mensagem Escutar .. /myTopic/Assinaturas/mySubscription
Obter o estado associado a uma sessão de tópico Escutar .. /myTopic/Assinaturas/mySubscription
Definir o estado associado a uma sessão de tópico Escutar .. /myTopic/Assinaturas/mySubscription
Regras
Criar uma regra Escutar .. /myTopic/Assinaturas/mySubscription
Eliminar uma regra Escutar .. /myTopic/Assinaturas/mySubscription
Enumerar regras Gerir ou Ouvir .. /myTopic/Assinaturas/mySubscription/Rules

Próximos passos

Para mais informações sobre mensagens do Service Bus, consulte os seguintes tópicos.