Mantenere i segreti fuori dai repository e ripulire sistematicamente le fughe di dati.
I segreti devono essere conservati in un repository controllato; in caso di fuga di dati, sono essenziali il blocco immediato, la sostituzione, la verifica dell'ambito e la documentazione della pulizia.
"Come tenere i segreti fuori da Git e come eliminarli" viene esaminato qui dal punto di vista della "Protezione dei segreti e analisi forense delle implementazioni". Per gli sviluppatori e i responsabili di progetto tecnici, il "Blocco immediato" e la "Solo pulizia della cronologia" sono particolarmente importanti.
Pubblicato: 3 minuti di lettura · Autore: Sebastian Geier
Cosa fare, e in quale ordine, dopo aver inserito accidentalmente un segreto nel repository?
Un segreto inserito nel repository viene immediatamente revocato o ruotato. Successivamente, vengono analizzati l'utilizzo e l'accesso prima che la cronologia venga pulita e il rilevamento dei segreti venga abilitato per i nuovi commit.
Caso di implementazione: "Solo pulizia della cronologia"
Una chiave API compare in un file di configurazione. La chiave viene prima ruotata presso il provider e i relativi accessi vengono verificati; solo successivamente la cronologia viene riscritta e il file sostituito con un esempio sicuro e con l'archiviazione segreta.
Pulizia della cronologia
Pulizia della cronologia – Fork, cloni o cache contengono ancora una chiave valida.
Utilizzo sconosciuto – La rotazione senza controllo dei log non rileva un precedente utilizzo improprio e non ne gestisce gli effetti o gli accessi successivi.
Perdita di dati ripetuta – Il nuovo valore viene nuovamente applicato tramite lo stesso file di configurazione.
Analisi della portata
Bloccare la chiave, distribuire le chiavi sostitutive in modo controllato e stabilizzare i sistemi interessati.
Verifica dei log di accesso, delle autorizzazioni, dei fork e degli artefatti per l'ambito.
Pulizia della cronologia e chiusura del percorso di accesso originale tramite scanner e regole di archiviazione.
Protezione permanente.
Segnale di controllo
Segnale 1
Tempo intercorso tra il rilevamento e l'invalidazione comprovata del segreto.
Segnale di controllo
Segnale 2
Nuove scoperte di segreti per origine, livello di protezione interessato e tempo rimanente fino al completamento della rotazione.
Blocco immediato.
Criterio di test
Blocco immediato.
Il metodo di accesso interessato può essere invalidato indipendentemente dalla pulizia del repository.
Criterio di test
Analisi della portata
Log, autorizzazioni e copie mostrano dove il valore era accessibile o utilizzato.
Protezione permanente. – L'ispezione locale e la protezione anti-spam rileveranno tempestivamente la stessa classe di segreti in futuro.
Domande correlate e prossimi passi
Una domanda di approfondimento pertinente con relativa risposta Proteggere le modifiche al database insieme alle modifiche al codice."Come si possono implementare le migrazioni di database senza rischiare di collegarle a modifiche del codice? "
Un secondo link per "Proteggere i segreti da Git e ripulire la cronologia" porta a Rilevare tempestivamente le discrepanze di configurazione tra ambienti.Questo post rimane incentrato sulla domanda: "Come si rilevano le discrepanze di configurazione tra ambienti prima che causino problemi? "
Se si desidera mettere in pratica "Proteggere i segreti da Git e ripulire la cronologia", è possibile fare riferimento a Sistemi web robusti Questo articolo si concentra su "Protezione dei segreti e analisi forense delle implementazioni" e "Blocco immediato".
Conclusione: Proteggere i segreti da Git e ripulire la cronologia
Una perdita di dati è un evento di accesso, non solo un problema di Git. Il blocco e l'analisi della portata hanno la precedenza sulla pulizia superficiale della cronologia.
Fonti e ulteriori informazioni
Le seguenti fonti documentano le linee guida tecniche e metodologiche utilizzate per "impedire l'inserimento di segreti in Git e rimuoverli".
Framework per lo sviluppo sicuro del software, versione 1.1 – NIST SP 800-218Il framework NIST definisce pratiche verificabili per la protezione di ambienti di sviluppo, artefatti e credenziali di accesso.
Protezione delle modifiche (Push) – Documentazione di GitHubLa documentazione ufficiale di GitHub descrive il blocco, la delega, l'elusione e la gestione dei segreti rilevati.
Tesi chiave
La chiave interessata viene prima revocata o ruotata, quindi vengono esaminati l'accesso e l'utilizzo. Solo a questo punto la cronologia viene ripulita; le regole di protezione impediscono successivamente l'inserimento di nuove voci.
Cosa non riguarda
Eliminare un file o riscrivere la cronologia di Git non rende nuovamente segreto un metodo di accesso pubblicato.
Di cosa si tratta
Innanzitutto, il segreto viene reso inefficace; successivamente vengono eseguiti test di ambito, pulizia della cronologia e controlli di protezione continui.
Git, distribuzione e controllo qualità
Integrare efficacemente GitHub Push Protection nei flussi di lavoro reali.
"Mantenere i segreti fuori da Git e ripulirli" include, come controllo separato, la domanda: in che modo GitHub Push Protection diventa parte del flusso di lavoro anziché un semplice ostacolo?
Git, distribuzione e controllo qualità
Utilizzare Git come fonte autorevole anziché una copia aggiuntiva
Integra "Mantenere i segreti fuori da Git e ripulirli" con una decisione separata: quali regole rendono Git l'unica fonte affidabile per il codice dell'applicazione?
Panoramica degli Insight
Tutti gli Insight di VELUNO in sintesi
Ulteriori analisi sui sistemi web, la visibilità digitale e modelli di lavoro robusti.
Protezione permanente: decisione concreta successiva
Una breve procedura di emergenza dovrebbe documentare il provider, il proprietario, la fonte del log e il percorso di rotazione per ogni classe di segreti. Questo garantisce che la risposta non inizi solo dopo la successiva scoperta.