Configurazione e analisi dei parametri del kernel nel SAP Security Audit Log (SAL)

Per l’audit di un sistema SAP, il Security Audit Log (SAL) è una delle fonti più importanti. Con EHP 7 è cambiato il modo in cui viene configurato: accanto ai parametri di profilo esistono parametri del kernel, che valgono per l’intero sistema e hanno la precedenza. Chi non lo sa verifica nel posto sbagliato.

Perché il Security Audit Log conta per l’audit

Un sistema ERP è soggetto a requisiti di legge sulla correttezza dei dati e sulla tracciabilità delle modifiche. Da qui derivano, nella pratica, un panorama di sistemi composto almeno da sviluppo e produzione e la separazione delle funzioni tra IT e aree di business. Particolarmente critici sono gli accessi che annullano deliberatamente questa separazione, come gli interventi di utenti di emergenza.

È proprio qui che interviene il Security Audit Log: registra gli eventi rilevanti per la sicurezza, riferiti all’utente, in un’area protetta, indipendentemente dai documenti di modifica dell’applicazione. Nell’audit interno e nella revisione del bilancio è quindi una fonte centrale di evidenza. Perché l’evidenza regga, il log deve essere completo, permanente e configurato allo stesso modo su tutte le istanze.

Configurazione fino a EHP 6: parametri di profilo e SM19

Fino a EHP 6 il Security Audit Log si configura nella transazione SM19, in due varianti:

• Configurazione statica: le impostazioni sono memorizzate nella banca dati come parametri di profilo o di istanza e sono attive dopo ogni avvio del sistema. Per l’esercizio continuativo serve una configurazione statica attiva. I filtri stabiliscono quali utenti o gruppi di utenti vengono registrati; quanti filtri siano possibili dipende dalla release.
• Configurazione dinamica: il log può essere attivato e adattato durante l’esercizio, senza riavvio. Solo il numero dei filtri paralleli è fisso.

Si impostano, tra l’altro, i mandanti da registrare, le classi di audit (per esempio logon di dialogo o logon RFC), la categoria di eventi (tutti, critici, gravi) nonché dimensione e percorso di archiviazione dei file di audit. I parametri di profilo più importanti sono rsau/enable (log attivo o disattivo), rsau/selection_slots (numero dei filtri), rsau/user_selection (filtro utenti) e rsau/max_diskspace/local (spazio su disco).

In sede di audit si verifica di solito nella transazione RZ10 se questi parametri rispettano i requisiti normativi, le direttive aziendali o le raccomandazioni correnti. A integrazione, la tabella PAHI mostra se dei parametri sono stati modificati a breve termine, per esempio subito prima dell’audit.

Da EHP 7: parametri del kernel in SM19

Con EHP 7, in SM19 si è aggiunta la scheda «Parametri del kernel». Attraverso di essa il Security Audit Log viene attivato e impostato a livello di sistema, in modo simile a come le politiche di sicurezza per le password (SECPOL) valgono per l’intero sistema. Tre cose sono decisive:

1. I parametri del kernel prevalgono sui parametri di profilo. Non appena sono impostati, i noti parametri di profilo rsau/* non hanno più effetto. Chi vuole continuare a lavorare con i parametri di profilo deve disattivare i parametri del kernel.
2. La manutenzione non avviene più in RZ10, ma direttamente nel Security Audit Log. In RZ10 può quindi comparire un valore che non è in vigore.
3. I valori sono memorizzati nella tabella RSAUPROF. A questo scopo il sistema crea profili con il nome $KERNEL$; ogni slot rappresenta un parametro. Lo slot 0006, per esempio, decide se vengono scritti più file di audit al giorno.

All’attivazione compare una richiesta di conferma. Se si risponde negativamente, i server applicativi non risultano configurati in modo uniforme.

Che cosa significa per l’audit

Un audit che legge solo i parametri di profilo può, da EHP 7, trarre in inganno: un log apparentemente disattivato tramite rsau/enable = 0 può benissimo essere attivo per effetto dei parametri del kernel e, viceversa, un parametro di profilo impostato non dice nulla su ciò che viene effettivamente registrato. Anche la cronologia delle modifiche si trova altrove: le modifiche ai parametri del kernel non compaiono in PAHI, ma vengono scritte tramite la registrazione delle tabelle (rec/client) per RSAUPROF.

Per l’audit questo significa:

• Leggere entrambi i punti: i parametri di profilo in RZ10 e la scheda «Parametri del kernel» in SM19.
• Stabilire che cosa è in vigore: se i parametri del kernel sono attivi, contano loro, non i parametri di profilo.
• Analizzare la cronologia: con il report RSTBHIST (per esempio tramite SA38) per la tabella RSAUPROF, cercando i profili $KERNEL$. PAHI da sola non basta.
• Verificare la coerenza: con i parametri del kernel l’impostazione vale per l’intero sistema; con i parametri di profilo resta necessario il confronto tra tutte le istanze.

Valutazione

Dal punto di vista della compliance, la novità è un progresso. Dopo il riavvio, i parametri del kernel valgono per l’intero sistema; viene meno il rischio che la distribuzione ai singoli server applicativi fallisca e che lì il log manchi. L’auditor non deve più verificare la coerenza di ogni istanza singolarmente.

Due cose restano insoddisfacenti. A seconda della release ci sono due punti da verificare, i parametri di profilo e SM19. E la tabella RSAUPROF era pensata per i filtri; con i profili $KERNEL$ viene usata per uno scopo diverso, e la struttura disomogenea rende l’analisi più laboriosa di quanto dovrebbe essere.

Nota: nelle release più recenti (da SAP NetWeaver 7.50 con Support Package 03, quindi anche in S/4HANA) le transazioni RSAU_CONFIG, RSAU_READ_LOG e RSAU_ADMIN sostituiscono le precedenti SM19, SM20 e SM18. La distinzione tra parametri di profilo e del kernel e la memorizzazione in RSAUPROF restano.

Una versione più dettagliata di questo articolo, in tedesco e con immagini, è stata pubblicata sul blog di esperti rz10.de: Kernel-Parameter für das SAP Security Audit Log (SAL): Vorsicht vor Inkonsistenzen.