Creare un pacchetto di una soluzione SIEM per Microsoft Sentinel

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. Questo processo di creazione automatica dei pacchetti genera i modelli e i file di configurazione arm necessari, convalida la struttura del pacchetto e prepara l'artefatto della soluzione per l'invio al Centro per i partner. La creazione di pacchetti garantisce che la soluzione sia formattata correttamente, completa e pronta per la distribuzione dei clienti nei propri ambienti Sentinel.

Imballare la tua soluzione

Lo strumento di creazione pacchetti offre un modo semplice per generare il pacchetto della soluzione in modo automatizzato e convalidare il pacchetto generato. È possibile raggruppare in un pacchetto diversi tipi di contenuti di Microsoft Sentinel che includono una combinazione di connettori dati, parser, cartelle di lavoro, regole di analisi, query di ricerca proattiva, connettori personalizzati di App per la logica di Azure e playbook.

Lo strumento di creazione del pacchetto V3 produce i file seguenti:

• mainTemplate.json Un singolo modello ARM che combina tutto il contenuto della soluzione
• createUIDefinition.json Definizione della procedura guidata di installazione dell'hub di contenuti
• Controllo delle versioni .zip dei due file. Questo è l'artefatto inviato al Centro per i partner.

Dalla radice del repository in PowerShell:

cd Tools\Create-Azure-Sentinel-Solution\V3
.\createSolutionV3.ps1

Lo script ti chiede il percorso della tua cartella Data/ (per esempio C:\GitHub\Azure-Sentinel\Solutions\<YourSolutionName>\Data). Per informazioni dettagliate, vedere le linee guida per gli strumenti per la creazione di pacchetti di soluzioni .

Distribuire e abilitare

Eseguire la distribuzione mainTemplate.json nell'area di lavoro di sviluppo/test Microsoft Sentinel usando il portale di Azure:

1. Nel portale di Azure cercare Distribuisci un modello personalizzato e selezionarlo.
2. Selezionare Compila un modello personalizzato nell'editor, incollare il contenuto di mainTemplate.jsone salvare.
3. Specificare i parametri. Selezionare la sottoscrizione, il gruppo di risorse e l'area di lavoro in cui viene distribuito Microsoft Sentinel.
4. Selezionare Rivedi + crea, quindi Crea.

È anche possibile eseguire la distribuzione tramite interfaccia della riga di comando di Azure:

az deployment group create \
  --resource-group <your-resource-group> \
  --template-file Package/mainTemplate.json \
  --parameters workspaceName=<your-workspace-name> location=<your-location>

Al termine della distribuzione, attivare e testare ogni tipo di contenuto in questo ordine:

1. Connettore dati Passare a Connettori dati, trovare il connettore, aprire la pagina del connettore e abilitarlo. Seguire la procedura di configurazione per iniziare a inviare dati all'area di lavoro.

2. Verificare l'inserimento dati Dopo aver abilitato il connettore, eseguire una query sulla tabella per verificare che i record arrivino:

   <YourTable_CL>
   | take 10
   

   L'acquisizione iniziale può richiedere fino a 30 minuti. Se non vengono visualizzati dati, controllare la pagina relativa allo stato del connettore ed esaminare eventuali messaggi di errore prima di continuare.

3. Regole analitiche Passare ad Analisi, trovare le regole in Modelli di regola e abilitarle. Conferma che le regole generino avvisi o incidenti utilizzando i dati di test.

4. Query di ricerca Passare a Ricerca, trovare le query ed eseguirle sui dati inseriti. Confermare che i risultati vengano restituiti e che le mappature delle entità siano visualizzate correttamente.

5. Playbook Distribuisci qualsiasi playbook, autorizza le connessioni di Logic App e associalo a una regola di automazione o a una regola di analisi. Attivare un incidente di test per verificare l'esecuzione end-to-end.

6. Cartelle Passare a Cartelle di lavoro, trovare il modello di cartella di lavoro e salvare un'istanza. Verificare che tutte le visualizzazioni siano popolate con i dati inseriti.

7. Parser Eseguire l'alias della funzione parser direttamente in Log Analytics per verificare che l'estrazione dei campi sia corretta:

   <YourParserAlias>
   | take 10
   

Usa il monitoraggio dello stato di Sentinel per monitorare l'attività del connettore e diagnosticare i problemi di acquisizione. Vai a Impostazioni>Stato oppure esegui una query sulle tabelle SentinelHealth e SentinelAudit. Per informazioni dettagliate, vedere Controllo e monitoraggio dell'integrità in Microsoft Sentinel.

Eseguire verifiche locali

Due tipi di controlli ti aiutano a superare con successo una PR.

• Lo script di convalida locale esegue controlli automatizzati sui file della soluzione e rileva la maggior parte dei problemi di struttura e di schema prima di aprire una PR.
• L'elenco di controllo di pre-invio include controlli manuali, ad esempio verificando che la descrizione del connettore sia significativa, che i collegamenti vengano risolti e che lo schema della tabella sia bloccato. Questi sono controlli che lo script di convalida locale non può valutare per conto dell'utente. Eseguire entrambe le operazioni prima dell'invio.

Eseguire la suite di convalida locale dalla directory radice del repository:

Prerequisiti (solo prima volta):

npm install
npm run tsc

Eseguite le convalide rispetto alle modifiche apportate al ramo:

# From the repository root — auto-diffs your branch against main/master
node .script/local-validation/validate.js

# Or validate everything in your solution folder regardless of git status
node .script/local-validation/validate.js --path "Solutions/<YourSolutionName>"

Risolvere tutti i problemi prima di aprire la PR. Gli errori in questo passaggio vengono visualizzati come controlli CI non riusciti e bloccano l'unione.

Elenco di controllo di pre-invio

Prima di aprire una richiesta pull, confermare ciascun elemento applicabile riportato di seguito.

Verificare la pacchettizzazione della soluzione

Verificare che il pacchetto della soluzione sia completo, corretto e pronto per l'invio. Per ogni invio di soluzione sono necessari i controlli seguenti.

Controllo delle versioni e denominazione

• La versione del pacchetto e il nome file ZIP del pacchetto sono gli stessi (ad esempio, 3.1.0.zip per la versione 3.1.0).
• La versione viene incrementata rispetto alla versione precedente ed è la stessa in SolutionMetadata.json, Data/Solution_*.jsonReleaseNotes.md, e il nome file ZIP del pacchetto.
• offerId e publisherId in SolutionMetadata.json e mainTemplate.json sono in minuscolo e corrispondono esattamente all'offerta del Partner Center.
• ReleaseNotes.md la voce è presente per questa versione con il formato corretto. Consulta le Note di rilascio per le intestazioni di colonna richieste e il formato della data.

Contenuto e personalizzazione

• Tutto il testo nel pacchetto usa "Microsoft Sentinel", non "Azure Sentinel". Controllare sia mainTemplate.json che createUiDefinition.json.
• Il nome della soluzione non contiene "MS Sentinel" o "Microsoft Sentinel" come prefisso (eccezione: i nomi che terminano con "soluzione per Microsoft Sentinel" sono accettabili).
• I conteggi dei componenti nella createUiDefinition.json sezione Informazioni di base sono corretti e in questo ordine: Connettori dati, Parser, Cartelle di lavoro, Regole analitiche, Query di ricerca, Watchlist, Connettore App per la logica di Azure personalizzato, Playbook.
• Il testo della descrizione in createUiDefinition.json è completo, grammaticalmente corretto e include collegamenti alla documentazione del prodotto pertinente che rimandano correttamente.
• Le immagini a cui si fa riferimento in createUiDefinition.json vengono caricate correttamente e non sono danneggiate.
• Tutti i aka.ms collegamenti brevi in mainTemplate.json e createUiDefinition.json funzionano correttamente. Testa ognuno prima di inviare.

mainTemplate.json

• metadata node è presente con "kind": "Solution" e "type": "Microsoft.OperationalInsights/workspaces/providers/metadata".
• Le informazioni di supporto, l'autore e i dettagli del provider sono corretti.
• categories.domains i valori sono validi. Vedere le categorie di soluzioni.
• La versione dello schema del contenuto in mainTemplate.json è 3.0.0.
• Il file ZIP non contiene file di una versione precedente del pacchetto. Verificare il contenuto zip prima dell'invio.
• Convalida mainTemplate.json usando Distribuzione personalizzata nel portale di Azure per individuare gli errori del modello ARM prima di inviarlo.

createUiDefinition.json

• Convalidare tramite il Create UI Definition Sandbox per confermare che la procedura guidata di installazione venga visualizzata correttamente.

Registrazioni CI

• Ogni tabella di log personalizzata (*_CL) a cui si fa riferimento in regole, query o parser ha uno schema JSON in .script/tests/KqlvalidationsTests/CustomTables/ . La convalida KQL non riesce con "Il nome 'YourTable_CL' non fa riferimento ad alcuna tabella nota" se lo schema è mancante o in formato non valido.
• Il connettore id è registrato in .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json Ciò è necessario per le regole di analisi e le query di ricerca per passare la convalida dello schema.
• WorkbooksMetadata.json nella radice del repository è presente una voce per la cartella di lavoro.

Se si aggiorna una soluzione esistente

• Verificare che non venga accidentalmente eseguito l'override di alcun contenuto esistente. Se hai eseguito una riassegnazione o hai eseguito il pull delle ultime modifiche, controlla attentamente il differenziale prima di inviare.
• Se esiste già un connettore Funzioni di Azure e si aggiunge un connettore CCF, non rimuovere il connettore Funzioni di Azure senza conferma esplicita dal team del connettore. La sua rimozione potrebbe causare problemi ai clienti esistenti.

Verificare il logo

Verificare che il logo soddisfi i requisiti.

• Il logo soddisfa tutti i requisiti di file e SVG. Per altre informazioni, vedere Aggiungere il logo.
• Il logo viene visualizzato nitidamente a 75×75 px. Visualizza l'anteprima a quelle dimensioni prima di inviarla.

Verificare il connettore dati

Verificare che il codice JSON del connettore soddisfi i requisiti.

Denominazione e file

• Il nome file JSON è ProviderNameApplianceName.json senza spazi
• id il campo corrisponde alla base del nome file, ad esempio file ContosoFW.json → id: "ContosoFW" Non deve essere presente alcuno spazio e deve essere univoco tra tutti i connettori nel repository.
• titleè il nome del provider e dell'appliance con spazi, ad esempio . "Contoso Firewall"
• publisher è il nome del provider/fornitore
• Verificare che i nomi del fornitore e dell'appliance siano aggiornati. Le aziende e i prodotti vengono spesso rinominati o acquisiti, quindi confermare che i nomi siano ancora corretti prima di inviare.

Descrizione e istruzioni

• descriptionMarkdown spiega in modo significativo quali dati vengono inseriti dal connettore, in quale formato e collegamenti alla documentazione del prodotto del fornitore, una descrizione generica verrà contrassegnata durante la revisione
• I passaggi di istruzioni vengono personalizzati per il prodotto specifico. Non devono essere testo segnaposto dal modello
• Tutti i passaggi di istruzione sono grammaticalmente corretti e con controllo ortografico
• Tutti gli URL nel connettore JSON si risolvono, inclusi tutti i collegamenti brevi aka.ms. I collegamenti interrotti sono uno degli ostacoli più comuni nella revisione della PR. Verificare che ogni collegamento funzioni prima dell'invio

Tipo di dati

• I nomi dei tipi di dati seguono il formato corretto per il tipo di connettore e non hanno spazi in DATATYPE_NAME:
  • CEF: CommonSecurityLog (DATATYPE_NAME)
  • Syslog: Syslog (DATATYPE_NAME)
  • API REST (CCF o Funzioni di Azure):DATATYPE_NAME_CL
• DATATYPE_NAME rappresenta il provider, l'appliance e, facoltativamente, la categoria di dati. Deve essere descrittivo, non generico.

Autorizzazioni

• permissions blocco corrisponde esattamente al modello del tipo di connettore pertinente. Confrontare la proprietà per proprietà con DataConnectors/Templates/. Non aggiungere, rimuovere o modificare singole proprietà.

KQL

• Ogni voce graphQuery, connectivityCriteria e sampleQuery viene eseguita senza errori in Analisi dei log rispetto ai tuoi dati.

Metadata

• metadata il blocco è presente nel connettore JSON
• metadata.id è un GUID. Generare un GUID con [guid]::NewGuid() in PowerShell e verificare che non esista già nel repository.
• metadata.support include un attributo email o un attributo link.

Dipendenza del parser

• Se il connettore dipende da un parser per consentire ai clienti di eseguire query sui dati come richiesto per Syslog e CEF e si applica a qualsiasi tipo di connettore in cui i dati non elaborati non sono direttamente queryabili, il parser YAML è in Solutions/<Name>/Parsers/e il connettore JSON lo fa riferimento in entrambe instructionSteps le note e additionalRequirementBanner con un collegamento alla funzione Kusto.

Controlli aggiuntivi per i connettori Funzioni di Azure

• azuredeploy_DataConnector_API_AzureFunctionApp_template.json è presente in Data Connectors/.
• run.ps1 o run.py e tutti i file di supporto sono presenti.
• È presente un .zip di tutti i file dell'app per le funzioni; i file zip delle funzioni Python devono includere una cartella .python_packages.
• Il FunctionName parametro ha entrambe le minLength proprietà e maxLength
• Il modello ARM non contiene una risorsa Microsoft.Web/sites/hostNameBindings. Rimuovere se presente.
• L'URL Azure Deploy codificato nel JSON del connettore funziona end-to-end tramite l'esperienza di distribuzione nel portale di Azure.
• Lo script della funzione viene eseguito senza errori di sintassi.

Verificare le cartelle di lavoro

Verificare che il codice JSON della cartella di lavoro soddisfi i requisiti.

Voce WorkbooksMetadata.json

• WorkbooksMetadata.json nella radice del repository è presente una nuova voce per la cartella di lavoro. Unione di blocchi di immissione mancanti o in formato non valido.
• workbookKey è univoco. Nessuna voce esistente nel file usa la stessa chiave.
• description viene compilato ed è grammaticalmente corretto.
• logoFileName punta al file SVG del logo; il file del logo è incluso nella PR e supera l'elenco di controllo del logo.
• dataTypesDependencies elenca tutte le tabelle delle query della cartella di lavoro: "CommonSecurityLog" per i connettori CEF, "Syslog" per i connettori Syslog, "DATATYPE_CL" per i connettori di log personalizzati. Più tipi sono validi, ad esempio ["CommonSecurityLog", "Contoso_CL"].
• dataConnectorsDependencies corrisponde esattamente al id campo nel codice JSON del connettore. Sono validi più connettori, ad esempio ["ContosoFW", "ContosoCloud"].
• previewImagesFileNames elenca i nomi file dell'immagine di anteprima; ogni file è presente in Solutions/<Name>/Workbooks/Images/Preview/ e i nomi file corrispondono esattamente a ciò che si trova nei metadati.
• version il campo è presente; se si tratta di un aggiornamento di una cartella di lavoro esistente, la versione viene incrementata.
• title è il nome visualizzato nella galleria Workbooks. Le parentesi nel titolo non sono consentite.
• templateRelativePath corrisponde al nome file JSON effettivo della cartella di lavoro, "ContosoFirewall.json"ad esempio .
• provider è il nome della società o del fornitore.
• WorkbooksMetadata.json è json valido. Convalidare con un linter JSON prima dell'invio. Una virgola finale o una chiave duplicata causa un errore di compilazione immediato.

Immagini di anteprima

• Sono inclusi almeno uno sfondo scuro e uno screenshot di sfondo chiaro.
• Le immagini sono in formato PNG.
• I nomi file di sfondo scuro contengono "Black", ad esempio ; ContosoFirewallBlack.pngi nomi file di sfondo chiaro contengono "White", ad esempio ContosoFirewallWhite.png.
• Più screenshot per tema sono numerati con un suffisso: ContosoFirewallBlack1.png, ContosoFirewallBlack2.png.

Contenuto della cartella di lavoro

• Tutte le query nella cartella di lavoro vengono eseguite senza errori di sintassi KQL.
• La cartella di lavoro include almeno 4 grafici o visualizzazioni.
• Il file JSON della cartella di lavoro si trova in Solutions/<YourSolutionName>/Workbooks/, non nella cartella radice Workbooks/ .
• Dopo la creazione del pacchetto, confermare che createUiDefinition.json fa riferimento al nome file della cartella di lavoro come stringa statica, non come un'espressione ARM dinamica come [steps('workbooks').workbook1.workbook1-name].
• Tutti i collegamenti brevi aka.ms nella cartella di lavoro vengono risolti. Verificare ognuno di essi prima dell'invio.
• Se la cartella di lavoro richiede un parser, includere una nota nella descrizione della cartella di lavoro o nel testo dell'istruzione che informa i clienti di distribuire il parser e salvarlo come funzione denominata <FunctionName>. Senza questa nota, le query della cartella di lavoro che fanno riferimento all'alias della funzione hanno esito negativo.
• Se la cartella di lavoro usa ThreatIntelligenceIndicator, seguire le linee guida per la corrispondenza TI oltre a questi criteri.

Verificare le regole analitiche

Verificare che la regola di analisi YAML soddisfi i requisiti.

• id è un GUID. Cercare nel repository per verificare che non esista già prima dell'invio.
• requiredDataConnectors[].connectorId corrisponde esattamente a id nel codice JSON del connettore.
• Ogni voce in relevantTechniques appartiene ad almeno uno dei tactics elencati.
• entityMappings è presente con almeno una mappatura.
• Non c'è alcun blocco metadata. Rimuoverlo se la regola è stata copiata da una regola autonoma in Detections/.

Verificare le query di ricerca

Verifica che la query di ricerca avanzata in formato YAML soddisfi i requisiti.

Struttura e campi

• L'estensione del file è .yaml, non .yml.
• id è un GUID e non esiste già nel repository.
• Non sono presenti campi specifici della regola analitica: kind, severity, queryFrequencyqueryPeriod, triggerOperator, triggerThreshold, alertDetailsOverride. eventGroupingSettings
• Non è presente alcun blocco metadata. Rimuovilo se la query è stata copiata da una query autonoma in Hunting Queries/; se si invia contenuto autonomo al di fuori di una soluzione, metadata.source.kind deve essere "Community".

Nome e descrizione

• name è di 50 caratteri o meno.
• name corrisponde o è molto vicino al nome file.
• description riflette la finalità effettiva della query, non una copia del nome e non il testo segnaposto.
• description è di 255 caratteri o meno.
• description include riferimenti o collegamenti, se applicabile, ad esempio la documentazione del fornitore, la pagina tecnica MITRE.

Tattiche e tecniche

• È presente almeno una tactics voce.
• È presente almeno una voce relevantTechniques; includere, ove applicabile, le designazioni delle sottotecniche, ad esempio T1078.004 e non solo T1078.
• Ogni tecnica appartiene ad almeno una delle tattiche elencate.

Connettori dati necessari

• requiredDataConnectors[].connectorId corrisponde esattamente a id nel codice JSON del connettore.
• Tutti i tipi di dati sottoposti a query in KQL sono elencati in requiredDataConnectors[].dataTypes.
• Se la query usa una tabella personalizzata (*_CL), è presente un codice JSON dello schema per tale tabella in .script/tests/KqlvalidationsTests/CustomTables/.

Qualità delle query

• Le query vengono eseguite senza errori sui dati inseriti
• La query non contiene un filtro temporale codificato direttamente. Il pannello Ricerca inserisce l'intervallo di tempo selezionato dall'analista in fase di esecuzione.
• StartTimee EndTime vengono usati in summarize per visualizzare i limiti temporali nei risultati (nonStartTimeUtc/EndTimeUtc ).
• summarize include count() o dcount() ove appropriato.
• project o summarize il risultato è limitato ai campi di contesto. Non mostrare tutte le colonne grezze.
• Usare has invece di contains dove possibile. has è compatibile con l'indice e più veloce in tabelle di grandi dimensioni. Utilizzare contains solo quando è effettivamente necessaria una corrispondenza di sottostringa.
• Usare operatori senza distinzione tra maiuscole e minuscole (=~, in~, !~) dove appropriato.
• Parametrizza i valori ripetuti utilizzando istruzioni let, ove appropriato.
• Verificare la query rispetto alla Guida di stile per le query prima di inviarla.
• Tutti i collegamenti brevi aka.ms vengono risolti. Verificare ognuno di essi prima dell'invio.
• Se la query usa ThreatIntelligenceIndicator:, seguire le linee guida per la corrispondenza TI oltre a questi criteri.

Verificare i playbook

Verificare che il modello ARM del playbook e il file Leggimi soddisfino i requisiti.

• readme.md include tutte le sezioni obbligatorie: titolo e descrizione, pulsanti Distribuzione rapida, Prerequisiti (scrittura None se non sono presenti), passaggi post-distribuzione, Screenshot
• La risorsa del workflow name è "[parameters('PlaybookName')]", non codificata in modo statico
• Tutti i nomi delle variabili di connessione derivano da PlaybookName utilizzando concat()
• Il modello ARM $schema è l'URI del modello di distribuzione 2019-04-01
• Nessun ID della sottoscrizione, ID del tenant o nome del gruppo di risorse codificato in modo statico
• metadata.releaseNotes la matrice è presente nella risorsa del flusso di lavoro

Verificare i parser

Verificare che il parser YAML soddisfi i requisiti.

• Function.Version e Function.LastUpdated sono stringhe tra virgolette, ad esempio '1.0.0' non 1.0.0, '2026-06-15' non 2026-06-15.
• I dati di esempio sono disponibili per testare il parser in un'area di lavoro di sviluppo.
• Il parser viene distribuito senza errori in Analisi dei log come funzione Kusto.
• L'esecuzione del parser sui dati di esempio restituisce risultati con i campi previsti popolati. Se si usa l'inserimento di log personalizzato per i test, verificare che il parser gestisca comunque il formato di inserimento effettivo prodotto dal connettore.
• Tutti i aka.ms link brevi nel parser YAML vengono risolti. Verificare ognuno di essi prima dell'invio.
• Se il parser usa ThreatIntelligenceIndicator, seguire le linee guida per la corrispondenza TI oltre a questi criteri prima di inviare.
• Se il parser esegue il mapping a uno schema ASIM (facoltativo ma consigliato), i campi di origine pertinenti vengono mappati alle colonne dello schema ASIM corrette e entrambe le varianti senza parametro (ASim<Schema><Product>.yaml) e con parametri (vim<Schema><Product>.yaml) vengono registrate nel parser unificante corrispondente in Parsers/ASim<Schema>/.

Apri una pull request su GitHub

Una volta testata la soluzione, superata la convalida locale e verificato il flusso dei dati end-to-end, eseguire il commit dei file e aprire una richiesta pull dal fork verso il ramo master del repository Sentinel di Azure. Se non hai eseguito il fork e clonato il repository e creato un ramo, consulta Eseguire il fork e clonare il repository nella sezione Configurare l'ambiente.

Fai il commit dei tuoi file

Prepararsi per il commit di tutti i file di soluzione dalla radice del repository. Per una nuova soluzione, sono inclusi i seguenti elementi:

git add Solutions/<YourSolutionName>/
git add Logos/<YourLogo>.svg
git add Solutions/<YourSolutionName>/Package/

# If adding custom table schemas or connector ID registration:
git add .script/tests/KqlvalidationsTests/CustomTables/<YourTable_CL>.json
git add .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json

git commit -m "Add <YourSolutionName> solution"
git push origin <your-branch-name>

Cosa includere nella PR

La PR deve contenere tutti i seguenti elementi:

• Tutti i file di contenuto della soluzione in Solutions/<YourSolutionName>/
• Il tuo logo SVG in Logos/
• La soluzione pacchettizzata sotto Solutions/<YourSolutionName>/Package/ (mainTemplate.json, createUIDefinition.json e il .zip)
• Eventuali file di schema di tabella personalizzati aggiunti a .script/tests/KqlvalidationsTests/CustomTables/
• Il connettore id è stato aggiunto a .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json

Descrizione della PR

Apri la PR per Azure:master. Il modello di PR contiene campi obbligatori. Compilarli prima dell'invio. Eliminare il blocco di linee guida (la sezione tra le righe tratteggiate) prima di inviare:

Change(s):
- Added <YourSolutionName> solution with data connector, analytic rules, and workbook.

Reason for Change(s):
- New solution for <Your Product> integration with Microsoft Sentinel.

Version updated:
- Yes — <version>

Testing Completed:
- Yes — deployed mainTemplate.json to dev workspace, confirmed data ingestion in <YourTable_CL>, analytic rules active, workbook loads.

Checked that the validations are passing and have addressed any issues that are present:
- Yes — ran local validation suite, all checks pass.

Controlli CI e revisione manuale

Quando apri la PR, i controlli CI automatizzati vengono eseguiti sui tuoi file. Rivedi eventuali problemi nella scheda Controlli e invia le correzioni al tuo ramo. Assicurarsi che la validazione locale sia superata prima di aprire la PR — gli errori CI al momento dell'invio rallentano la coda di revisione.

Dopo che i controlli CI sono stati superati, un membro del team Microsoft Sentinel esaminerà la PR entro cinque giorni lavorativi dall'invio iniziale. Eventuali osservazioni vengono inserite come commenti sulla PR. Dopo aver eseguito il push delle correzioni, le revisioni di completamento vengono completate entro due giorni lavorativi.

La revisione potrebbe includere:

• Feedback tecnico sulla configurazione, lo schema o la qualità del contenuto del connettore
• Richieste di aggiornamento dei metadati, correzione di collegamenti interrotti o correzione della formattazione
• Domande sul comportamento dell'origine dati o del connettore

La PR viene approvata e integrata in master dopo che la revisione completa si è conclusa con esito positivo.

Pubblicare

Dopo aver unito la richiesta pull a master, creare e configurare l'offerta in Centro per i partner Microsoft per rendere disponibile la soluzione nel marketplace.

Prerequisiti prima di iniziare:

• PR integrata in master e pacchetto disponibile in Solutions/<YourSolutionName>/Package/ sul ramo master
• Account marketplace commerciale nel Centro per i partner. Iscriversi presto. Non attendere che la soluzione sia pronta. Vedi Creare un account del marketplace commerciale nel Centro per i partner.

Creare l'offerta:

1. In Partner Center, seleziona Offerte del Marketplace>Nuova offerta>Applicazione Azure.
2. Impostare l'ID offerta in modo che coincida con il offerId nel SolutionMetadata.json, ad esempio azure-sentinel-solution-<yourproduct>. Questo non può essere modificato dopo la creazione.
3. Seleziona il tuo ID editore . Deve corrispondere a publisherId in SolutionMetadata.json.

Configurazione dell'offerta chiave:

Per indicazioni complete sul campo per campo, vedere Pubblicare una soluzione Microsoft Sentinel.

Preview

Dopo aver inviato l'offerta nel Centro per i partner, la soluzione entra in anteprima prima di passare in diretta a tutti i clienti. In questa fase, la soluzione è disponibile solo per gli ID sottoscrizione Azure aggiunti nella scheda Destinatari di anteprima.

Usare il periodo di anteprima per:

• Installare la soluzione dal Marketplace nelle sottoscrizioni di test e verificare l’intera esperienza di installazione del cliente
• Verificare che mainTemplate.json venga distribuito correttamente, che tutti i contenuti siano visualizzati nei pannelli di Sentinel e che il connettore si connetta correttamente
• Condividi con clienti selezionati del programma Design Partner utilizzando gli ID della sottoscrizione per ottenere un primo riscontro

Dopo che tu e gli eventuali clienti in anteprima avete convalidato la soluzione, seleziona Go live nel Partner Center per passare a Go to Market.

Contenuti correlati

• Sviluppare una soluzione Microsoft Sentinel
• Creare un connettore senza codice per Microsoft Sentinel
• catalogo delle soluzioni Microsoft Sentinel
• Linee guida generali sui contributi per Microsoft Sentinel