Control de acceso basado en certificados para mensajería de Pub Sub

Question

Control de acceso basado en certificados para mensajería de Pub Sub

#1 de ruffsl (0 votos)

1

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?

public-key-infrastructure tls access-control openssl x.509

pregunta ruffsl 22.06.2016 - 07:56

fuente

1 respuesta

Lea otras preguntas en las etiquetas public-key-infrastructure tls access-control openssl x.509

Cómo almacenar / procesar de forma segura la clave secreta para JWT ¿Los "paquetes de prueba de unidad" en iOS o Mac han sido un vector de ataque?

score 0 · Accepted Answer

Bien, para la posteridad, este es mi enfoque final para que alguien que venga más tarde encuentre esto, y se pregunta qué terminé haciendo al intentar no oscurecer la carga de la política.

Básicamente, utilicé la Certificate Policies para enumerar las políticas aplicables a la idenety Cada elemento de la lista contiene la información sobre políticas y la estructura del identificador de la política con los calificadores de la política. Los calificadores de políticas están hechos para ser una lista de cadenas de texto, y cada cadena define un ámbito de espacio de nombres aplicable utilizando una sintaxis de expresiones regulares.

Utilicé un anidamiento de OID para asignar el identificador de política a acciones tales como espacios de nombres de temas suscriptibles permitidos / denegados, etc. ttps: //github.com/ros/ros_comm/blob/e8568a493f039e6112884de733af00d289213a34/tools/rosgraph/src/rosgraph/sros_consts.py#L6-L8

Cuando dos pares se conectan, usan el contexto del certificado de la conexión TLS para adquirir los datos de extensión de Políticas de certificado del otro nodo. Antes de que el cliente envíe la solicitud de la API, examinó la extensión de la política del servidor para verificar que está autorizada para atender la llamada a la API. Si es así, continuará y si no finaliza la conexión.

Cuando el servidor que acepta analiza el método API solicitado, examinó la extensión de la política del cliente para verificar que esté autorizado para solicitar la llamada a la API. Si es así, procederá y lo enviará, y si no termina la conexión.

Se realizan algunas optimizaciones menores, como ordenar el calificador antes de incrustar, y luego buscar el calificador de la política relacionada de dening para los espacios de nombres coincidentes solicitados en la llamada a la API antes de buscar el calificador de política permitido, para terminar las conexiones no deseadas antes.

Hay algunas ventajas y desventajas en la incorporación de políticas en el mismo certificado utilizado en la capa de transporte. Me refiero a eso brevemente en un escrito adicional aquí: SROS: Asegurando ROS sobre el cable, en la gráfica y a través del núcleo .