Paketieren einer SIEM-Lösung für Microsoft Sentinel

Nachdem Sie Ihre Microsoft Sentinel Lösungskomponenten entwickelt und getestet haben, ist die Verpackung der nächste wichtige Schritt im Lösungslebenszyklus. Das Packaging-Tool konsolidiert alle Inhalte Ihrer Lösung – Datenkonnektoren, Parser, Arbeitsmappen, Analyseregeln, Hunting-Abfragen, benutzerdefinierte Konnektoren für Azure Logic Apps und Playbooks – in einem standardisierten Format zur Bereitstellung. Dieser automatisierte Verpackungsprozess generiert die erforderlichen ARM-Vorlagen und Konfigurationsdateien, überprüft die Paketstruktur und bereitet Ihr Lösungsartefakt für die Übermittlung an das Partner Center vor. Das Verpacken stellt sicher, dass Ihre Lösung ordnungsgemäß formatiert, vollständig und bereit für Kunden ist, die sie in ihren Sentinel-Umgebungen bereitstellen können.

Verpacken Sie Ihre Lösung

Das Verpackungstool bietet eine einfache Möglichkeit, Ihr Lösungspaket auf automatisierte Weise zu generieren und das generierte Paket zu validieren. Sie können verschiedene Arten von Microsoft Sentinel-Inhalten paketieren, darunter eine Kombination aus Datenkonnektoren, Parsern, Arbeitsmappen, Analyseregeln, Hunting-Abfragen, benutzerdefinierten Connectors für Azure Logic Apps und Playbooks.

Das V3-Paketerstellungstool erzeugt die folgenden Dateien:

• mainTemplate.json Eine einzelne ARM-Vorlage, die alle Lösungsinhalte kombiniert
• createUIDefinition.json Definition des Installationsassistenten für Content Hub
• Eine Version .zip der beiden Dateien. Dies ist das Artefakt, das Sie an partner Center übermitteln.

Aus dem Repositorystamm in PowerShell:

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

Das Skript fordert Sie zur Eingabe des Pfads zu Ihrem Data/ Ordner auf (z. B C:\GitHub\Azure-Sentinel\Solutions\<YourSolutionName>\Data. ). Ausführliche Informationen finden Sie in den Anleitungen zum Packen von Lösungen .

Bereitstellen und Aktivieren

Stellen Sie mainTemplate.json mithilfe des Azure Portals in Ihrem Entwicklungs-/Test-Microsoft Sentinel Arbeitsbereich bereit:

1. Suchen Sie im Azure-Portal nach "Bereitstellen einer benutzerdefinierten Vorlage", und wählen Sie sie aus.
2. Wählen Sie "Eigene Vorlage erstellen" im Editor aus, fügen Sie den Inhalt ein mainTemplate.json, und speichern Sie sie.
3. Fügen Sie die Parameter ein. Wählen Sie Ihr Abonnement, Ihre Ressourcengruppe und den Arbeitsbereich aus, in dem Microsoft Sentinel bereitgestellt wird.
4. Wählen Sie Überprüfen + erstellen und danach Erstellen aus.

Sie können auch über Azure CLI bereitstellen:

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

Aktivieren und üben Sie nach Abschluss der Bereitstellung jeden Inhaltstyp in der folgenden Reihenfolge aus:

1. Datenconnector Wechseln Sie zu Datenconnectors, suchen Sie Ihren Connector, öffnen Sie die Connectorseite, und aktivieren Sie ihn. Führen Sie die Konfigurationsschritte aus, um mit dem Senden von Daten an Ihren Arbeitsbereich zu beginnen.

2. Überprüfen der Datenaufnahme Nachdem Sie den Connector aktiviert haben, fragen Sie die Tabelle ab, um zu bestätigen, dass Datensätze eingetroffen sind:

   <YourTable_CL>
   | take 10
   

   Die erstaufnahme kann bis zu 30 Minuten dauern. Wenn keine Daten angezeigt werden, überprüfen Sie die Connectorstatusseite, und überprüfen Sie alle Fehlermeldungen, bevor Sie fortfahren.

3. Analytische Regeln Wechseln Sie zu "Analytics", suchen Sie Ihre Regeln unter Regelvorlagen, und aktivieren Sie sie. Vergewissern Sie sich, dass die Regeln Warnungen oder Vorfälle mit Ihren Testdaten generieren.

4. Suchabfragen Wechseln Sie zur Suche, suchen Sie Ihre Abfragen, und führen Sie sie für Ihre erfassten Daten aus. Stellen Sie sicher, dass Ergebnisse zurückgegeben werden und Entitätszuordnungen korrekt angezeigt werden.

5. Playbooks Stellen Sie beliebige Playbooks bereit, autorisieren Sie die Logic App-Verbindungen und weisen Sie sie einer Automatisierungsregel oder Analyseregel zu. Lösen Sie einen Testvorfall aus, um die End-to-End-Ausführung zu überprüfen.

6. Arbeitsmappen Wechseln Sie zu "Arbeitsmappen", suchen Sie ihre Arbeitsmappenvorlage, und speichern Sie eine Instanz. Vergewissern Sie sich, dass alle Visualisierungen mit Ihren aufgenommenen Daten aufgefüllt werden.

7. Parser Führen Sie den Parser-Funktionsalias direkt in Log Analytics aus, um zu bestätigen, dass die Feldextraktion korrekt ist:

   <YourParserAlias>
   | take 10
   

Verwenden Sie die Sentinel-Systemzustandsüberwachung, um Connector-Aktivitäten zu überwachen und Erfassungsprobleme zu diagnostizieren. Wechseln Sie zu Einstellungen>Integrität oder fragen Sie die SentinelHealth- und SentinelAudit-Tabellen ab. Weitere Informationen finden Sie unter Überwachung und Integritätsüberwachung in Microsoft Sentinel.

Ausführen lokaler Überprüfungen

Zwei Arten von Prüfungen helfen Ihnen, erfolgreich durch eine PR zu gelangen.

• Das lokale Überprüfungsskript führt automatisierte Überprüfungen ihrer Lösungsdateien durch und erfasst die meisten strukturellen und Schemaprobleme, bevor Sie eine PR öffnen.
• Die Checkliste vor der Einreichung umfasst manuelle Prüfungen, z. B. ob Ihre Connector-Beschreibung aussagekräftig ist, Links funktionieren und Ihr Tabellenschema gesperrt ist. Dies sind Prüfungen, die das lokale Validierungsskript nicht für Sie auswerten kann. Führen Sie beide vor dem Absenden aus.

Führen Sie die lokale Validierungssuite aus dem Repositorystamm aus:

Voraussetzungen (nur zum ersten Mal):

npm install
npm run tsc

Führen Sie Überprüfungen für Ihre Verzweigungsänderungen aus:

# 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>"

Beheben Sie alle Fehler, bevor Sie Ihre PR öffnen. Fehler in diesem Schritt werden als fehlgeschlagene CI-Überprüfungen angezeigt und blockieren die Zusammenführung.

Prüfliste für die Vorübermittlung

Bevor Sie eine PR öffnen, vergewissern Sie sich, dass jeder unten aufgeführte Punkt zutrifft.

Überprüfen des Lösungspakets

Stellen Sie sicher, dass Ihr Lösungspaket vollständig, richtig und bereit für die Übermittlung ist. Für jede Lösungsübermittlung sind die folgenden Prüfungen erforderlich.

Versionsverwaltung und Benennung

• Paketversions- und Paket-ZIP-Dateiname sind identisch (z. B 3.1.0.zip . für Version 3.1.0).
• Die Version wird gegenüber dem vorherigen Release erhöht und ist in SolutionMetadata.json, Data/Solution_*.json, ReleaseNotes.md und im ZIP-Dateinamen des Pakets dieselbe.
• offerId und publisherId in SolutionMetadata.json und mainTemplate.json sind Kleinbuchstaben und entsprechen Ihrem Partner Center-Angebot genau.
• ReleaseNotes.md Der Eintrag ist für diese Version mit dem richtigen Format vorhanden. Siehe Versionshinweise für die erforderlichen Spaltenüberschriften und das Datumsformat.

Inhalt und Branding

• Der gesamte Text im Paket verwendet "Microsoft Sentinel", nicht "Azure Sentinel". Überprüfen Sie beide mainTemplate.json und createUiDefinition.json.
• Der Lösungsname enthält nicht "MS Sentinel" oder "Microsoft Sentinel" als Präfix (Ausnahme: Namen, die mit "Lösung für Microsoft Sentinel" enden, sind akzeptabel).
• Die Anzahl der Komponenten im Abschnitt createUiDefinition.json „Grundlagen“ ist korrekt und in dieser Reihenfolge: Datenkonnektoren, Parser, Arbeitsmappen, Analyseregeln, Hunting-Abfragen, Watchlists, benutzerdefinierter Azure Logic Apps-Konnektor, Playbooks.
• Der Beschreibungstext in createUiDefinition.json ist vollständig, grammatikalisch korrekt und enthält Links zur relevanten Produktdokumentation, die korrekt funktionieren.
• Bilder, auf die in createUiDefinition.json verwiesen wird, werden korrekt geladen und sind nicht beschädigt.
• Alle aka.ms kurzen Links in mainTemplate.json und createUiDefinition.json auflösen. Testen Sie die einzelnen Tests vor der Übermittlung.

mainTemplate.json

• metadata Knoten ist mit "kind": "Solution" und "type": "Microsoft.OperationalInsights/workspaces/providers/metadata" vorhanden.
• Supportinformationen, Autor und Anbieterdetails sind korrekt.
• categories.domains Werte sind gültig. Siehe Lösungskategorien.
• Inhaltsschemaversion in mainTemplate.json ist 3.0.0.
• Die ZIP-Datei enthält keine Dateien aus einer älteren Paketversion. Überprüfen Sie den ZIP-Inhalt vor der Übermittlung.
• Validieren Sie mainTemplate.json mithilfe von Benutzerdefinierte Bereitstellung im Azure-Portal, um ARM-Vorlagenfehler vor dem Übermitteln zu erkennen.

createUiDefinition.json

• Validieren Sie mithilfe der Create UI Definition Sandbox, dass der Installations-Assistent korrekt angezeigt wird.

CI-Registrierungen

• Jede benutzerdefinierte Protokolltabelle (*_CL), auf die in Regeln, Abfragen oder Parsern verwiesen wird, verfügt über ein Schema-JSON in .script/tests/KqlvalidationsTests/CustomTables/ . Die KQL-Überprüfung schlägt mit "Der Name 'YourTable_CL' verweist nicht auf eine bekannte Tabelle" fehl, wenn das Schema fehlt oder falsch formatiert ist.
• Ihr Connector id ist in .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json registriert. Dies ist erforderlich, damit Analyseregeln und Hunting-Abfragen die Schemaüberprüfung bestehen.
• WorkbooksMetadata.json im Stammverzeichnis des Repositorys enthält einen Eintrag für Ihre Arbeitsmappe.

Beim Aktualisieren einer vorhandenen Lösung

• Vergewissern Sie sich, dass kein vorhandener Inhalt versehentlich außer Kraft gesetzt wird. Wenn Sie eine Neubasis haben oder die neueste Version abgerufen haben, überprüfen Sie den Diff sorgfältig, bevor Sie die Übermittlung einreichen.
• Wenn bereits ein Azure Functions Connector vorhanden ist und Sie einen CCF-Connector hinzufügen, entfernen Sie den Azure Functions Connector nicht ohne explizite Bestätigung vom Connectorteam. Das Entfernen könnte bestehende Kunden beeinträchtigen.

Überprüfen des Logos

Stellen Sie sicher, dass Ihr Logo die Anforderungen erfüllt.

• Das Logo erfüllt alle Datei- und SVG-Anforderungen. Weitere Informationen finden Sie unter Hinzufügen Ihres Logos.
• Das Logo wird bei 75×75 px klar dargestellt. Sehen Sie es sich in dieser Größe an, bevor Sie es senden.

Überprüfen Sie den Datenkonnektor

Stellen Sie sicher, dass Ihr Connector-JSON die Anforderungen erfüllt.

Datei und Benennung

• JSON-Dateiname ist ProviderNameApplianceName.json ohne Leerzeichen
• id das Feld entspricht der Dateinamenbasis, z. B. Datei ContosoFW.json → id: "ContosoFW" Es darf keine Leerzeichen vorhanden sein, und es muss zwischen allen Connectors im Repository eindeutig sein.
• title ist der Anbieter- und Appliance-Name mit Leerzeichen, "Contoso Firewall"z. B. .
• publisher ist der Name des Anbieters/Herstellers
• Überprüfen Sie, ob die Anbieter- und Appliance-Namen aktuelle Unternehmen sind und Produkte häufig umbenannt oder erworben werden, damit die Namen noch korrekt sind, bevor Sie übermitteln.

Beschreibung und Anweisungen

• descriptionMarkdown aussagekräftig erklärt, welche Daten der Connector liefert, in welchem Format sie vorliegen, und auf die Produktdokumentation des Anbieters verweist – eine allgemeine Beschreibung wird bei der Überprüfung beanstandet.
• Anleitungsschritte werden für das jeweilige Produkt angepasst. Sie sollten nicht Platzhaltertext aus der Vorlage sein.
• Alle Anweisungsschritte sind grammatikalisch korrekt und rechtschreibgeprüft.
• Alle URLs im Connector-JSON lassen sich auflösen, einschließlich aller aka.ms Kurzlinks. Fehlerhafte Links sind einer der häufigsten Blocker in der PR-Überprüfung. Überprüfen, ob jeder Link funktioniert, bevor er übermittelt wird

Datentypen

• Datentypnamen folgen dem richtigen Format für Den Verbindertyp und haben keine Leerzeichen in DATATYPE_NAME:
  • CEF: CommonSecurityLog (DATATYPE_NAME)
  • Syslog: Syslog (DATATYPE_NAME)
  • REST-API (CCF oder Azure Functions):DATATYPE_NAME_CL
• DATATYPE_NAME stellt den Anbieter, die Appliance und optional die Datenkategorie dar. Er sollte beschreibend und nicht generisch sein.

Erlaubnisse

• permissions block entspricht exakt der Vorlage für den relevanten Verbindertyp. Vergleichen Sie Eigenschaft für Eigenschaft mit DataConnectors/Templates/. Fügen Sie keine einzelnen Eigenschaften hinzu, entfernen oder ändern Sie sie nicht.

KQL

• Jeder graphQuery-, connectivityCriteria- und sampleQuery-Eintrag wird in Log Analytics für Ihre Daten fehlerfrei ausgeführt.

Metadata

• metadata-Block ist im Connector-JSON vorhanden.
• metadata.id ist eine GUID. Generieren Sie mit [guid]::NewGuid() in PowerShell eine GUID, und vergewissern Sie sich, dass sie nicht bereits irgendwo im Repository vorhanden ist.
• metadata.support enthält entweder ein email Attribut oder ein link Attribut.

Parserabhängigkeit

• Wenn der Connector von einem Parser für Kunden abhängt, um die Daten abzufragen, die für Syslog und CEF erforderlich sind, und gilt für jeden Connectortyp, in dem Rohdaten nicht direkt abfragbar sind, befindet sich der Parser YAML in Solutions/<Name>/Parsers/, und der Connector JSON verweist in beiden instructionSteps Notizen und additionalRequirementBanner mit einem Link zur Kusto-Funktion darauf.

Zusätzliche Überprüfungen für Azure Functions Connectors

• azuredeploy_DataConnector_API_AzureFunctionApp_template.json ist vorhanden in Data Connectors/.
• run.ps1 oder run.py und alle unterstützenden Dateien sind vorhanden.
• Ein .zip aller Function-App-Dateien ist vorhanden; Python-Funktions-ZIP-Dateien müssen einen .python_packages-Ordner enthalten.
• Der FunctionName-Parameter hat sowohl minLength- als auch maxLength-Eigenschaften
• Die ARM-Vorlage enthält keine Microsoft.Web/sites/hostNameBindings Ressource. Entfernen Sie es, falls vorhanden.
• Die codierte Azure-Deploy-URL in der Connector-JSON funktioniert durchgängig im Bereitstellungsworkflow des Azure-Portals.
• Das Funktionsskript wird ohne Syntaxfehler ausgeführt.

Überprüfen von Arbeitsmappen

Überprüfen Sie, ob Ihre Arbeitsmappe JSON die Anforderungen erfüllt.

Eintrag in WorkbooksMetadata.json

• WorkbooksMetadata.json im Stammverzeichnis des Repositorys enthält einen neuen Eintrag für diese Arbeitsmappe. Ein fehlender oder falsch formatierter Eintragsblock wird zusammengeführt.
• workbookKey ist einzigartig. Kein vorhandener Eintrag in der Datei verwendet denselben Schlüssel.
• description ist ausgefüllt und grammatikalisch korrekt.
• logoFileName verweist auf Ihre SVG-Logodatei; die Logodatei ist in der PR enthalten und übergibt die Logo-Checkliste.
• dataTypesDependencies listet alle Tabellen auf, die von der Arbeitsmappe abgefragt werden: "CommonSecurityLog" für CEF-Konnektoren, "Syslog" für Syslog-Konnektoren, "DATATYPE_CL" für benutzerdefinierte Protokollkonnektoren. Mehrere Typen sind gültig, zum Beispiel ["CommonSecurityLog", "Contoso_CL"].
• dataConnectorsDependencies entspricht dem id Feld in Ihrem Connector-JSON genau. Mehrere Verbinder sind gültig, zum Beispiel ["ContosoFW", "ContosoCloud"].
• previewImagesFileNames listet die Dateinamen der Vorschaubilder auf; jede Datei ist in Solutions/<Name>/Workbooks/Images/Preview/ vorhanden, und die Dateinamen entsprechen genau den Angaben in den Metadaten.
• version Feld ist vorhanden; wenn es sich um eine Aktualisierung einer bestehenden Arbeitsmappe handelt, wird die Version inkrementiert.
• title ist der Anzeigename, der in der Arbeitsmappen-Galerie angezeigt wird. Klammern im Titel sind nicht zulässig.
• templateRelativePath entspricht dem tatsächlichen JSON-Dateinamen der Arbeitsmappe, "ContosoFirewall.json"z. B. .
• provider ist Ihr Firmen-/Anbietername.
• WorkbooksMetadata.json ist gültiger JSON-Code. Überprüfen Sie vor der Übermittlung mit einem JSON-Linter. Ein nachfolgendes Komma oder doppelter Schlüssel verursacht einen sofortigen Buildfehler.

Vorschaubilder

• Mindestens ein dunkler Hintergrund und ein screenshot mit hellem Hintergrund sind enthalten.
• Bilder sind PNG-Format.
• Dateinamen für dunklen Hintergrund enthalten "Black", zum Beispiel ContosoFirewallBlack.png; Dateinamen für hellen Hintergrund enthalten "White", zum Beispiel ContosoFirewallWhite.png.
• Mehrere Screenshots pro Design werden mit einem Suffix nummeriert: ContosoFirewallBlack1.png, ContosoFirewallBlack2.png.

Arbeitsmappeninhalt

• Alle Abfragen in der Arbeitsmappe werden ohne KQL-Syntaxfehler ausgeführt.
• Die Arbeitsmappe verfügt über mindestens 4 Diagramme oder Visualisierungen.
• Die JSON-Datei der Arbeitsmappe befindet sich in Solutions/<YourSolutionName>/Workbooks/, nicht im Stammordner Workbooks/.
• Bestätigen Sie nach dem Verpacken, dass createUiDefinition.json auf den Dateinamen der Arbeitsmappe als statische Zeichenfolge verweist, nicht auf einen dynamischen ARM-Ausdruck wie [steps('workbooks').workbook1.workbook1-name].
• Alle aka.ms kurzen Verknüpfungen in der Arbeitsmappe werden aufgelöst. Überprüfen Sie vor der Übermittlung die einzelnen.
• Wenn für die Arbeitsmappe ein Parser erforderlich ist, fügen Sie in die Beschreibung der Arbeitsmappe oder in den Anleitungstext einen Hinweis ein, der die Kunden anweist, den Parser bereitzustellen und ihn als Funktion mit dem Namen <FunctionName> zu speichern. Ohne diese Notiz schlagen Arbeitsmappenabfragen, die auf den Funktionsalias verweisen, fehl.
• Wenn die Arbeitsmappe ThreatIntelligenceIndicator verwendet, befolgen Sie zusätzlich zu diesen Kriterien die TI-Abgleichsrichtlinien.

Überprüfen von Analyseregeln

Stellen Sie sicher, dass Ihre Analyseregel YAML die Anforderungen erfüllt.

• id ist eine GUID. Durchsuchen Sie das Repository vor dem Einreichen, um sicherzustellen, dass es nicht bereits existiert.
• requiredDataConnectors[].connectorId entspricht genau dem id in Ihrem Connector-JSON.
• Jeder Eintrag in relevantTechniques gehört zu mindestens einem der aufgeführten tactics.
• entityMappings ist mit mindestens einer Zuordnung vorhanden.
• Es gibt keinen metadata-Block. Entfernen Sie sie, wenn die Regel aus einer eigenständigen Regel in Detections/ kopiert wurde.

Überprüfen von Suchabfragen

Stellen Sie sicher, dass Ihre Suchabfrage YAML die Anforderungen erfüllt.

Struktur und Felder

• Dateierweiterung ist .yaml, nicht .yml.
• id ist eine GUID und ist noch nicht im Repository vorhanden.
• Es sind keine analytischen regelspezifischen Felder vorhanden: kind, , severity, queryFrequency, queryPeriod, triggerOperator, triggerThreshold, . alertDetailsOverrideeventGroupingSettings
• Es gibt keinen metadata-Block. Entfernen Sie ihn, wenn die Abfrage aus einer eigenständigen Abfrage in Hunting Queries/ kopiert wurde; wenn eigenständige Inhalte außerhalb einer Lösung eingereicht werden, muss metadata.source.kind"Community" sein.

Name und Beschreibung

• name beträgt 50 Zeichen oder weniger.
• name entspricht oder ist sehr nah am Dateinamen.
• description gibt die tatsächliche Absicht der Abfrage an, keine Kopie des Namens und keinen Platzhaltertext.
• description beträgt 255 Zeichen oder weniger.
• description enthält Verweise oder Links, sofern zutreffend, z. B. Lieferantendokumentation, MITRE-Technikseite.

Taktiken und Techniken

• Mindestens ein tactics Eintrag ist vorhanden.
• Mindestens ein relevantTechniques Eintrag ist vorhanden. Fügen Sie gegebenenfalls Untertechnikbezeichnungen hinzu, T1078.004 z. B. nicht nur T1078.
• Jede Technik gehört zu mindestens einer der aufgeführten Taktiken.

Erforderliche Datenkonnektoren

• requiredDataConnectors[].connectorId entspricht genau dem id in Ihrem Connector-JSON.
• Alle im KQL abgefragten Datentypen werden in requiredDataConnectors[].dataTypesaufgeführt.
• Wenn die Abfrage eine benutzerdefinierte Tabelle (*_CL) verwendet, ist ein Schema-JSON für diese Tabelle vorhanden..script/tests/KqlvalidationsTests/CustomTables/

Abfragequalität

• Die Abfrage wird für Ihre ingestierten Daten ohne Fehler ausgeführt.
• Abfrage enthält keinen hartcodierten Zeitfilter. Das Hunting Blade fügt zur Laufzeit den vom Analysten ausgewählten Zeitraum ein.
• StartTime und EndTime werden in summarize verwendet, um Zeitbegrenzungen in den Ergebnissen anzuzeigen (nicht StartTimeUtc/EndTimeUtc).
• summarize enthält count() oder dcount() gegebenenfalls.
• Die Ausgabe von project oder summarize ist auf Kontextfelder beschränkt. Zeigen Sie nicht jede Rohspalte an.
• Verwenden Sie has statt contains wo möglich. has ist in großen Tabellen indexfähig und schneller. Verwenden Sie contains nur, wenn eine Übereinstimmung mit einer Teilzeichenfolge wirklich erforderlich ist.
• Verwenden Sie gegebenenfalls Operatoren (=~, in~, !~) ohne Berücksichtigung der Groß-/Kleinschreibung.
• Parametrisieren Sie wiederholte Werte mithilfe von let Anweisungen, falls zutreffend.
• Überprüfen Sie die Abfrage vor der Übermittlung anhand des Abfrageformatvorlagenhandbuchs .
• Alle aka.ms kurzen Links lösen sich auf. Überprüfen Sie vor der Übermittlung die einzelnen.
• Wenn die Abfrage verwendet: ThreatIntelligenceIndicator befolgen Sie zusätzlich zu diesen Kriterien die TI-Übereinstimmungsrichtlinien.

Überprüfen von Playbooks

Vergewissern Sie sich, dass Ihre Playbook-ARM-Vorlage und -Infodatei die Anforderungen erfüllen.

• readme.md enthält alle erforderlichen Abschnitte: Titel und Beschreibung, Schaltflächen für schnelle Bereitstellung, Voraussetzungen (schreiben None , wenn keines vorhanden ist), Schritte nach der Bereitstellung, Screenshots
• Workflow-Ressource name ist "[parameters('PlaybookName')]" nicht hartkodiert
• Alle Namen der Verbindungsvariablen werden mithilfe von PlaybookName von concat() abgeleitet.
• ARM-Vorlage $schema ist die 2019-04-01 URI der Bereitstellungsvorlage
• Keine hartcodierten Abonnement-IDs, Mandanten-IDs oder Ressourcengruppennamen
• metadata.releaseNotes Das Array ist in der Workflow-Ressource vorhanden

Überprüfen von Parsern

Stellen Sie sicher, dass Ihr Parser YAML die Anforderungen erfüllt.

• Function.Version und Function.LastUpdated sind zitierte Zeichenfolgen, zum Beispiel '1.0.0', nicht 1.0.0, '2026-06-15', nicht 2026-06-15.
• Beispieldaten stehen zum Testen des Parsers in einem Entwicklungsarbeitsbereich zur Verfügung.
• Der Parser wird fehlerfrei als Kusto-Funktion in Log Analytics bereitgestellt.
• Wenn Sie den Parser mit Beispieldaten ausführen, liefert er Ergebnisse, bei denen die erwarteten Felder ausgefüllt sind. Wenn Sie zu Testzwecken eine benutzerdefinierte Log-Erfassung verwenden, stellen Sie sicher, dass der Parser weiterhin das tatsächliche Erfassungsformat verarbeitet, das Ihr Connector erzeugt.
• Alle aka.ms kurzen Links im Parser-YAML werden aufgelöst. Überprüfen Sie vor der Übermittlung die einzelnen.
• Wenn der Parser ThreatIntelligenceIndicator verwendet, beachten Sie zusätzlich zu diesen Kriterien vor dem Einreichen die TI-Matching-Richtlinien.
• Wenn der Parser einem ASIM-Schema (optional, aber empfohlen) zugeordnet ist, werden relevante Quellfelder den richtigen ASIM-Schemaspalten zugeordnet, und sowohl die parameterlosen () als auch die parametrisierten (ASim<Schema><Product>.yaml) Variantenvim<Schema><Product>.yaml werden im entsprechenden vereinheitlichenden Parser unter Parsers/ASim<Schema>/registriert.

Öffnen einer GitHub Pullanforderung

Sobald Ihre Lösung getestet wurde, die lokalen Validierungen erfolgreich sind und Sie den End-to-End-Datenfluss überprüft haben, übertragen Sie Ihre Dateien per Commit und öffnen Sie von Ihrem Fork aus einen Pull Request gegen den master-Branch des Azure-Sentinel-Repositorys. Wenn Sie noch keinen Fork des Repositorys erstellt, es nicht geklont und keinen Branch angelegt haben, lesen Sie im Abschnitt „Ihre Umgebung einrichten“ Einen Fork des Repositorys erstellen und es klonen.

Übernehmen Sie Ihre Dateien

Stellen Sie alle Lösungsdateien aus dem Repositorystamm bereit, und führen Sie einen Commit für alle Lösungsdateien durch. Für eine neue Lösung umfasst dies Folgendes:

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>

Was in deine PR gehört

Ihre PR muss alle folgenden Elemente enthalten:

• Alle Lösungsinhaltsdateien unter Solutions/<YourSolutionName>/
• Ihr Logo als SVG in Logos/
• Die verpackte Lösung unter Solutions/<YourSolutionName>/Package/ (mainTemplate.json, createUIDefinition.json und das .zip)
• Alle benutzerdefinierten Tabellenschemadateien, die zu .script/tests/KqlvalidationsTests/CustomTables/ hinzugefügt wurden
• Ihr Konnektor id wurde zu .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json hinzugefügt.

PR-Beschreibung

Öffnen Sie die PR gegen Azure:master. Die PR-Vorlage enthält erforderliche Felder. Füllen Sie sie vor der Übermittlung aus. Löschen Sie den Leitlinienblock (den Abschnitt zwischen den gestrichelten Linien), bevor Sie folgendes übermitteln:

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.

CI-Checks und manuelle Prüfung

Wenn Sie die PR öffnen, werden automatisierte CI-Prüfungen für Ihre Dateien ausgeführt. Überprüfen Sie alle fehlgeschlagenen Prüfungen auf der Registerkarte Checks und spielen Sie die Korrekturen in Ihren Branch ein. Stellen Sie sicher, dass die lokale Validierung erfolgreich durchläuft, bevor Sie die PR öffnen – CI-Fehler beim Einreichen verzögern die Review-Warteschlange.

Nachdem CI-Prüfungen bestanden haben, überprüft ein Microsoft Sentinel Teammitglied Ihre PR innerhalb von fünf Werktagen nach der ersten Übermittlung. Alle Ergebnisse werden als Kommentare zur PR hinterlassen. Nachdem Sie Korrekturen pushen, werden Nachverfolgungsüberprüfungen innerhalb von zwei Werktagen abgeschlossen.

Die Überprüfung kann Folgendes umfassen:

• Technisches Feedback zur Konnektorkonfiguration, zum Schema oder zur Inhaltsqualität
• Anforderungen zum Aktualisieren von Metadaten, Beheben fehlerhafter Verknüpfungen oder korrigieren der Formatierung
• Fragen zum Verhalten der Datenquelle oder des Connectors

Die PR wird genehmigt und nach erfolgreicher vollständiger Überprüfung in master zusammengeführt.

Veröffentlichen

Nachdem Ihre PR in master zusammengeführt wurde, erstellen und konfigurieren Sie Ihr Angebot im Microsoft Partner Center, um die Lösung im Marketplace verfügbar zu machen.

Voraussetzungen vor dem Start:

• PR in master gemergt und Paket unter Solutions/<YourSolutionName>/Package/ im master-Branch verfügbar
• Kommerzielles Marketplace-Konto im Partner Center. Melden Sie sich früh an. Warten Sie nicht, bis die Lösung bereit ist. Siehe Erstellen eines kommerziellen Marketplace-Kontos im Partner Center.

Erstellen Sie das Angebot:

1. Wählen Sie im Partner Center Marketplace-Angebote>Neues Angebot>Azure-Anwendung aus.
2. Legen Sie die Angebots-ID so fest, dass sie dem offerId in Ihrem SolutionMetadata.json, z. B. entspricht azure-sentinel-solution-<yourproduct>. Dies kann nach der Erstellung nicht mehr geändert werden.
3. Wählen Sie Ihre Publisher-ID aus. Sie muss in publisherId mit SolutionMetadata.json übereinstimmen.

Schlüsselangebotskonfiguration:

Vollständige Feld-nach-Feld-Anleitungen finden Sie unter Veröffentlichen einer Microsoft Sentinel Lösung.

Preview

Nachdem Sie das Angebot im Partner Center eingereicht haben, gelangt Ihre Lösung zunächst in die Vorschau, bevor sie für alle Kunden live geschaltet wird. In dieser Phase ist die Lösung nur für die Azure Abonnement-IDs verfügbar, die Sie auf der Registerkarte "Vorschau" der Zielgruppe hinzugefügt haben.

Verwenden Sie den Vorschauzeitraum für:

• Installieren Sie die Lösung aus dem Marketplace in Ihren Testabonnements, und überprüfen Sie die vollständige Kundeninstallationserfahrung.
• Vergewissern Sie sich, dass mainTemplate.json reibungslos bereitgestellt wird, alle Inhalte in den Sentinel-Blades angezeigt werden und der Konnektor erfolgreich verbunden wird
• Teilen mit ausgewählten Designpartnerkunden mithilfe ihrer Abonnement-IDs für frühes Feedback

Nachdem Sie und alle Kunden mit Vorabzugriff die Lösung validiert haben, wählen Sie im Partner Center Go live aus, um zu Go to Market zu wechseln.

Verwandte Inhalte

• Entwickeln einer Microsoft Sentinel Lösung
• Erstellen eines codelosen Connectors für Microsoft Sentinel
• Microsoft Sentinel-Lösungskatalog
• Allgemeine Beitragsrichtlinien für Microsoft Sentinel