RFC significa Remote Function Call (RFC) ed è l'interfaccia standard SAP per permettere ai sistemi di comunicare tra loro.
La mancata configurazione di questo aspetto può esporre il sistema a diverse problematiche di sicurezza. Ci sono molteplici aspetti di cui tenere conto. In questo articolo parleremo di come proteggere il sistema dalle chiamate RFC fatte da sistemi terzi o altri sistemi SAP.
Ecco oggi parleremo proprio di questo ultimo aspetto, infatti esistono delle function che SAP espone in cui non serve avere delle credenziali nel sistema per ottenere le informazioni. Ma possono essere utili per finalità di OSINT (Open-source intelligence).
Di default tutte le function RFC (remote enabled) sono richiamabili dall'esterno. Chiaramente per alcune di queste serve poi avere una specifica utenza per poterle eseguire (con relative autorizzazioni). Ma in generale possono essere richiamate. Nella immagine sotto è possibile vedere, ad esempio, che il function module RFCPING è richiamabile dall'esterno. Vedi check box "Remote-Enable Module" attivo.
Per poter evitare questo comportamento, quindi fare in modo che di default sia tutto "chiuso" e rimanga aperto solo quello esplicitamente permesso è necessario attivare un componente chiamato UCON Unified Connectivity.
In questo video puoi vedere il comportamento malevolo di richiamo function module dall'esterno
Tramite l'utilizzo dell'UCON puoi verificare e scoprire se sono attive casistiche analoghe anche nel tuo sistema. Particolarmente utile anche per SAP FIORI.
SAP Unified Connectivity (UCON) è un framework, già presente in SAP (ABAP) fin dalla versione 7.40, il cui scopo è proteggere i sistemi SAP dagli accessi RFC riducendo al numero strettamente necessario i moduli eseguibili in tale modalità, avvalendosi dell’uso di una “whitelist” (Communication Assembly - CA).
Vale a dire che solo i Function Modules, che risultino utilizzati nel sistema dopo un adeguato periodo di osservazione, saranno inseriti nella CA e quindi accessibili risultando invece bloccati tutti gli altri (in SAP sono presenti diverse decine di migliaia di tali oggetti a fronte di un reale utilizzo per tipologia di sistema di qualche centinaio raramente migliaia).
Una delle paure più sentite è quella, inoltre, di mettere mano a queste configurazioni. Cosa succede se spegniamo o disattiviamo dei servizi? Che ripercussioni potranno esserci? Ecco vediamo quale potrebbe essere un percorso tipico di adozione di questo strumento.
Il percorso che viene tipicamente seguito si compone di due fasi di analisi del sistema ed una fase finale. Le prime due sono:
della durata di qualche mese e comunque la somma della durata delle due fasi dovrebbe coprire un periodo temporale significativo per l’utilizzo tipico del sistema (chiusure semestrali, annuali, etc.).
Solo al termine delle due fasi di analisi si passa alla fase Finale, in cui la protezione viene attivata dopo aver adeguatamente valorizzato il contenuto della CA (Communication Assembly).
Il risultato delle fasi di Logging ed Evaluation consiste in una lista che totalizza le chiamate per singolo Function Module, ripartite secondo diversi criteri come, ad esempio:
L’intero processo viene gestito tramite una singola transazione (UCONCOCKPIT) di cui riportiamo a titolo esemplificativo il pannello principale:
Il percorso descritto può essere immaginato come un cammino, dall’alto verso il basso rispetto a quanto rappresentato sopra, in base al completamento delle diverse fasi.
Tipicamente le 2 fasi di analisi vengono eseguite in ambiente produttivo, mentre le configurazioni della CA vengono svolte in ambiente di sviluppo e trasportate tramite il meccanismo dei trasporti standard SAP.
Chiedici qui come possiamo aiutarti ad attivare questa funzione nel modo corretto!