Autorizar o acesso aos recursos dos Hubs de Eventos usando Assinaturas de Acesso Compartilhado

Artigo
10/22/2023

Uma assinatura de acesso compartilhado (SAS) fornece uma maneira de conceder acesso limitado a recursos em seu namespace de Hubs de eventos. A SAS protege o acesso a recursos de 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 revisa as práticas recomendadas de SAS.

Observação

Este artigo aborda a autenticação do acesso a recursos dos Hubs de Eventos usando SAS. Para saber mais sobre o acesso de autenticação nos recursos dos Hubs de Eventos usando SAS, confira Autenticar com SAS.

O que são assinaturas de acesso compartilhado do azure?

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

A SAS é um mecanismo de autorização baseado 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 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.

Observação

Os Hubs de Eventos do Azure dão suporte a autorizações de recursos de Hubs de Eventos usando o Microsoft Entra ID. Autorizar usuários ou aplicativos usando o token OAuth 2.0 retornado pelo Microsoft Entra ID fornece segurança superior e facilidade de uso em sas (assinaturas de acesso compartilhado). Com o Microsoft Entra ID, não é necessário armazenar os tokens em seu código e arriscar possíveis vulnerabilidades de segurança.

A Microsoft recomenda usar o Microsoft Entra ID com seus aplicativos do Hubs de Eventos do Azure quando possível. Para saber mais, consulte Autorizar o acesso para Hubs de Eventos do Azure usando o Microsoft Entra ID.

Importante

Tokens SAS (assinaturas de acesso compartilhado) são essenciais para proteger seus recursos. Embora forneça granularidade, a SAS concede aos clientes acesso aos seus recursos de hubs de eventos. Eles não devem ser compartilhados publicamente. Ao compartilhar, caso necessário por motivos de solucionamento de problemas, considere usar uma versão reduzida de qualquer arquivo de log ou excluir os tokens SAS (se houver) dos arquivos de log e verifique se as capturas de tela também não contêm as informações de SAS.

Políticas de autorização de acesso compartilhado

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

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

Enviar – dá o direito de enviar mensagens para a entidade
Escutar – Dá o direito de escutar ou receber mensagens da entidade
Gerenciar – Dá 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 os três conjuntos de regras, cada um abrangendo os direitos básicos e a combinação de Enviar e Escutar. 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 aos recursos dos Hubs de Eventos 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 perca nem revele esses itens. Eles estarão sempre 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, conexões contínuas criadas com base em tais tokens continuarão funcionando até o token expirar.

Quando você cria um namespace dos Hubs de Eventos, é 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 a use em seu aplicativo. É possível criar regras de políticas 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 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 Hubs de Eventos.
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 for usada por um número pequeno de operações imediatas e de curta duração que devem ser concluídas dentro do 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, poderão ser observadas 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 Hubs de Eventos superam os benefícios da SAS. Para essas operações, crie um serviço de camada intermediária que grave nos Hubs de Eventos 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.

Conclusão

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

Próximas etapas

Confira os seguintes artigos relacionados: