Negli audit aziendali su larga scala, i team tecnici riscontrano costantemente che la maggior parte dei report Universal Batch Engine (UBE)Il motore di JD Edwards che gestisce l'esecuzione di report e processi batch in background. personalizzati aggira involontariamente il kernel di sicurezza JDE (F00950La tabella centrale di JD Edwards che gestisce tutte le configurazioni di sicurezza degli utenti.). I leader ERP spesso presumono che la row securityFunzionalità che limita l'accesso ai dati nel database in base a valori specifici, come filiali o società. attiva su tabelle come F060116 (Payroll) o F4105 (Item Cost) limiti intrinsecamente l'output dei batch. Non è così. Nel momento in cui uno sviluppatore utilizza il Table I/OOperazioni di lettura o scrittura diretta sul database eseguite all'interno del codice di JD Edwards. diretto nelle Event RulesIl linguaggio di programmazione visuale proprietario utilizzato per personalizzare la logica in JD Edwards. o richiama una C Business FunctionFunzioni scritte in linguaggio C per eseguire elaborazioni complesse o ad alte prestazioni in JD Edwards. personalizzata che esegue JDB_OpenTable senza passare esplicitamente il contesto di sicurezza dell'utente, la row security a livello di engine viene ignorata.

La mitigazione dei rischi di sicurezza e visibilità dei dati nei report personalizzati JDE UBE richiede la valutazione dell'intera pipeline di output, non solo dei permessi di esecuzione dell'utente. I processi batch personalizzati archiviano regolarmente compensi dei dirigenti non mascherati, margini unitari e dettagli bancari dei fornitori come file PDF piatti direttamente nella directory PrintQueueLa cartella sul server JD Edwards in cui vengono salvati temporaneamente i file di output dei report generati. dell'Enterprise Server, oppure li inviano tramite liste di distribuzione automatizzate a ruoli interni non autorizzati. Se i controlli di sicurezza non sono progettati direttamente nella Business ViewUn oggetto logico che definisce la relazione tra le tabelle del database utilizzate da report e applicazioni. sottostante o applicati a livello di codice a runtime, il vostro parco di UBE personalizzati rimane una backdoor silenziosa e non monitorata nel database.

Bypass della Row Security nelle Business View Personalizzate e nel Codice ER

Le Business View create su misura per gli UBE omettono frequentemente i campi chiave per la sicurezza come Company (CO), Business Unit (MCU) o Address Number (AN8)Il numero identificativo univoco utilizzato in JD Edwards per clienti, fornitori, dipendenti e contatti.. Quando uno sviluppatore crea una vista su F0911 o F0101 ed esclude il campo MCU per semplificare i criteri di join, il generatore SQL a runtime di EnterpriseOneLa suite ERP moderna e web-based sviluppata da JD Edwards (Oracle). perde il suo punto di ancoraggio. Di conseguenza, non può aggiungere le clausole WHERE di row security della tabella F00950 alle query di database generate. L'engine elabora la richiesta senza filtri, esponendo transazioni GL globali o record anagrafici a utenti che dovrebbero vedere solo una singola filiale.

Spostare l'accesso ai dati nelle Event Rules introduce una vulnerabilità parallela attraverso il Table I/O. Mentre i fetch standard della sezione principale basata su Business View invocano la sicurezza a runtime, le operazioni di Table I/O nelle ERAcronimo di Event Rules, la logica di programmazione interna di JD Edwards. — come i costrutti Fetch Single o Select/Fetch Next espliciti — eseguono operazioni dirette sul database che aggirano completamente le regole di sicurezza della F00950. Se un report personalizzato calcola i saldi YTD scansionando la tabella F0902 tramite Table I/O nelle ER, un manager operativo limitato alla Business Unit 100 aggregherà i saldi di tutte le unità operative senza generare alcuna eccezione di sicurezza a runtime.

La funzione di sistema esplicita Suppress Row SecurityUna funzione di sistema che disattiva temporaneamente i controlli di sicurezza a livello di riga per ottimizzare o sbloccare query. inserita nelle Event Rules trasforma l'esposizione localizzata dei dati in un bypass totale dell'esecuzione. Gli sviluppatori inseriscono regolarmente questa chiamata nell'evento Initialize Section per risolvere errori di fetch o velocizzare l'esecuzione su centinaia di migliaia di record. Una volta eseguita, disabilita permanentemente la valutazione della sicurezza a runtime per l'intero ambito di esecuzione del report, eseguendo ogni successiva chiamata al database con visibilità amministrativa, indipendentemente da chi abbia avviato il job.

Questi difetti arrivano regolarmente in produzione perché i team convalidano gli UBE personalizzati esclusivamente con profili SYSADMIN o CNCConfigurable Network Computing, l'architettura di sistema e il ruolo di amministratore tecnico in JD Edwards. durante i test unitari. I ruoli amministrativi operano senza le restrizioni della F00950, quindi l'assenza di campi chiave genera comunque totali corretti durante la fase di QAQuality Assurance, la fase di test e controllo qualità del software prima del rilascio in produzione., senza avvisare il team dell'esposizione sottostante. La convalida della sicurezza degli UBE richiede l'esecuzione di cicli di test obbligatori con ruoli operativi limitati e l'auditing delle definizioni delle Business View personalizzate per confermare che MCU, CO e AN8 siano presenti in ogni tabella principale.

Custom UBE Data Path: Enforced vs Bypassed Security

La Fallacia del Fetch Diretto delle Tabelle nelle C Business Functions

Quando gli sviluppatori scrivono C Business Functions per evitare il sovraccarico delle Event Rules nei job batch pesanti, la prima APIApplication Programming Interface, un insieme di funzioni che permette a diversi componenti software di comunicare tra loro. che utilizzano è JDB_OpenTable. Se tale chiamata inizializza un handle di tabella senza un handle utente (hUser) esplicitamente associato derivato da JDB_InitUser o JDB_InitBhvr, il runtime esegue la query del database con i privilegi completi del processo. In gran parte delle riscritture personalizzate per ottimizzare le prestazioni, gli sviluppatori passano un handle di sistema generico per risparmiare poche righe di codice, escludendo completamente il kernel di sicurezza JDE dal round-trip del database.

Questa pratica inizia solitamente come un tentativo di ottimizzazione per gli UBE personalizzati che elaborano centinaia di migliaia di record. Gli sviluppatori sostituiscono le Business View standard con fetch diretti in C per ridurre i tempi di esecuzione dei job da ore a minuti, ignari del fatto che i thread asincroni degli UBE in background valutano le regole di sicurezza della F00950 in modo diverso rispetto alle sessioni APPLLe applicazioni interattive con interfaccia utente grafica in JD Edwards. interattive. Mentre le schermate delle applicazioni interattive passano automaticamente il contesto della sessione utente attiva attraverso il kernel di sicurezza, i processi batch in background eseguiti sull'Enterprise Server si affidano interamente agli handle utente esplicitamente costruiti all'interno dello stack di chiamata delle funzioni.

Includere questi fetch non convalidati all'interno di C BSFN generiche e riutilizzabili apre un vettore permanente di esfiltrazione dei dati in tutta la libreria dei report. Un UBE finanziario personalizzato che richiama una funzione di fetch diretto su tabelle sensibili come F060116 per il payroll o F4105 per i costi effettivi aggirerà completamente la sicurezza a livello di riga se hUser è assente. L'UBE mostrerà dati riservati a qualsiasi utente autorizzato a inviare il report, indipendentemente dalla sua configurazione di row security nella F00950. Prima di promuovere oggetti C personalizzati tramite OWMObject Management Workbench, lo strumento di JD Edwards per gestire lo sviluppo e il ciclo di vita degli oggetti software. verificate ogni chiamata JDB_OpenTable per assicurarvi che colleghi gli handle del database direttamente al contesto utente a runtime.

Esposizione della Directory PrintQueue e Output WSJ Non Protetto

Quando un Enterprise Server esegue un UBE, l'engine di runtime scrive l'output grezzo in formato PDF, CSV e OSA direttamente nella directory PrintQueue come file piatti non crittografati, prima che venga attivata qualsiasi logica di distribuzione. Su un tipico server di produzione con AIX o Windows Server 2022, qui si accumulano migliaia di file temporanei contenenti dati salariali grezzi, dettagli dei conti bancari e profili di credito dei clienti non mascherati. Se gli amministratori di sistema lasciano intatti i permessi predefiniti del sistema operativo, gli account di servizio o gli utenti del dominio locale possono aggirare completamente la sicurezza di EnterpriseOne leggendo direttamente il file system tramite condivisioni SSHSecure Shell, un protocollo di rete crittografato utilizzato per accedere in modo sicuro a un server remoto. o SMBServer Message Block, un protocollo di rete utilizzato principalmente per condividere file e stampanti tra computer..

All'interno di EnterpriseOne, la vulnerabilità si manifesta attraverso configurazioni errate in Work With Submitted Jobs (P986110B) e nella sua tabella sottostante F986110 Job Master. La sicurezza standard predefinita di JDE consente agli utenti di interrogare lo stato di esecuzione in tutti gli ambienti, il che significa che un impiegato di livello inferiore può visualizzare le intestazioni dei job creati da ruoli dirigenziali. Senza una row security esplicita che limiti F986110.JCUSER all'utente connesso, qualsiasi dipendente che apre il WSJWork with Submitted Jobs, l'applicazione di JD Edwards utilizzata per monitorare lo stato dei processi batch inviati. può selezionare un job batch di payroll o GL eseguito dal CFO e selezionare Row > View Output per scaricare il PDF non crittografato.

L'esposizione si amplia quando il burstingProcesso che suddivide un unico report cumulativo in più file separati in base a criteri specifici per la distribuzione. dei report è abilitato nelle definizioni standard di UBE o BI PublisherStrumento di Oracle integrato in JD Edwards per formattare, generare e distribuire report in vari formati.. Le routine di bursting generano spesso decine di singoli segmenti PDF e li scrivono in percorsi di staging di rete UNC temporanei prima di inviarli via e-mail alle liste di distribuzione. Poiché queste cartelle di staging raramente applicano liste di controllo degli accessi dinamiche a livello di file, una directory di staging creata per i rendiconti delle commissioni dei fornitori rimane frequentemente leggibile da parte dell'intero dominio per giorni.

Il rafforzamento di questa infrastruttura richiede un'azione amministrativa immediata sia a livello di sistema operativo che di applicazione. Limitate i permessi della directory PrintQueue dell'Enterprise Server esclusivamente all'account di servizio JDE e implementate la row security su F986110 limitando le query su JCUSER in modo che corrispondano a login_user. Infine, pianificate l'esecuzione del Job Master Purge (R9861101) ogni 24 ore con il flag di eliminazione dell'output abilitato, garantendo che i file temporanei rimangano sul disco per meno di 24 ore.

Liste di Distribuzione e Vulnerabilità nella Consegna dei Report

Le Event Rules (ER) e-mail integrate e le definizioni di bursting di BI Publisher rimuovono i controlli di sicurezza nel momento stesso in cui l'engine genera l'output. Quando un report batch viene eseguito con un account utente di sistema generico come OVRWRITE o JDE all'interno dello scheduler aziendale, l'esecuzione ignora le rivalutazioni in tempo reale della Security Workbench F00950 per i destinatari finali dell'output. L'engine elabora il dataset principale utilizzando l'autorità elevata dell'utente del servizio batch, aggirando i modelli di sicurezza basati sui ruoli e a livello di riga che proteggono le applicazioni interattive come P0801 o P4108.

Le liste di distribuzione dinamiche create da tabelle personalizzate aggravano questa vulnerabilità. Gli UBE personalizzati interrogano frequentemente tabelle di cross-reference personalizzate per comporre gli array dei destinatari e-mail per i report sui salari dei dirigenti o sui margini lordi. Se la logica di fetch sottostante salta la convalida esplicita della row security rispetto all'ID utente del destinatario, metriche operative sensibili finiscono direttamente nelle caselle di posta errate. Un dipendente trasferito internamente che ha lasciato una business unit il martedì riceverà comunque il report finanziario non oscurato di quella unit il venerdì, semplicemente perché la query personalizzata convalida lo stato attivo nella Address Book F0101 senza valutare i permessi correnti sui dati.

I protocolli di consegna presentano una lacuna altrettanto critica. Le configurazioni standard di BI Publisher e di consegna della posta nativa di EnterpriseOne instradano gli output PDF e CSV generati su connessioni SMTPSimple Mail Transfer Protocol, il protocollo standard utilizzato per l'invio di e-mail su reti IP. non crittografate sulla porta 25. Gli estratti finanziari grezzi viaggiano in chiaro attraverso le reti interne, lasciando i dati salariali e le strutture dei costi non mascherati esposti a semplici attività di packet sniffing. Il rafforzamento di questa pipeline richiede la configurazione di SMTPS con TLSTransport Layer Security, un protocollo crittografico che garantisce comunicazioni sicure e private su Internet. esplicito all'interno delle impostazioni JDE.INI dell'Enterprise Server e la sostituzione degli allegati di file grezzi con riferimenti URL sicuri e autenticati a repository crittografati.

Applicare la Row Security a Runtime nella Progettazione di Report Personalizzati

L'esecuzione standard delle Event Rules spesso aggira la row security se gli sviluppatori creano Business View personalizzate senza un'applicazione esplicita a runtime. Chiamare esplicitamente la funzione di sistema Set User SelectionFunzione di sistema di JD Edwards utilizzata per aggiungere o modificare dinamicamente i filtri di selezione dei dati in un report. all'interno dell'evento Initialize Section costringe l'engine UBE a valutare il contesto di sicurezza dell'utente che esegue il report dalla tabella F00950 prima di generare la clausola dinamica SQL WHERE. Ciò garantisce che i criteri di selezione guidati dalle ER integrino, anziché annullare involontariamente, la row security attiva mappata sul ruolo dell'utente.

Quando l'elaborazione dei report sposta il Table I/O all'interno di C Business Functions personalizzate, le chiamate standard a JDB_OpenTable vengono spesso eseguite con un handle di sistema non limitato che aggira completamente la row security a runtime. Il refactoring di queste funzioni C per passare handle utente espliciti tramite JDB_InitBhvr garantisce che le mappature di sicurezza della F00950 vengano valutate continuamente durante ogni ciclo di JDB_SelectKeyed e JDB_Fetch. Saltare questo refactoring lascia i saldi della contabilità generale o i record del payroll vulnerabili a un'esposizione totale, indipendentemente dalle restrizioni a livello di oggetto esistenti nell'ambiente.

La sicurezza dei report deve contemporaneamente proteggere la definizione dell'esecuzione all'interno di F9860 e F00950. Se la sicurezza degli oggetti concede l'accesso al prompt a runtime senza restrizioni, gli utenti finali possono facilmente cancellare i filtri strutturali di selezione dei dati nella schermata "Prompt for Values" prima dell'invio. L'applicazione di una rigida sicurezza sulle azioni degli oggetti impedisce la manomissione dei parametri e garantisce che la logica di selezione predefinita rimanga intatta al momento dell'invio in coda.

Le architetture moderne isolano l'elaborazione batch instradando le esecuzioni degli UBE attraverso wrapper di OrchestratorComponente di JD Edwards utilizzato per creare integrazioni, automazioni e API REST senza scrivere codice complesso. invece delle selezioni di menu dirette di EnterpriseOne. L'avvio di un report tramite un'Orchestration applica la convalida dei ruoli a livello RESTUno stile architetturale per la creazione di servizi web leggeri, scalabili e facili da integrare. e la sanificazione del payload di input prima che il job raggiunga le code di lavoro dell'Enterprise Server. Questo livello API moderno impedisce agli utenti non autorizzati di richiamare direttamente le specifiche degli UBE, mantenendo al contempo audit trail completi su tutte le operazioni aziendali.

Comparison of UBE Data Access Patterns

Consolidamento dei Repository di Output degli UBE e Controlli di Audit

Una directory PrintQueue non monitorata su un server aziendale accumula frequentemente decine di migliaia di file PDF e CSV non crittografati che coprono diversi anni di esecuzioni in produzione. Rimuovere i permessi di lettura degli utenti di dominio a livello di sistema operativo — limitando l'accesso al file system esclusivamente all'account di servizio JDE che esegue jdenet_k — rappresenta la difesa di base. Combinate questo intervento con script shell o PowerShellUn framework di automazione e gestione della configurazione di Microsoft, composto da una shell a riga di comando e un linguaggio di scripting. notturni automatizzati per eliminare i file piatti più vecchi di 7-14 giorni. Forzare la gestione dell'output attraverso interfacce web client autorizzate impedisce agli utenti di estrarre output di report obsoleti direttamente dalle condivisioni dell'Enterprise Server.

I soli permessi di directory non impediranno a un utente di salvare copie locali di report riservati una volta generati. Nel file jde.ini dell'Enterprise Server, sotto la sezione [UBE], impostate i flag di PDF EncryptionFunzionalità che protegge i file PDF tramite crittografia e restrizioni su stampa e copia del testo. utilizzando EncryptPDF=1 insieme ai parametri di restrizione a 128 o 256 bit (PrintAllow=N e CopyAllow=N). Questo applica una sicurezza immediata sui documenti per i job batch ad alta sensibilità come R070901 (Payroll Register) e R09801 (GL Post). L'output generato rimane crittografato sia a riposo che in transito, impedendo la stampa non autorizzata, la copia del testo o la serializzazione locale anche nel caso in cui il flusso PDF grezzo venga intercettato.

Prevenite l'esfiltrazione di massa di dataset sensibili disabilitando le funzionalità di esportazione in CSV a livello di Report Properties dell'UBE all'interno di Report Design Aid per gli oggetti ad alto rischio. Per mantenere una supervisione completa, configurate l'auditing sulla tabella Job Control Status Master (F986110) e monitorate le operazioni di visualizzazione dell'output. La correlazione dei record della tabella F986110 (JCUSER, JCPDFNAME, JCJOBSTATUS) con i log di accesso del server delle applicazioni web fornisce ai team di sicurezza una cronologia di tracciamento granulare. In caso di indagini su potenziali violazioni interne, questa aggregazione di log descrive in dettaglio il timestamp esatto, l'indirizzo IP e l'ID utente associati a ogni evento di esecuzione, download o visualizzazione dei report.