Na arquitetura 5G baseada em serviços, uma AMF pode descobrir o endpoint SBI de uma UDM ou SMF, mas a descoberta, por si só, não concede permissão para consultar dados do assinante nem para criar uma sessão PDU. A comunicação baseada em serviços torna mais flexíveis as interações entre funções de rede, ao mesmo tempo que expõe um conjunto mais amplo de APIs do núcleo. Se um produtor de serviços NF processar toda solicitação alcançável sem verificar a autorização, não poderá determinar com segurança se o chamador é legítimo, está registrado ou tem permissão para utilizar o serviço solicitado.

O 5GC resolve esse problema por meio de um modelo de autorização baseado em OAuth 2.0. Um consumidor de serviços NF primeiro solicita um token de acesso ao NRF e depois apresenta esse token ao chamar o produtor de serviços NF de destino. O produtor só executa a operação solicitada após validar o token e suas declarações de autorização. Nesse modelo, o NRF atua não apenas como registro e função de descoberta, mas também como servidor de autorização para o acesso protegido à SBI.

Riscos de chamadas SBI sem proteção

As redes 5G standalone utilizam a arquitetura baseada em serviços, na qual funções de rede como AMF, SMF, UDM e AUSF disponibilizam um ou mais serviços por meio de interfaces baseadas em HTTP/2. Um consumidor pode invocar esses serviços por APIs HTTP padronizadas, reduzindo dependências rígidas ponto a ponto e permitindo a criação dinâmica de relações de serviço.

Durante o registro do UE, por exemplo, a AMF pode chamar o serviço Nudm_SDM da UDM para obter informações de assinatura. Durante o estabelecimento de uma sessão PDU, a AMF pode chamar o serviço Nsmf_PDUSession da SMF para criar um contexto de gerenciamento de sessão. Ambos os procedimentos envolvem informações sensíveis do assinante ou recursos críticos do núcleo da rede.

Se a UDM devolver dados de assinatura apenas porque a solicitação chegou ao URI correto, não terá garantia de que o chamador seja uma AMF autorizada. Da mesma forma, uma SMF que crie uma sessão sem validar o solicitante poderá aceitar chamadas de uma função de rede não confiável ou configurada incorretamente. A acessibilidade do endpoint confirma apenas que a comunicação é tecnicamente possível; ela não comprova identidade nem autorização.

O risco torna-se maior em implantações nativas de nuvem. Instâncias NF podem ser criadas, escaladas, atualizadas, realocadas ou removidas conforme mudam as necessidades operacionais. Um consumidor de serviços também pode selecionar diferentes instâncias produtoras por meio da descoberta baseada no NRF. Por isso, endereços estáticos e configurações fixas entre pares são insuficientes para controlar cada solicitação de serviço.

O 5GC separa a descoberta de serviços da autorização de serviços. A descoberta responde onde um serviço adequado está disponível. A autorização determina se o consumidor atual pode utilizá-lo. Antes que a solicitação de negócio seja processada, o consumidor deve obter uma credencial associada ao serviço pretendido, e o produtor deve validá-la.

NRF como servidor de autorização

OAuth 2.0 é uma estrutura geral de autorização para acesso controlado entre aplicações. Não é exclusiva de redes móveis. Seu modelo padrão define três funções principais: o cliente que solicita acesso, o servidor de autorização que emite um token e o servidor de recursos que protege o recurso ou serviço solicitado.

No modelo de segurança SBI do 5GC, essas funções correspondem diretamente ao comportamento das funções de rede:

Quando uma AMF precisa chamar um serviço da UDM, a AMF atua como consumidora de serviços NF, a UDM como produtora, e o NRF fornece a função de autorização. A AMF obtém um token antes de chamar Nudm_SDM. Em seguida, a UDM verifica se o token é válido e se suas declarações permitem acesso ao serviço solicitado.

Para dar suporte a esse processo, o NRF disponibiliza o serviço Nnrf_AccessToken. Uma solicitação de token pode incluir a identidade do consumidor, o nome do serviço solicitado, o tipo de NF de destino, o tipo de NF consumidora e o identificador do cliente. Depois de avaliar a solicitação, o NRF devolve um token de acesso junto com informações como o tipo do token e o período de validade.

O NRF não executa a operação de negócio solicitada. Ele define o contexto de autorização e emite a credencial de acesso. A consulta de dados do assinante, a criação de sessões e outras operações específicas continuam sob responsabilidade do produtor de serviços NF correspondente.

Fluxo de acesso a serviços baseado em token

O procedimento de acesso a serviços NF definido para o 5GC pode ser dividido em duas etapas. Primeiro, o consumidor obtém um token de acesso do NRF. Depois, apresenta esse token ao produtor de destino ao solicitar o serviço real. Essa separação impede que uma solicitação não verificada siga diretamente para o processamento de negócio.

Solicitação de um token de acesso

O consumidor de serviços NF deve primeiro possuir uma identidade válida e um contexto de registro disponível para o NRF. Em seguida, chama Nnrf_AccessToken e identifica o serviço que pretende acessar, o tipo de NF de destino e suas próprias informações como consumidor.

O NRF avalia a solicitação com base nos dados de registro disponíveis e na política de autorização. Se a autorização for concedida, gera um token de acesso e o devolve ao consumidor. Nesse momento, nenhuma consulta de assinante, criação de sessão ou outra operação de negócio foi realizada. O consumidor recebeu apenas permissão para tentar chamar o serviço protegido.

Chamada do serviço protegido

O consumidor envia a solicitação de negócio ao produtor de serviços NF e inclui o token de acesso no cabeçalho HTTP Authorization. Antes de processar a solicitação, o produtor verifica a integridade do token, seu período de validade e suas declarações de autorização. O serviço solicitado só é executado quando todas essas verificações são bem-sucedidas.

Considere o estabelecimento de uma sessão PDU. A AMF primeiro envia uma solicitação HTTP/2 POST ao serviço Nnrf_AccessToken do NRF, informando que precisa acessar o serviço Nsmf_PDUSession da SMF. Após a autorização, o NRF devolve o token em uma resposta HTTP 200 OK.

A AMF então envia a solicitação Nsmf_PDUSession à SMF selecionada e inclui o token. A SMF valida a credencial antes de criar o contexto de gerenciamento da sessão PDU. Se a solicitação for aceita e o contexto for criado com sucesso, a SMF poderá devolver uma resposta HTTP 201 Created.

Essa sequência coloca a autorização antes da execução de negócio. Conhecer o endereço da SMF e o caminho da API não é suficiente. Sem um token válido que cubra o serviço pretendido, o solicitante não deve ser autorizado a prosseguir com a criação normal da sessão.

Escopo e limites do projeto

A descoberta de serviços baseada no NRF e a autorização baseada no NRF são relacionadas, mas constituem capacidades distintas. A descoberta identifica instâncias produtoras disponíveis e os serviços que elas suportam. A autorização decide se um consumidor específico pode chamar um desses serviços. Concluir a descoberta não elimina a necessidade de obter um token apropriado.

O token de acesso também não substitui os dados de negócio. O NRF não consulta informações de assinatura da UDM nem cria uma sessão na SMF quando emite um token. Ele fornece evidência de que o consumidor foi autorizado dentro de um escopo definido. O produtor continua responsável por processar a solicitação e gerar a resposta.

Uma implementação segura exige aplicação das regras no lado do produtor. Exigir que o consumidor solicite um token oferece pouca proteção se o produtor não validar a integridade, a expiração e as declarações do token antes de executar o serviço. Portanto, consumidor, NRF e produtor devem seguir regras compatíveis de processamento de tokens.

A autorização também é limitada por escopo e tempo. Um token emitido para um serviço SBI não concede automaticamente acesso irrestrito a todas as interfaces expostas por outras funções de rede. Tokens expirados ou cujas declarações não correspondam ao serviço de destino não devem ser tratados como credenciais válidas.

Assim, o NRF oferece duas funções distintas relacionadas à segurança no núcleo 5G. Ele mantém perfis NF e oferece descoberta de serviços, ajudando os consumidores a localizar produtores adequados. Por meio de Nnrf_AccessToken, também controla se esses consumidores estão autorizados a invocar serviços SBI protegidos.

Perguntas frequentes

Um token de acesso pode substituir o registro da NF?

Não. O registro da NF estabelece a identidade da instância e seu perfil de serviço. Um token de acesso fornece autorização para um contexto definido de acesso ao serviço. O registro e a emissão de tokens têm finalidades diferentes.

Um token pode ser usado com várias instâncias NF?

Isso depende das declarações do token, do tipo de NF de destino, do escopo do serviço e da política de autorização aplicável. Cada produtor deve verificar se o token é válido para a solicitação atual, em vez de aceitá-lo apenas porque ainda não expirou.

Os tokens existentes deixam de funcionar imediatamente quando o NRF fica indisponível?

O comportamento depende do formato do token, do período de validade, do método de verificação no produtor e da política de implantação. Uma indisponibilidade temporária do NRF não determina automaticamente o estado de todos os tokens emitidos anteriormente, mas novas solicitações de token podem ser afetadas.

O OAuth 2.0 criptografa o conteúdo das mensagens SBI?

Não. O OAuth 2.0 fornece principalmente autorização e controle de acesso. A proteção do transporte SBI é realizada por mecanismos de segurança separados, como TLS. Um token de acesso válido não deve ser tratado como substituto do transporte criptografado.