Resumo

  • A RFC 10065 torna o identificador de grupo transportável entre RADIUS e o modelo YANG de ACL, sem criar um espaço de nomes global.
  • A verificação operacional é confirmar que AAA, controlador e cada ponto de aplicação usam o mesmo mapeamento atualizado.

Um dispositivo entra na rede e passa pela autenticação. O servidor devolve um identificador de grupo. Para que ele se transforme em permissão ou bloqueio de tráfego, o controlador e os pontos de aplicação precisam reconhecer a mesma definição. A RFC 10065 oferece uma estrutura comum para modelar esse caminho, mas o identificador não é uma decisão de acesso por si só.

A fronteira importa: o valor pode cruzar interfaces padronizadas, enquanto o significado e a relação com os campos dos pacotes continuam sendo trabalho de cada implantação.

O que a norma padroniza

A RFC 10065 define um módulo YANG de listas de controle de acesso baseadas em grupos, ampliando o modelo de ACL do IETF. A rede pode declarar grupos de usuários, dispositivos ou aplicações e usar esses grupos como origem ou destino das regras. Campos Ethernet, IPv4, IPv6 e de transporte podem ser combinados com a identidade do grupo. Também é possível associar uma agenda efetiva à regra, com recorrências e períodos do modelo comum da RFC 9922.

Para acesso dependente de autenticação, o documento define o atributo RADIUS User-Access-Group-ID, tipo 241.12. Ele transporta como texto o ID do grupo de usuário atribuído pelo serviço AAA. Pode aparecer em Access-Accept. Um Access-Request também pode sugerir um grupo, mas o servidor não precisa aceitar a sugestão. Mais de um atributo em Access-Accept indica que o usuário pertence a vários grupos.

A abstração pode evitar que cada mudança de endereço de um equipamento exija uma nova política. A regra passa a se referir a uma categoria de acesso em vez de uma lista fixa de IPs. Ainda assim, alguém precisa manter a ligação entre contexto, grupo e regra.

A semântica permanece no ambiente local

No fluxo descrito pela RFC, o usuário autentica no NAS. O servidor AAA verifica a solicitação e, se a aceita, atribui um ID. O AAA ou o NAS notifica o controlador SDN sobre a correspondência entre o ID e atributos comuns de cabeçalho, como a quíntupla. O controlador administra a política e configura os pontos de aplicação pertinentes.

A RFC deixa os detalhes dessa notificação fora de escopo. Também deixa a definição de grupos para cada implantação. Os critérios podem incluir função, certificado do dispositivo, endereço, localização, hora ou política corporativa. Uma pessoa pode mudar de grupo quando essas condições mudam. O documento não cria uma autoridade global para definir grupos nem um protocolo universal de sincronização da correspondência.

No modelo YANG, o ID precisa distinguir um grupo na lista pertinente. Isso não equivale a uma identidade mundial. Redes diferentes podem reutilizar o mesmo texto para representar conjuntos e permissões diferentes. Entregar a mesma string por RADIUS não prova que todos os equipamentos interpretam seu conteúdo da mesma forma.

Dois papéis distintos para o tempo

A política pode ter um horário que determine quando uma regra vale. Separadamente, a hora pode ser um critério para atribuir uma pessoa a determinado grupo. Uma condição define a vigência da ACL; a outra pode alterar a classificação do usuário. Testes em troca de turno precisam verificar os dois pontos sem confundi-los.

Há uma opção de converter o grupo para campos de pacote convencionais no controlador e distribuir ACLs comuns. Outra é fazer o próprio ponto de aplicação corresponder diretamente ao grupo. A RFC observa que esta alternativa pode exigir suporte de hardware ou software e afetar o desempenho de encaminhamento. Ela descreve a escolha, sem oferecer medições que determinem a melhor solução para todas as redes.