Periodicamente dovremmo svolgere degli esami. Non perché stiamo male, ma proprio perché serve verificare (anche quando non ci sono sintomi) che tutto sia in ordine.
La visita serve a misurare quello che non si vede: pressione, glicemia, parametri che possono essere fuori norma per mesi senza produrre sintomi, fin quando il problema non diventa abbastanza grande da manifestarsi. Il valore della visita non sta nel trovare qualcosa, sta nel sapere che quello che non si vede è davvero sotto controllo, oppure nel trovare qualcosa prima che diventi un'emergenza.
Un SAP S/4HANA Security Assessment funziona esattamente così. Il sistema SAP lavora, i processi "girano", gli utenti accedono, le interfacce comunicano. Tutto sembra in ordine. Ma dentro, in strati di configurazione che nessuno esamina da mesi o da anni, possono esserci condizioni che un attaccante esterno o un insider malevolo sa riconoscere e sfruttare.
Autorizzazioni eccessive che nessuno ha mai revocato. SAP Security Notes critiche non applicate. Utenze tecniche con profili troppo ampi create per sbloccare un'emergenza e dimenticate lì. Accessi Fiori configurati in fretta che mostrano dati che non dovrebbero essere visibili.
L'assessment non è la cura: è la diagnosi.
Ed è da una diagnosi accurata che si costruisce qualsiasi piano di sicurezza che abbia senso.
Cosa si analizza, cosa emerge tipicamente dai sistemi delle aziende?
C'è una tentazione comprensibile: usare per S/4HANA le stesse checklist, gli stessi strumenti e la stessa metodologia che funzionavano su SAP ECC. Dopotutto, il sistema è SAP, i concetti di base sono gli stessi, le transazioni di analisi sono familiari, il team conosce già i punti critici da esaminare.
È una tentazione che porta sistematicamente a risultati incompleti.
S/4HANA non è ECC con un'interfaccia nuova: è una piattaforma con un'architettura diversa, e quella differenza architetturale produce superfici di attacco e vulnerabilità che in ECC semplicemente non esistevano.
In SAP ECC la superficie di accesso è sostanzialmente piatta: transazioni SAP GUI, RFC, web services. In S/4HANA si aggiunge un layer intero, le app SAP Fiori; che ha una propria logica di sicurezza, propri punti di esposizione e proprie vulnerabilità.
Le app Fiori comunicano con il backend attraverso servizi OData: layer di API che, se non configurati correttamente, possono esporre dati sensibili a utenti non autorizzati o in scenari di attacco più sofisticati a soggetti esterni che hanno trovato un punto di ingresso nella rete aziendale (Fiori esposto su internet).
Immaginiamo gli OData services come alle finestre di un edificio. Le porte, le transazioni SAP GUI, sono presidiate da anni, in azienda si conosce tutto, il tipo di serrature, sapete chi ha le chiavi. Le finestre sono state aperte quando si è installato S/4HANA e quindi Fiori, ma non tutte sono state dotate di inferriate.
Un assessment che non esamina il layer OData sta guardando le porte e ignorando le finestre.
SAP S/4HANA gira su database HANA; un database in-memory con caratteristiche architetturali diverse dai database tradizionali (Oracle, SQL Server, MaxDB) usati con ECC. Anche se tecnicamente è possibile utilizzare HANA anche su sistemi ECC.
HANA ha una propria gestione degli accessi, propri utenti di amministrazione, proprie procedure di backup e proprie vulnerabilità specifiche.
Un assessment SAP S/4HANA che non include una verifica della configurazione di sicurezza del database HANA è un assessment che ignora le fondamenta dell'edificio.
Per le aziende che hanno adottato estensioni su SAP Business Technology Platform app custom, integrazioni, workflow approvazione, analytics, il perimetro dell'assessment deve estendersi oltre il sistema S/4HANA on-premise. La BTP ha infatti un proprio modello di autorizzazione, proprie identità utente e propri meccanismi di autenticazione che devono essere verificati separatamente e in relazione al sistema core.
Trascurare BTP in un assessment S/4HANA significa valutare la sicurezza di un edificio limitandosi ad alcuni aspetti o stanze.
Un assessment strutturato su S/4HANA copre sei aree principali, ciascuna con le proprie tecniche di analisi e i propri indicatori di rischio. Non sono indipendenti: i problemi in un'area aggravano spesso quelli in un'altra, e una visione d'insieme è necessaria per valutare il rischio reale del sistema.
È l'area centrale di qualsiasi assessment SAP, e quella che in S/4HANA presenta la maggiore complessità, perché al tradizionale sistema di ruoli e profili SAP GUI si aggiunge l'intera architettura Fiori.
L'analisi esamina: la struttura dei ruoli e la loro coerenza con il principio del minimo privilegio; la presenza di profili ad alto rischio come accessi completi su oggetti critici; la corretta configurazione dei Business Catalog e dei Business Role Fiori; gli accessi effettivamente esercitati rispetto a quelli assegnati; e la presenza di utenti con ruoli che coprono funzioni incompatibili, il segnale classico di una violazione di SoD.
Come in una radiografia, l'analisi delle autorizzazioni mostra la struttura interna del sistema, non quella che appare in superficie, ma quella reale, con le fratture e le anomalie che si sono accumulate nel tempo senza che nessuno le vedesse dall'esterno.
Le utenze di amministrazione SAP e le utenze tecniche sono i punti di maggiore concentrazione di potere nel sistema e quindi i punti di maggiore rischio.
L'assessment le esamina una per una: chi sono, quali ruoli o profili hanno, quando sono state create, chi le ha create, quando sono state usate l'ultima volta, se hanno una scadenza definita.
Le utenze tecniche sono spesso il capitolo più sorprendente di un assessment. Si trovano regolarmente utenze create anni prima per un'emergenza specifica; un'interfaccia da sbloccare, una migrazione da completare, un'urgenza di fine mese, e mai disattivate.
Alcune hanno profili che in quel momento sembravano l'unico modo per risolvere il problema. Col tempo sono diventate porte aperte dimenticate, aperte, accessibili, ma invisibili perché nessuno le usa e quindi nessuno le nota (nella migliore delle ipotesi).
SAP pubblica le Security Notes, le patch di sicurezza, ogni secondo martedì del mese. Alcune correggono vulnerabilità minori. Altre correggono vulnerabilità critiche.
Una Security Note non applicata è come una finestra rotta che tutti nel palazzo sanno essere rotta. Il proprietario la conosce, ci ha messo del nastro adesivo provvisorio, "la sistemeremo presto", ma nel frattempo chiunque passi di lì può notarla.
I database delle vulnerabilità SAP note sono pubblici. Chi attacca i sistemi SAP li consulta regolarmente.
Il Security Audit Log di SAP (transazione SM20 o RSAU_CONFIG / RSAU_READ_LOG) è lo strumento che registra chi ha fatto cosa nel sistema e quando. Se è configurato correttamente, è la prima risorsa da consultare quando si sospetta un accesso anomalo o quando si deve rispondere a un audit normativo. Se non è configurato, o se è attivo ma registra solo una piccola parte degli eventi rilevanti, l'azienda naviga al buio: sa che qualcosa è successo, ma non ha i dati per capire cosa.
Per contesti normativi come NIS2 o SOX, la retention è un requisito esplicito. Per qualsiasi scenario di incident response, è una necessità pratica.
S/4HANA è un sistema sempre più accessibile da remoto, SAP Fiori da browser, accessi di supporto dei partner via VPN, integrazioni cloud.
Ogni canale di accesso remoto è un potenziale punto di ingresso che deve essere protetto.
L'assessment verifica la presenza di autenticazione a più fattori (MFA) sugli accessi remoti, la configurazione dei parametri di sicurezza delle sessioni, i timeout di sessione, e la gestione degli accessi dei fornitori e dei partner esterni.
L'analisi si estende al di sotto del layer applicativo SAP per verificare la configurazione di sicurezza del database HANA: utenti di amministrazione, autorizzazioni sugli schemi, configurazione della crittografia, sicurezza della comunicazione tra application server e database, e aggiornamento delle patch HANA.
C'è una ragione per cui molti CIO e responsabili IT, dopo aver ricevuto il report di un SAP S/4HANA Security Assessment, commentano con una variante della stessa frase: "non pensavamo fosse così." Non necessariamente peggiore di quanto temuto; in alcuni ambiti persino migliore, ma comunque diversa.
Diversa perché il sistema che appare dall’esterno, attraverso i report generati e le evidenze, non è lo stesso sistema che si vede dall’interno, con lo sguardo di chi conosce davvero dove e cosa osservare.
In quasi tutti gli assessment emerge almeno un'utenza nominativa o tecnica con il profilo SAP_ALL attivo in produzione.
Spesso il team IT ne è consapevole : "è rimasto lì da quando abbiamo fatto il go-live", "è l'utente del consulente che ci ha aiutato nella migrazione", "lo usiamo per le emergenze".
Quello che non sempre vien considerato è che SAP_ALL in produzione è la chiave maestra dell'intero sistema: chiunque abbia accesso a quell'utenza può fare qualunque cosa, leggere qualunque dato, modificare qualunque configurazione.
È come tenere la chiave del caveau in bella mostra sulla scrivania della reception.
In qualsiasi assessment è il primo elemento che si verifica, come una sorta di prima impressione. Se non se ne rilevano, su nessuna utenza, comprese quelle tecniche , è già un segnale molto positivo.
Il patch management SAP è in molti casi più complesso di un aggiornamento Windows: le Security Notes vanno valutate, testate nei sistemi non produttivi e approvate prima di essere applicate, creando inevitabilmente un ritardo.
In molti sistemi questo ritardo è diventato di anni, con note critiche non applicate per vulnerabilità note e pubbliche. Non è negligenza intenzionale, ma l’effetto di processi di change lenti, risorse limitate e una priorità che il business rimanda perché “il sistema funziona”.
La configurazione dei Business Catalog Fiori è un'operazione delicata che, se eseguita con fretta o con scarsa conoscenza dello strumento, produce spesso risultati inattesi: app visibili a utenti che non dovrebbero vederle, dati esposti tramite i servizi OData senza restrizioni adeguate, tile del Launchpad che portano a funzionalità incompatibili con il ruolo dell'utente.
In molti sistemi S/4HANA di prima generazione, quelli migrati quando Fiori era ancora una novità, questa configurazione non è mai stata rivista sistematicamente dopo il go-live. Oppure la gestione dei gruppi vs spazi.
Le violazioni di Segregation of Duties che emergono dagli assessment non sono quasi mai frutto di scelte consapevoli: sono il risultato di anni di piccole modifiche incrementali al role concept, ciascuna motivata da un'esigenza legittima, ma che nell'insieme hanno prodotto combinazioni di accesso che nessuno aveva progettato.
L'utente del ciclo attivo che può anche approvare le note di credito che genera.
Il responsabile acquisti che può anche confermare il pagamento ai fornitori che ha selezionato. Singolarmente, ciascuna autorizzazione ha una giustificazione. Insieme, violano i principi fondamentali di controllo interno.
Tornando alla metafora medica: una visita di controllo non si esaurisce con la misurazione della pressione. Prevede un percorso anamnesi, esami, diagnosi, piano terapeutico in cui ciascun passo informa il successivo. Lo stesso vale per un assessment SAP S/4HANA strutturato.
La risposta ideale è: regolarmente, almeno una volta all'anno, come la visita medica annuale. Ma ci sono momenti specifici in cui l'assessment è particolarmente urgente — o particolarmente prezioso.
Il periodo immediatamente successivo al go-live è quello in cui il sistema è più esposto: le configurazioni sono nuove, il role concept è stato costruito sotto pressione di progetto, le urgenze dell'Hypercare hanno prodotto workaround che nessuno ha ancora rivisto.
Un assessment nei primi 3-6 mesi dopo il go-live è il modo più efficace per identificare i problemi introdotti durante la migrazione prima che si consolidino e diventino "parte del paesaggio".
NIS2, SOX, ISO 27001, audit del revisore contabile: tutti questi contesti richiedono che l'azienda possa dimostrare di avere il controllo sulla sicurezza dei propri sistemi critici. Un assessment condotto prima dell'audit con il tempo necessario per correggere i gap identificati è molto più utile di scoprire i problemi durante l'audit stesso.
È la differenza tra farsi trovare preparati e farsi trovare impreparati: il risultato è lo stesso se non ci sono problemi, ma radicalmente diverso se ci sono.
Fusioni, acquisizioni, ristrutturazioni, cambi del sistema di gestione IT, onboarding di nuovi grandi fornitori con accesso al sistema SAP: tutti questi eventi alterano il perimetro di sicurezza del sistema in modi che non sempre vengono catturati dai processi ordinari di gestione degli accessi.
Un assessment dopo un cambio organizzativo significativo è il modo per verificare che il perimetro rimanga sotto controllo.
Ogni volta che il perimetro del sistema si estende nuovi servizi BTP, nuove integrazioni cloud, nuovi scenari mobile il perimetro di sicurezza si estende di conseguenza.
Un assessment mirato sul nuovo perimetro è il modo per assicurarsi che l'espansione non abbia introdotto vulnerabilità che il team IT non conosce ancora.
Un SAP S/4HANA Security Assessment è un'analisi strutturata dello stato di sicurezza del sistema. Esamina autorizzazioni, ruoli, profili utente, app Fiori, utenze tecniche, patch management, audit trail, accessi remoti e sicurezza del database HANA. Il risultato è un report con i rischi identificati, la loro severità e un piano di remediation prioritizzato.
Un assessment S/4HANA deve coprire aree assenti o marginali in ECC: la sicurezza delle app Fiori e dei servizi OData, i nuovi oggetti di autorizzazione specifici di S/4HANA, la sicurezza del database HANA e la gestione delle autorizzazioni in scenari ibridi con SAP BTP. Un assessment condotto con metodologie ECC applicato a S/4HANA produce risultati incompleti e potenzialmente fuorvianti.
Un assessment completo richiede tipicamente tra 2 e 4 settimane.
La raccomandazione è almeno una volta all'anno, integrata da revisioni più frequenti sulle aree a maggiore dinamicità. Un assessment dovrebbe essere eseguito anche in occasione di eventi specifici: go-live post-migrazione, cambi organizzativi, onboarding di nuovi fornitori, attivazione di SAP BTP o preparazione a un audit normativo.
No. L'assessment viene condotto in modalità read-only, senza modifiche alla configurazione e senza interruzione dell'operatività. L'analista accede con credenziali dedicate, esegue le verifiche tramite transazioni di analisi e non effettua alcuna modifica al sistema.
Vuoi capire qual è il reale stato di sicurezza del tuo sistema SAP S/4HANA? O stai pianificando un assessment e vuoi confrontarti su come strutturarlo in modo da ottenere risultati davvero utili?