Costruire un sistema "Hello, world!" basato su X.509 per stabilire la fiducia tra i server

1

Voglio costruire un sistema software distribuito con i seguenti elementi:

  • Un numero di lavoratori , che gestiscono dati potenzialmente sensibili ed eseguono codice per conto di un certo numero di clienti.
  • Un numero di clienti , che può inviare comandi ai lavoratori.
  • Un'autorità di fiducia centrale , che concede il diritto di eseguire azioni su un dato lavoratore a un cliente.

In un'operazione tipica, il client contatta l'autorità fiduciaria e richiede l'autorizzazione per eseguire un'operazione su un lavoratore. L'autorità fiduciaria dovrebbe autenticare il client e, se ha esito positivo, concedere l'autorizzazione. Il client si collegherebbe quindi al server worker e invierà il comando richiesto, presentando l'autorizzazione ottenuta in precedenza. Il server di lavoro potrebbe verificare la validità dell'autorizzazione per l'operazione richiesta e -se ha esito positivo- eseguirlo.

X.509 sembra una scelta naturale per questo tipo di problema e la soluzione più semplice che ho trovato è simile a questa:

  • L'autorità fiduciaria utilizza un certificato X.509 per distribuire le autorizzazioni ai client, firmandole con la chiave privata del certificato.
  • Il client trasmette l'autorizzazione firmata dall'autorità di fiducia al server di lavoro.
  • Il server di lavoro scarica il certificato pubblico dal server dell'autorità fidata e utilizza la sua chiave pubblica per convalidare l'autorizzazione fornita dal client.

Per implementarlo, fornirei un'API REST basata su HTTPS sul server dell'autorità attendibile. Utilizzando questa API, il server di lavoro può scaricare il certificato della chiave pubblica e validarlo localmente con un certificato di livello superiore (se è stato firmato da una CA). Utilizzando la chiave pubblica ottenuta in questo modo, il lavoratore può quindi convalidare un'autorizzazione ricevuta da un cliente.

Per ottenere un'autorizzazione, un client può utilizzare un altro endpoint dell'API sull'autorità di affidabilità, a cui fornisce tutti i dettagli rilevanti del comando e del server di lavoro specificati. Il trusted server risponderà quindi con un'autorizzazione firmata che il client può trasmettere al server worker.

(in tutti i passaggi precedenti presumo che la comunicazione tra tutte le parti possa essere protetta e convalidata utilizzando una qualche forma di TLS)

La mia domanda riguardo questa configurazione è triplice:

  • È un approccio ragionevole? In caso contrario, quale sarebbe?
  • Contro quali possibili scenari di attacco questo schema sarebbe vulnerabile?
  • Esistono implementazioni di riferimento open-source di tale sistema?
posta ThePhysicist 13.05.2017 - 16:17
fonte

1 risposta

3

x509 è un formato di file non un'architettura di applicazione.

Non è chiaro cosa stai chiedendo o intenzione di costruire realmente qui. Un servizio web HTTPS che utilizza i certificati client non è esattamente innovativo né addirittura esoterico. Sicuramente, se ti aspetti di costruire le tue capacità crittografiche, ti raccomanderei strongmente di ripensarci: sono disponibili ma sono estremamente difficili anche per gli esperti che implementano correttamente.

La maggior parte dei software open-source sono componenti piuttosto che modelli completi di infrastruttura distribuita.

Supponendo che si desideri semplicemente un servizio web HTTPS utilizzando i certificati client, la parte server impiegherà circa un'ora per configurare utilizzando (ad esempio) Apache, mod_ssl e un livello logico appropriato. Ciò che costituisce un livello logico adatto dipende da dove si desidera implementare l'autenticazione e l'autorizzazione. Se questo è fatto in Apache (con SSLOptions +SrdEnvVars ) , allora qualsiasi vecchio linguaggio di scripting farà (anzi potresti usare stunnel o stud davanti a un webserver generico piuttosto che mod_ssl all'interno di Apache).

Per i test - stunnel o perno forniscono un modo semplice per avvolgere le connessioni usando TLS e client certs (supponendo che tu non voglia usa solo un browser )

In termini di generazione di una "autorizzazione firmata", anche in questo caso è semplice - ma esiste un motivo per implementare un meccanismo di autorizzazione secondario in aggiunta alle funzionalità disponibili in TLS / x509? Se è possibile autenticare in modo affidabile il client e l'autorità di fiducia, quindi incorporare l'autorizzazione nel certificato cliente o semplicemente fornire mappature di identità agli autori degli agenti dall'autorità di fiducia.

    
risposta data 13.05.2017 - 16:42
fonte

Leggi altre domande sui tag