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). Include contenuti dell'eBook Protezione di ambienti DevOps aziendali ed evidenzia le procedure consigliate per gli strumenti, le estensioni e le integrazioni dei rami.

La velocità dello sviluppatore si basa sulla capacità di lavorare su come e dove si vogliono ottimizzare i risultati aziendali. Si vogliono computer potenti e personalizzabili con accesso radice o amministratore. Tuttavia, le richieste degli sviluppatori possono essere eseguite in contrasto con le normative di conformità e la necessità di controllare e controllare l'accesso e l'archiviazione dell'ambiente dei dipendenti privati.

I computer non gestiti che si connettono alla rete dell'organizzazione sfidano i team di sicurezza, l'approvvigionamento e il consiglio di governance. Lo scenario migliore per fornire agli sviluppatori ambienti dipendenti predefiniti e con protezione avanzata crea disprezzo su entrambi i lati. 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 come 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 vettori di attacco nelle vulnerabilità delle applicazioni di dipendenza e estensione.

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 queste misure Zero Trust per proteggere l'ambiente di sviluppo:

• Configurare i privilegi minimi.
• Limitare chi può modificare e approvare il codice con la sicurezza del ramo.
• 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 superfici di minaccia per gli sviluppatori di grandi dimensioni rendono irrialistica per gli sviluppatori mantenere la 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 correggere le potenziali opportunità di accesso che causano attacchi informatici al ruolo di sviluppatore software, prendere in considerazione le seguenti procedure consigliate per la sicurezza con privilegi minimi Zero Trust per le app.

• Implementare privilegi minimi e accesso JIT 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à su piattaforme di terze parti 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à dell'organizzazione definire in modo esplicito nomi utente, messaggi di posta elettronica e nomi visualizzati di GitHub. Gli utenti identificano quindi facilmente i collaboratori.
• Per i tre modi in cui uno sviluppatore può connettersi a un ambiente SaaS (HTTPS con identità, token di accesso personale, connessione con 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. Amministrazione 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. Amministrazione 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 rinvia a un gestore di credenziali Git.

Procedure consigliate per la sicurezza dei rami

Quando gli hacker 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).

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'unica commonality è che i rami protetti fungono da origine per le nuove versioni nell'ambiente di produzione.
• Gli amministratori dei repository Git controllano le 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, richiedere un controllo di approvazione o di controllo dello stato per tutte le richieste pull unite nel ramo protetto. I criteri dei rami consentono ai team di proteggere rami importanti di sviluppo. I criteri applicano gli standard di gestione del codice e della qualità del codice del team.

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. Incorporare solo le estensioni del marketplace di VS Code dagli editori 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

• Incorporare la sicurezza Zero Trust nel flusso di lavoro dello sviluppatore consente di innovare in modo rapido e sicuro.
• Proteggere l'ambiente della piattaforma DevOps consente di implementare i principi Zero Trust nell'ambiente della piattaforma DevOps ed evidenzia le procedure consigliate per la gestione dei segreti e dei certificati.
• Gli ambienti DevOps sicuri per Zero Trust descrivono le procedure consigliate per proteggere gli ambienti DevOps con un approccio Zero Trust per impedire agli hacker di compromettere le caselle degli sviluppatori, infettare le pipeline di rilascio con script dannosi e ottenere l'accesso ai dati di produzione tramite ambienti di test.
• Implementare i principi Zero Trust come descritto nel memorandum 22-09 (a supporto dell'ordine esecutivo degli Stati Uniti 14028, Miglioramento della sicurezza informatica nazionale) usando Microsoft Entra ID come sistema centralizzato di gestione delle identità.
• Accelerare e proteggere il codice con Azure DevOps con strumenti che offrono agli sviluppatori il codice più veloce e sicuro per l'esperienza cloud.
• Configurare Azure per considerare attendibile l'OIDC di GitHub come identità federata. OpenID Connessione (OIDC) consente ai flussi di lavoro di GitHub Actions di accedere alle risorse in Azure senza dover archiviare le credenziali di Azurecome segreti GitHub di lunga durata.