Controllo dell'accesso basato su certificato per la messaggistica secondaria di Pub

Question

Controllo dell'accesso basato su certificato per la messaggistica secondaria di Pub

#1 da (0 voti)

1

Sto estendendo un framework Sub Pub p2p / master esistente per supportare misure di sicurezza aggiuntive, tramite la crittografia over the wire e il controllo degli accessi basato su argomenti. Mi piacerebbe utilizzare i certificati x.509 che io genero per i nodi per comunicare su TLS per includere anche le politiche specifiche sull'argomento del nodo; Limiti a quali argomenti il certificato può essere utilizzato per iscriversi o pubblicare con.

L'idea corrente è tale:

Bootsrap
- keyserver & master avviato
- grafico a livello di grafico caricato in keyserver
- i nuovi nodi senza certificati richiedono keyserver
- keyserver cerca i sottocomponenti pub che corrispondono allo spazio dei nomi del nodo
- keyserver restituisce nodo un certificato con criterio secondario pub incorporato
Out in the wild
- viene avviato solo il master, nessun server delle chiavi
- i nodi avviati utilizzano il certificato esistente per registrarsi con il master
- il master registra l'editore o il sottoscrittore per gli argomenti richiesti
- (il master potrebbe provare ad applicare il criterio grafico qui, ma il master solo notifica agli iscritti dove si trovano gli editori, il trasporto dei messaggi per gli argomenti è ancora p2p)
- l'utente tenta di connettersi al publisher
- editore controlla scrupolosamente il certificato del sottoscrittore per verificare se dispone dell'autorizzazione per leggere l'argomento
- nel frattempo l'abbonato fa lo stesso, controllando che l'editore abbia il permesso di scrivere sull'argomento
- se la verifica dell'etere fallisce, la connessione viene rifiutata!

Mi piacerebbe utilizzare lo stile di sintassi globbing di apparmor per consentire agli utenti inesperti di generalizzare semplicemente il controllo degli accessi sui percorsi, questo può essere analizzato e ricercato abbastanza facilmente e quindi incorporare l'insieme delle politiche di matching nel cert come forse un ( human readable dai comuni cert viewer? multi-line indented ?) string. Un esempio potrebbe essere simile a questo:

criterio grafico:

nodes:
  /*:
    topics:
      /logout{,_agg}:
        allow: rw
  /listener{,1,2}/**:
    topics:
      /chatter:
        allow: r
  /talker:
    topics:
      /chatter:
        allow: w

criterio del nodo risultante per / listener:

topics:
  /logout{,_agg}:
    allow: rw
  /chatter:
    allow: r

In questo modo, se il nodo principale è mai compromesso (ma non il server di chiavi assente), i nodi in natura non possono essere ingannati a parlare o ascoltare qualcuno che non dovrebbe. Esiste un'estensione di certificato esistente che dovrei usare o un particolare modulo con cui dovrei incorporarli, oppure c'è solo un modo migliore per farlo?

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

posta ruffsl 22.06.2016 - 07:56

fonte

1 risposta

Leggi altre domande sui tag access-control openssl public-key-infrastructure tls x.509

Soluzione di condivisione file con flusso di lavoro di approvazione [chiuso] Perché devo reindirizzare per inviare il token di autenticazione OAuth2 esterno al client?

score 0 · Accepted Answer

Ok, per i posteri, ecco il mio approccio finale per chi arriva più avanti trovandolo, e si chiede cosa ho fatto mentre cercavo di non oscurare il carico utile della politica.

In sostanza ho utilizzato l'estensione Norme di certificazione per elencare le polizze applicabili al idenety. Ogni elemento nella lista contiene PolicyInformation structues l'identificatore della politica con i qualificatori della politica. I qualificatori della politica sono fatti per essere un elenco di stringhe di testo, con ogni sting che definisce uno scope dello spazio dei nomi applicabile usando la sintassi come la sintassi.

Ho usato un nidificazione di OID per mappare l'identificatore della politica a tali azioni come spazi dei nomi degli argomenti sottoscrivibili / negati consentiti, ecc. TTP: //github.com/ros/ros_comm/blob/e8568a493f039e6112884de733af00d289213a34/tools/rosgraph/src/rosgraph/sros_consts.py#L6-L8

Quando due peer si connettono, utilizzano il contesto del certificato dalla connessione TLS per acquisire i dati dell'estensione delle Politiche dei certificati dell'altro nodo. Prima che il client invii la richiesta API, ha esaminato l'estensione della politica del server per verificare che sia autorizzata a servire la chiamata API. Se lo è, procederà e se non terminerà la connessione.

Quando il server accettante analizza il metodo API richiesto, ha esaminato l'estensione della politica del client per verificare che sia autorizzato a richiedere la chiamata API. Se è, procederà e lo invierà, e se non terminerà la connessione.

Vengono eseguite alcune ottimizzazioni minori, come l'ordinamento del qualificatore prima dell'incorporazione, e successivamente la ricerca del qualificatore relativo alla politica di dening per trovare gli spazi dei nomi richiesti nella chiamata API prima di cercare il qualificatore di politica consentito, in modo da terminare prima le connessioni indesiderate.

Ci sono alcuni pro e contro nelle politiche di incorporamento nello stesso certificato utilizzato nel livello di trasporto. Lo tocco brevemente in un altro articolo qui sopra: SROS: protezione ROS su thewire, nel grafico e attraverso il kernel .