Controle de acesso do Barramento de Serviço com Assinaturas de Acesso Compartilhado

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

A SAS protege o acesso a Barramento de Serviço 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 nome, está associada a direitos específicos e executa um par de chaves de criptografia. Use o nome e a chave da regra por meio do SDK do Barramento de Serviço ou em seu próprio código para gerar um token SAS. Um cliente pode passar o token para o Barramento de Serviço para comprovar a autorização para a operação solicitada.

Visão geral das SAS

Assinaturas de Acesso Compartilhado são um mecanismo de autorização baseada em declarações usando tokens simples. Quando SAS é usado, as chaves nunca são passadas na conexão. As chaves são usadas para assinar criptograficamente informações que posteriormente podem ser verificadas pelo serviço. A SAS pode ser usada como esquema de nome de usuário e senha no qual o cliente está em posse imediata de um nome de regra de autorização e uma chave correspondente. A SAS também pode ser usada como modelo de segurança federada, no qual o cliente recebe um token de acesso de tempo limitado e assinado de um serviço de token de segurança sem nunca ter posse da chave de assinatura.

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

O token de Assinatura de Acesso Compartilhado contém o nome da política de autorização escolhida, o URI do recurso que deve ser acessado, uma expiração instantânea e uma assinatura criptográfica HMAC-SHA256 calculada com esses campos usando a chave de criptografia primária ou secundária da regra de autorização escolhida.

Políticas de autorização de acesso compartilhado

Cada namespace do Barramento de Serviço e cada entidade do Barramento de Serviço 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 suas configurações de política individuais.

Para cada regra de política de autorização, você toma decisões quanto a três informações: nome, escopo e direitos. O nome é apenas isso, um nome exclusivo dentro do escopo. O escopo é bastante simples: é o URI do recurso em questão. Para um namespace do Barramento de Serviço, o escopo é o namespace totalmente qualificado, como https://<yournamespace>.servicebus.windows.net/.

Os direitos concedidos pela regra de política podem ser uma combinação de:

• Enviar – concede o direito de enviar mensagens para a entidade
• Escutar – concede o direito de receber (fila, assinaturas) e todo o manuseio de mensagens relacionado
• Gerenciar – concede o direito de gerenciar a topologia do namespace, incluindo a criação e a exclusão de entidades

O direito de Gerenciar inclui os direitos de Enviar e de Escutar.

Uma política de namespace ou entidade pode armazenar até 12 regras de Autorização de Acesso Compartilhado, fornecendo espaço para três conjuntos de regras, cada um abrangendo os direitos básicos e a combinação de Enviar e Escutar. 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 ressalta que o armazenamento da política de SAS não é pretendida como armazenamento de conta de usuário ou serviço. Se seu aplicativo precisa conceder acesso ao Barramento de Serviço com base no usuário ou em identidades de serviço, ele deve implementar um serviço de token de segurança que emite tokens SAS após uma verificação de acesso e autenticação.

Uma regra de autorização recebe uma Chave primária e uma Chave secundária. Essas chaves são criptograficamente fortes. Não as perca ou divulgue - elas sempre estarão disponíveis no portal do Azure. Você pode usar qualquer uma das chaves geradas e pode gerá-las novamente a qualquer momento. Se você gerar novamente ou alterar uma chave na política, todos os tokens emitidos anteriormente com base na chave tornam-se inválidos instantaneamente. No entanto, as conexões contínuas criadas com base em tais tokens continuam funcionando até o token expirar.

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

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

Se você souber ou suspeitar de uma chave comprometida e se você precisar revogar as chaves, será possível gerar novamente 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 nos seus aplicativos, você precisará estar ciente de dois riscos possíveis:

• Se ocorrer perda de uma SAS, ela poderá ser usada por qualquer pessoa que a obtiver, o que poderá comprometer seus recursos de Barramento de Serviço.
• Se uma SAS fornecida para 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 recomendações a seguir para usar assinaturas de acesso compartilhado podem ajudar a atenuar esses riscos:

• Peça que os clientes renovem a SAS automaticamente, se necessário: os clientes devem renovar a SAS bem antes da expiração para que haja tempo para novas tentativas caso o serviço que fornece a SAS não esteja disponível. Se a SAS se destinar a uso para um pequeno número de operações imediatas e de curta duração que devem ser concluídas no período de expiração, isso poderá ser desnecessário, pois não se espera que a SAS seja renovada. No entanto, se você tiver um cliente que está sempre fazendo solicitações via SAS, surge a possibilidade de expiração. A principal consideração consiste em equilibrar a necessidade de curta duração da SAS (como mencionado acima) com a necessidade de garantir que o cliente solicite renovação com antecedência suficiente (para evitar uma interrupção devido ao vencimento da SAS antes de uma renovação bem-sucedida).
• Tenha cuidado com a hora de início da SAS: se você definir a hora de início de uma SAS como agora, você poderá observar falhas intermitentemente nos primeiros minutos devido à defasagem horária (diferenças na hora atual de acordo com computadores diferentes). Em geral, defina a hora de início para pelo menos 15 minutos no passado. Ou então, simplesmente não a defina, o que a tornará imediatamente válida em todos os casos. O mesmo geralmente também se aplica à hora de expiração. Lembre-se de que pode haver até 15 minutos de defasagem horária em um dos dois sentidos em qualquer solicitação.
• Seja específico com o recurso a ser acessado: uma melhor prática de segurança é fornecer ao usuário os privilégios mínimos necessários. Se um usuário precisar apenas 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. Isso também ajuda a reduzir o dano caso uma SAS seja comprometida, pois a SAS terá menos poder nas mãos de um invasor.
• Não use a SAS sempre: às vezes, os riscos associados a uma determinada operação em relação aos Barramentos de Serviço superam os benefícios da SAS. Para essas operações, crie um serviço de camada intermediária que grave nos Barramento de Serviço após a validação, autenticação e auditoria da regra de negócio.
• Sempre use HTTPs: sempre use HTTPS para criar ou distribuir uma SAS. Se uma SAS for passada por HTTP e interceptada, um invasor que estiver realizando um ataque intermediário poderá lê-la e, em seguida, usá-la exatamente como o usuário previsto, o que poderá comprometer dados confidenciais ou gerar dados corrompidos pelo usuário mal-intencionado.

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

Você pode configurar a regra Política de Autorização de Acesso Compartilhado em namespaces, filas ou tópicos do Barramento de Serviço. A sua configuração em uma assinatura do Barramento de Serviço não tem suporte no momento, porém é possível usar regras configuradas em um namespace ou tópico para obter acesso segura às assinaturas.

Nessa figura, as regras de autorização manageRuleNS, sendRuleNS e listenRuleNS se aplicam à fila Q1 e ao tópico T1, enquanto listenRuleQ e sendRuleQ se aplicam somente à fila Q1 e sendRuleT se aplica 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 e a uma de suas chaves de assinatura pode gerar um token SAS. O token é gerado ao criar uma cadeia de caracteres no seguinte formato:

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

• se – instante da expiração do token. Número inteiro que reflete os 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 sendo acessado.

• sig - Assinatura HMACSHA256 codificada por URL. O cálculo de hash é semelhante ao seguinte pseudocódigo e retorna base64 de saída binária bruta.

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

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

O URI do recurso é o URI completo do recurso do Barramento de Serviço ao qual o acesso é solicitado. Por exemplo, http://<namespace>.servicebus.windows.net/<entityPath> ou sb://<namespace>.servicebus.windows.net/<entityPath>; ou seja, http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

O URI deve ser codificado por percentual.

A regra de autorização de acesso compartilhado usada para assinar 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 na signature-string.

Regenerando chaves

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

Se você souber ou suspeitar de uma chave comprometida e se precisar revogar as chaves, será possível regenerar a chave primária e a chave secundária de uma Política de Autorização de Acesso Compartilhado, 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 Barramento de Serviço 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 Política de SAS: RootManageSharedAccessKey, selecione Regenerar chave primária na barra de comandos.

   

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

   

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

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

Autenticação de Assinatura de Acesso Compartilhado com Barramento de Serviço

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

Para um exemplo de um aplicativo do Barramento de Serviço que ilustre a configuração e use a autorização SAS, confira Autenticação de Assinatura de Acesso Compartilhado com o Barramento de Serviço.

Acessar regras de Autorização de Acesso Compartilhado em uma entidade

Use a operação get/update em filas ou tópicos nas bibliotecas de gerenciamento do Barramento de Serviço 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.

Usar a autorização de Assinatura de Acesso Compartilhado

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

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

Para usar a autorização SAS com assinaturas do Barramento de Serviço, você poderá usar as chaves SAS configuradas em um namespace ou em um tópico do Barramento de Serviço.

Usar a Assinatura de Acesso Compartilhado (no nível do HTTP)

Agora que sabe como criar Assinaturas de acesso compartilhado para qualquer entidade no Barramento de Serviço, você 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 de que isso funciona para tudo. Você pode criar SAS para uma fila, tópico ou assinatura.

Se você fornecer a um remetente ou um cliente um token SAS, eles não têm a chave diretamente e não podem reverter o hash para obtê-la. Dessa forma, você tem controle sobre o que eles podem acessar e por quanto tempo. É importante se lembrar de que se você alterar a chave primária da política, quaisquer Assinaturas de acesso compartilhado criadas por meio dela serão invalidadas.

Usar a Assinatura de Acesso Compartilhado (no nível do AMQP)

Na seção anterior, você viu como usar o token SAS com uma solicitação HTTP POST para envio dos dados ao Barramento de Serviço. Como você sabe, é possível acessar o Barramento de Serviço usando o protocolo AMQP (Advanced Message Queuing Protocol), que é o protocolo preferencial por motivos de desempenho em muitos cenários. O uso de tokens SAS com AMQP é descrito no documento Segurança com base em declarações do AMQP Versão 1.0, em estado de rascunho funcional desde 2013, mas que conta com suporte do Azure no momento.

Antes de começar a enviar dados ao Barramento de Serviço, o editor precisa enviar o token SAS dentro de uma mensagem AMQP para um nó AMQP bem definido chamado $cbs (veja-o 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; esse é o nó em que o serviço responde ao editor com o resultado da validação do token (um padrão simples de solicitação/resposta entre o editor e o serviço). Esse nó de resposta é criado "dinamicamente", falando sobre "criação dinâmica de nó remoto", como descrito pela especificação do AMQP 1.0. Depois de verificar a validade do token SAS, o editor poderá começar a enviar dados ao 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 Barramento de Serviço (por exemplo, no WinRT, no .NET Compact Framework, no .NET Micro Framework e no Mono) ao desenvolver em C#. Essa biblioteca é útil para entender como funciona a segurança baseada em declarações no nível do AMQP, como você viu que funciona no nível HTTP (com uma solicitação HTTP POST e o token SAS enviados dentro do cabeçalho "Authorization"). Se você não precisar desse conhecimento aprofundado sobre o AMQP, poderá usar o SDK oficial do Barramento de Serviço em qualquer uma das linguagens com suporte, como .NET, Java, JavaScript, Python e Go, que fará isso para 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 método PutCbsToken() recebe a PutCbsToken() (instância da classe de conexão AMQP, conforme fornecida pela biblioteca AMQP .Net Lite), que representa a conexão TCP com o serviço, e o parâmetro sasToken, o token SAS a ser enviado.

Em seguida, o editor cria dois links AMQP para enviar o token SAS e receber a resposta (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 mensagem simples. O token SAS é o corpo da mensagem (usando o construtor). A propriedade "ReplyTo" é definida como o nome do nó para receber o resultado da validação no link receptor (você pode alterar o nome dele se quiser e ele será criado dinamicamente pelo serviço). As três últimas propriedades application/custom são usadas pelo serviço para indicar o tipo de operação que ele deve executar. Conforme descrito pela especificação do rascunho CBS, elas devem ser o nome da operação ("put-token"), o tipo de token (nesse caso, um servicebus.windows.net:sastoken) e o "nome" do público-alvo ao qual o token se aplica (toda a entidade).

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

Direitos necessários para operações do Barramento de Serviço

A tabela a seguir mostra os direitos de acesso necessários para diversas operações em recursos do Barramento de Serviço.

Próximas etapas

Para saber mais sobre as mensagens do Barramento de Serviço, confira os tópicos a seguir.

• Filas, tópicos e assinaturas do Barramento de Serviço
• Como usar filas do Barramento de Serviço
• Como usar tópicos e assinaturas do Barramento de Serviço