Condividi tramite

Distribuire l'integrazione di GitHub Advanced Security con Microsoft Defender for Cloud

Questa guida illustra i passaggi di configurazione e altre azioni che consentono di integrare GitHub Advanced Security (GHAS) e Microsoft Defender for Cloud. Questa integrazione consente di ottimizzare la sicurezza delle applicazioni native del cloud di Microsoft.

Seguendo questa guida, è possibile:

  • Configura il tuo 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 cloud.
  • 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 in base al contesto di runtime.
  • Creare problemi di GitHub da Defender per il cloud per avviare la correzione.
  • Colmare il divario tra i team di ingegneria e sicurezza.

Prerequisiti

Aspetto Dettagli
Requisiti ambientali - Account GitHub con un connettore creato in Defender for Cloud
- Licenza GHAS
- Defender Cloud Security Posture Management (CSPM) abilitato nella sottoscrizione
- Microsoft Security Copilot (facoltativo per la correzione automatica)
Ruoli e autorizzazioni - Autorizzazioni di amministratore della sicurezza
- Lettore di sicurezza nella sottoscrizione di 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 altri cloud sovrani)

Prepara il tuo ambiente

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

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

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 variabili>Azioni. 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 portale di Azure.

  4. Nel repository selezionare Azioni.

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

    Screenshot della 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 kubectl run 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 primo fattore di rischio (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 di Defender for Cloud che mostra le selezioni per l'apertura del portale di Microsoft Defender.

  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.

    Screenshot del generatore di query di Microsoft Defender con un filtro del nome della risorsa applicato per una risorsa cloud.

  7. Nella pagina Anteprima asset , se Microsoft Defender ha già rilevato la risorsa, il nome del contenitore viene visualizzato 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

Annotazioni

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

  1. Verificare che l'analisi senza agente di GitHub rilevi il repository.

  2. Passare a Cloud Security Explorer ed eseguire la query.

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

  3. Verificare che Defender for Cloud (nel Registro dei container di Azure) abbia analizzato l'immagine del container e l'abbia usata per creare un container. 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 i repository GitHub e le 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 GitHub e immagini del contenitore.

  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.

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.

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

  2. SelezionareSicurezza>Campagne>Crea campagna>Dai filtri di scansione del codice.

    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 runtime.

  4. Selezionare Salva>Pubblica come campagna.

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

Passaggio 5: Valutare le raccomandazioni dal codice al cloud

Utilizzare le raccomandazioni dal codice al cloud e gli avvisi di sicurezza per comprendere lo stato delle questioni 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.

Per visualizzare le raccomandazioni per lo sviluppo dal codice al cloud

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

  2. Cercare il nome del contenitore creato. Aprire quindi una delle raccomandazioni che includono la parola Update.

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

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

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

Visualizzare gli avvisi di sicurezza

  1. Selezionare la scheda CVEs associati . Si noti che alcuni ID CVE hanno un collegamento Visualizza su GitHub nella colonna Avvisi GitHub correlati .

  2. Selezionare il collegamento per aprire l'avviso di sicurezza GHAS pertinente.

Screenshot della scheda 'CVEs associati' che presenta un collegamento a un avviso correlato su GitHub.

Segnalare un problema in GitHub

Per chiudere il ciclo tra i team di progettazione e sicurezza, è possibile creare un problema di 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 di GitHub viene generato automaticamente con tutti gli ID CVE trovati nell'ambito della raccomandazione. La raccomandazione è con e senza corrispondenze di avvisi Dependabot, inclusi altri contesti di runtime sul repository di origine.

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

Quando si assegna il problema, lo stato del problema viene aggiornato nel portale di Defender for Cloud.

Screenshot di un problema di GitHub con i 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 di 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.

Contenuti correlati

  • Last updated on