Empacotar uma solução SIEM para Microsoft Sentinel

Depois de desenvolver e testar os componentes da solução Microsoft Sentinel, o empacotamento é a próxima etapa crítica no ciclo de vida da solução. A ferramenta de empacotamento consolida todo o conteúdo da solução – conectores de dados, analisadores, workbooks, regras analíticas, consultas de busca, conectores personalizados dos Aplicativos Lógicos do Azure e playbooks – em um formato padronizado para a implantação. Esse processo de empacotamento automatizado gera os modelos e arquivos de configuração necessários do ARM, valida a estrutura do pacote e prepara o artefato da solução para envio ao Partner Center. O empacotamento garante que sua solução esteja formatada, concluída e pronta corretamente para os clientes implantarem em seus ambientes sentinelas.

Empacotar sua solução

A ferramenta de empacotamento fornece uma maneira fácil de gerar seu pacote de solução de maneira automatizada e valida o pacote gerado. Você pode empacotar tipos de conteúdo diferentes do Microsoft Sentinel, incluindo uma combinação de conectores de dados, analisadores, workbooks, regras analíticas, consultas de busca, conectores personalizados dos Aplicativos Lógicos do Azure e playbooks.

A ferramenta de criação de pacote V3 produz os seguintes arquivos:

• mainTemplate.json Um único modelo do ARM combinando todo o conteúdo da solução
• createUIDefinition.json Definição do assistente de instalação do hub de conteúdo
• Uma versão .zip dos dois arquivos. Esse é o artefato que você envia para o Partner Center.

A partir da raiz do repositório no PowerShell:

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

O script solicita o caminho para sua Data/ pasta (por exemplo C:\GitHub\Azure-Sentinel\Solutions\<YourSolutionName>\Data). Consulte as diretrizes da ferramenta de empacotamento de soluções para obter detalhes completos.

Implantar e habilitar

Implante mainTemplate.json em seu workspace de desenvolvimento/teste Microsoft Sentinel usando o portal Azure:

1. No portal do Azure, pesquise por Implantar um modelo personalizado e selecione-o.
2. Selecione Criar seu próprio modelo no editor, cole o conteúdo e mainTemplate.jsonsalve.
3. Preencha os parâmetros. Selecione sua assinatura, grupo de recursos e o workspace em que Microsoft Sentinel é implantado.
4. Selecione Examinar + criar, depois Criar.

Você também pode implantar por meio de 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 implantação, habilite e exercite cada tipo de conteúdo na ordem:

1. Conector de dados Vá para Conectores de Dados, localize o conector, abra a página do conector e habilite-a. Siga as etapas de configuração para começar a enviar dados para seu workspace.

2. Verificar a ingestão de dados Depois de habilitar o conector, consulte sua tabela para confirmar se os registros estão chegando:

   <YourTable_CL>
   | take 10
   

   A ingestão inicial pode levar até 30 minutos. Se nenhum dado for exibido, verifique a página de status do conector e examine as mensagens de erro antes de continuar.

3. Regras analíticas Vá para Análise, localize suas regras em modelos de regra e habilite-as. Confirme se as regras geram alertas ou incidentes com seus dados de teste.

4. Consultas de busca Vá para a Busca, localize suas consultas e execute-as em relação aos dados ingeridos. Confirme se os resultados são retornados e os mapeamentos de entidade aparecem corretamente.

5. Playbooks Implante playbooks, autorize as conexões dos Aplicativos Lógicos e anexe-os a uma regra de automação ou a uma regra analítica. Acione um incidente de teste para verificar a execução de ponta a ponta.

6. Pastas de trabalho Vá para Pastas de trabalho, encontre seu modelo de pasta de trabalho e salve uma cópia. Confirme que todas as visualizações são preenchidas com os dados ingeridos.

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

   <YourParserAlias>
   | take 10
   

Use o monitoramento de integridade do Sentinel para observar a atividade do conector e diagnosticar problemas de ingestão. Vá para Configurações>Integridade ou consulte as tabelas SentinelHealth e SentinelAudit. Consulte Auditoria e monitoramento de integridade no Microsoft Sentinel para obter detalhes.

Executar validações locais

Dois tipos de verificações ajudam você a passar por um PR com êxito.

• O script de validação local executa verificações automatizadas em relação aos arquivos da solução e captura a maioria dos problemas estruturais e de esquema antes de abrir uma PR.
• A lista de verificação de pré-envio abrange verificações manuais; por exemplo, verificar se a descrição do conector faz sentido, se os links funcionam e se o esquema da tabela está bloqueado. Estas são verificações que o script de validação local não pode avaliar por você. Execute ambos antes de enviar.

Execute o conjunto de validação local na raiz do repositório:

Pré-requisitos (somente pela primeira vez):

npm install
npm run tsc

Execute as validações com base nas alterações no seu branch:

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

Corrija todas as falhas antes de abrir o PR. As falhas nessa etapa aparecem como verificações de CI com falha e bloqueiam a mesclagem.

Lista de verificação de pré-envio

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

Verificar o empacotamento da solução

Verifique se o pacote da solução está completo, correto e pronto para envio. As verificações a seguir são necessárias para cada envio de solução.

Controle de versão e nomenclatura

• A versão do pacote e o nome do arquivo 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 arquivo ZIP do pacote.
• offerId e publisherId dentro SolutionMetadata.json e mainTemplate.json são minúsculos e correspondem exatamente à sua oferta do Partner Center.
• A entrada ReleaseNotes.md está presente nessa versão com o formato correto. Consulte notas de versão para ver os cabeçalhos de coluna e o formato de data necessários.

Conteúdo e identidade visual

• Todo o texto no pacote usa "Microsoft Sentinel", não "Azure Sentinel". Verifique ambos mainTemplate.json e createUiDefinition.json.
• O nome da solução não contém "MS Sentinel" ou "Microsoft Sentinel" como prefixo (exceção: nomes que terminam com "solução para Microsoft Sentinel" são aceitáveis).
• As contagens de componentes na seção básica createUiDefinition.json estão corretas e seguem esta ordem: Conectores de Dados, Analisadores, Workbooks, Regras Analíticas, Consultas de Busca, Watchlists, Conector Personalizado dos Aplicativos Lógicos do Azure, Playbooks.
• O texto de descrição em createUiDefinition.json está completo, gramaticalmente correto e inclui links para a documentação relevante do produto que levam corretamente ao conteúdo correspondente.
• As imagens referenciadas em createUiDefinition.json carregam corretamente e não estão quebradas.
• Todos os links curtos aka.ms em mainTemplate.json e createUiDefinition.json funcionam. Teste cada um antes de enviar.

mainTemplate.json

• O nó metadata está presente com "kind": "Solution" e "type": "Microsoft.OperationalInsights/workspaces/providers/metadata".
• As informações de suporte, o autor e os detalhes do provedor estão corretos.
• categories.domains os valores são válidos. Confira as categorias de solução.
• A versão do esquema de conteúdo em mainTemplate.json é 3.0.0.
• O zip não contém arquivos de uma versão de pacote mais antiga. Verifique o conteúdo zip antes de enviar.
• Valide mainTemplate.json usando a Implantação personalizada no portal do Azure para detectar erros no modelo do ARM antes do envio.

createUiDefinition.json

• Valide usando o Create UI Definition Sandbox para confirmar se o assistente de instalação é exibido corretamente.

Registros de CI

• Cada tabela de log personalizada (*_CL) referenciada em regras, consultas ou analisadores tem um esquema JSON em .script/tests/KqlvalidationsTests/CustomTables/ . A validação KQL falhará com "O nome 'YourTable_CL' não se refere a nenhuma tabela conhecida" se o esquema estiver ausente ou malformado.
• O conector id está registrado em .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json Isso é necessário para que as regras analíticas e as consultas de busca sejam aprovadas na validação de esquema.
• WorkbooksMetadata.json na raiz do repositório tem uma entrada para o workbook.

Se estiver atualizando uma solução existente

• Confirme se nenhum conteúdo existente foi substituído acidentalmente. Se você fez rebase ou efetuou pull nas últimas alterações, revise o diff cuidadosamente antes de enviar.
• Se já existir um conector do Azure Functions e você estiver adicionando um conector CCF, não remova o conector do Azure Functions sem confirmação explícita da equipe do Conector. Removê-lo pode prejudicar os clientes existentes.

Verificar o logotipo

Verifique se o logotipo atende aos requisitos.

• O logotipo atende a todos os requisitos de arquivo e SVG. Para obter mais informações, consulte Adicionar seu logotipo.
• O logotipo é renderizado de forma limpa em 75×75 px. Visualize-o nesse tamanho antes de enviar.

Verificar o conector de dados

Verifique se o JSON do conector atende aos requisitos.

Arquivo e nomenclatura

• O nome do arquivo JSON está ProviderNameApplianceName.json sem espaços
• id O campo corresponde à base de nome de arquivo, por exemplo, arquivo ContosoFW.json → id: "ContosoFW" Não deve haver espaços e deve ser exclusivo entre todos os conectores no repositório.
• titleé o nome do provedor e do dispositivo com espaços, por exemplo. "Contoso Firewall"
• publisher é o nome do provedor/fornecedor
• Verifique se os nomes do provedor e do dispositivo são empresas atuais e os produtos geralmente são renomeados ou adquiridos, portanto, confirme se os nomes ainda são precisos antes de serem enviados.

Descrição e instruções

• descriptionMarkdown explica significativamente quais dados o conector traz, em que formato e links para a documentação do produto do fornecedor — uma descrição genérica será sinalizada durante a revisão
• As etapas de instrução são personalizadas para o produto específico. Eles não devem ser texto padrão do modelo
• Todas as etapas de instrução são gramaticalmente corretas e marcadas por ortografia
• Todas as URLs no conector JSON funcionam, incluindo todos os links curtos aka.ms. Links quebrados são um dos bloqueadores mais comuns na revisão de RP. Verificar se cada link funciona antes de enviar

Tipos de dados

• Os nomes de tipo 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)
  • API REST (CCF ou Azure Functions):DATATYPE_NAME_CL
• DATATYPE_NAME representa o provedor, o dispositivo e, opcionalmente, a categoria de dados. Deve ser descritivo, não genérico.

Permissões

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

KQL

• Todas as entradas graphQuery, connectivityCriteria e sampleQuerysão executadas sem erros em Log Analytics em relação aos dados.

Metadata

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

Dependência do analisador

• Se o conector depender de um analisador para os clientes consultarem os dados conforme necessário para Syslog e CEF e se aplicar a qualquer tipo de conector em que os dados brutos não sejam diretamente consultáveis, o YAML do analisador estará em Solutions/<Name>/Parsers/e o conector JSON fará referência a ele nas anotações instructionSteps e em additionalRequirementBanner com um link para a função Kusto.

Verificações adicionais para conectores Azure Functions

• azuredeploy_DataConnector_API_AzureFunctionApp_template.json está presente em Data Connectors/.
• run.ps1 ou run.py e todos os arquivos de suporte estão presentes.
• Há um .zip de todos os arquivos do aplicativo Functions; os arquivos ZIP de funções do Python devem incluir uma pasta .python_packages.
• O parâmetro FunctionName tem as propriedades minLength e maxLength
• O modelo do ARM não contém um Microsoft.Web/sites/hostNameBindings recurso. Remova-o se estiver presente.
• A URL de implantação do Azure codificada no JSON do conector funciona de ponta a ponta por meio da experiência de implantação do portal Azure.
• O script de função é executado sem erros de sintaxe.

Verificar pastas de trabalho

Verifique se o JSON da pasta de trabalho atende aos requisitos.

Entrada do WorkbooksMetadata.json

• WorkbooksMetadata.json na raiz do repositório contém uma nova entrada para esse workbook. Uma entrada ausente ou malformada bloqueia a mesclagem.
• workbookKey é exclusivo. Nenhuma entrada existente no arquivo usa a mesma chave.
• description é preenchido e está gramaticalmente correto.
• logoFileName aponta para o arquivo de logotipo do SVG; o arquivo de logotipo é incluído no PR e passa na lista de verificação de logotipo.
• dataTypesDependencies lista todas as tabelas que o workbook consulta: "CommonSecurityLog" para os conectores de CEF, "Syslog" para os conectores de Syslog, "DATATYPE_CL" para os conectores de logs personalizados. Vários tipos são válidos, por exemplo, ["CommonSecurityLog", "Contoso_CL"].
• dataConnectorsDependencies corresponde exatamente ao id campo no JSON do conector. Vários conectores são válidos, por exemplo, ["ContosoFW", "ContosoCloud"].
• previewImagesFileNames lista os nomes de arquivo de imagem de visualização; cada arquivo está presente Solutions/<Name>/Workbooks/Images/Preview/ e os nomes de arquivo correspondem exatamente ao que está nos metadados.
• O campo version está presente; se esta for uma atualização de uma pasta de trabalho existente, a versão é incrementada.
• title é o nome de exibição mostrado na galeria Workbooks. Parênteses no título não são permitidos.
• templateRelativePath corresponde ao nome de arquivo JSON da pasta de trabalho real, por exemplo, "ContosoFirewall.json".
• provider é o nome da empresa/fornecedor.
• WorkbooksMetadata.json é JSON válido. Valide com um linter JSON antes de enviar. Uma vírgula no final ou uma chave duplicada causa uma falha imediata de compilação.

Visualizar imagens

• Pelo menos uma tela de fundo escura e uma captura de tela de fundo claro estão incluídas.
• As imagens são formato PNG.
• Os nomes de arquivo de plano de fundo escuro contêm "Black", por exemplo, ContosoFirewallBlack.png; nomes de arquivo de plano de fundo claros contêm "White", por exemplo, ContosoFirewallWhite.png.
• Várias capturas de tela por tema são numeradas com um sufixo: ContosoFirewallBlack1.png, ContosoFirewallBlack2.png.

Conteúdo da pasta de trabalho

• Todas as consultas na pasta de trabalho são executadas sem erros de sintaxe KQL.
• A pasta de trabalho tem pelo menos 4 gráficos ou visualizações.
• O arquivo JSON da pasta de trabalho está dentro Solutions/<YourSolutionName>/Workbooks/, não na pasta raiz Workbooks/ .
• Após o empacotamento, confirme que createUiDefinition.json faz referência ao nome do arquivo da pasta de trabalho como uma string estática, e não como uma expressão ARM dinâmica, como [steps('workbooks').workbook1.workbook1-name].
• Todos os links curtos aka.ms no workbook funcionam. Verifique cada um antes de enviar.
• Se a pasta de trabalho exigir um analisador, inclua uma observação na descrição da pasta de trabalho ou no texto de instruções, informando os clientes de que devem implantar o analisador e salvá-lo como uma função chamada <FunctionName>. Sem essa observação, as consultas de pasta de trabalho que fazem referência ao alias da função falham.
• Se o workbook usar ThreatIntelligenceIndicator, siga as orientações em Correspondência de TI além desses critérios.

Verificar regras analíticas

Verifique se o YAML da regra analítica atende aos requisitos.

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

Verificar as consultas de busca

Verifique se o YAML da consulta de busca atende aos requisitos.

Estrutura e campos

• A extensão de arquivo é .yaml, não .yml.
• id é um GUID e ainda não existe no repositório.
• Nenhum campo específico da regra analítica está presente: kind, , severity, queryFrequency, queryPeriod, , triggerOperator, triggerThreshold, , alertDetailsOverride. eventGroupingSettings
• Não há bloco metadata. Remova-o se a consulta tiver sido copiada de uma consulta autônoma em Hunting Queries/; se estiver enviando conteúdo autônomo fora de uma solução, metadata.source.kind deve ser "Community".

Nome e descrição

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

Táticas e técnicas

• Pelo menos uma tactics entrada está presente.
• Pelo menos uma relevantTechniques entrada está presente; 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 no JSON do seu 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 estará presente em .script/tests/KqlvalidationsTests/CustomTables/.

Qualidade da consulta

• A consulta é executada sem erros em relação aos dados ingeridos
• A consulta não inclui um filtro de tempo codificado. A folha Busca injeta, em runtime, o intervalo de tempo selecionado pelo analista.
• StartTime e EndTime são usados em summarize para exibir limites de tempo nos resultados (não StartTimeUtc/EndTimeUtc).
• summarize inclui count() ou dcount() quando apropriado.
• project ou summarize a saída é limitada a campos contextuais. Não exiba todas as colunas brutas.
• Use has em vez de contains sempre que possível. has tem reconhecimento de índice e é mais rápido em tabelas grandes. Use somente contains quando uma correspondência de subcadeia de caracteres for realmente necessária.
• Use operadores que não diferenciam maiúsculas de minúsculas (=~, in~, !~) quando apropriado.
• Parametrize valores repetidos usando instruções let, quando apropriado.
• Revise a consulta de acordo com o Guia de Estilo de Consulta antes de enviar.
• Todos os links curtos aka.ms funcionam. Verifique cada um antes de enviar.
• Se a consulta utilizar ThreatIntelligenceIndicator: siga as diretrizes de TI Matching, além destes critérios.

Verificar playbooks

Verifique se o modelo ARM e o arquivo README do seu playbook atendem aos requisitos.

• readme.md tem todas as seções necessárias: título e descrição, botões de Implantação Rápida, Pré-requisitos (gravar None se não houver nenhum), etapas de pós-implantação, Capturas de tela
• O recurso name de fluxo de trabalho não é "[parameters('PlaybookName')]"codificado
• Todos os nomes de variáveis de conexão são derivados de PlaybookName usando concat()
• O modelo ARM $schema é o URI do modelo de implantação 2019-04-01
• Nenhum ID de assinatura, ID de locatário ou nome de grupo de recursos codificado no código
• A matriz metadata.releaseNotes está presente no recurso de fluxo de trabalho

Verificar analisadores

Verifique se o YAML do analisador atende aos requisitos.

• Function.Version e Function.LastUpdated são cadeias entre aspas, por exemplo '1.0.0', não 1.0.0; '2026-06-15', não 2026-06-15.
• Os dados de exemplo estão disponíveis para testar o analisador em um workspace de desenvolvimento.
• O analisador é implantado sem erros no Log Analytics como função Kusto.
• Executar o analisador com dados de exemplo retorna resultados com os campos esperados preenchidos. Se você estiver usando ingestão personalizada de logs para testes, confirme se o analisador ainda processa corretamente o formato de ingestão real gerado pelo seu conector.
• Todos os links curtos aka.ms no YAML do analisador funcionam. Verifique cada um antes de enviar.
• Se o analisador usar ThreatIntelligenceIndicator, siga as diretrizes de TI Matching, 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 serão mapeados para as colunas de esquema ASIM corretas e as variantes sem parâmetro (ASim<Schema><Product>.yaml) e com parâmetros (vim<Schema><Product>.yaml) serão registradas no analisador de unificação correspondente em Parsers/ASim<Schema>/.

Abrir um pull request no GitHub

Quando a solução tiver sido testada, as validações locais tiverem sido aprovadas e você tiver verificado o fluxo de dados de ponta a ponta, confirme os arquivos e abra uma pull request direto da bifurcação para a ramificação master do repositório do Azure-Sentinel. Se você ainda não fez uma bifurcação nem o clone do repositório e criou uma ramificação, consulte Fazer uma bifurcação e um clone do repositório na seção Preparar seu ambiente.

Confirmar seus arquivos

Preparar e confirmar todos os arquivos de solução direto da raiz do repositório. Para uma nova solução, isso 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 em seu PR

Sua PR deve conter todos os itens a seguir:

• Todos os arquivos de conteúdo da solução em Solutions/<YourSolutionName>/
• Seu logotipo SVG em Logos/
• A solução empacotada em Solutions/<YourSolutionName>/Package/ (mainTemplate.json, createUIDefinition.jsone o .zip)
• Todos os arquivos de esquema de tabela personalizados adicionados a .script/tests/KqlvalidationsTests/CustomTables/
• Seu conector id foi adicionado a .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json

Descrição do PR

Abra o PR em relação a Azure:master. O modelo de PR tem campos necessários. Preencha-os antes de enviar. Exclua o bloco de diretrizes (a seção entre as linhas tracejadas) antes de enviar:

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 você abre o PR, as verificações de CI automatizadas são executadas nos arquivos. Revise as falhas na guia Verificações e envie as correções por push para a ramificação. Verifique se a validação local foi aprovada antes de abrir o PR, pois as falhas de CI no envio atrasam a fila de revisão.

Depois que as verificações de CI passarem, um membro da equipe Microsoft Sentinel examinará sua PR dentro de cinco dias úteis após o envio inicial. Todas as conclusões são deixadas como comentários na PR. Depois que você envia as correções por push, as revisões de acompanhamento são concluídas dentro de dois dias úteis.

A revisão pode incluir:

• Comentários técnicos sobre a configuração do conector, o esquema ou a qualidade do conteúdo
• Solicitações para atualizar metadados, corrigir links desfeitos ou formatação correta
• Perguntas sobre a fonte de dados ou o comportamento do conector

O PR é aprovado e mesclado em master após a conclusão bem-sucedida da revisão completa.

Publicar

Depois que o PR for mesclado para master, crie e configure a oferta no Microsoft Partner Center para disponibilizar a solução no marketplace.

Pré-requisitos antes de iniciar:

• O PR mesclado para master e pacote disponível em Solutions/<YourSolutionName>/Package/ na ramificação master
• Conta do marketplace comercial no Partner Center. Inscreva-se cedo. Não espere até que a solução esteja pronta. Consulte Criar uma conta do marketplace comercial no Partner Center.

Crie a oferta:

1. No Partner Center, selecione Ofertas do Marketplace>Nova oferta>Aplicativo do Azure.
2. Defina o ID da Oferta para corresponder a offerId em seu SolutionMetadata.json, por exemplo, azure-sentinel-solution-<yourproduct>. Isso não pode ser alterado após a criação.
3. Selecione sua ID de Publisher . Ele deve corresponder a publisherId em SolutionMetadata.json.

Configuração principal da oferta:

Para obter diretrizes completas campo a campo, consulte Publicar uma solução de Microsoft Sentinel.

Preview

Depois de enviar a oferta no Partner Center, sua solução entra em Preview antes de ser disponibilizada para todos os clientes. Nesta fase, a solução está disponível apenas para as IDs de assinatura Azure que você adicionou na guia Visualizar público.

Use o período de visualização para:

• Instale a solução do marketplace em suas assinaturas de teste e valide a experiência completa de instalação do cliente
• Confirme se o mainTemplate.json foi implantado sem problemas, se todo o conteúdo aparece nas folhas do Sentinel e se o conector se conecta com sucesso
• Compartilhar com clientes parceiros de design selecionados usando suas IDs de assinatura para comentários antecipados

Depois que você e todos os clientes da versão prévia tiverem validado a solução, selecione Entrar em operação no Partner Center para avançar para Go to Market.

Conteúdo relacionado

• Desenvolver uma solução de 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 Microsoft Sentinel