Dove dovresti memorizzare / come dovresti controllare l'accesso ai segreti delle applicazioni?

Question

Dove dovresti memorizzare / come dovresti controllare l'accesso ai segreti delle applicazioni?

#1 da (3 voti)
#2 da (0 voti)

2

Ci sono queste domande rilevanti:

Strategia per mantenere le informazioni segrete come le chiavi API fuori dal controllo del codice sorgente
Come gestisci i file di configurazione nel controllo sorgente?
Come configurare i file di configurazione del controllo in modo pragmatico?

Ma per quanto posso dire, si occupano del lato opposto del problema. Quindi sì, abbiamo progettato una buona applicazione che non ha segreti memorizzati in esso o nel suo repository. Li estraggono dalle variabili di ambiente o dai file memorizzati nel sistema. Grande, fantastico, sicuro, vero?

Ma per quanto riguarda i nostri segreti ? Da dove vengono? Li archiviamo in un altro repository vcs? Esistono solo in un database crittografato?

Ovviamente vogliamo che gli sviluppatori abbiano i propri set di credenziali - ma avremo bisogno di avere le credenziali per i nostri server test / preprod / prod.

Come manteniamo questi sicuri? Ovviamente li vogliamo accessibili ai sistemi che ne hanno bisogno ...

security configuration

posta Wayne Werner 17.11.2015 - 16:49

fonte

2 risposte

0

I segreti come le credenziali di un database devono essere conservati in un file di configurazione locale, creato da te o trasmesso in modo sicuro.

risposta data 17.11.2015 - 17:09

fonte

Leggi altre domande sui tag security configuration

Alcune domande sull'implementazione di uno scheduler di prelazione in C: Cambio di contesto e tempo di esecuzione del dispatcher La scrittura di funzioni aritmetiche per consentire "type coercion" è una buona idea?

score 3 · Accepted Answer

Se ti stai chiedendo come gestire le tue chiavi, ci sono 2 posizioni per memorizzarle:

Per dev / test - potresti anche metterli nel repository SCM. A meno che il tuo repository non sia pubblicamente accessibile.

Per la produzione, si desidera archiviarli con un singolo punto di autorizzazione, sia qualcuno (con un vice) che mantiene gli originali su un CD o un'unità USB in un firesafe o simile.

Copie di questi possono essere date alle persone rilevanti che hanno bisogno di distribuirle. Quindi (ad es.) Un DBA che crea il DB e imposta gli account utente ad esso associati riceverà le password e gli account da utilizzare. Questo può essere inviato via email a lui, supponendo che ti fidi del tuo provider di posta elettronica, o consegnato un pezzo di carta che viene mangiato subito dopo se sei veramente paranoico.

In molti casi non è necessario essere abbastanza sicuri: il DBA può creare password e account utente da utilizzare, ma deve dire a qualcuno (preferibilmente il contatto che mantiene queste informazioni) che cosa erano in caso di incidente.

Altrimenti, si utilizzano le funzionalità del sistema operativo per proteggere i dettagli: la creazione di account tramite LDAP o AD o la creazione di file di certificato in directory protette e la garanzia che siano protetti in modo che solo gli account utente corretti possano accedervi.