Resumo

  • O rascunho individual apresentado ao IETF em 27 de outubro obriga a política distribuída a declarar área, dono, autor, linguagem e conteúdo. A consulta que verifica se o dono ou remetente pode mandar naquela área aparece como MAY.
  • A mesma estrutura pode entregar Rego a um domínio e uma regra de túnel IPsec a outro. O teste de governança é saber quem autorizou cada destinatário a instalar a ordem e como a retira quando a autorização termina.

A encomenda chegou carimbada; quem autorizou a entrega?

Uma equipe recebe um artefato de política de outro domínio. O formato está correto, a assinatura confere e o campo owner aponta para uma entidade reconhecível. O automatismo agradece: basta encaminhar a encomenda ao motor certo. Só que a assinatura pertence à encomenda, enquanto o poder de alterar a rede pertence ao domínio que a recebe. Um não passa a ser o outro por conveniência da interface.

O rascunho Model for distributed policy sharing cria um contêiner YANG para um artefato isolado em trânsito. Nele, area, language, policy-content, owner e author são obrigatórios; origin e a assinatura de proveniência são opcionais no exemplo. O conteúdo é opaco para o contêiner. Rego, Cedar, ALFA ou XACML podem compartilhar a embalagem, mas cada ambiente de execução continua responsável pelo significado da regra. O modelo não cria um repositório completo nem prescreve o protocolo de transporte.

Essa divisão é honesta. Também torna impossível fingir que preencher owner resolveu o direito de governar a área indicada. Quem escreveu o pacote escolheu o valor do campo. O recebedor precisa confrontá-lo com sua própria delegação, com o prazo de validade e com as operações permitidas. Uma assinatura associada à proposta de proveniência YANG pode demonstrar origem e integridade dos dados assinados. Ela não concede licença para mexer nas regras de outro administrador.

Uma palavra opcional diante de uma porta enorme

Na seção 6.1, o Policy Administration Point, PAP, valida o esquema, acompanha o ciclo de vida e pode verificar a proveniência. Antes de aceitar ou distribuir a política, ele MAY consultar um Policy Decision Point para descobrir se o dono declarado ou o remetente está autorizado a definir ou alterar regras naquela área. O desenho da seção 6.2 põe a verificação de governança bem no centro do PAP. Quem olhar só o desenho verá um posto de controle. Quem ler o verbo encontrará uma escolha local.

Escolhas locais são inevitáveis quando organizações têm modelos distintos de confiança. O problema começa quando o destinatário não declara qual escolha fez. Uma política que muda permissões ou comportamento de rede pode ser executada corretamente pelo PDP de produção mesmo tendo entrado sem mandato. A confirmação de que a regra funcionou não sana a falta de autorização para instalá-la.

Em mensagem à lista NMOP, uma autora descreveu um teste planejado para o próximo hackathon. Um domínio receberia Rego em um PDP baseado em OPA; outro receberia uma política baseada no RFC 9061 para estabelecer um túnel IPsec entre nós específicos. A experiência proposta é boa para mostrar distribuição heterogênea. Para provar a fronteira de governança, ela precisaria mostrar também o registro de autorização em cada lado antes da instalação. A mensagem não traz resultado de um teste concluído.

O Datatracker do IETF lista o documento como rascunho individual ativo, estado I-D Exists. A redação ainda é uma proposta. O risco descrito no próprio texto é claro: em ambientes multidomínio pode não haver certeza de que uma fonte conhecida está autorizada a definir política para uma área particular.

O recibo certo precisa sobreviver à troca de versão

O rascunho permite que o PAP mantenha revisões anteriores em controle de versão externo e que eventos de criação, atualização, ativação, reversão e retirada sejam lançados em um registro append-only. Ambos são MAY. Para uma auditoria real, o registro precisa ligar cada revisão exata à assinatura, à declaração de dono, à delegação aceita pelo destinatário, ao alvo de instalação e à medida de retirada. Sem essa costura, uma empresa consegue provar que recebeu uma regra, mas não por que deixou a regra mandar.

O RFC 2904 organiza funções de autorização há décadas. A questão atual é menos elegante e mais concreta: quem assina o aceite da política no domínio receptor e onde fica o documento que sustenta esse aceite?

Fontes