Firma delle richieste API con una chiave privata: questo scenario di consegna delle chiavi è sicuro?

if C finds out D's X-USERNAME then they can access D's data which seems even less secure than userID/password.

Possono? B potrebbe generare un certificato separato per ogni cliente che può essere utilizzato solo per accedere ai propri dati. L'intestazione X-Username potrebbe semplicemente essere metadata. Ma potresti voler provare questo per essere sicuro. Soprattutto quando non chiedono per quale cliente devono firmare il certificato.

L'azienda A come fornitore di software dovrà assicurarsi di:

Con certificato incorporato:

• A invia un CSR separato a B con una chiave diversa per ogni cliente C e D.
• A incorpora la rispettiva chiave privata nell'eseguibile prima consegna a C o D. Questo espone la chiave privata durante la consegna.

Senza certificato fornito (soluzione alternativa)

• Il cliente stesso archivia una CSR con la sua chiave generata su B
• A fornisce il software senza una chiave ma il requisito per importa una chiave prima dell'uso.

In entrambi i casi, la chiave privata non dovrebbe mai passare a B. Questo non è un requisito: basta firmare la chiave pubblica. La soluzione alternativa è più solida con molti clienti e prende il rischio di perdite chiave dalla società A.

Non provare nemmeno ad autenticare le applicazioni, basta autenticare gli utenti! E se si desidera una seria procedura di gestione PKI, una chiave privata dovrebbe sempre essere sotto il controllo esclusivo del suo proprietario: è un requisito fondamentale per il non ripudio. Se A costruisce il CSR e dopo averli firmati B li consegna a C e D, un amministratore di una società potrebbe conservare una copia delle chiavi private e successivamente eseguire qualsiasi operazione per conto di C e D.

L'uso forzato del software di una società dovrebbe essere curato a livello legale, non a livello tecnico. Solo l'autenticazione C e D dovrebbe essere garantita dai certificati.

Se ritieni che i tuoi requisiti di sicurezza consentano a un'azienda di creare le chiavi private per C e D, la mia comprensione è che hai solo bisogno di autenticazione tramite password e l'utilizzo di PKI è eccessivo e non aggiunge ulteriore sicurezza.

Quello che segue non è altro che la mia opinione su quale possa essere una possibile via. Innanzitutto, la creazione di un certificato completo su A (inclusa la chiave privata) e l'invio come file PKCS12 a C e D è decisamente una cattiva pratica e dovrebbe essere evitata. Ma poiché A fornisce ai suoi clienti un software desktop, la generazione del certificato potrebbe essere inclusa nella procedura di installazione:

• la procedura di installazione genera una coppia di chiavi (automaticamente, con l'aiuto della libreria OpenSSL)
• chiede al cliente un ID (ad esempio un numero di licenza), un nome e li include in un CSR
• il CSR viene inviato ad A (con HTTPS), firmato automaticamente da A dopo che l'ID è stato controllato e il certificato (senza la chiave) è memorizzato da A indicizzato dall'ID. Se un vecchio certificato è stato associato a tale ID, viene revocato (in base ai requisiti aziendali, questa parte potrebbe richiedere una procedura manuale ...)
• il certificato firmato da A viene restituito alla procedura di installazione
• la procedura di installazione memorizza il certificato nell'archivio di sistema (assumendo Windows qui) - l'utente è normalmente richiesto per validare il controllo dell'account utente

Una volta fatto questo, il client ha un certificato firmato da A e la chiave non ha mai lasciato la macchina client

Da un altro lato, A fornisce a B un proprio certificato di firma (non la chiave!) e un indirizzo di lista di revoche di certificati o un altro modo per controllare se un certificato è stato revocato

Quando un cliente desidera utilizzare il servizio Web da B con un software, può autenticare la sua connessione HTTPS con il suo certificato - Un software sa come usarlo perché è stato installato dalla procedura di installazione. B può convalidare il certificato con quello di A e persino controllare che il certificato non sia stato revocato.

La separazione della responsabilità è:

• A è responsabile per l'infrastruttura PKI: firma dei certificati dei clienti, mantenimento di un CRL e dell'elenco dei clienti
• B è responsabile per il suo servizio web. Si affidano ad A per la sicurezza dei certificati (link certificate < - > customer)
• C & D sono responsabili per la sicurezza della propria chiave privata. Dovrebbero essere in grado di chiedere un nuovo certificato se viene compromesso di aver perso riavviando (parte) la procedura di installazione. In quel caso, il precedente dovrebbe alimentare il CRL

Poiché solo le procedure automatiche sono coinvolte nella generazione dei certificati, siamo ancora lontani dai veri requisiti di non ripudia e il programma di installazione richiederà un po 'di lavoro, ma:

• questo si basa su protocolli e protocolli X509 standard
• le responsabilità o A, B e C & D sono chiare