Autorizar o acesso a recursos dos Hubs de Eventos com Assinaturas de Acesso Partilhado

  • Artigo

Uma assinatura de acesso compartilhado (SAS) fornece uma maneira de conceder acesso limitado a recursos em seu namespace de Hubs de Eventos. O SAS protege o acesso aos recursos dos Hubs de Eventos com base em regras de autorização. Essas regras são configuradas em um namespace ou em um hub de eventos. Este artigo fornece uma visão geral do modelo SAS e analisa as práticas recomendadas do SAS.

Nota

Este artigo aborda a autorização de acesso aos recursos dos Hubs de Eventos usando o SAS. Para saber mais sobre como autenticar o acesso aos recursos dos Hubs de Eventos usando SAS, consulte Autenticar com SAS.

O que são assinaturas de acesso compartilhado?

Uma assinatura de acesso compartilhado (SAS) fornece acesso delegado aos recursos dos Hubs de Eventos com base em regras de autorização. 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 dos clientes dos Hubs de Eventos ou em seu próprio código para gerar tokens SAS. Um cliente pode então passar o token para Hubs de Eventos para provar a autorização para a operação solicitada.

O SAS é um mecanismo de autorização baseado em declarações que utiliza 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 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.

Nota

Os Hubs de Eventos do Azure também dão suporte à autorização para recursos de Hubs de Eventos 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). Com o Microsoft Entra ID, não há necessidade de armazenar os tokens em seu código e arriscar possíveis vulnerabilidades de segurança.

A Microsoft recomenda usar a ID do Microsoft Entra com seus aplicativos de Hubs de Eventos do Azure quando possível. Para obter mais informações, consulte Autorizar o acesso ao recurso de Hubs de Eventos do Azure usando a ID do Microsoft Entra.

Importante

Os tokens SAS (Assinaturas de Acesso Compartilhado) são essenciais para proteger seus recursos. Ao mesmo tempo em que fornece granularidade, o SAS concede aos clientes acesso aos recursos dos Hubs de Eventos. Não devem ser partilhados publicamente. Ao compartilhar, se necessário por motivos de solução de problemas, considere usar uma versão reduzida de quaisquer arquivos de log ou excluir os tokens SAS (se presentes) dos arquivos de log e certifique-se de que as capturas de tela também não contenham as informações SAS.

Políticas de autorização de acesso compartilhado

Cada namespace de Hubs de Eventos e cada entidade de Hubs de Eventos (um hub de eventos ou um tópico Kafka) tem uma política de autorização de acesso compartilhado composta por regras. A política no nível do namespace se aplica a todas as entidades dentro do 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 é um nome exclusivo nesse escopo. O escopo é o URI do recurso em questão. Para um namespace de Hubs de Eventos, o escopo é o FQDN (nome de domínio totalmente qualificado), como https://<yournamespace>.servicebus.windows.net/.

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

  • Enviar – Dá o direito de enviar mensagens para a entidade
  • Ouvir – Dá o direito de ouvir ou receber mensagens da entidade
  • Gerenciar – Dá 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 os três conjuntos de regras, cada um cobrindo os direitos básicos e a combinação de Enviar e Ouvir. 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 aos recursos dos Hubs de Eventos 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 nem os 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 continuarão a funcionar até que o token expire.

Quando você cria um namespace de Hubs de Eventos, uma regra de política chamada RootManageSharedAccessKey é criada automaticamente para o namespace. Esta política tem permissões de gerenciamento 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 regras de política adicionais na guia Configurar para o namespace no portal, via PowerShell ou CLI do Azure.

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 dos Hubs de Eventos.
  • 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 um pequeno número de 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 no tempo atual de acordo com máquinas diferentes), as falhas podem ser observadas intermitentemente durante os 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 aos Hubs de Eventos superam os benefícios do SAS. Para essas operações, crie um serviço de camada intermediária que grave em seus Hubs de Eventos após a validação, autenticação e auditoria de regras 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 um ataque 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.

Conclusão

As assinaturas de acesso de compartilhamento são úteis para fornecer permissões limitadas aos recursos dos Hubs de Eventos para seus clientes. Eles são parte vital do modelo de segurança para qualquer aplicativo que use Hubs de Eventos do Azure. Se você seguir as práticas recomendadas listadas neste artigo, poderá usar o SAS para fornecer maior flexibilidade de acesso aos seus recursos, sem comprometer a segurança do seu aplicativo.

Próximos passos

Veja os seguintes artigos relacionados: