Resumen

  • RFC 1447 identificaba cada fila de acceso mediante la parte destino, la parte sujeto y el contexto de recursos; las clases PDU permitidas quedaban en otro campo.
  • Reconocer o autenticar una parte era anterior a la autorización local que se aplicaba al recibir una comunicación concreta.
  • VACM sustituyó la arquitectura original, pero siguió exigiendo relacionar principal, contexto, condiciones de seguridad, tipo de vista y objeto individual.

Una identidad no contestaba cuatro preguntas

La Party MIB se publicó en abril de 1993 dentro del primer marco SNMPv2. Una party era un entorno virtual de ejecución limitado administrativamente a parte de las operaciones posibles de una entidad. No equivalía sin más a una persona, una empresa o una dirección de red.

Una entidad podía realizar varias partes con atribuciones solapadas o separadas. También podía conservar información sobre una parte remota que no ejecutaba localmente. El identificador señalaba una entrada administrativa; no transportaba una credencial universal de administrador.

RFC 1447 plasmó esa cautela en aclTable. La clave de una fila contenía aclTarget, aclSubject y aclResources. El destino nombraba a la parte que debía realizar la operación; el sujeto, a la parte que la solicitaba; los recursos, al contexto SNMPv2 sobre el cual recaía la solicitud.

Después de localizar esa terna, aclPrivileges indicaba las clases de comunicación admitidas. El permiso no pertenecía al sujeto aislado. Pertenecía a una relación dirigida, dentro de un espacio de objetos y para determinados verbos.

Los bits describían verbos, no prestigio

El campo de privilegios sumaba valores asociados a los tipos PDU. Get valía 1; GetNext, 2; Response, 4; Set, 8; GetBulk, 32; Inform, 64; y SNMPv2-Trap, 128. Cero representaba el conjunto vacío. El valor predeterminado, 35, autorizaba Get, GetNext y GetBulk.

No había una escala donde 35 fuese más poderoso que 34 por una unidad. Cuarenta y tres añadía Set al mismo conjunto de lectura; cuatro reservaba Response. Interpretar la política exigía descomponer el entero y saber a qué terna pertenecía.

Los ejemplos iniciales mostraban políticas diferentes por dirección. Una parte del gestor podía enviar consultas de lectura a una parte agente. La fila inversa permitía respuestas y traps. Poder preguntar no otorgaba automáticamente poder para responder, y ninguna dirección incluía escritura si faltaba Set.

Por eso una consola puede abreviar 35 como «lectura», pero no debería traducirlo a «de confianza». La confianza borra el destino, el contexto, el sentido del mensaje y el verbo concreto que sostenían el permiso.

El receptor conservaba la decisión

RFC 1445 aplicaba el control de acceso al recibir la comunicación, no al transmitirla. El emisor construía la fuente, el destino, el contexto y la PDU y enviaba el mensaje sin ejecutar la política local del receptor.

Al llegar, la entidad examinaba por separado el destino, la fuente, el resultado de autenticación, el contexto y la relación de acceso. Sólo después comparaba la clase de comunicación con los privilegios de la fila.

El orden impedía una conclusión cómoda. Un mensaje bien codificado podía indicar un destino desconocido. Un destino conocido podía recibir una fuente desconocida. Una fuente auténtica podía pedir un contexto inexistente. El contexto podía existir sin una entrada ACL adecuada. La entrada podía conceder Get pero no Set.

Dos receptores también podían conocer el mismo sujeto y decidir de forma distinta, porque sus destinos locales, contextos, vistas y filas no eran los mismos. El remitente controlaba lo que solicitaba; no podía fabricar la autorización vigente del otro extremo mediante un paquete válido.

El contexto mantenía visible el ámbito

Un contexto SNMPv2 reunía recursos gestionados. Si eran locales, remitía a una vista MIB; si eran remotos, podía expresar una relación proxy. Así, el mismo sujeto y destino podían tener permisos diferentes según el contexto, y el mismo verbo Set podía referirse a superficies de objetos distintas.

«Puede leer» seguía siendo una frase incompleta. Había que decir en qué contexto, frente a qué destino y dentro de qué vista. La admisión de la clase PDU no eliminaba el límite de los objetos accesibles.

También limitaba el significado de una ausencia. No ver una variable en un contexto no probaba que la variable no existiese, que todos los demás contextos la ocultasen o que otro sujeto careciese de permiso. Era el resultado de una relación local en un momento administrativo.

La política podía desaparecer o no estar activa

Una fila ACL incluía aclStorageType y aclStatus. Podía ser volátil, no volátil o permanente, y su ciclo de vida se expresaba mediante RowStatus. Estar visible en la tabla no garantizaba actividad, supervivencia tras el reinicio ni capacidad de edición.

La historia general de RowStatus ya pertenece a otra pieza. En RFC 1447 subraya algo más específico: la autoridad que gobernaba el tráfico de gestión era a su vez estado gestionado. Un mensaje SNMP podía modificar los objetos que decidirían el destino de mensajes posteriores.

Una respuesta positiva a un Set sobre la ACL no demostraba todavía que la siguiente solicitud fuese autorizada bajo la relación prevista. Había que conservar los valores enviados, la respuesta, el estado de fila, las dependencias activas y una nueva prueba en recepción. La persistencia requería otra observación tras el límite temporal pertinente.

VACM reorganizó la relación

El modelo basado en parties pasó a ser histórico. RFC 2575 y luego RFC 3415 definieron VACM para la arquitectura modular de SNMP. El camino cambió: modelo y nombre de seguridad se asociaban a un grupo; grupo, contexto, modelo y nivel de seguridad seleccionaban una entrada; leer, escribir o notificar elegía una vista; la variable concreta se comprobaba dentro de ella.

VACM distinguía errores como contexto inexistente, grupo ausente, entrada de acceso ausente, vista inexistente y objeto fuera de vista. Todos podían acabar pareciendo una denegación, pero señalaban un enlace diferente de la decisión.

Party MIB y VACM no son la misma tabla ni ofrecen garantías idénticas. Su continuidad es conceptual: saber quién actúa no determina por sí solo dónde, con qué protección, mediante qué clase de operación ni sobre qué objeto puede actuar.

La autoridad simbólica no era el efecto gestionado

La primacía del código en ejecución de Lu Heng separa especificación, implementación, validación, despliegue y uso. Su lectura de las capas de realidad mantiene aparte el rango simbólico y la consecuencia ejecutable. RFC 1447 permite aplicar ese lente sin convertirlo en doctrina del IETF.

El identificador de party pertenecía a la identidad. La fila ACL declaraba política local. El procesamiento de recepción la ejecutaba. La respuesta registraba un resultado de protocolo. El estado de una interfaz, un contador o una ruta pertenecía a una observación posterior.

Una parte conocida no probaba autorización. Una fila presente no probaba que estuviera activa. Un Set admitido no probaba efecto correcto ni persistencia. Una lectura devuelta no probaba exactitud semántica. Conservar cada límite hace que la evidencia sea más útil, no menos.

La Party MIB es histórica. Su lección operacional permanece: la autoridad puede auditarse mientras sigue unida a la relación que la produjo; se vuelve opaca cuando se adhiere a una identidad como si fuese un título nobiliario.

Fuentes