Sviluppare una soluzione SIEM per Microsoft Sentinel

Le soluzioni Microsoft Sentinel consentono ai fornitori di software indipendenti (ISV) e ai partner di raggruppare un connettore dati con contenuti di sicurezza correlati, ad esempio cartelle di lavoro, regole analitiche, query di ricerca proattiva, playbook e parser, in un unico pacchetto installabile. I clienti possono quindi individuare e distribuire queste soluzioni dall'hub del contenuto Microsoft Sentinel e Azure Marketplace.

Note

Se si è un ISV che crea un'integrazione Microsoft Sentinel, il team di Microsoft App Assure potrebbe essere in grado di assistere durante tutto il processo. Per coinvolgere il team, inviare un messaggio di posta elettronica a azuresentinelpartner@microsoft.com.

Phase Activities
Imparare Informazioni su Sentinel, identificare cosa creare, creare account di pubblicazione, configurare l'ambiente
Build Esegui il provisioning dell'ambiente, crea il connettore e il contenuto della soluzione
Test Creare un pacchetto della soluzione, testarlo, inviare una richiesta pull e risolvere il feedback
Pubblicare Crea un'offerta in Partner Center, testa l'anteprima e pubblicala
Preview Informare i clienti, risolvere i problemi di supporto, monitorare per quattro settimane
Vai al mercato Rimuovi il flag di anteprima, ascolta i clienti, migliora la tua soluzione

Learn

Prima di iniziare la creazione, completa i passaggi seguenti:

Costruire

Nella fase di compilazione si configura l'ambiente di sviluppo, quindi si crea il connettore e il contenuto della soluzione.

Configurare l'ambiente

Prima di compilare, configurare l'ambiente di sviluppo in modo da poter creare, testare e inviare il contenuto della soluzione.

Creare una copia tramite fork e clonare il repository

Per creare una copia tramite fork e clonare il repository Azure-Sentinel, seguire questa procedura:

  1. In GitHub passare al repositoryAzure-Sentinel e selezionare Fork.

  2. Clona il tuo fork sul computer locale.

    git clone https://github.com/<your-github-username>/Azure-Sentinel.git
cd Azure-Sentinel

  3. Aggiungere l'"upstream" remoto in modo da poter eseguire il pull delle modifiche più recenti:

    git remote add upstream https://github.com/Azure/Azure-Sentinel.git

Configurare un'area di lavoro di sviluppo/test

È necessaria un'area di lavoro Microsoft Sentinel funzionante per sviluppare e convalidare il connettore e il contenuto prima dell'invio. Consultare Configurare Microsoft Sentinel.

Dopo che l'area di lavoro è stata configurata, assegnare le autorizzazioni seguenti:

  • Collaboratore di Microsoft Sentinel nell'area di lavoro per distribuire e gestire le risorse
  • Log Analytics Contributor nell'area di lavoro per creare e gestire tabelle personalizzate e regole di raccolta dati (DCR)
  • Collaboratore nel gruppo di risorse per distribuire i modelli ARM durante i test

Eseguire l'onboarding nel portale di Defender

Esegui l'onboarding dell'area di lavoro nel portale Defender per convalidare l'installazione della soluzione, garantire un'acquisizione dei dati senza problemi nella piattaforma unificata per le operazioni di sicurezza e testare il processo end-to-end prima della pubblicazione. Per altre informazioni, vedere Microsoft Sentinel nel portale di Microsoft Defender.

Creare una soluzione

Una soluzione Microsoft Sentinel è una cartella di file di contenuto e connettore che lo strumento di creazione pacchetti assembla in un pacchetto distribuibile. Creare la struttura di cartelle, aggiungere i file di creazione del pacchetto, quindi compilare ogni tipo di contenuto.

Creare la struttura di cartelle della soluzione in GitHub

Per configurare la struttura di cartelle della soluzione, seguire questa procedura:

  1. Creare e passare a un nuovo ramo del fork. Usa un nome descrittivo, ad esempio add-<YourSolutionName>-solution:

    git checkout -b add-<YourSolutionName>-solution

  2. Creare una cartella con il nome della soluzione in Solutions/:

    Solutions/<YourSolutionName>/
├── Data/
│   └── Solution_<YourSolutionName>.json
├── SolutionMetadata.json
├── ReleaseNotes.md
├── Data Connectors/
├── Workbooks/
├── Analytic Rules/
├── Hunting Queries/
├── Playbooks/
└── Parsers/
    File/Cartella Obbligatorio Contenuto
    Data/Solution_<YourSolutionName>.json Obbligatorio Manifesto della soluzione che elenca ogni file di contenuto nella soluzione e guida lo strumento di creazione del pacchetto
    SolutionMetadata.json Obbligatorio Metadati dell’editore e del marketplace: ID editore, ID offerta, categorie e informazioni di assistenza
    ReleaseNotes.md Obbligatorio Tabella della cronologia delle modifiche versionata, necessaria per ogni invio del pacchetto
    Data Connectors/ Opzionale File JSON del connettore o codice Funzioni di Azure per i connettori basati su funzioni
    Workbooks/ Opzionale Screenshot dei file JSON della cartella di lavoro e delle anteprime nere/bianche
    Analytic Rules/ Opzionale Modelli di regole di analisi YAML
    Hunting Queries/ Opzionale Modelli di query di ricerca YAML
    Playbooks/ Opzionale File JSON del playbook e definizioni dei connettori personalizzati di App per la logica di Azure
    Parsers/ Opzionale Definizioni YAML di funzioni/parser Kusto

    Le sottocartelle di contenuto sono facoltative. Creare solo le cartelle applicabili alla soluzione. Non è necessario includere ogni tipo di contenuto, ma soddisfare i requisiti minimi del contenuto migliora il punteggio di qualità.

    Per un esempio di struttura di cartelle completa, aprire la cartella Soluzioni/ nel repository ed esplorare alcune delle soluzioni esistenti.

Creare i file di pacchettizzazione della soluzione

Data/Solution_<YourSolutionName>.json

Questo file guida lo strumento di creazione pacchetti V3. Elenca ogni file di contenuto nella soluzione e controlla come vengono assemblati in mainTemplate.json. Ogni tipo di contenuto è una matrice. Aggiungere una voce per ogni file per ciascun contenuto di cui si dispone. Per altre informazioni sullo strumento di creazione pacchetti, vedere Creare un pacchetto della soluzione.

Nell'esempio seguente la soluzione ha due regole analitiche, quindi la "Analytic Rules" matrice ha due voci. Se, ad esempio, non stai creando alcun playbook, rimuovi completamente la chiave "Playbooks" dal file.

{
  "Name": "Contoso MyProduct",
  "Author": "Contoso - support@contoso.com",
  "Logo": "<img src=\"https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Logos/contoso.svg\" width=\"75px\" height=\"75px\">",
  "Description": "The Contoso MyProduct solution for Microsoft Sentinel enables you to ingest MyProduct logs into Microsoft Sentinel.",
  "BasePath": "C:/GitHub/Azure-Sentinel/Solutions/Contoso MyProduct",
  "Version": "1.0.0",
  "Metadata": "SolutionMetadata.json",
  "TemplateSpec": true,
  "Data Connectors": [
    "Data Connectors/ContosoMyProduct.json"
  ],
  "Workbooks": [
    "Workbooks/ContosoMyProductWorkbook.json"
  ],
  "Analytic Rules": [
    "Analytic Rules/ContosoMyProductSuspiciousLogin.yaml",
    "Analytic Rules/ContosoMyProductDataExfiltration.yaml"
  ],
  "Hunting Queries": [
    "Hunting Queries/ContosoMyProductThreatHunt.yaml"
  ],
  "Parsers": [
    "Parsers/ContosoMyProduct.yaml"
  ],
  "Playbooks": [
    "Playbooks/ContosoMyProduct-EnrichIncident/azuredeploy.json"
  ]
}
Campo Notes
Name Solo caratteri alfanumerici e spazi. Nessun trattino, caratteri di sottolineatura o simboli.
Author Formato: Organization - email@domain.com
Logo Tag HTML <img> che punta al file SVG del logo nell'URL grezzo di GitHub in Logos/. Vedere Aggiungere il logo per i requisiti dei file e le regole di convalida.
BasePath Percorso locale del repository per la cartella della soluzione. Non usato in fase di esecuzione.
Version Deve corrispondere a SolutionMetadata.json e mainTemplate.json.
TemplateSpec Controllare le soluzioni esistenti nel repository per il valore corretto per il tipo di connettore.
Matrici di contenuto Una voce per file. Aggiungere tutti i file per un determinato tipo di contenuto alla relativa matrice. Rimuovere completamente la chiave se non si dispone di contenuto di tale tipo. Non lasciare una matrice vuota. I percorsi sono relativi a BasePath.

SolutionMetadata.json

Questo file contiene i metadati del marketplace e dell'editore usati durante la certificazione del Centro per i partner.

{
  "publisherId": "contoso",
  "offerId": "contoso-myproduct-sentinel",
  "firstPublishDate": "2026-06-15",
  "lastPublishDate": "2026-06-15",
  "providers": [
    "Contoso"
  ],
  "categories": {
    "domains": [
      "Security - Threat Intelligence"
    ]
  },
  "support": {
    "name": "Contoso",
    "email": "support@contoso.com",
    "tier": "Partner",
    "link": "https://support.contoso.com"
  }
}

publisherId e offerId provengono dall'offerta del Centro per i partner. support.tier deve essere "Partner" per le soluzioni ISV. Per i valori validi categories.domains , vedere il catalogo delle soluzioni.

Campo Notes
publisherId ID editore del tuo Partner Center.
offerId ID dell'offerta del Centro per i partner. Questo valore viene impostato quando si crea l'offerta nel Centro per i partner e non può essere modificato dopo la creazione. Il valore deve corrispondere esattamente all'ID dell'offerta in Partner Center. Una mancata corrispondenza causa un errore di certificazione. Vedere Creare un pacchetto per una soluzione SIEM per Microsoft Sentinel per informazioni su come viene creato l'ID dell'offerta.
firstPublishDate Data ISO 8601. Impostare una sola volta e non modificarlo dopo la pubblicazione iniziale.
lastPublishDate Eseguire l'aggiornamento in modo che corrisponda a ogni nuova versione.
providers Elenco dei nomi dei fornitori/produttori di prodotti.
categories.domains Una o più categorie di dominio dal catalogo delle soluzioni.
categories.verticals Verticali di settore facoltative. Omettere se non applicabile.
support.tier "Partner"per ISV, "Microsoft" per Microsoft, "Community" per la community.

ReleaseNotes.md

Il ReleaseNotes.md file registra la cronologia delle modifiche per la soluzione. Questo file viene convalidato durante i controlli della PR. Le voci mancanti o non valide comportano il rifiuto della richiesta pull.

La tabella deve avere esattamente tre colonne con questi nomi di intestazione esatti (inclusi i marcatori in grassetto):

| **Version** | **Date Modified (DD-MM-YYYY)** | **Change History** |
|---|---|---|
| 1.0.1 | 12-06-2026 | Updated analytic rule query to fix false positives. |
| 1.0.0 | 01-06-2026 | Initial solution release. |

Regole di convalida

  • Formato della versione: X.Y.Z Non includere il prefisso v. Sono necessarie tutte e tre le parti.
  • Le versioni sono elencate in ordine decrescente, con la più recente all'inizio della riga
  • Formato data: DD-MM-YYYY con trattini (non YYYY-MM-DD)
  • Le intestazioni di colonna devono corrispondere esattamente, inclusi i marcatori **bold**
  • La cella Cronologia modifiche non deve essere vuota
  • Aggiungere una nuova riga per ogni aggiornamento della versione, incluse le correzioni di errori di digitatura

La versione in ReleaseNotes.md deve corrispondere alla versione in SolutionMetadata.jsonData/Solution_*.json, e al nome file zip del pacchetto.

Posizionare il logo Logos/<YourProductName>.svg nella radice del repository. Fai riferimento ad esso in Data/Solution_<YourSolutionName>.json usando un tag HTML <img> che punta all'URL raw di GitHub:

"Logo": "<img src=\"https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Logos/YourProductName.svg\" width=\"75px\" height=\"75px\">"

Il file SVG deve soddisfare i requisiti seguenti:

Controlla Requisito
Formato del file Solo estensione .svg. I formati PNG, JPEG o altri non sono consentiti.
Dimensione del file ≤ 5 KB
Attributo style= Non consentito. Rimuovere tutti gli attributi inline style="..." dagli elementi.
Attributo cls= Non consentito
Spazio dei nomi xmlns:xlink Non consentito. Rimuovere dall'elemento radice <svg>.
Attributo data-name Non consentito. Illustrator aggiunge questi attributi come nomi di livello. Devono essere rimossi.
xlink:href Non consentito. Usare percorsi SVG inline anziché riferimenti alle immagini incorporate.
Tag <title> Non consentito. Rimuovere tutti gli <title>...</title> elementi.
PNG integrato Non consentito. Tutti <image> gli elementi che fanno riferimento ai .png file vengono rifiutati
Valori degli elementi id id="..." Se sono presenti attributi, ogni valore deve essere un UUID valido (ad esempio, id="a1b2c3d4-e5f6-4789-abcd-0123456789ab"). Gli ID leggibili come id="Layer_1" non funzionano. Tutti gli ID devono essere univoci all'interno del file.

Attenzione

I file SVG esportati direttamente da Adobe Illustrator, Figma o Inkscape senza essere ripuliti quasi sempre non superano la validazione. Gli artefatti di esportazione comuni che devono essere rimossi includono quanto segue:

  • style="stroke: none; fill: rgb(0,0,0); ..." su ogni elemento: sostituisci con gli attributi diretti fill e stroke oppure rimuovi se predefinito
  • data-name="Layer 1": Attributo del nome del livello Illustrator; rimuovere da ogni <g> elemento
  • xmlns:xlink="http://www.w3.org/1999/xlink": Nella radice <svg>; rimuovi l'intero attributo
  • <title>Layer 1</title>: All'interno del primo <g>; eliminare il tag
  • ID non GUID come id="Layer_1" o id="cls-1": sostituisci con un UUID o rimuovi completamente l'attributo id se non è referenziato

Un logo pulito usa solo gli attributi fill e stroke direttamente sugli elementi path, senza attributi id a meno che non facciano riferimento a un elemento <defs>. Per un esempio minimamente valido, vedi Logos/XBOW.svg.

Creare un connettore dati

Se si sta creando un connettore usando il flusso di lavoro dell'agente di intelligenza artificiale, vedere Creare connettori personalizzati usando l'agente di intelligenza artificiale in Microsoft Sentinel anziché seguire la procedura seguente.

Scegliere il tipo di connettore

Microsoft Sentinel supporta diversi tipi di connettore, molti dei quali usano Codeless Connector Framework (CCF). Scegliere quella più adatta all'origine dati e all'esperienza del cliente desiderata.

Tipo di connettore Migliore per Linee guida
Polling CCF API REST chiamate dal connettore in base a una pianificazione. Completamente SaaS, senza alcun agente o macchina virtuale necessaria. Comprende il monitoraggio dell'integrità integrato e il supporto Microsoft completo. Creare un connettore senza codice per Microsoft Sentinel
Push CCF Origini dati che inviano i log a un endpoint Microsoft Sentinel. Connettori push CCF di Microsoft Sentinel (anteprima)
blob CCF Origini dati che scrivono i log in Archiviazione BLOB di Azure o Azure Data Lake Storage. Configurare il connettore Archiviazione di Azure
CCF GCP Sorgenti dati che scrivono i log su Google Cloud Storage. Informazioni di riferimento sul connettore dati GCP
CEF Appliance locali che emettono log in formato Common Event Format. I dati si trovano nella tabella nota CommonSecurityLog . Connetti i log in formato CEF
Syslog Appliance locali che possono generare solo Syslog non elaborato. Meno preferito; le query richiedono l'analisi sintattica KQL. Raccogliere origini dati syslog
Funzioni di Azure(legacy) API REST quando CCF non è fattibile a causa di limitazioni tecniche. Usare solo come ultima risorsa. Contattare azuresentinelpartner@microsoft.com prima di eseguire la compilazione per confermare i requisiti di idoneità. Modello di connettore Funzioni di Azure
Compilare la definizione del connettore

I passaggi dettagliati della build variano in base a ogni tipo di connettore. I passaggi dettagliati della build variano in base a ogni tipo di connettore. Seguire le indicazioni per il tipo scelto dalla tabella dei tipi di connettore. .

Usare le soluzioni seguenti nel repository Azure-Sentinel come riferimenti per ogni tipo di connettore.

Tipo di connettore Esempio della funzione reference
Interrogazione CCF Connettore di polling CCF SentinelOne
Push CCF Connettore di push CCF di Jamf Protect
Blob CCF Connettore BLOB CCF cloudflare
CCF GCP Connettore dei log di audit di Google Cloud Platform
CEF/Syslog Connettori CEF e Syslog Cisco ISE

Quando il file JSON del connettore è completo, collocalo nella sottocartella Data Connectors/ della cartella della soluzione e assegnagli il nome ProviderNameApplianceName.json (senza spazi).

Testare il connettore

Importante

Prima di compilare cartelle di lavoro, regole di analisi e altro contenuto, verificare che il connettore invii dati alla tabella prevista e che le query restituisca risultati. È più facile individuare i problemi di flusso dei dati e di schema in questa fase che dopo aver creato contenuti che dipendono da essi. Vedere la sezione Testare il pacchetto per informazioni su come creare un pacchetto e distribuire il connettore in un'area di lavoro di sviluppo.

Creare il contenuto

Oltre al connettore dati, arricchire la soluzione con contenuto SIEM che consente ai clienti di ottenere valore immediato dai dati. I contenuti SIEM aggiuntivi comprendono:

  • Cartelle di lavoro
  • Regole analitiche
  • Ricerca di query
  • Playbook
  • Parser

Questo contenuto è facoltativo ma consigliato. Per i requisiti minimi e l'assegnazione dei punteggi di qualità, vedere Microsoft Sentinel linee guida sulla qualità della soluzione.

Creare cartelle di lavoro

Le cartelle di lavoro sono dashboard e visualizzazioni che consentono ai clienti di comprendere i dati. Per creare una cartella di lavoro, vedere Creare cartelle di lavoro per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout della cartella di lavoro, vedere gli esempi di riferimento seguenti nel repository Azure-Sentinel:

Creare regole di analisi

Le regole analitiche sono modelli che rilevano le minacce nei dati. Ogni regola è un file YAML. Per creare una regola analitica, vedere Creare regole di analisi per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout delle regole di analisi, vedere gli esempi di riferimento seguenti nel repository di Azure-Sentinel:

Creare query di ricerca

Le query di ricerca sono modelli che consentono ai clienti di cercare in modo proattivo le minacce nei dati. Vengono visualizzati nella scheda Ricerca perché gli analisti possano eseguirli manualmente. Condividono la stessa struttura YAML delle regole analitiche, ma non sono automatizzate; I campi di esecuzione programmata non si applicano e causano un fallimento della revisione se inclusi. Per creare una query di ricerca, vedere Creare query di ricerca per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout delle query di ricerca, vedere gli esempi di riferimento seguenti nel repository di Azure-Sentinel:

Creare playbook

I playbook sono flussi di lavoro automatizzati per la risposta che aiutano i clienti a rispondere alle minacce presenti nei propri dati. Ogni playbook è un flusso di lavoro di App per la logica di Azure esportato come modello ARM. I due file obbligatori sono azuredeploy.json e readme.md, inseriti in Solutions/<YourSolutionName>/Playbooks/<PlaybookName>/. Per creare un playbook, vedi Creare playbook per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout dei playbook, vedere gli esempi di riferimento seguenti nel repository Azure-Sentinel:

Creare parser

Un parser è una funzione Kusto salvata nell'area di lavoro Log Analytics che si colloca prima dei dati di log grezzi e li normalizza in campi puliti e interrogabili. Invece di scrivere la logica di estrazione dei campi in ogni query, i clienti chiamano l'alias del parser una volta e ottengono risultati strutturati. I parser vengono definiti come file YAML e distribuiti automaticamente quando un cliente installa la soluzione. Per creare un parser, vedere Creare parser per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout del parser, vedere gli esempi di riferimento seguenti nel repository di Azure-Sentinel:

Prova il pacchetto

Il test segue il pacchetto → distribuire → abilitare → ciclo di convalida . Il ciclo è lo stesso indipendentemente dalla quantità di contenuto creato. Lo strumento di creazione pacchetti V3 converte i file della soluzione in un modello arm distribuibile (mainTemplate.json). Distribuisci il modello nell'area di lavoro di sviluppo di Microsoft Sentinel, abilita ciascun tipo di contenuto e verifica che funzioni prima di inviare una PR.

Ripetere questo ciclo durante la compilazione. Non è necessario completare tutti i tipi di contenuto prima di iniziare il test. Crea il pacchetto e distribuiscilo man mano che completi ciascun tipo di contenuto, verifica che funzioni, quindi aggiungi altro contenuto e crea nuovamente il pacchetto.

Se la soluzione include un connettore dati, testare il connettore prima di compilare contenuto dipendente, ad esempio regole di analisi e cartelle di lavoro. Tutto il contenuto SIEM dipende dal flusso di dati nelle tabelle corrette con lo schema corretto. Se il connettore non funziona o lo schema non corrisponde a quello previsto dalle regole, sarà necessario rielaborare il contenuto dipendente. Assicurarsi che i dati vengano trasmessi per primi per risparmiare tempo.

Note

Solo per i connettori di polling CCF: Prima del packaging, è possibile verificare la configurazione di polling del connettore senza distribuirla in un'area di lavoro attiva. Nell'estensione Microsoft Sentinel per Visual Studio Code fare clic con il pulsante destro del mouse sul file di definizione del connettore e selezionare Test Connector (Connettore di test). Per informazioni dettagliate , vedere Passaggio 4: Convalidare la configurazione del connettore .

Imballare la tua soluzione

Dopo aver sviluppato e testato i componenti della soluzione Microsoft Sentinel, la creazione dei pacchetti è il passaggio critico successivo del ciclo di vita della soluzione. Lo strumento di creazione di pacchetti consolida tutto il contenuto della soluzione, ovvero connettori dati, parser, cartelle di lavoro, regole analitiche, query di ricerca, Azure connettori personalizzati delle app per la logica e playbook, in un formato standardizzato per la distribuzione. Per altre informazioni, vedere Creare un pacchetto di una soluzione SIEM per Microsoft Sentinel.

Vai al mercato

Quando si seleziona Go live, la soluzione passa attraverso un controllo di certificazione finale prima di diventare disponibile pubblicamente. Dopo la certificazione, la soluzione viene elencata nell'hub del contenuto Microsoft Sentinel e visibile nell'area di lavoro Sentinel di ogni tenant del cliente in Hub contenuto. È anche rilevabile su Azure Marketplace. La soluzione è ora disponibile per tutti i clienti Microsoft Sentinel. Per maggiori informazioni, consulta Pubblica soluzioni SIEM su Microsoft Sentinel.

Da questo momento in poi, qualsiasi aggiornamento alla soluzione, ad esempio modifiche al contenuto, correzioni di bug e incrementi di versione, richiede una nuova pull request su GitHub, una nuova versione del pacchetto e un nuovo invio al Partner Center con il file ZIP aggiornato. Per tenere traccia dello stato e dei problemi di supporto post-pubblicazione, vedere Tenere traccia della soluzione dopo la pubblicazione nel Centro per i partner.

Contenuti correlati

  • Last updated on