Quali sono le linee guida per l'ambiente di buona firma del codice? [chiuso]

3

Prendi questo scenario come esempio: un'organizzazione ha pochi build server che controllano periodicamente l'origine da un repository e costruiscono tutto. Al termine di una compilazione, i file binari vengono firmati e archiviati in codice e talvolta pubblicati sul pubblico insieme alle firme e al certificato pubblico.

Supponendo che:

  • Il certificato EV privato viene memorizzato su un token hardware connesso al server di firma, presumibilmente in un ambiente fisicamente sicuro (ambiente di firma del codice).
  • il server sarebbe probabilmente basato su Linux.

Quali precauzioni sono appropriate per un server di firma di questo tipo, HSM o altro.

  • Se l'ambiente della firma si trova dietro una porta chiusa accessibile solo con un badge identificativo.
  • Potrebbe essere sufficiente negare una semplice accessibilità fisica (posizionare l'ambiente di firma in una scatola ventilata e fisicamente sicura?
  • Quali sono le considerazioni su come dovrebbe essere fisicamente sicuro l'ambiente?
  • Una sala server bloccata sarebbe sufficientemente sicura?
  • Quando è sbagliato avere un server di firma del codice connesso alla rete aziendale? (Per fornire l'accesso ai server di compilazione)
  • Le sessioni ssh basate su chiave sono sufficienti per proteggere le comunicazioni tra i build server e il server di firma sulla rete aziendale?

Grazie!

    
posta Whome 16.11.2015 - 14:51
fonte

1 risposta

3

Il principio principale da considerare è questo: la chiave privata non dovrebbe mai spostarsi.

In nessun modo l'ambiente di firma del codice deve essere accessibile all'ambiente di build / test. Se l'ambiente di sviluppo può soddisfare direttamente le richieste di firma del codice significa compromettere l'ambiente di build / test (uno spazio con un'enorme superficie di attacco) comprometterebbe la firma del codice.

Il codice da firmare deve essere ricollocato nell'ambiente di firma, la chiave non può essere spostata nell'ambiente di generazione.

Una soluzione che posso pensare è che il sistema di generazione pubblichi artefatti di build qualificati e un custode delle chiavi (una persona reale) per ottenere tali artefatti di build, firmarli nell'ambiente di firma e quindi pubblicare le risorse utente firmate in un repository di risorse.

Preferibilmente l'ambiente di firma sarebbe fisicamente isolato, ma per ragioni di lavoro il livello di protezione che si pone su di esso non deve superare il rischio di esposizione chiave moltiplicato per il costo dell'esposizione chiave. L'ambiente di firma in uno scenario a rischio molto basso (hai solo la firma del codice per la convenienza dell'implementazione e accetti il rischio di danno alla reputazione e responsabilità legale se malintenzionato) potrebbe essere la stazione di lavoro del custode chiave se sufficientemente protetta.

    
risposta data 16.11.2015 - 17:26
fonte