Negli ultimi anni il concetto di Zero Trust è passato dall’essere una buzzword a un requisito architetturale fondamentale per proteggere gli ambienti SAP.
L’evoluzione verso cloud, ibrido, accessi remoti e API aperte ha definitivamente reso ormai datato il modello “perimeter-based”. Oggi nessuna azienda può permettersi di dare fiducia implicita a utenti, sistemi o reti.
SAP attraverso la gestione dei processi finanziari, logistici, HR e operativi diventa un luogo da proteggere.
Zero Trust in SAP significa prima di tutto gestione delle identità aziendali.
Partendo dagli aspetti relativi all'autenticazione dei sistemi ad esempio nel caso SAP BTP e S/4HANA, l’autenticazione deve essere implementata tramite l'utilizzo dei servizi Cloud Identity Service, attraverso Identity Authentication Service (IAS) che può essere integrato con provider (IdP Identity Provider) come Microsoft Entra ID o Okta, con MFA obbligatorio per tutti gli utenti SAP. Ma anche alla gestione del provisioning delle abilitazioni.
Secondo le best practice per SAP BTP e ambienti ibridi, la segmentazione logica e di rete è essenziale per evitare movimenti laterali.
Segmentare reti/ambienti è quindi utile in questo senso (es. nel contesto cloud attraverso i subaccounts)
Il minimo privilegio, che consiste nel concedere ad utenti, applicazioni o sistemi solo i permessi minimi indispensabili per svolgere le proprie mansioni è un concetto importante. Tuttavia deve essere valutato in relazione alla definizione del modello autorizzativo (estremizzando, creare un ruolo per utente, pur rispettando il principio, non è quasi mai una strada percorribile).
In generale:
Eliminare i privilegi amministrativi non necessari.
Separazione tra account amministrativi da quelli business.
Uso, dove possibile ed applicabile del "Just-in-Time" (JIT), elevazione dei privilegi solo quando necessario e per un tempo limitato.
Revisione periodica dei permessi assegnati
Sono politiche utili al contesto. Oltre a valutare (nel caso con strumenti a pagamento) ulteriori contesti di applicabilità di logiche non solo RBAC (Role Based Access Control) ma anche ABAC (Attribute Based Access Control).
Il modello Zero Trust richiede protezioni attive, non controlli passivi.
LA verifica continua, ovvero dove ogni accesso o attività viene riesaminata in base a policy, identity, device e rischio corrente, senza alcuna fiducia implicita tra applicazioni interne diventa fondamentale nel modello.
L'utilizzo quindi di sistemi per gestire questi eventi (SIEM-SOAR) diventa fondamentale, nel contesto specifico SAP. Sono moltissimi gli strumenti, molti meno quelli che riescono a tradurre eventi critici di SAP in azioni (alert) concrete.
Le aziende che hanno implementato Zero Trust per SAP in scenari reali usano politiche dinamiche basate sulla classificazione dei dati per impedire esportazioni non autorizzate o accessi fuori contesto. Questo chiaramente non applicabile in tutti i contesti, ma l'identificazione dei dati di questo tipo è fondamentale per valutare e capire cosa e come applicare.
L'adozione di queste pratiche spesso non è solo un problema tecnico, ma più culturale. Infatti alcuni di questi aspetti devono essere visti e percepiti come un valore aziendale, anziché un freno. L'adozione di queste pratiche o strumenti, che possono apparire come costi puri in un contesto di analisi del rischio possono acquisire il valore strategico aziendale. Percepito dai più (in maniera negativa) quando possono capitare eventi bruschi come blocchi delle attività produttive, impossibilità di utilizzare le risorse aziendali o fughe di dati.