Cosa è il ruolo di base?

Il ruolo di base è un contenitore al cui interno sono inserite alcune delle autorizzazioni che tutti gli utenti dovrebbero avere.

Si tratta di un insieme di utility, non critiche ed utili in alcuni momenti. Come conviene progettarlo e cosa dovrebbe contenere?

Cosa deve contenere?

Il ruolo di base dovrebbe contenere esclusivamente autorizzazioni non critiche e nessuna attività di business.

Ecco quali sono le attività che dovrebbero avere tutti gli utenti SAP:

• Transazione SU53, visualizza errori autorizzativi
• Transazione SP02, visualizza le proprie stampe
• Non la SP01, leggi qui per ulteriori dettagli
• Transazione SMX, visualizza I propri job
• Non la SM37, in quanto permetterebbe agli utenti di vedere altri job, oltre ai propri, di gestire ed amministrare job in caso di autorizzazioni batch non controllate
• SU50
• Non la SU3. Tramite questa ultima transazione infatti è possibile modificare i paramenti utente. Anche se nella maggior parte dei casi i parametri utente servono per pre-popolare dei campi all’interno delle transazioni (immagina il caso dove un sistema SAP ERP contenga una sola società definita. In ogni transazione che contiene quel campo, dovrò sempre valorizzarlo manualmente. Esiste quindi un modo per valorizzare il campo un con default? Sì, tramite i parametri utente. I parametri utente sono utilizzati anche per aspetti autorizzativi o di configurazione. In altre parole potrei avere la possibilità di cambiare il comportamento si alcune transazioni.

Il ruolo di base non dovrebbe contenere la possibilità di pianificare job periodici (se previsto dalla release) così come non dovrebbe contenere oggetti critici esempio:

• S_BTCH_ADM - Funzioni amministrative di pianificazione dei job
• S_BTCH_NAM - Possibilità di pianificare job a nome di altri utenti (diverso dal proprio)
• S_DEVELOP - Possibilità di sviluppare o visualizzare codice sorgente

È fondamentale inoltre per garantire la sicurezza applicativa SAP, evitare di rilasciare autorizzazioni che permetterebbero ad un utente di accedere a dati sensibili o di business.

Questo ruolo infatti potrebbe essere assegnato anche ad utenti esterni che devono accedere comunque al sistema SAP.

Ma in quali casi la modifica dei parametri utente può essere critica?

Tramite la transazione OMET (Settings for Function Authorizations) è possibile configurare alcuni comportamenti del processo acquisti. Ad esempio che durante la creazione di OdA sia necessariamente da inserire il riferimento all'RdA.

Questa configurazione viene attivata se l'utente ha il parametro "EFB Function Authorization: Purchase Order" valorizzato come da configurazione della transazione OMET.

Un utente in questo caso potrebbe rimuoversi il valore/parametro e bypassare il controllo.

• Oppure anche nel caso delle varianti nel processo sales. Tramite il parametro utente "SD_VARIANT_MAINTAIN Authorization for variant maintenance" è possibile, inserendo il valore A, diventare amministratori delle varianti nelle transazioni delle vendite SAP es. VA*.
  
• Oppure nei sistemi HR per la rilevazione delle ore è possibile stabilire un profilo di acquisizione dei dati (es. dipendenti o esterni). Questa impostazione del formato di timesheet è configurabile dal parametro utente CVR. La possibilità di modificarlo comporterebbe l'inserimento di ore su un timesheet non corretto.
• Nei sistemi CRM esiste un parametro utente che permette di assegnare tutti i CRM business role definiti CRM_UI_PROFILE
• In alcuni sistemi sono utilizzati dei parametri utenti custom per influenzare il comportamento di transazioni o di autorizzazioni

Attenzione le modifiche alla tabella dei parametri utente: USR05 non sono tracciate di default.

Come costruirlo?

Meglio creare un ruolo ed assegnarlo a tutti oppure inserire nei ruoli di business le attività citate sopra?

L’ideale sarebbe creare un ruolo ad hoc da assegnare a tutte le utenze. Ripetere le medesime autorizzazioni nei vari ruoli collettivi comporta:

• Un appesantimento della documentazione dei ruoli
• Una duplicazione delle informazioni per coloro che devono approvare il contenuto dei ruoli (vedi articolo owner)
• Il doversi ricordare ogni volta che un nuovo ruolo (figura professionale) viene definito, l’inserimento del task base

Come viene gestito negli strumenti di Identity o SAP GRC?

È possibile assegnare automaticamente un ruolo base alla creazione di ogni nuova richiesta. Questo ruolo può essere auto-approvato, senza iterazione alcuna quindi.

Devi impostare o rivedere il tuo modello autorizzativo SAP, approfondisci qui!

Se utilizzo la struttura organizzativa?

È possibile assegnare i ruoli in maniera diretta o indiretta. I ruoli assegnati in maniera diretta sono quelli attribuiti tramite la transazione SU01 oppure PFCG. Mente i ruoli attribuiti in maniera indiretta sono:

• Tutti i ruoli singoli contenuti in collettivi
• Tutti i ruoli assegnati a posizioni organizzative (alle quali sono assegnati anche utenti)

I questo ultimo caso, meglio creare una posizione con tutti gli utenti assegnati al ruolo di base oppure assegnare ad ogni posizione organizzativa il ruolo base in aggiunta agli altri?

Per evitare problemi di performance e semplificare la gestione, anche se le attribuzioni sono indirette (tramite struttura organizzativa) conviene assegnare il ruolo base direttamente agli utenti SAP.