Condividi tramite


Configurare l'integrazione nativa di GitHub Sicurezza Avanzata con portale di Microsoft Azure

Questa guida illustra i passaggi di configurazione e altre azioni che consentono di integrare GitHub Advanced Security (GHAS) e portale di Microsoft Azure con un caso d'uso che consente di convalidare l'integrazione end-to-end. Questa integrazione consente di ottimizzare la sicurezza delle applicazioni native del cloud di Microsoft correlando i rischi di runtime e il contesto con il codice originato per una correzione più rapida basata sull'intelligenza artificiale.

Seguendo questa guida, è possibile:

  • Configurare il repository GitHub per la copertura di Defender for Cloud.
  • Creare un fattore di rischio di esecuzione.
  • Testare casi d'uso reali in Defender for Cloud.
  • Collegare il codice alle risorse di runtime.
  • Avviare una campagna di sicurezza in GitHub. Questa campagna usa il contesto di runtime per classificare in ordine di priorità gli avvisi di sicurezza GHAS.
  • Creare issue GitHub in Defender for Cloud per iniziare la risoluzione.
  • Colmare il divario tra i team di ingegneria e sicurezza.

Prerequisiti

Aspetto Dettagli
Requisiti ambientali - GitHub account con un connettore creato in Defender for Cloud
- Licenza GHAS
- Defender Cloud Security Posture Management (DCSPM) abilitato nella sottoscrizione
- Microsoft Security Copilot (facoltativo per la correzione automatica)
Ruoli e autorizzazioni - Autorizzazioni di amministratore della sicurezza
- Amministratore della sicurezza nella sottoscrizione Azure (per visualizzare i risultati in Defender for Cloud)
- Proprietario dell'organizzazione GitHub
Ambienti Cloud - Disponibile solo nei cloud commerciali (non in Azure per enti pubblici, Azure gestito da 21Vianet o da altri cloud sovrani)

Prepara il tuo ambiente

Passaggio 1: Configurare il repository GitHub ed eseguire il flusso di lavoro

Per testare l'integrazione, usare repository personalizzati o un esempio GitHub repository che include già tutto il contenuto per creare un'immagine del contenitore vulnerabile. Prima di configurare un repository, assicurarsi che:

  • Si definisce un connettore per l'organizzazione GitHub che si prevede di usare nel portale di Defender for Cloud. Seguire i passaggi descritti in Connettere l'ambiente GitHub a portale di Microsoft Azure.

  • Configurare l'analisi del codice senza agente per il connettore GitHub. Seguire la procedura descritta in Configurare l'analisi del codice senza agente (anteprima).

  • Il repository usato per l'integrazione è privato.

Se si vuole usare un repository di esempio, clonare il repository seguente nell'organizzazione GitHub: build25-woodgrove/mdc-customer-playbook. Questo repository consente ai clienti di testare l'integrazione di Defender for Cloud e GHAS. Ha GHAS abilitato ed è inserito in un tenant di Azure con CSPM di defender abilitato.

Nel repository seguire questa procedura:

  1. Andare a Impostazioni.

  2. Nel riquadro sinistro selezionare Segreti e variabiliAzioni. Selezionare quindi Nuovo segreto del repository.

    Screenshot delle selezioni per la creazione di un nuovo segreto del repository in GitHub.

  3. Aggiungere i segreti seguenti a livello di repository o organizzazione:

    Variable Description
    ACR_ENDPOINT Server di login del registro dei container
    ACR_USERNAME Nome utente per il registro contenitori
    ACR_PASSWORD Password per il registro contenitori

    Annotazioni

    I nomi possono essere scelti liberamente e non devono seguire un modello specifico.

    È possibile trovare queste informazioni nel portale di Azure seguendo questa procedura:

    1. Selezionare il registro contenitori in cui si vuole eseguire la distribuzione.

    2. In Impostazioni selezionare Chiavi di accesso. Il riquadro Chiavi di accesso mostra le chiavi per il server di accesso, il nome utente e la password.

      Screenshot del riquadro che elenca le chiavi di accesso per un registro contenitori nel Azure portal.

  4. Nel repository selezionare Azioni.

  5. Selezionare il flusso di lavoro Compila e invia all'ACR e quindi selezionare Esegui flusso di lavoro.

    Screenshot di una sezione Actions di un repository GitHub che mostra la cronologia del flusso di lavoro e il pulsante per l'esecuzione di un flusso di lavoro.

  6. Verificare che l'immagine sia stata distribuita al registro dei contenitori.

    Per il repository di esempio, l'immagine deve trovarsi in un registro denominato mdc-mock-0001 con il tag mdc-ghas-integration.

  7. Distribuire la stessa immagine come contenitore in esecuzione nel cluster. Un modo per completare questo passaggio consiste nel connettersi al cluster e usare il comando . Ecco un esempio per il servizio Azure Kubernetes:

    1. Impostare la sottoscrizione del cluster:

      az account set --subscription $subscriptionID
      
    2. Impostare le credenziali per il cluster:

      az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing
      
    3. Distribuire l'immagine:

      kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
      

Passaggio 2: Creare il fattore di rischio di esempio (regola business critical)

Uno dei fattori di rischio rilevati da Defender for Cloud per questa integrazione è la criticità aziendale. Le organizzazioni possono creare regole per etichettare le risorse come business critical.

  1. Nel portale di Defender for Cloud passare a Impostazioni ambienteCriticità risorse.

  2. Nel riquadro destro selezionare il collegamento per aprire Microsoft Defender.

    Screenshot dell'interfaccia Defender for Cloud che mostra le selezioni per l'apertura del Microsoft Defender portal.

  3. Selezionare Crea una nuova classificazione.

    Screenshot del pulsante per la creazione di una nuova classificazione.

  4. Immetti un nome e una descrizione.

  5. Nel generatore di query selezionare Risorsa cloud.

  6. Scrivere una query per impostare Nome risorsa uguale al nome del contenitore distribuito nel cluster per la convalida. Quindi seleziona Avanti.

    Schermata del generatore di query di Microsoft Defender con un filtro sul nome della risorsa applicato a una risorsa cloud.

  7. Nella pagina Preview Assets, se Microsoft Defender ha già rilevato la tua risorsa, il nome del contenitore appare con un tipo di asset K8s-container o K8s-pod.

    Anche se il nome non è ancora visibile, continuare con il passaggio successivo. Microsoft Defender applica l'etichetta di criticità al contenitore dopo aver rilevato il contenitore. Questo processo può richiedere fino a 24 ore.

  8. Scegliere un livello di criticità e quindi esaminare e inviare la regola di classificazione.

Passaggio 3: Verificare che l'ambiente sia pronto

La convalida conferma che l'ambiente è configurato correttamente per visualizzare il codice in base alle raccomandazioni di runtime e generare risultati interattivi.

Durante questo passaggio, Defender verifica che:

  • Visibilità completa del codice durante il runtime
  • I repository di codice sorgente vengono monitorati continuamente da portale di Microsoft Azure per individuare le vulnerabilità di sicurezza.
  • Gli artefatti di compilazione (ad esempio le immagini dei contenitori) vengono analizzati nei registri contenitori prima della distribuzione.
  • I carichi di lavoro di runtime distribuiti nei cluster Kubernetes vengono monitorati per individuare i rischi per la sicurezza.
  • Defender for Cloud correla e traccia ogni artefatto dal codice, tramite compilazione e distribuzione, al runtime e ritorno.

Annotazioni

Possono essere necessarie fino a 24 ore dopo l'applicazione dei passaggi precedenti per visualizzare i risultati seguenti.

  1. Verificare che GitHub analisi senza agente preleva il repository.

  2. Passare a Cloud Security Explorer ed eseguire la query. Le query di convalida testano se Defender può identificare gli artefatti prodotti dalle pipeline e dai carichi di lavoro. Se le query restituiscono risultati, indica che l'analisi e la correlazione funzionano come previsto.

    Screenshot dei risultati della ricerca nel generatore di query di Cloud Security Explorer, con filtri impostati su repository GitHub e immagini del contenitore.

    Annotazioni

    Se non vengono restituiti risultati, potrebbe indicare che gli artefatti non sono ancora generati, l'analisi non è configurata o le autorizzazioni non sono presenti. Per altre informazioni, vedere Ruoli utente e autorizzazioni .

  3. Verificare che Defender for Cloud (in Registro Azure Container) ha analizzato l'immagine del contenitore e usata per creare un contenitore. Nella query aggiungere le condizioni per la distribuzione specifica.

    Screenshot di Cloud Security Explorer che mostra i risultati dell'analisi per una query con filtri per repository GitHub e immagini del contenitore.

  4. Verificare che il contenitore sia in esecuzione e che Defender for Cloud abbia analizzato il cluster AKS.

    Screenshot dei risultati delle query di Cloud Security Explorer con filtri per repository di GitHub e immagini di container.

  5. Verificare che i fattori di rischio siano configurati correttamente sul lato Defender for Cloud. Cerca il tuo nome del contenitore nella pagina di inventario di Defender for Cloud, e dovrebbe essere contrassegnato come critico.

    Annotazioni

    Questo passaggio è necessario solo se i fattori di rischio non sono già configurati nell'ambiente.

  6. Se si usano già fattori di rischio, è possibile verificare la configurazione in ImpostazioniCriticità risorsa.

La convalida corretta garantisce che i passaggi successivi, ad esempio raccomandazioni, campagne e GitHub generazione di problemi producano risultati significativi.

Passaggio 4: Creare una campagna GitHub

Poiché il flusso di lavoro distribuisce un'immagine che crea un contenitore in esecuzione con uno dei fattori di rischio (business critical), gli sviluppatori possono visualizzare i fattori di rischio in GitHub.

Annotazioni

Dopo aver classificato la risorsa come critica, possono essere necessarie fino a 12 ore prima che Defender for Cloud invii i dati a GitHub. Ulteriori informazioni.

Per creare una campagna di analisi, è necessario lavorare a livello di organizzazione GitHub. Questa esperienza non è disponibile a livello di singolo repository.

  1. In GitHub passare all'organizzazione GitHub usata per il test di configurazione.

  2. SelezionareSicurezzaCampagneCrea campagnaDai filtri di scansione del codice. Questa campagna definisce quali elementi individuati dal cloud (ad esempio immagini di contenitori o carichi di lavoro) vengono valutati e monitorati nell'ambiente.

    Screenshot delle opzioni disponibili su GitHub per creare una campagna a partire da filtri di scansione del codice o dei segreti.

  3. Creare la campagna seguente. Questa campagna mostra gli avvisi aperti con gravità media in cui l'immagine distribuita dal repository è associata a una risorsa critica. Il repository di test dovrebbe essere rilevato con questa campagna.

    Screenshot di una campagna GitHub con filtri per avvisi aperti, gravità e rischio di esecuzione.

  4. Selezionare SalvaPubblica come campagna.

  5. Immettere le informazioni necessarie e quindi pubblicare la campagna.

Passaggio 5: Valutare le raccomandazioni

Usare le raccomandazioni dal codice al runtime e gli avvisi di sicurezza per valutare lo stato dei problemi di sicurezza. È quindi possibile assegnare la raccomandazione per la risoluzione al team di ingegneria pertinente grazie alla connessione tra gli avvisi di sicurezza di Dependabot e la corrispondenza degli ID comunemente noti delle vulnerabilità ed esposizioni (CVE) in Defender per il Cloud.

Raccomandazioni sul runtime del codice

Per visualizzare i suggerimenti di ottimizzazione tra codice e runtime:

  1. Nel portale di Defender for Cloud passare alla scheda Raccomandazioni .

  2. Cercare il nome del contenitore creato. Aprire quindi una delle raccomandazioni per aggiornare il software , il nome della raccomandazione inizia con Aggiorna.

    Se è stato usato il repository di esempio, cercare Aggiornare la raccomandazione brace-expansion.

  3. Passare alla scheda Informazioni dettagliate correzione e visualizzare il codice per il diagramma di runtime. Il diagramma mappa il contenitore in esecuzione, all'immagine del contenitore nel repository del codice e al repository del codice di origine in GitHub.

    Quando viene eseguita la campagna, Defender visualizza il codice per le raccomandazioni di runtime che mettono in correlazione i risultati del cloud con il codice e gli artefatti di compilazione.

La visualizzazione seguente fornisce il contesto degli asset interessati e dei segnali di rischio. Questa visualizzazione consente di comprendere il motivo per cui è stata generata una raccomandazione prima di intervenire.

Screenshot della scheda Informazioni dettagliate sulla correzione che mostra un diagramma delle fasi di sviluppo collegate.

Avvisi di sicurezza

Gli avvisi di sicurezza vengono visualizzati come parte del flusso di valutazione delle raccomandazioni. Questi avvisi forniscono un contesto aggiuntivo sui rischi attivi e consentono di classificare in ordine di priorità la correzione, ma non creano automaticamente GitHub problemi.

  1. Selezionare la scheda Associated CVEs. Si noti che alcuni ID CVE hanno un collegamento View in GitHub nella colonna Related GitHub Alerts.

  2. Selezionare il collegamento per aprire l'avviso di sicurezza GHAS pertinente. Per visualizzare il contenuto degli avvisi GHAS in GitHub è necessario disporre delle autorizzazioni di accesso per il repository di GitHub pertinente. Contattare l'amministratore GitHub in caso contrario.

Screenshot della scheda Numeri CVE associati che mostra un collegamento a un avviso GitHub correlato.

Creare un problema di GitHub

Per chiudere il ciclo tra i team di progettazione e sicurezza, è possibile creare un problema GitHub che assegna priorità ai problemi di sicurezza su cui deve concentrarsi il team di progettazione. Questa prioritizzazione può includere il trasferimento dei risultati che GHAS non ha rilevato ma che Defender per il Cloud ha individuato per gli ID CVE che non fanno parte delle dipendenze dirette. Questi risultati possono includere vulnerabilità nell'immagine di base, nel sistema operativo o nel software come NGINX.

Il problema GitHub viene generato automaticamente con tutti gli ID CVE presenti nell'ambito della raccomandazione. La raccomandazione è con e senza corrispondenze di avvisi Dependabot, inclusi altri contesti di runtime sul repository di origine.

Dalla visualizzazione delle raccomandazioni è possibile generare in modo esplicito un problema di GitHub per tenere traccia del lavoro di correzione.

  1. Aprire la raccomandazione relativa all'aggiornamento software .

  2. Selezionare la scheda Informazioni dettagliate correzione.

  3. Esaminare la casella Runtime interessata.

  4. Validate se esiste già un problema di GitHub: se esiste già un problema di GitHub, viene visualizzata un'icona GitHub nella casella. Passare il puntatore del mouse sull'icona per visualizzare i dettagli del problema.
    Se non esiste alcun problema e si dispone delle autorizzazioni necessarie, è possibile generare un nuovo problema di GitHub.

  5. Selezionare Intervenire.

  6. Selezionare l'opzione Genera segnalazione su GitHub dal popup.

  7. Se il problema è stato creato correttamente, verrà visualizzata una notifica popup con un collegamento al problema.

  8. Il problema viene creato nel repository di codice di origine.

    Annotazioni

    Se l'opzione Genera problema GitHub non è disponibile, i permessi necessari per GitHub o il repository potrebbero mancare.
    Contattare il GitHub o l'amministratore del repository per richiedere l'accesso.

    Screenshot di un elenco di problemi di GitHub che mostra tre voci contrassegnate con tag di sicurezza e vulnerabilità.

  9. Quando il problema viene assegnato a un utente GitHub o se lo stato viene modificato, l'aggiornamento si riflette nel portale di Defender for Cloud.

Monitorare gli aggiornamenti di proprietà e stato - Le modifiche apportate allo stato dei problemi o all'assegnazione in GitHub vengono riflesse in Microsoft Defender per il cloud, consentendo di tenere traccia della proprietà e dell'avanzamento della risoluzione.

Screenshot di un problema di GitHub con tag di sicurezza e vulnerabilità, inclusi dettagli come ID CVE, fattori di rischio di runtime e informazioni sulla distribuzione.

Apportare correzioni proattive

Sul lato GitHub, se si dispone di una licenza GitHub Copilot, è possibile risolvere il problema con l'aiuto dell'agente di codifica GitHub:

  1. Assegnare un agente di codifica GitHub al problema.
  2. Esaminare la correzione generata.
  3. Se la correzione sembra ragionevole, applicarla.
  4. Osservare come Defender for Cloud aggiorna lo stato del problema a Chiuso.