Estoy extendiendo un marco p2p / master Pub Sub existente para admitir medidas de seguridad adicionales, a través del cifrado por cable y el control de acceso basado en temas. Me gustaría usar los certificados x.509 que genero para que los nodos se comuniquen a través de TLS para incluir también las políticas de temas específicos del nodo; es decir, limitar los temas con los que se puede usar el certificado para suscribirse o publicar.
La idea actual es como tal:
- Bootsrap
- servidor de claves & maestro iniciado
- política de todo el gráfico cargada en el servidor de claves
- los nodos nuevos sin certificados piden el servidor de claves
- keyserver busca una política secundaria de publicación que coincida con el espacio de nombres del nodo
- keyserver devuelve el nodo a un certificado con una política de sub-publicación integrada
- fuera en la naturaleza
- solo se inicia el maestro, no hay ningún servidor de claves
- los nodos iniciados utilizan el certificado existente para registrarse con el maestro
- los registros maestros publican o suscriben para los temas solicitados
- (el maestro podría intentar aplicar la política del gráfico aquí, pero el maestro solo notifica a los suscriptores dónde están los editores, el transporte de mensajes para los temas sigue siendo p2p)
- el suscriptor intenta conectarse al editor
- el editor examina el certificado del suscriptor para verificar que tenga permiso para leer el tema
- mientras que el suscriptor hace lo mismo, verificar que el editor tenga permiso para escribir en el tema
- si la comprobación de éter falla, la conexión se rechaza.
Me gustaría usar el estilo de sintaxis de globo de apparmor para permitir que los usuarios novatos simplemente generalicen el control de acceso a las rutas, esto se puede analizar y buscar fácilmente, y luego incrustar el conjunto de políticas coincidentes en el certificado como quizás una ( legible por humanos de los espectadores de certificados comunes? multilínea con sangría ?) cadena. Un ejemplo podría verse así:
política de gráficos:
nodes:
/*:
topics:
/logout{,_agg}:
allow: rw
/listener{,1,2}/**:
topics:
/chatter:
allow: r
/talker:
topics:
/chatter:
allow: w
política de nodo resultante para / listener:
topics:
/logout{,_agg}:
allow: rw
/chatter:
allow: r
De esta manera, si el nodo maestro alguna vez se ve comprometido (pero no el servidor de claves ausente), los nodos en la naturaleza aún no pueden dejarse engañar por hablar o escuchar a alguien que no debería. ¿Existe una extensión de certificado que deba usar o un formulario en particular con el que deba integrarlos, o hay una mejor manera de hacerlo?