Oltre il controllo del codice sorgente: verifica della distinta base IBM i per l'integrità di DevSecOps

DevSecOps su IBM i: protezione dell'integrità a livello di oggetto in tutti gli ambienti

Nel mondo IBM i, gli ecosistemi applicativi sono vasti, complessi e profondamente integrati. A differenza dei sistemi distribuiti, le applicazioni IBM i comprendono migliaia di oggetti discreti (programmi, aree dati, file, programmi di servizio e altro ancora) distribuiti su più librerie e ambienti, inclusi sviluppo, test e produzione. Gestire l'integrità, la sincronizzazione e la sicurezza di questi oggetti è essenziale per la continuità operativa e la conformità normativa.

Comprensione degli oggetti e delle dipendenze IBM i

Le applicazioni IBM i sono fondamentalmente basate su oggetti. Ogni oggetto svolge una funzione specifica, risiede in una libreria e contiene attributi come proprietà, autorità e dipendenze da altri oggetti. Ad esempio, un oggetto programma può dipendere da un programma di servizio o da un file di database, che deve essere nella versione corretta affinché l'applicazione funzioni correttamente.

Poiché questi oggetti vengono distribuiti come file binari e non creati dinamicamente dal codice sorgente in fase di esecuzione, come avviene in molti sistemi distribuiti, è particolarmente importante tenere traccia e verificare le versioni corrette di tutti gli oggetti in ogni ambiente.

La sfida DevSecOps

I team operativi e di sviluppo devono collaborare per garantire che gli oggetti IBM i rimangano coerenti tra sviluppo, test e produzione. Senza un processo DevSecOps coordinato, è facile che gli oggetti perdano la sincronia: file binari obsoleti, impostazioni di autorizzazione errate, dipendenze compilate in modo errato e modifiche non autorizzate possono introdurre rischi operativi.

Tali discrepanze possono causare guasti alle applicazioni, vulnerabilità della sicurezza, risultati di audit e ripercussioni finanziarie.

Il rischio aumenta quando le correzioni di emergenza vengono applicate direttamente in produzione. Sebbene spesso necessarie per risolvere problemi urgenti, questa pratica aggira i processi formali di controllo delle modifiche, i repository del codice sorgente e gli audit trail. Quando queste modifiche non vengono adattate ai sistemi di sviluppo e test, le deviazioni dell'ambiente possono persistere senza essere rilevate.

Nello scenario peggiore, gli ambienti di produzione potrebbero essere compromessi da modifiche dannose. Poiché gli oggetti IBM i non vengono ricostruiti dal codice sorgente durante la distribuzione, un malintenzionato con accesso alla produzione potrebbe iniettare file binari dannosi che rimangono invisibili alle revisioni standard del codice sorgente.

Proteggere la pipeline DevSecOps

Una strategia DevSecOps efficace per IBM i richiede più del semplice controllo del codice sorgente: richiede una governance completa a livello di oggetto. Le pratiche chiave includono:

• Monitoraggio e verifica a livello di oggetto: implementare strumenti e processi per monitorare gli oggetti in tutti gli ambienti, verificando che i file binari di produzione corrispondano esattamente a quanto definito negli ambienti di controllo del codice sorgente e di sviluppo.
• Distribuzione facile da controllare: adotta flussi di lavoro di promozione che registrano quali oggetti vengono distribuiti, dove, quando e da chi.
• Sincronizzazione dell'ambiente: assicurarsi che le correzioni di emergenza vengano acquisite, documentate e adattate negli ambienti di sviluppo e test per mantenere l'allineamento.
• Gestione delle autorizzazioni: verificare regolarmente le autorizzazioni a livello di oggetto per identificare privilegi eccessivi, modifiche improprie della proprietà e potenziali rischi per la sicurezza.

Perché l'integrità degli oggetti è importante

Anche con una distinta base (BOM) documentata per ogni release, avere un elenco degli oggetti previsti non è sufficiente. È necessario confermare che gli oggetti effettivamente in esecuzione in produzione corrispondano a quelli previsti dallo sviluppo e dal controllo del codice sorgente.

Le discrepanze possono causare fallimenti di audit, incongruenze operative e, nei casi più gravi, interruzioni aziendali dovute all'esecuzione di codice dannoso.

Le conseguenze di un audit fallito sono significative: sanzioni normative, danni alla reputazione, ritardi operativi e perdite finanziarie. Le organizzazioni potrebbero essere costrette a interrompere le implementazioni, riconvalidare i sistemi o sospendere le operazioni fino al ripristino della conformità.

Colmare il divario nel controllo della sorgente

Negli ambienti IBM i, DevSecOps non riguarda solo l'automazione della pipeline, ma anche la preservazione dell'integrità e della fiducia in ogni ambiente, un oggetto alla volta. I sistemi di controllo delle versioni più diffusi come Git, pur essendo eccellenti per la gestione del codice sorgente, non gestiscono in modo nativo l'architettura basata su oggetti di IBM i. Non sono in grado di confermare se l'oggetto distribuito in produzione sia stato creato a partire dal codice sorgente nel repository.

Questa lacuna evidenzia la necessità di ulteriori strumenti e processi di verifica specifici per IBM i per mantenere la fiducia operativa e la conformità.

Conclusion

Il successo di DevSecOps su IBM i non dipende solo dall'automazione, ma anche da una verifica rigorosa e continua dell'integrità a livello di oggetto nei sistemi di sviluppo, test e produzione. Poiché le applicazioni IBM i vengono create e distribuite come oggetti binari, spesso indipendenti dai repository sorgente, i tradizionali strumenti di controllo del codice sorgente non sono sufficienti a garantire la fedeltà di produzione.

Per proteggersi da problemi di conformità, minacce alla sicurezza e interruzioni operative, le organizzazioni devono adottare pratiche DevSecOps basate sugli oggetti. Ciò include un monitoraggio approfondito, processi di distribuzione pronti per l'audit, sincronizzazione proattiva dell'ambiente e scrupolose revisioni delle autorità.

In definitiva, per un DevSecOps efficace su IBM i è necessario verificare cosa è effettivamente in esecuzione, non solo ciò che è documentato.