La qualità degli sviluppi in SAP determinano la sicurezza applicativa.

Se non costruisci e sviluppi nel modo corretto puoi avere in futuro una serie di problematiche da gestire. Meglio individuare ed indirizzare la gestione degli sviluppi prima rispetto a farlo quando si è già in produzione.

Quali sono le regole base per la gestione degli sviluppi in SAP? Ne abbiamo selezionati 10 casi.

1 Valuta l'inserimento dei controlli autorizzativi

Ogni programma creato in SAP dovrebbe al suo interno avere dei controlli autorizzativi. Tramite lo statement AUTHORITY-CHECK.

Per ogni modulo SAP esistono oggetti principali se non sai da dove partire utilizza questa traccia:

•FI - Finance (Amministrazione Finanza)

•F_BKPF_BUK

•ACTVT (Attività)

•BUKRS (Società)

•SD - Sales (Vendite)

•V_VBAK_VKO

•ACTVT (Attività)

•VKORG (Organizzazione commerciale)

•VTWEG (Canale di distribuzione)

•SPART (Settore merceologico)

•MM (Gestione anagrafica materiali

•M_MATE_WRK

•ACTVT (Attività)

•WERKS (Divisione)

•Tesoreria

•F_FEBB_BUK

•ACTVT (Attività)

•BUKRS (Società)

•PM (Plant Management)

•I_AUART

•ACTVT (Attività)

•IWERK (Divisione di manutenzione)

2 Dichiara sempre tutti i campi nel codice

Dichiarare tutti i campi dell’oggetto autorizzativo, se non servono necessariamente nella logica del programma utilizza il valore DUMMY

Questa funzionalità permette di dichiarare meglio a livello di codice come è stato pensato il controllo autorizzativo.

3 Non controllare valori specifici

Quando utilizzi lo statement AUTHORITY-CHECK non definire nel codice il controllo di costanti o asterischi es.

AUTHORITY-CHECK 'F_BKPF_BUK'

ID 'ACTVT' FIELD *.

Utilizzare il codice sopra significa che nelle autorizzazioni dell'utente deve essere inserito esplicitamente il valore * (asterisco). Indipendentemente dall'operazione che sta svolgendo l'utente es. creazione, modifica o visualizza.

4 Mancato controllo dell'input utente

Ogni campo inserito dall'utente ed utilizzato a seguito nel programma dovrebbe essere validato e verificato, per lunghezza, tipologia o tramite white-list se possibile

5 Ruoli o Utenti hard-coded

Durante la scrittura di programmi da evitare l'inserimento di nomi-ruoli o nomi utenti nei programmi.

Es. se hai il ruolo ZXY allora puoi svolgere o meno una determinata attività.

Questo aspetto è comunque valido anche in altri casi. Ad esempio codici di società, divisioni o altre informazioni.

6 Utilizza function se presenti

SAP ha definito in molti caso delle function (visibili tramite transazione SE37) specifiche per il controllo autorizzativo. Ad esempio per il controllo delle transazioni richiamate o per l'accesso alle tabelle SAP:

• AUTHORITY_CHECK_DATASET
• AUTHORITY_CHECK_TCODE
• VIEW_AUTHORITY_CHECK

Evita quindi di utilizzare, in questi casi, un controllo specifico su un determinato oggetto quanto esiste una specifica function. In questi casi potrebbero esiste logiche diverse, come ad esempio nel caso dei controlli sugli oggetti legati alla protezione delle tabelle, come ad esempio S_TABU_DIS ed S_TABU_NAM.

Utilizzando la function VIEW_AUTHORITY_CHECK questi oggetti vengono controllati nell'ordine corretto. Inoltre in caso di modifiche da parte di SAP anche i programmi custom che utilizzano questa function riceveranno le novità.

7 Popola la transazione SU24

La transazione SU24 serve per collegare gli oggetti autorizzativi alle transazioni e fare in modo che siano correttamente gestiti durante l'inserimento delle transazioni nei ruoli.

8 Non usare tabelle custom

In alcune situazioni non è possibile evitare di fare del custom. Ma se proprio devi, è importante evitare di introdurre delle tabelle custom di controllo.

Ad esempio: se la tua utenza esiste in una certa tabella allora puoi fare qualcosa

Questa modalità, anche se apparentemente più sicura, comporta delle difficoltà di gestione, ad esempio:

• Non possono essere utilizzati i sistemi standard di troubleshooting
• Spesso non sono documentati
• In alcuni casi le autorizzazioni per la gestione delle tabelle SAP non sono presidiate, quindi un utente potrebbe modificare direttamente il contenuto della tabella attribuendo a sé stesso o altri "autorizzazioni"
• Spesso queste tabelle non hanno log delle modifiche attivi
• Pur cancellando utenze queste possono rimanere nelle tabelle custom definite

9 Non invertire la logica SAP

Il concetto autorizzativo SAP è "additivo". Significa che non è possibile negare (fatta eccezione per l'oggetto autorizzativo P_PERNR).

Negli sviluppi custom mantieni la logica standard. Evita di invertire questa logica. Es. se hai un certo oggetto autorizzativo allora non puoi fare una certa attività

10 Effettua una analisi del codice che sviluppi

Esistono diversi strumenti che SAP mette a disposizione per controllare lo sviluppo che stai facendo.

Il source code inspector o ABAP Test Cockpit, ma anche programmi a pagamento come il SAP CVA Code Vulnerability Analysis. O ancora programmi terzi presenti sul mercato.

Controllare in maniera approfondita tutti gli sviluppi che la tua azienda fa ogni giorno non è umanamente possibile. Per i volumi, per la quantità di controlli da effettuare.