Condividi tramite

Proteggere l'ambiente di sviluppo per Zero Trust

Questo articolo consente, come sviluppatore, di proteggere l'ambiente di sviluppo in modo da poter implementare i principi Zero Trust (verificare in modo esplicito, usare l'accesso con privilegi minimi, presupporre la violazione). Incorpora i contenuti dell'eBook Protezione degli ambienti DevOps aziendali ed evidenzia le migliori pratiche per la sicurezza dei rami e la fiducia negli strumenti, nelle estensioni e nelle integrazioni.

La velocità dello sviluppatore si basa sulla capacità di lavorare su come e dove si vogliono ottimizzare i risultati aziendali. Desideri macchine potenti e personalizzabili con accesso root o amministratore. Tuttavia, le richieste degli sviluppatori possono contrastare con le normative di conformità e la necessità di verificare e controllare l'accesso e l'archiviazione nell'ambiente privato dei dipendenti.

I computer non gestiti che si connettono alla rete dell'organizzazione sfidano i team di sicurezza, l'approvvigionamento e il consiglio di governance. La possibilità migliore di fornire agli sviluppatori ambienti di lavoro predefiniti e protetti per i dipendenti crea disprezzo da entrambe le parti. Quando i dipendenti si connettono da qualsiasi luogo, le reti Wi-Fi vulnerabili sono una porta aperta per il cyberattacco. Il furto e la perdita di hardware sono importanti preoccupazioni.

Le vulnerabilità si estendono alle integrazioni dell'ambiente di sviluppo. Gli strumenti di sviluppo che presentano un'estendibilità avanzata potrebbero avere integrazioni non mantenute nei marketplace. Le estensioni dannose possono mettere in pericolo gli strumenti di sviluppo e causare violazioni a livello aziendale.

Nel diagramma seguente si noti che l'ambiente di sviluppo si connette all'ambiente degli strumenti DevOps per influire sui rami Git. Estende la superficie dell'ambiente attraverso la connessione a pacchetti open source ed estensioni dell'applicazione. Le estensioni presentano vulnerabilità nelle vulnerabilità delle applicazioni di dipendenza e estensione.

Diagramma che illustra gli ambienti di sviluppo e le minacce alla sicurezza.

Offrire ai membri del team DevOps flessibilità e controllo, impedendo attacchi dannosi è una sfida fondamentale per gli uffici di sicurezza. DevOps può controllare l'ambiente di sviluppo con un ambiente cloud (vedere Avvio attendibile per le macchine virtuali di Azure e GitHub Enterprise Cloud Docs) e proteggere l'ambiente di sviluppo con contenitori (vedere la documentazione di GitHub Codespaces).

Inoltre, gli sviluppatori possono implementare le misure Zero Trust seguenti per proteggere l'ambiente di sviluppo:

  • Configurare i privilegi minimi.
  • Limitare chi può modificare e approvare il codice con la sicurezza del branch.
  • Adottare solo strumenti, estensioni e integrazioni attendibili.

Procedure consigliate per privilegi minimi

Gli sviluppatori spesso credono che possano rilevare malware, phishing e violazioni nei loro ambienti. Le ampie superfici di minaccia negli ambienti di sviluppo rendono irrealistico per gli sviluppatori mantenere una conoscenza onnipresente del sistema. Un'organizzazione perde tempo prezioso per la correzione quando rileva una violazione dopo un attacco compromette un ambiente sviluppatore con accesso amministratore a tutti i sistemi.

Per rimediare alle potenziali opportunità di accesso che attirano attori malintenzionati al ruolo di sviluppatore software, prendere in considerazione le seguenti procedure di sicurezza Zero Trust con privilegi minimi per le app.

  • Implementare il principio del privilegio minimo e l'accesso just-in-time per DevOps. Assicurarsi che i membri del team mantengano solo l'accesso minimo agli ambienti per il tempo più breve richiesto. Inserire i criteri per coprire i diritti di accesso degli amministratori nei dispositivi principali, gli strumenti DevOps, le pipeline di versione, i repository di codice, gli ambienti, gli archivi segreti e i database. Per i team DevOps, il requisito di base è una connessione all'archivio delle identità dell'organizzazione. Usare la federazione delle identità per l'integrazione con ambienti SaaS per evitare la duplicazione delle identità nelle piattaforme non Microsoft e ridurre il rischio di esposizione.
  • Non usare token di accesso personali per l'accesso al codice sorgente. Le procedure sicure per i team DevOps includono l'accesso a strumenti DevOps basati su SaaS, repository di codice (tramite SSH, HTTPS o token di accesso personale). Per l'accesso all'ambiente basato su SaaS, sono disponibili istruzioni chiare sul modo in cui i principi di accesso determinano chi può scaricare (clonare) i repository di codice dei sistemi e da quali dispositivi (locale, cloud e contenitore). Ad esempio, OneDrive può bloccare o limitare l'accesso ai dispositivi non gestiti.
  • Standardizzare e sincronizzare gli account utente di GitHub Enterprise Managed User (EMU) con le identità aziendali. Con Gli utenti gestiti dall'organizzazione è possibile controllare gli account utente dei membri dell'organizzazione tramite il provider di identità (IdP). Nell'archivio delle identità della tua organizzazione, definisci esplicitamente i nomi utente di GitHub, le email e i nomi visualizzati. Gli utenti identificano quindi facilmente i collaboratori.
  • Per i tre modi in cui uno sviluppatore può connettersi a un ambiente SaaS (HTTPS con un'identità, un token di accesso personale, connettersi con la chiave SSH), stabilire connessioni con l'archivio delle identità dell'organizzazione. Con GitHub (ad eccezione degli account GITHub EMU), l'identità è sempre l'identità pubblica. L'accesso controllato tramite Single Sign-On (SSO) richiede la connessione all'archivio delle identità dell'organizzazione.
  • Usare un'autorità di certificazione SSH per fornire certificati SSH firmati per i membri per accedere in modo sicuro alle risorse con Git. Un certificato SSH è un meccanismo che consente a una chiave SSH di firmare un'altra chiave SSH. GitHub Enterprise Cloud supporta i certificati SSH per offrire alle organizzazioni un maggiore controllo sul modo in cui i membri accedono ai repository. Gli amministratori possono caricare la chiave pubblica della CA SSH e rilasciare certificati per i membri da usare per l'autenticazione Git. I certificati possono accedere solo ai repository appartenenti all'organizzazione. Gli amministratori possono richiedere ai membri di usare i certificati quando accedono ai repository.
  • Usare un gestore credenziali Git per rafforzare l'accesso al codice. Gli strumenti come Visual Studio (VS) dispongono del supporto predefinito per le identità. VS Code si affida a un gestore di credenziali Git.

Procedure consigliate per la sicurezza dei rami

Quando gli attori malintenzionati ottengono l'accesso al repository di codice, possono studiare la sicurezza del sistema e modificare il codice senza che i team notino. Per impedire l'accesso al repository di codice non autorizzato, implementare una strategia di diramazione per stabilire il controllo sulle modifiche al codice (vedere l'esempio illustrato nel diagramma seguente).

Diagramma illustra una strategia di diramazione di esempio che protegge il repository principale.

Per correggere le potenziali opportunità di accesso al repository, prendere in considerazione le procedure consigliate per la sicurezza dei rami seguenti.

  • Proteggere i rami con revisioni del codice per fornire ai team DevOps il controllo sulle modifiche del codice e sui progressi di controllo. La strategia di diramazione nel diagramma precedente descrive un flusso controllato di modifiche che offre una chiara catena di comandi e progetti per gestire le modifiche al codice. Tra i diversi approcci per la strategia di diramazione, un elemento comune è che i rami protetti servono come origine per le nuove versioni nell'ambiente di produzione.
  • Gli amministratori dei repository Git hanno il controllo sulle autorizzazioni di approvazione. Il meccanismo di controllo delle strategie di diramazione si trova nel flusso di lavoro di approvazione. I rami protetti richiedono convalide, revisioni e approvazioni prima di accettare le modifiche. Un'opzione consiste nel creare una regola di protezione dei rami per applicare i flussi di lavoro. Ad esempio, è necessario una verifica di approvazione o il superamento del controllo dello stato per tutte le richieste pull unite nel ramo protetto. Le politiche dei rami aiutano i team a proteggere importanti rami di sviluppo. Le politiche applicano gli standard del team sulla qualità del codice e sulla gestione delle modifiche.

Procedure consigliate per l'attendibilità di strumenti, estensioni e integrazioni

L'estendibilità negli ambienti di sviluppo integrati (IDE) è così produttiva che è essenzialmente una funzionalità obbligatorio. Ci si basa sulla possibilità di applicare e curare le estensioni all'interno del marketplace di un IDE specifico per progettare l'ambiente di lavoro ottimale.

Per correggere gli IDE sicuri, prendere in considerazione gli strumenti, le estensioni e le procedure consigliate per l'integrazione seguenti.

  • Assicurarsi di integrare solo gli strumenti di marketplace e editori attendibili. Ad esempio, il marketplace di VS Code include migliaia di estensioni per semplificare la vita. Tuttavia, quando i team adottano nuovi strumenti o estensioni, l'aspetto più importante può verificare l'attendibilità di un editore.
  • Configurare procedure sicure per controllare l'uso dell'estensione per limitare la superficie di attacco degli ambienti di sviluppo. La maggior parte delle estensioni IDE richiede l'approvazione di determinati privilegi per funzionare, spesso come file con autorizzazioni di lettura per il sistema per analizzare il codice. Le estensioni richiedono connessioni agli ambienti cloud per funzionare (comuni negli strumenti di metrica). L'approvazione di funzionalità aggiuntive all'interno dell'IDE apre le organizzazioni a più minacce.
  • Nei computer di sviluppo tenere traccia del numero e della maturità delle estensioni usate per comprendere la potenziale superficie di attacco. Utilizzare solo le estensioni del marketplace di VS Code da pubblicatori verificati. Quando si installano le estensioni dell'applicazione con VS Code, controllare regolarmente le estensioni in esecuzione con la riga di comando, il codice --list-extensions --show-versions. Avere una buona conoscenza dei componenti estendibili in esecuzione nell'ambiente di sviluppo.

Passaggi successivi

  • Last updated on