Una cattiva abitudine. Quali sono le principali cause:
- Esigenze di progetto non meglio specificate
- Poca sensibilità sulle tematiche di sicurezza dei dati
- Poca conoscenza delle potenziali criticità di questa azione
Ma per quale motivo bisogna rimuovere al più presto queste autorizzazioni anche dalle utenze non interattive? Vediamo un esempio!
Davvero può essere critico?
Sì, ecco un esempio.
Due sistemi coinvolti DEV e PRD. Un utente esterno ad esempio sviluppatore (MALLORY, leggi qui chi è) ha accesso al sistema di DEV, sviluppo. Si tratta di uno sviluppatore, quindi i privilegi sono elevati in quel sistema.
In quel sistema è stato configurato il meccanismo dei trasporti SAP (TSM - Transport Management System). Una delle destinazioni nella transazione SM59 (Destinazioni RFC) presenti è quella verso il sistema di produzione (nell'esempio TMSADM@PH8.DOMAIN_AH8).
Questa destinazione contiene l'utenza di tipologia SISTEMA TMSADM.
Aspetta… Una destinazione da DEV verso PRD con cablato un utente? Sì, viene generata durante la configurazione del sistema dei trasporti SAP.
Vero, ma la destinazione è verso il mandante 000 di produzione non quello produttivo.
Vediamo come può essere comunque critica questa situazione.
- L'utente MALLORY, formalmente autorizzato ad accedere nell'ambiente di sviluppo ha l'accesso alla transazione SM59.
- Questo gli permette di vedere le destinazioni RFC presenti definite in quel sistema e con accesso ad eventuali altri sistemi. Purtroppo in quel sistema esistente una destinazione RFC che permette di arrivare al sistema di PRD, è proprio la TMSADM@PH8.DOMAIN_AH8
- MALLORY decide di scrive un programma (function module) che, richiamando quella destinazione RFC, permette di eseguire in quel sistema un reset della password dell'utenza DDIC (o altre che potrebbero esiste in quel sistema)
- A questo punto MALLORY può entrare con DDIC nel mandante 000
- Il mandante 000 non è quello produttivo. Sfortunatamente in quel sistema DDIC ha SAP_ALL assegnato. Questo rende molto semplice il trafugare le informazioni anche dal mandante produttivo
Ma come ha fatto MALLORY?
La prima debolezza è l'utenza TMSADM nel mandante 000 con permessi privilegiati. Questa utenza di sistema possiede SAP_ALL.
MALLORY scrive quindi un piccolo function module (utilizzando una naming ambigua in questo caso - ZPOCREATE_RFC) il quale richiama a sua volta delle function di modifica degli utenti verso il sistema di produzione pur essendo in quello di sviluppo.
Questo permette a MALLORY di cambiare la password dell'utenza DDIC (potrebbe chiaramente svolge anche altre tipologie di azioni). Anche questa con SAP_ALL in produzione ma sempre nel mandante 000.
Attenzione, qui la modifica risulta a nome di TMSADM.
Una volta modifica la password, MALLORY è pronto per accedere:
All'interno del sistema produttivo (ma nel mandante di default 000) è comunque possibile accedere ai dati, anche degli altri mandanti.
Tramite la transazione SE16N è possibile visualizzare i dati di una tabella in modo cross client:
Vedi anche note OSS:
- 584434 - CO-OM tools: Special function SE16N
- 561756 - CO-OM tools: Adaptation SE16N to SE16
Sfruttando la possibilità di entrare in DEBUG MALLORY riesce ad avere accesso ai dati nel mandante produttivo.
Come mi proteggo da MALLORY?
- Non assegnare mail SAP_ALL, a nessuna utenza
- Attiva il security audit log su tutti i mandanti del sistema di produzione
- Non definire destinazioni RFC con utenti validi ed attivi se possibile
- Effettua degli audit SAP per validare le azioni in DEBUG effettuate a sistema, queste sono tracciate nel SAP Audit Log
- Effettua una trace autorizzativa per capire di cosa ha bisogno ogni utenza di sistema
