Domanda:
Quando posso eseguire il commit di una chiave privata nel controllo del codice sorgente?
Nathan Basanese
2015-11-18 08:20:57 UTC
view on stackexchange narkive permalink

Vale a dire, in quali casi ha senso eseguire il commit di una coppia di chiavi non crittografata nel controllo del codice sorgente interno come SVN o Git?

Domanda correlata che discute di una chiave privata crittografata: È una cattiva pratica aggiungere una chiave privata crittografata al controllo del codice sorgente?

Domanda correlata sui programmatori stackexchange: [Strategia per mantenere le informazioni segrete come le chiavi API fuori dal controllo del codice sorgente?] (Https://programmers.stackexchange.com/questions/205606/strategy-for-keeping-secret-info-such-as -api-keys-out-of-source-control)
Quando è il tuo ultimo giorno di lavoro.
//, ... o quando scrivere una lettera di dimissioni è troppo complicato.
Quando in realtà non ha bisogno di essere privato
Forse lo trasformerà nel tuo ultimo giorno di lavoro.
Cinque risposte:
#1
+46
thexacre
2015-11-18 08:33:44 UTC
view on stackexchange narkive permalink

Quando la chiave privata non è altro che un dispositivo di prova utilizzato per testare alcuni processi che richiedono una chiave privata e in cui la chiave privata non è effettivamente utilizzata per proteggere alcun sistema.

In alcuni casi può essere appropriato eseguire il commit di una chiave crittografata . Ad esempio, se il repository è pubblico / open source ma un sistema di integrazione continua richiede l'accesso a quel file: Travis CI lo supporta.

Altrimenti non dovresti eseguire il commit delle chiavi private.

CI è un acronimo un po 'difficile per Google; presumibilmente non significa informatore riservato? Potresti chiarirlo a beneficio dei laici che sono finiti qui attraverso la barra laterale di HNQ?
CI qui è l'integrazione continua. È un server progettato per creare / testare ogni modifica al codice effettuata in un repository software. Maggiori informazioni su https://en.wikipedia.org/wiki/Continuous_integration
Avrebbe più senso generare una chiave casuale all'inizio del lavoro CI e distribuire quella chiave dove deve essere distribuita. Ciò impedirebbe alla stessa chiave unica di diffondersi in un sistema di produzione quando è già utilizzata in altri luoghi.
@SpaceTrucker che non è pratico quando la chiave nel repository viene utilizzata per l'autenticazione dell'API o della distribuzione. Nel caso di Travis CI tutto deve essere nel repository pubblico, comprese le chiavi di distribuzione.
#2
+38
Peter Green
2015-11-18 16:50:36 UTC
view on stackexchange narkive permalink

In generale, mescolare codice e configurazione segreta (password, chiavi ecc.) nello stesso repository è una cattiva idea perché generalmente molte più persone hanno bisogno (o almeno trarrebbero vantaggio) dell'accesso al codice rispetto a quelle necessarie per accedere a un dato segreto . Anche il flusso di lavoro comune con i sistemi VCS è creare molte copie.

Ciò non significa che non puoi inserire la configurazione segreta in un VCS ma dovrebbe essere un repository separato dal tuo codice e accedervi dovrebbe essere controllato molto strettamente.

//, mi piace che la prima frase di questa risposta mi offra uno strumento mentale per determinare quando e quando non farlo, in "generalmente molte più persone hanno bisogno (o almeno trarrebbero vantaggio) dell'accesso al codice di quante ne abbiano bisogno ogni dato segreto ". Ciò significa che posso basare la mia decisione su quanti devono accedere al codice rispetto a quanti devono accedere al segreto. Grazie, Peter.
+1. Se il codice necessita di una chiave per funzionare, potrebbe valere la pena includere chiavi di esempio in modo che un nuovo visualizzatore possa afferrare il codice e provarlo con meno passaggi (non è necessario generare alcuna chiave solo per la demo iniziale) e / o può ispezionare il formato per aiutare la comprensione, ma non metterei mai una chiave privata "reale" nello stesso repository, nemmeno un repository privato. Le chiavi private reali risiedono nel tuo sistema di controllo delle credenziali (che può essere / coinvolgere un repository VCS, ovviamente). Anche per i progetti pubblici assicurati che il codice faccia rumore quando viene utilizzata una chiave di esempio, altrimenti le persone potrebbero trascurare di generarne una nuova in seguito per un uso reale.
@DavidSpillett Mi piace l'idea della generazione del rumore
#3
+12
lorenzog
2015-11-18 17:12:26 UTC
view on stackexchange narkive permalink

Penso che quello che devi chiederti sia:

Se la chiave viene compromessa, posso rilevarla?

e

In che modo il processo di revoca influisce sulle altre persone?

Ad esempio: cosa succede se il repository di controllo del codice sorgente interno viene portato al di fuori del perimetro dell'azienda, ad es. tramite un laptop degli sviluppatori? E se questo laptop viene rubato? E se fosse un dipendente scontento che ne fa una copia e la conserva sul proprio laptop personale?

In altre parole, la chiave può essere utilizzata per accedere a una risorsa pubblica e se sì cosa è il danno?

Se le tue pratiche di sviluppo richiedono la condivisione di una chiave privata, allora non è una chiave privata per definizione. Potresti pensare al motivo per cui questo sta accadendo e se dovresti prendere in considerazione il token di accesso per utente (ad esempio oAuth, una chiave API) o altre soluzioni.

#4
+4
SpaceTrucker
2015-11-20 14:05:23 UTC
view on stackexchange narkive permalink

Dal momento che questa risposta non è stata ancora data, sembra che sia necessario:

Mai mai. Davvero mai”.

Come già sottolineato, per definizione una chiave privata dovrebbe essere tenuta segreta. Ma il controllo del codice sorgente è fatto per condividere e rendere disponibili le informazioni (forse per un pubblico limitato, ma comunque).

Il motivo per cui potresti volerlo fare è solo perché non hai i processi di cui hai bisogno avere a posto. Anche se potresti voler utilizzare quella chiave per qualche sistema di test che verrà cancellato dopo ogni esecuzione di test, probabilmente non imponi le tue intenzioni. Le intenzioni decadranno nel tempo e ad un certo punto la chiave verrà utilizzata nella produzione.

//, mi piace l'idea qui che un "decadimento" delle intenzioni sia qualcosa da cui guardarsi, o da considerare in un modello di sicurezza.+1
#5
+2
Cort Ammon
2015-11-20 08:55:00 UTC
view on stackexchange narkive permalink

Quando si eseguono analisi crittografiche per cose come gli attacchi Man in the Middle, è tipico definire le parti in base alla loro conoscenza. Quindi le tecniche per consentire ad Alice di parlare con Bob e consentire a Bob di credere che il messaggio provenisse da Alice definiscono Alice come "qualcuno che sa tutto ciò che è importante che Alice conosce".

Mettendo la chiave privata nel repository , ora devi eseguire tutte le analisi di sicurezza in cui la chiave privata è ora una chiave privata per "chiunque possa scaricare il repository o ottenerne una copia".

Se quel livello di sicurezza è sufficiente per il tuo chiave privata, quindi puoi metterla nel repository. Altrimenti, metterlo nel repository invaliderà qualsiasi prova di sicurezza che dipendeva dal fatto che la diffusione della chiave privata fosse più ristretta di quella.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...