Empacotar uma solução SIEM para Microsoft Sentinel

Depois de desenvolver e testar os componentes da sua solução Microsoft Sentinel, a embalagem é o próximo passo crítico no ciclo de vida da solução. A ferramenta de empacotamento consolida todo o conteúdo da sua solução — conectores de dados, analisadores, livros, regras analíticas, consultas de pesquisa, conectores personalizados do Azure Logic Apps e playbooks — num formato padronizado para implementação. Este processo automatizado de empacotamento gera os modelos ARM e ficheiros de configuração necessários, valida a estrutura do pacote e prepara o artefacto da sua solução para submissão ao Partner Center. O empacotamento garante que a sua solução se encontra devidamente formatada, completa e pronta para os clientes a implementarem nos respetivos ambientes Sentinel.

Empacota a tua solução

A ferramenta de embalagem oferece uma forma fácil de gerar o seu pacote de soluções de forma automatizada e valida o pacote gerado. Pode empacotar diferentes tipos de conteúdos do Microsoft Sentinel que incluem uma combinação de conectores de dados, parsers, livros de exercícios, regras analíticas, consultas de caça, conectores personalizados para aplicações Azure Logic e playbooks.

A ferramenta de criação de pacotes V3 produz os seguintes ficheiros:

• mainTemplate.json Um único modelo ARM que combina todo o conteúdo da solução
• createUIDefinition.json Definição do assistente de instalação do content hub
• Uma versão .zip dos dois ficheiros. Este é o artefacto que submetes ao Centro de Parceiros.

Da raiz do repositório no PowerShell:

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

O script indica-te o caminho para a tua Data/ pasta (por exemplo C:\GitHub\Azure-Sentinel\Solutions\<YourSolutionName>\Data). Consulte as orientações para a ferramenta de embalagem de soluções para todos os detalhes.

Implementar e ativar

Implemente mainTemplate.json no seu espaço de trabalho Microsoft Sentinel de desenvolvimento/teste usando o portal Azure:

1. No portal do Azure, procure Deploy a custom template e selecione-o.
2. Selecione Criar o seu próprio modelo no editor, cole o conteúdo de mainTemplate.json, e guarde.
3. Preencha os parâmetros. Selecione a sua subscrição, grupo de recursos e o espaço de trabalho onde o Microsoft Sentinel está implementado.
4. selecione Examinar + criar, depois Criar.

Também pode implementar via CLI do Azure:

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

Após a conclusão da implementação, ative e exercite cada tipo de conteúdo por ordem:

1. Conector de dados Vai a Conectores de Dados, encontra o teu conector, abre a página do conector e ativa-o. Siga os passos de configuração para começar a enviar dados para o seu espaço de trabalho.

2. Verificar a ingestão de dados Depois de ativar o conector, consulte a sua tabela para confirmar que os registos estão a chegar:

   <YourTable_CL>
   | take 10
   

   A ingestão inicial pode demorar até 30 minutos. Se não aparecerem dados, verifique a página de estado do conector e reveja quaisquer mensagens de erro antes de continuar.

3. Regras analíticas Vai a Analytics, encontra as tuas regras em Modelos de Regras e ativa-as. Verifique se as regras geram alertas ou incidentes com os seus dados de teste.

4. Consultas de pesquisa Aceda a Hunting, localize as suas consultas e execute-as nos seus dados ingeridos. Confirme que os resultados são devolvidos e que os mapeamentos das entidades surgem corretamente.

5. Playbooks Implemente quaisquer playbooks, autorize as ligações da Logic App e anexe a uma regra de automação ou de análise. Acione um incidente de teste para verificar a execução de ponta a ponta.

6. Cadernos de exercícios Vai a Workbooks, encontra o teu modelo de workbook e guarda uma instância. Confirme que todas as visualizações estão preenchidas com os seus dados ingeridos.

7. Analisadores Execute o alias da função parser diretamente no Log Analytics para confirmar se a extração do campo está correta:

   <YourParserAlias>
   | take 10
   

Utilize a monitorização da saúde Sentinel para observar a atividade dos conectores e diagnosticar problemas de ingestão. Acede a Definições>Saúde ou consulta as tabelas SentinelHealth e SentinelAudit. Consulte Auditoria e monitorização de saúde no Microsoft Sentinel para mais detalhes.

Executar validações locais

Dois tipos de verificações ajudam-no a concluir com êxito uma pull request.

• O script de validação local executa verificações automáticas aos seus ficheiros de solução e deteta a maioria dos problemas estruturais e de esquema antes de abrir uma PR.
• A lista de verificação pré-submissão inclui verificações manuais, por exemplo, verificar que a descrição do seu conector faz sentido, que as hiperligações funcionam e que o esquema da tabela está bloqueado. São verificações que o script local de validação não consegue avaliar em teu nome. Executa ambos antes de submeter.

Execute a suite de validação local a partir da raiz do repositório:

Pré-requisitos (apenas na primeira vez):

npm install
npm run tsc

Execute validações com as alterações das suas ramificações:

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

Corrige todas as falhas antes de abrir o seu PR. Falhas nesta etapa aparecem como falhas em verificações de CI e bloqueiam a fusão.

Lista de verificação pré-submissão

Antes de abrir um PR, confirme cada item aplicável abaixo.

Verificar a embalagem da solução

Verifique se o seu pacote de soluções está completo, correto e pronto para submissão. As seguintes verificações são obrigatórias para cada submissão de solução.

Controlo de versões e atribuição de nomes

• A versão do pacote e o nome do ficheiro zip do pacote são os mesmos (por exemplo, 3.1.0.zip para a versão 3.1.0).
• A versão é incrementada em relação à versão anterior e é a mesma em SolutionMetadata.json, Data/Solution_*.json, ReleaseNotes.md, e no nome do ficheiro zip do pacote.
• offerId e publisherId em SolutionMetadata.json e mainTemplate.json são minúsculas e correspondem exatamente à sua oferta do Centro de Parceiros.
• ReleaseNotes.md A entrada está presente para esta versão no formato correto. Consulte as Notas de versão para os cabeçalhos de coluna e o formato de data necessários.

Conteúdo e marca

• Todo o texto no pacote usa "Microsoft Sentinel", não "Azure Sentinel". Verifique tanto mainTemplate.json como createUiDefinition.json.
• O nome da solução não contém "MS Sentinel" ou "Microsoft Sentinel" como prefixo (exceção: nomes que terminam em "solution for Microsoft Sentinel" são aceitáveis).
• As contagens de componentes na createUiDefinition.json secção básica estão corretas e nesta ordem: Data Connectors, Parsers, Workbooks, Regras Analíticas, Hunting Queries, Watchlists, Custom Azure Logic Apps Connector, Playbooks.
• O texto de descrição em createUiDefinition.json está completo, gramaticalmente correto e inclui hiperligações para a documentação relevante do produto que funcionam corretamente.
• As imagens referenciadas em createUiDefinition.json carregam corretamente e não estão danificadas.
• Todos os links curtos em aka.ms e mainTemplate.jsoncreateUiDefinition.json funcionam. Testa cada um antes de submeter.

mainTemplate.json

• metadata nó está presente com "kind": "Solution" e "type": "Microsoft.OperationalInsights/workspaces/providers/metadata".
• As informações de apoio, os detalhes do autor e do prestador estão corretos.
• categories.domains Os valores são válidos. Ver categorias de solução.
• A versão do esquema de conteúdo em mainTemplate.json é 3.0.0.
• O zip não contém ficheiros de uma versão de pacote mais antiga. Verifique o conteúdo do ficheiro ZIP antes de o submeter.
• Valide mainTemplate.json com Implementação personalizada no portal do Azure para detetar erros de modelos ARM antes de enviar.

createUiDefinition.json

• Valide usando o Sandbox Create UI Definition para confirmar que o assistente de instalação renderiza corretamente.

Registos CI

• Cada tabela de registos personalizada (*_CL) referida em regras, consultas ou analisadores tem um esquema JSON em .script/tests/KqlvalidationsTests/CustomTables/ . A validação KQL falha com "O nome 'YourTable_CL' não se refere a nenhuma tabela conhecida" se o esquema estiver em falta ou mal formado.
• O seu conector id está registado em .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json Isto é necessário para que as regras analíticas e as consultas de pesquisa sejam aprovadas na validação do esquema.
• WorkbooksMetadata.json Na raiz do repositório há uma entrada para o teu caderno de exercícios.

Se estiver a atualizar uma solução existente

• Confirme que nenhum conteúdo existente é substituído acidentalmente. Se rebaseaste ou retiraste o mais recente, revê bem o diferencial antes de submeteres.
• Se já existe um conector Funções do Azure e estás a adicionar um conector CCF, não removas o conector Funções do Azure sem confirmação explícita da equipa do Connector. Removê-la pode prejudicar os clientes existentes.

Verificar o logótipo

Verifique se o seu logótipo cumpre os requisitos.

• O logótipo cumpre todos os requisitos relativos a ficheiros e a SVG. Para mais informações, consulte Adicionar o logótipo.
• O logótipo é apresentado com nitidez a 75×75 px. Pré-visualiza nesse tamanho antes de submeter.

Verifique o conector de dados

Verifica se o JSON do teu conector cumpre os requisitos.

Ficheiro e atribuição de nomes

• O nome do ficheiro JSON é ProviderNameApplianceName.json sem quaisquer espaços
• id campo corresponde à base do nome do ficheiro, por exemplo, ContosoFW.json ficheiro → id: "ContosoFW" Não deve haver espaços e deve ser único entre todos os conectores no repositório.
• title é o nome do fornecedor e do dispositivo com espaços entre palavras, por exemplo, "Contoso Firewall".
• publisher é o nome do prestador/fornecedor
• Verifique se os nomes do fornecedor e do dispositivo estão atualizados. As empresas e os produtos são frequentemente renomeados ou adquiridos, por isso confirme se os nomes continuam corretos antes de enviar.

Descrição e instruções

• descriptionMarkdown Explica de forma significativa que dados o conector traz, em que formato, e liga à documentação do produto do fornecedor — uma descrição genérica será assinalada durante a revisão
• Os passos de instrução são personalizados para o produto específico. Não deviam ser texto provisório do modelo
• Todos os passos das instruções são gramaticalmente corretos e foram verificados ortograficamente
• Todos os URLs no conector JSON resolvem-se, incluindo quaisquer aka.ms links curtos. Links quebrados são um dos bloqueios mais comuns na revisão de relações públicas. Verifique se todos os links funcionam antes de submeter

Tipos de dados

• Os nomes dos tipos de dados seguem o formato correto para o tipo de conector e não têm espaços em DATATYPE_NAME:
  • CEF: CommonSecurityLog (DATATYPE_NAME)
  • Syslog: Syslog (DATATYPE_NAME)
  • REST API (CCF ou Funções do Azure):DATATYPE_NAME_CL
• DATATYPE_NAME representa o fornecedor, o dispositivo e, opcionalmente, a categoria de dados. Deve ser descritivo, não genérico.

Permissões

• permissions O bloco corresponde exatamente ao modelo relevante do tipo de conector. Compare propriedade por propriedade com DataConnectors/Templates/. Não adicione, remova ou modifique propriedades individuais.

KQL

• Cada entrada graphQuery, connectivityCriteria e sampleQuery é executada sem erros no Log Analytics nos seus dados.

Metadata

• metadata o bloco está presente no JSON do conector
• metadata.id é um GUID. Gere um GUID com [guid]::NewGuid() no PowerShell e confirme que ainda não existe em parte alguma do repositório.
• metadata.support inclui um email ou um link atributo.

Dependência do parser

• Se o conector depende de um parser para os clientes consultarem os dados, como é exigido para Syslog e CEF, e se aplica a qualquer tipo de conector onde os dados brutos não sejam consultáveis diretamente, o parser YAML está em Solutions/<Name>/Parsers/, e o JSON do conector referencia-o tanto instructionSteps nas notas como additionalRequirementBanner com um link para a função Kusto.

Verificações adicionais para conectores Funções do Azure

• azuredeploy_DataConnector_API_AzureFunctionApp_template.json está presente em Data Connectors/.
• run.ps1 ou run.py e todos os ficheiros de apoio estão presentes.
• Existe uma .zip com todos os ficheiros da Function App; os ficheiros ZIP das funções Python devem incluir uma pasta .python_packages.
• O FunctionName parâmetro tem propriedades tanto minLength e maxLength
• O modelo ARM não contém um Microsoft.Web/sites/hostNameBindings recurso. Remova-o se estiver presente.
• O URL codificado do Azure Deploy no conector JSON funciona de ponta a ponta através da experiência de deploy do portal Azure.
• O script da função corre sem erros de sintaxe.

Verificar cadernos de exercícios

Verifica se o teu caderno de exercícios JSON cumpre os requisitos.

entrada de WorkbooksMetadata.json

• WorkbooksMetadata.json No repo root há uma nova entrada para este livro de exercícios. Uma entrada em falta ou mal formada bloqueia a fusão.
• workbookKey é único. Nenhuma entrada existente no ficheiro utiliza a mesma chave.
• description é preenchida e está gramaticalmente correta.
• logoFileName aponta para o seu ficheiro de logótipo SVG; o ficheiro do logótipo está incluído no PR e passa na lista de verificação do logótipo.
• dataTypesDependencies lista todas as tabelas das consultas do livro de trabalho: "CommonSecurityLog" para conectores CEF, "Syslog" para conectores Syslog, "DATATYPE_CL" para conectores de log personalizados. Múltiplos tipos são válidos, por exemplo, ["CommonSecurityLog", "Contoso_CL"].
• dataConnectorsDependencies corresponde exatamente ao id campo do teu conector JSON. Múltiplos conectores são válidos, por exemplo, ["ContosoFW", "ContosoCloud"].
• previewImagesFileNames lista os nomes dos ficheiros da imagem de pré-visualização; cada ficheiro está presente em Solutions/<Name>/Workbooks/Images/Preview/ e os nomes dos ficheiros correspondem exatamente ao que está nos metadados.
• o campo version está presente; se esta for uma atualização de um livro existente, a versão é aumentada.
• title é o nome de exibição mostrado na galeria de Cadernos de Exercícios. Parênteses no título não são permitidos.
• templateRelativePath corresponde ao nome real do ficheiro JSON do livro de exercícios, por exemplo, "ContosoFirewall.json".
• provider é o nome da sua empresa/fornecedor.
• WorkbooksMetadata.json é JSON válido. Valida com um linter JSON antes de submeter. Uma vírgula final ou uma tecla duplicada causa uma falha imediata na compilação.

Pré-visualizar imagens

• Estão incluídas pelo menos uma captura de ecrã de fundo escuro e uma de fundo claro.
• As imagens são em formato PNG.
• Os nomes de ficheiros de fundo escuros contêm "Black", por exemplo, ContosoFirewallBlack.png; os nomes de ficheiros de fundo claro contêm "White", por exemplo, ContosoFirewallWhite.png.
• Múltiplas capturas de ecrã por tema são numeradas com um sufixo: ContosoFirewallBlack1.png, ContosoFirewallBlack2.png.

Conteúdo do caderno de exercícios

• Todas as consultas no livro de exercícios correm sem erros de sintaxe KQL.
• O caderno de exercícios tem pelo menos 4 gráficos ou visualizações.
• O ficheiro JSON do livro de trabalho está em Solutions/<YourSolutionName>/Workbooks/, não na pasta raiz.Workbooks/
• Após o empacotamento, confirme que createUiDefinition.json faz referência ao nome de ficheiro do livro como uma cadeia estática, e não como uma expressão ARM dinâmica, como [steps('workbooks').workbook1.workbook1-name].
• Todos aka.ms os links curtos do caderno de exercícios resolvem-se. Verifica cada um antes de os submeteres.
• Se o livro exigir um parser, inclua uma nota na descrição do livro ou no texto de instruções a informar os clientes de que devem implementar o parser e guardá-lo como uma função com o nome <FunctionName>. Sem esta nota, as consultas do livro de exercícios que fazem referência ao alias da função falham.
• Se o caderno de exercícios utilizar ThreatIntelligenceIndicator, siga as diretrizes de correspondência TI além destes critérios.

Verificar regras analíticas

Verifique se a sua regra analítica YAML cumpre os requisitos.

• id é um GUID. Pesquise no repositório para confirmar que ainda não existe antes de submeter.
• requiredDataConnectors[].connectorId corresponde exatamente ao id JSON do teu conector.
• Cada entrada em relevantTechniques pertence a pelo menos um dos listados tactics.
• entityMappings está presente em pelo menos um mapeamento.
• Não há bloqueio metadata . Remova-a se a regra foi copiada de uma regra autónoma em Detections/.

Verificar consultas de caça

Verifique se a sua consulta de caça YAML cumpre os requisitos.

Estrutura e campos

• A extensão do ficheiro é .yaml, não .yml.
• id é um GUID e ainda não existe no repositório.
• Não existem campos analíticos específicos de regras: kind, severity, queryFrequency, queryPeriodtriggerOperator, , triggerThreshold, alertDetailsOverride, . eventGroupingSettings
• Não existe nenhum bloco metadata. Remova-o se a consulta tiver sido copiada de uma consulta autónoma em Hunting Queries/; se submeter conteúdo autónomo fora de uma solução, o metadata.source.kind deve ser "Community".

Nome e descrição

• name tem 50 caracteres ou menos.
• name Corresponde ou está muito próximo do nome do ficheiro.
• description reflete a intenção real da consulta, não uma cópia do nome, nem texto provisório.
• description são 255 caracteres ou menos.
• description inclui referências ou links quando aplicável, por exemplo, documentação do fornecedor, página de técnicas MITRE.

Táticas e técnicas

• Pelo menos uma tactics entrada está presente.
• Está presente pelo menos uma relevantTechniques entrada; inclua designações de sub-técnica quando aplicável, por exemplo, T1078.004 não apenas T1078.
• Cada técnica pertence a pelo menos uma das táticas listadas.

Conectores de dados necessários

• requiredDataConnectors[].connectorId corresponde exatamente ao id JSON do teu conector.
• Todos os tipos de dados consultados no KQL estão listados em requiredDataConnectors[].dataTypes.
• Se a consulta usar uma tabela personalizada (*_CL), um JSON de esquema para essa tabela está presente em .script/tests/KqlvalidationsTests/CustomTables/.

Qualidade da consulta

• A consulta corre sem erros nos dados ingeridos
• A consulta não inclui um filtro de tempo codificado fixamente. A lâmina de caça injeta o intervalo de tempo selecionado pelo analista em tempo de execução.
• StartTime e EndTime são usados em summarize para apresentar os limites temporais nos resultados (não StartTimeUtc/EndTimeUtc).
• summarize inclui count() ou dcount() quando apropriado.
• project ou summarize a saída está limitada a campos contextuais. Não mostre todas as colunas em bruto.
• Use has em vez de contains , sempre que possível. has é consciente do índice e é mais rápido em tabelas grandes. Só use contains quando uma correspondência de substring for realmente necessária.
• Utilize operadores que não distinguem maiúsculas de minúsculas (=~, in~, !~) quando apropriado.
• Parametrize os valores repetidos utilizando declarações let quando apropriado.
• Revise a consulta com o Guia de Estilo da Consulta antes de submeter.
• Todas as aka.ms hiperligações curtas funcionam. Verifica cada um antes de os submeteres.
• Se a consulta utilizar ThreatIntelligenceIndicator: siga as diretrizes de correspondência de TI, para além destes critérios.

Verificar livros de jogadas

Verifique se o modelo ARM e o ficheiro Leiame do seu playbook cumprem os requisitos.

• readme.md tem todas as secções obrigatórias: título e descrição, botões de Desdobramento Rápido, Pré-requisitos (escreva None se não houver), Passos pós-desdobramento, Capturas de ecrã
• O recurso name do fluxo de trabalho é "[parameters('PlaybookName')]", não codificado fixamente
• Todos os nomes das variáveis de ligação são derivados de PlaybookName utilizando concat()
• O modelo ARM $schema é o URI do modelo de implementação 2019-04-01
• Sem IDs de subscrição, IDs de tenant ou nomes de grupos de recursos codificados fixamente
• metadata.releaseNotes matriz está presente no recurso do fluxo de trabalho

Verificar processadores

Verifica se o YAML do teu parser cumpre os requisitos.

• Function.Version e Function.LastUpdated são cadeias citadas, por exemplo '1.0.0' não 1.0.0, '2026-06-15' não 2026-06-15.
• Dados de exemplo estão disponíveis para testar o parser num espaço de trabalho de desenvolvimento.
• O parser é implementado sem erros no Log Analytics como uma função Kusto.
• Executar o parser com dados de amostra retorna resultados com os campos esperados preenchidos. Se estiveres a usar ingestão de logs personalizada para testes, confirma se o parser ainda gere o formato real de ingestão que o teu conector produz.
• Todos aka.ms os links curtos no parser YAML resolvem-se. Verifica cada um antes de os submeteres.
• Se o analisador usar ThreatIntelligenceIndicator, siga as diretrizes de TI Matching, para além destes critérios, antes de enviar.
• Se o analisador for mapeado para um esquema ASIM (opcional, mas recomendado), os campos de origem relevantes são mapeados para as colunas adequadas do esquema ASIM, e tanto as variantes sem parâmetros (ASim<Schema><Product>.yaml) como as parametrizadas (vim<Schema><Product>.yaml) são registadas no analisador unificador correspondente em Parsers/ASim<Schema>/.

Abra um pull request no GitHub

Quando a sua solução tiver sido testada, as validações locais forem aprovadas e tiver verificado o fluxo de dados de ponta a ponta, faça commit dos seus ficheiros e abra um pull request a partir do seu fork para o ramo master do repositório Azure-Sentinel. Se ainda não fizeste um fork e clonaste o repositório nem criaste um ramo, vê Criar um fork e clonar o repositório na secção Provisionar o ambiente.

Confirme os seus ficheiros

Fasear e comprometer todos os ficheiros de solução a partir da raiz do repositório. Para uma nova solução, isto inclui:

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>

O que incluir no seu PR

O seu PR tem de conter todos os seguintes elementos:

• Todos os ficheiros de conteúdo da solução em Solutions/<YourSolutionName>/
• O teu logótipo SVG em Logos/
• A solução incluída no pacote em Solutions/<YourSolutionName>/Package/ (mainTemplate.json, createUIDefinition.json e o .zip)
• Todos os ficheiros de esquema de tabela personalizados adicionados a .script/tests/KqlvalidationsTests/CustomTables/
• O seu conector id foi adicionado a .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json

Descrição da RP

Abra a PR contra Azure:master. O modelo de PR tem campos obrigatórios. Preencha-os antes de submeter. Elimine o bloco de orientação (a secção entre as linhas tracejadas) antes de submeter:

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.

Verificações de CI e revisão manual

Quando abrir o PR, são executadas verificações automáticas de CI aos seus ficheiros. Revise quaisquer falhas no separador Verificações e envie correções para a sua agência. Certifique-se de que a validação local é concluída com êxito antes de abrir a PR — falhas de CI aquando da submissão atrasam a fila de revisão.

Após a aprovação nas verificações de CI, um membro da equipa do Microsoft Sentinel irá rever a sua PR no prazo de cinco dias úteis após a submissão inicial. Quaisquer conclusões são deixadas como comentários sobre a publicidade. Depois de aplicar as correções, as revisões de seguimento são concluídas no prazo de dois dias úteis.

A análise pode incluir:

• Feedback técnico sobre a configuração do conector, esquema ou qualidade do conteúdo
• Pedidos para atualizar metadados, corrigir links avariados ou corrigir a formatação
• Perguntas sobre o comportamento da fonte de dados ou do conector

A PR é aprovada e fundida em master depois de a revisão completa ser concluída com êxito.

Publicar

Depois de o seu PR ser fundido com master, crie e configure a sua oferta no Centro de Parceiros Microsoft para tornar a solução disponível no mercado.

Pré-requisitos antes de começar:

• PR integrado em master e pacote disponível em Solutions/<YourSolutionName>/Package/ no ramo master
• Conta de marketplace comercial no Centro de Parceiros. Inscreva-se cedo. Não esperes até a solução estar pronta. Veja Criar uma conta de marketplace comercial no Centro de Parceiros.

Crie a oferta:

1. No Centro de Parceiros, selecione Ofertas do Marketplace>Nova oferta>Aplicação do Azure.
2. Defina o ID da Oferta para corresponder ao offerId do seu SolutionMetadata.json, por exemplo, azure-sentinel-solution-<yourproduct>. Isto não pode ser alterado depois da criação.
3. Selecione o seu ID de Publisher. Tem de coincidir publisherId em SolutionMetadata.json.

Configuração da oferta chave:

Para orientações completas campo a campo, consulte Publicar uma solução Microsoft Sentinel.

Preview

Após submeter a oferta no Centro de Parceiros, a sua solução entra em Pré-visualização antes de ser disponibilizada a todos os clientes. Nesta fase, a solução está disponível apenas para os IDs das subscrições do Azure que adicionou no separador Público da pré-visualização.

Use o período de pré-visualização para:

• Instale a solução do marketplace nas suas subscrições de teste e valide a experiência completa de instalação do cliente
• Confirma que o mainTemplate.json conector é implementado corretamente, todo o conteúdo aparece nas lâminas Sentinela e que o conector se liga com sucesso
• Partilhe com clientes parceiros de design selecionados usando os seus IDs de subscrição para obter feedback antecipado

Depois de o utilizador e quaisquer clientes de pré-visualização terem validado a solução, selecione Go live no Partner Center para avançar para Go to Market.

Conteúdo relacionado

• Desenvolver uma solução Microsoft Sentinel
• Criar um conector sem código para Microsoft Sentinel
• catálogo de soluções de Microsoft Sentinel
• Diretrizes gerais de contribuição para o Microsoft Sentinel