Memorizzazione di crediti cliente da server di terze parti con accesso in lettura ad esso

3

Il nostro servizio fornirà un'automazione su un altro servizio. I clienti condividono con noi la password e il nostro staff fa il lavoro del cliente. Un altro lavoro funzionerà con i nostri agenti di lavoro (server remoto).

Quindi, abbiamo bisogno di accedere alle password in due punti: molti (10-15) pc remoti, quelli collegati al pool di lavoro da jenkins e il sito web dello staff.

Per gli agenti di lavoro possiamo usare la crittografia a chiave pubblica. Cifra i dati sul frontend, decrittalo solo in un momento di script. Funzionerà alla grande.

Ma come fornire accesso personale ai dati da parte del personale? Condividere la chiave privata è una pessima idea.

Creare un altro server, che ha decrittografato api è migliore, ma è anche pessimo.

Ecco i limiti:

  1. Il personale ha un limite di decrittazione al giorno (circa 20). Non può fare più lavoro.
  2. Vogliamo cambiare la chiave privata molto velocemente, se l'utente dello staff ha sparato
  3. È meglio crittografare i dati su un fronte.
posta punksta 27.12.2016 - 15:28
fonte

1 risposta

3

Stai cercando di capire come memorizzare in modo sicuro i valori segreti, ma usarli nella tua applicazione, e la risposta, in genere, è usare una sorta di sistema di gestione dei segreti .

Mi piacciono molto Turtles All The Way Down perché fa un buon lavoro di spiegazione del problema principale con la gestione dei segreti (tu devi autenticare il sistema e dove memorizzi tale password?), oltre a dare una panoramica delle più attuali soluzioni software attuali. È un po 'un lungo discorso, ma vale la pena guardare.

Personalmente, mi piace molto Vault per gestire questo tipo di situazioni. In poche parole, le password degli utenti vengono archiviate in un archivio dati crittografato; i tuoi amministratori di sistema e l'applicazione possono accedere a tali password effettuando una chiamata API a Vault. Queste chiamate API vengono registrate per scopi di controllo successivi e vengono autenticate tramite un sistema simile alla sessione, in cui si fornisce una password (ad esempio, ci sono un certo numero di opzioni di autenticazione) e si ottiene un token che viene memorizzato per l'uso normale, ma che scadranno periodicamente e potranno essere revocati in modo esplicito. Ciò impedisce a un utente malintenzionato che ottiene l'accesso al token di ottenere un accesso permanente e fa lo stesso per i dipendenti quando lasciano l'azienda. Questo è grosso modo il modo in cui funzionano anche altri sistemi di archiviazione basati su rete, come Keywhiz.

C'è un'enfasi molto importante sull'ultima parte del paragrafo precedente: un utente malintenzionato può utilizzare il token per accedere a tutte le password memorizzate degli utenti e quindi continuare a utilizzarle indipendentemente dal fatto che il token rubato sia scaduto o meno. Questo attacco si verifica perché memorizzi credenziali statiche (password). Se invece dovessi richiedere credenziali temporanee dai siti di terze parti, potresti restituire quelle ai tuoi utenti interni, impedendo loro di ottenere un accesso permanente senza accesso permanente a Vault. Vault ha il supporto per un certo numero di sistemi per farlo , ma sei limitato qui a ciò che l'altro supporto siti.

    
risposta data 27.12.2016 - 18:19
fonte

Leggi altre domande sui tag