Il componente Query SAP fornisce un modo semplice di generare report senza necessità di scrivere codice (o di limitarne al minimo indispensabile). Da questo punto di vista, è molto simile al Quickviewer (SQVI), ma molto più potente e di conseguenza un po’ più difficile da padroneggiare. Una descrizione completa di questo strumento va oltre lo scopo di questo articolo. Invece, la mia intenzione è quella di concentrarmi quasi esclusivamente sulle caratteristiche di sicurezza per le query SAP e dimostrare come è possibile usare i concetti di base di sicurezza per separare una catena di processo in precisi ruoli e responsabilità. Questo è il lavoro di base di un “analista della sicurezza” durante la fase della progettazione della sicurezza.

 

Le Query sono reports che possono essere configurati per lo più usando funzionalità di  drag and drop anche se è presente un editor grafico per recuperare i dati dalle tabelle del data dictionary. Le Query SAP sono costituite da tre componenti principali: SQ01, SQ02 e SQ03. SQ01 è la transazione per la manutenzione delle query. Questa consente di creare, modificare, cancellare, visualizzare o più semplicemente eseguire le query precedentemente create.

Le query non sono direttamente definite nelle tabelle, ma usano un oggetto intermedio chiamato Infoset. Un infoset può essere definito come una join di tabelle o come un database logico contenente l’insieme di dati a cui la query può potenzialmente accedere. SQ02 è la transazione per la visualizzazione e la manutenzione degli infoset.
L’ultimo anello della catena è la transazione per la manutenzione dei gruppi di utenti. A differenza di altri componenti SAP, la sicurezza per le query non viene del tutto controllata attraverso i ruoli e le autorizzazioni. Per accedere ad una query, l’utente e l’infoset devono essere assegnati allo stesso gruppo utente. Il gruppo utenti per le query non è in alcun modo collegato ai gruppi utenti appartenenti all’user master record (autorizazioni assegnate agli utenti).

 

Dopo questa breve introduzione sulle query di SAP, proverò a spiegare come mettere in sicurezza il sistema e consentire l’utilizzo di questa applicazione  in tranquillità ed evitare che siano accessibili dati sensibili ad utenti non autorizzati.

La protezione per le query SAP è controllata attraverso l’oggetto autorizzativo“S_QUERY”. All’oggetto è assegnato il campo “ACTVT” con solo tre valori possibili:

2 (change)

23 (maintain)

67 (translate)

Di queste, l’attività “2“ è indispensabile per modificare le query, gli infoset e i gruppi utenti. L’attività “23” è necessaria per mantenere le assegnazioni ai gruppi utente. Quindi, l’accesso alle transazioni SQ02 o SQ03 non è possibile senza avere i permessi per l’attività “23”. Infine, un utente avente il campo autorizzativo “23” può accedere alle query appartenenti a gruppi di utenti, senza dover utilizzare SQ03.

È possibile notare che a differenza di molti altri oggetti di autorizzazione, S_QUERY non ha attività 03 (display) e non è necessario assegnare autorizzazioni all’oggetto S_QUERY per la visualizzazione o l’esecuzione di una query (per poter eseguire delle query, è sufficiente avere l’oggetto autorizzativo S_QUERY senza nessun campo “ACTVT”).

Oltre all’oggetto di autorizzazione S_QUERY, potrebbe essere richiesto un autorizzazione per l’accesso ad oggetti come S_TABU_DIS per controllare l’accesso ai dati recuperati dalle tabelle, l’accesso per modificare layout (S_ALV_LAYO) o per l’esportazione dei dati verso Excel (S_GUI) etc…

In una tipica organizzazione si potrebbe avere l’esigenza di separare l’accesso alle query in tre ruoli:

Query Executor

Questi sono gli utenti di reporting che saranno responsabili per le query effettivamente in esecuzione e l’interpretazione dei risultati. Questi sono normalmente gli utenti finali (end-user) e non vengono assegnati privilegi per l’aggiornamento/modifica delle query.
Query Creator

Questi sono gli utenti funzionali che hanno un ottima conoscenza dei flussi per progettare/creare query ed eventualmente modificarle in base alle varie esigenze. Questi dovrebbero quindi essere in grado di eseguire le query per verificare l’output di dati. Tuttavia, dato che l’esecutore delle query è ancora un utente aziendale, si potrebbe impedire le modifiche ai gruppi utenti.
Query Administrators

Questi utenti appartengono al personale di supporto, responsabili del mantenimento e della mappatura gruppo utenti. Questi utenti non necessitano dei permessi per il mantenimento della struttura delle query.

Con i requisiti di cui sopra, è possibile progettare tre ruoli per le tre classi di utente:

Query Executor – Ha bisogno dell’accesso alla transazione SQ01, ma non necessita di permessi per l’oggetto autorizzativo S_QUERY.  Potrebbe essere richiesto l’accesso all’oggetto S_TABU_DIS per il recupero dei dati.

Query Creator – Necessita dell’accesso alle transazioni SQ01, SQ02 e S_QUERY (entrambe le attività 02 e 23). Anche per questo, potrebbe essere necessario l’oggetto autorizzativo S_TABU_DIS. Non deve avere accesso alla transazione SQ03.

Query Administrator – Accesso alla transazione SQ03 e S_QUERY (entrambe le attività 02 e 23).