v2.0.0 · Passo 3

Perfis de carga: DL_TECH_VULNERABILIDADE_V3 e DL_TECH_CMDB_V2

Novos perfis de carga do APEX para alimentar as colunas Tier-1 criadas no capítulo 11 — sem sobrescrever DL_TECH_VULNERABILIDADE_V2/DL_TECH_CMDB_V1, que continuam servindo a v1.3.0 em produção.

Status: mapeamento confirmado contra export real, perfis ainda não criados

O mapeamento abaixo foi conferido campo a campo contra um export real de Tenable/ServiceNow (arquivos em ampmInsights_V1_Cliente/Artefatos/, só linhas AM...) — não é suposição. O que falta é a parte que não é scriptável: criar os dois perfis de carga de fato no App Builder (Shared Components → Data Load Definitions), seguindo o roteiro da seção 4.

1. Por que perfis novos, não sobrescrever os antigos

Mesma regra já usada na v1.3.0 (ver capítulo 10): não alterar DL_TECH_VULNERABILIDADE_V2/DL_TECH_CMDB_V1 até o fluxo novo estar validado, para não quebrar a carga que já roda em produção no cliente. Os perfis novos são adicionais às colunas de sempre — não removem nenhum mapeamento existente.

2. RAW_JSON continua pendente (de propósito)

Este passo não popula RAW_JSON. O motivo: o Data Load do APEX só leva pra tabela as colunas que ele mapeia — os campos Tier 2/3 do export (que nunca ganharam coluna tipada) não chegam nem perto da tabela por este caminho. Popular RAW_JSON de verdade (a linha completa do export, todas as ~99/41 colunas) depende da tabela de staging (próximo item da Fase 1 no TASKS.md) — lá sim a linha inteira do CSV existe antes de qualquer filtro de coluna, e um `JSON_OBJECT(*)` sobre o staging resolve isso corretamente.

3. Mapeamento — DL_TECH_CMDB_V2 (12 colunas novas)

Coluna de origem exatamente como aparece no export ServiceNow real:

Coluna no export ServiceNowColuna destino (v2.0.0)Observação
install_statusINSTALL_STATUStexto direto
life_cycle_stage_statusLIFE_CYCLE_STAGE_STATUStexto direto
assigned_to (ou assigned, se assigned_to vier vazio)ASSIGNED_TOnos ativos AMPM amostrados, os dois vinham vazios com frequência — não é bug, é lacuna do cadastro de origem
attestation_scoreATTESTATION_SCOREnumérico direto
attestation_statusATTESTATION_STATUStexto direto (ex.: "Ainda não revisada")
attestedATTESTED_FLAGvem como Verdadeiro(a)/Falso(a) — mesma convenção já usada em SOX/COFRE/TENABLE/SIEM no capítulo 10; converter para 1/0
attested_byATTESTED_BYtexto direto
u_fim_do_suporteU_FIM_DO_SUPORTEformato confirmado: DD-MM-YYYY (ex.: 01-07-2029) — configurar a máscara de data do Data Load Wizard como DD-MM-YYYY
locationLOCATIONtexto direto
asset_tagASSET_TAGtexto direto
u_server_roleU_SERVER_ROLEtexto direto

4. Mapeamento — DL_TECH_VULNERABILIDADE_V3 (23 colunas novas)

Coluna no export TenableColuna destino (v2.0.0)Observação
definition.cveDEFINITION_CVElista separada por vírgula, texto direto
definition.descriptionDEFINITION_DESCRIPTIONtexto direto (CLOB)
definition.solutionDEFINITION_SOLUTIONtexto direto (CLOB)
definition.synopsisDEFINITION_SYNOPSIStexto direto
software_vulnsSOFTWARE_VULNStexto bruto (CLOB) — não fazer parsing agora, formato não é JSON válido (ver gap analysis seção 2.4)
definition.cvss3.base_scoreDEFINITION_CVSS3_BASE_SCOREnumérico direto
definition.cvss3.base_vectorDEFINITION_CVSS3_BASE_VECTORtexto direto
definition.cpeDEFINITION_CPEtexto direto
definition.epss.scoreDEFINITION_EPSS_SCOREnumérico direto
definition.vpr.drivers_on_cisa_kevCISA_KEV_FLAGconfirmado: vem como texto true/false (não aninhado) — converter para 1/0
definition.exploited_by_malwareEXPLOITED_BY_MALWARE_FLAGconfirmado: texto true/false — converter para 1/0
definition.exploited_by_nessusEXPLOITED_BY_NESSUS_FLAGconfirmado: texto true/false — converter para 1/0
portPORTnumérico direto
asset.operating_systemASSET_OPERATING_SYSTEMtexto direto; asset.operating_systems (plural) tem o mesmo conteúdo nos exemplos vistos — usar o singular como principal
last_fixedLAST_FIXEDdata/timestamp direto
time_to_fixTIME_TO_FIXnumérico direto
vuln_sla_dateVULN_SLA_DATEdata/timestamp direto
definition.patch_publishedPATCH_PUBLISHEDcorreção: o nome real no export tem o prefixo definition., diferente do que constava antes
definition.vulnerability_publishedVULNERABILITY_PUBLISHEDcorreção: idem, prefixo definition.
sourceSOURCE_SCANtexto direto
scan.idSCAN_IDtexto direto
scan.targetSCAN_TARGETtexto direto

5. Como criar os perfis — e por que não é um script SQL

Por que isto não vira um .sql como os Passos 1 e 2

As definições de carga (DL_TECH_CMDB_V1 e as duas de vulnerabilidades) já existem hoje dentro de sql/02_ampminsights_apex_app.sql, criadas via wwv_flow_imp_shared.create_data_profile/.create_data_profile_col/ .create_load_table — a API interna que o próprio export/import do APEX usa. Escrever essas chamadas à mão, fora do contexto de um import completo (com os IDs que só o APEX gera corretamente), arrisca corromper os Shared Components da Application 100. Por isso este passo é feito uma vez no App Builder e depois capturado automaticamente num novo export completo (seção 7) — o cliente nunca toca em Data Load Definitions manualmente, só importa esse arquivo, exatamente como já faz hoje em cada release.

Boa notícia: não precisa preencher campo a campo. O jeito mais rápido é criar o perfil do zero apontando pra um arquivo de amostra (só cabeçalho, sem dados) com todas as colunas certas — o APEX detecta as colunas automaticamente a partir do cabeçalho. Já preparei os dois arquivos:

Arquivo de amostra (no repositório)ColunasPerfil a criar
templates/sample_DL_TECH_CMDB_V2.xlsx27 (16 originais + 11 novas — sem RAW_JSON)DL_TECH_CMDB_V2
templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx40 (18 originais + 22 novas — sem RAW_JSON)DL_TECH_VULNERABILIDADE_V3
  1. Baixe os dois arquivos de templates/ neste repositório.
  2. App Builder → Application 100 → Shared Components → Data Load Definitions → Create.
  3. Na tela de criação, escolha carregar a partir de um arquivo e faça upload do sample_DL_TECH_CMDB_V2.xlsx (ou o de vulnerabilidades) — o APEX lê o cabeçalho e monta o Data Profile com as 27 (ou 40) colunas automaticamente.
  4. Name: DL_TECH_CMDB_V2 (ou DL_TECH_VULNERABILIDADE_V3). Target Type: Table. Table Name: TB_26AI_TECH_CMDB (ou TB_26AI_TECH_V2). Loading Method: Append — mesma configuração do perfil original (ver aba "Data Load" da tela, igual à do DL_TECH_CMDB_V1).
  5. Em Edit Data Profile, confira o tipo de cada coluna nova contra a tabela da seção 3 (ou 4) — a maioria detecta como VARCHAR2/texto por padrão, então ajuste manualmente: DEFINITION_CVSS3_BASE_SCORE, DEFINITION_EPSS_SCORE, PORT, TIME_TO_FIX, ATTESTATION_SCORE → NUMBER; LAST_FIXED, VULN_SLA_DATE, PATCH_PUBLISHED, VULNERABILITY_PUBLISHED → data/timestamp; U_FIM_DO_SUPORTE → data, máscara DD-MM-YYYY.
  6. Para os campos flag (ATTESTED_FLAG, CISA_KEV_FLAG, EXPLOITED_BY_MALWARE_FLAG, EXPLOITED_BY_NESSUS_FLAG): configure a transformação de valor (Column Transformation) Verdadeiro(a)/true → 1, Falso(a)/false → 0 — mesma convenção já usada em SOX/COFRE/TENABLE/SIEM.
  7. Salve e teste com uma planilha pequena (5-10 linhas de ativos AM..., com dado real nas colunas — não só o cabeçalho) antes de rodar a carga completa.

6. Como validar

Depois de rodar uma carga de teste pequena:

Confirma que os campos novos vieram preenchidos
SELECT asset_name, definition_cve, definition_cvss3_base_score,
       cisa_kev_flag, exploited_by_malware_flag
FROM V_26AI_TECH
WHERE definition_cve IS NOT NULL
FETCH FIRST 5 ROWS ONLY;

Se vier linha com DEFINITION_CVE preenchido e CISA_KEV_FLAG/ EXPLOITED_BY_MALWARE_FLAG como 1 ou 0 (nunca texto), os perfis estão funcionando.

7. Como isso chega ao cliente (sem ele tocar em App Builder)

Depois dos perfis criados e testados (seções 5 e 6), a captura definitiva é um novo export completo da Application 100 (App Builder → Application 100 → ícone de exportar/download → SQL Script) — isso gera um 02_ampminsights_apex_app.sql novo, com os dois perfis novos já embutidos com os IDs corretos gerados pelo próprio APEX. Esse arquivo substitui o atual no próximo release (mesmo fluxo já usado em toda entrega anterior — zip → bucket → PAR, ver o processo de release do projeto). O cliente só importa esse arquivo via App Builder → Import — um wizard guiado, não precisa entender Data Load Definitions.

Você faz isso uma vez; o cliente nunca faz

As seções 5-6 (criar e testar os perfis) são trabalho seu, num ambiente com acesso ao App Builder. O cliente recebe só o resultado — o export completo atualizado — e importa como já importa qualquer outra versão da aplicação.