Perché diventa strategico avere un documento che descrive come è stata pensata la security SAP in azienda?

Quando serve? A cosa serve? Perché farlo? Come farlo e mantenerlo?

Cosa è il SAP Security guide line document?

Si tratta di un documento che descrive quali sono le scelte fatte dalla società sugli aspetti di security SAP. Può essere fatto nel momento progettuale oppure anche a seguito.

Solitamente è diviso in varie sezioni che documentano tutti gli aspetti di security, ad esempio:

• Gestione utenze in SAP
• Gestione della profilazione SAP (Ruoli autorizzativi, profili, autorizzazioni, oggetti autorizzativi ritenuti critici), gestione delle modifiche (change management)
• Gestione dei workflow approvativi
• Naming convention dei vari oggetti (Utenti SAP, Ruoli SAP, oggetti custom)
• Sicurezza degli sviluppi ABAP
• Sicurezza delle comunicazioni (es. Crittografia, Single Sing On etc)
• Gestione dei profili di istanza SAP relativi alla security SAP
• Politiche di aggiornamento dei sistemi e patching SAP

Non necessariamente deve essere un documento a se stante chiamato SAP Security guide line o nomi analoghi. Ma può essere inserito in un documento di security generale aziendale. Oppure essere richiamato da quest'ultimo.

Spesso le specificità di SAP sono molte e conviene fare un documento ad hoc che ne descriva tutti gli aspetti in dettaglio.

È sempre possibile realizzarlo?

Per alcuni aspetti sì, per altri potrebbe non esserlo. Cosa intendo dire?

Alcuni aspetti di configurazione security SAP possono essere attivati e gestiti in qualsiasi momento. Mentre, ad esempio, la naming convention delle utenze oppure dei ruoli autorizzativi potrebbe non essere così "documentabile".

Se nel mio sistema di fatto non esiste una unica regola di naming convention di ruoli o utenti (ma potrebbe essere applicata ad oggetti autorizzativi custom o transazioni), potrebbe essere molto difficile o addirittura inutile andare a documentare quanto presente a sistema.

Perché è importante avere questo documento?

Avere un documento che descriva il modello autorizzativo definito e le regole, diventa un punto di riferimento per questa area (nella lettura chiamato anche SAP Security Baseline).

Può essere utile anche per gli aspetti legati al GDPR in termini di accountability del sistema.

Pensa alle seguenti situazioni:

• Affidi all'esterno la realizzazione di un progetto, che comprende anche la gestione delle autorizzazioni, cosa deve fare e soprattutto non fare il fornitore?
• Non è pensabile fare un passaggio di consegne verbale, è molto probabile che si perdano dei concetti o che non siano completamente recepiti. Non che questo sia mitigato completamente da un documento, ma credo possa essere meglio.
• La gestione di questi aspetti può essere seguita da diverse persone in azienda. Avere un documento aiuta ad essere tutti allineati sapendo che esiste un punto unico di riferimento in azienda (limitando di basarsi sulla memoria storica delle persone)
• Quanto sopra può essere anche applicato a nuovi colleghi che entrano nel team. Attenzione. Non deve essere un manuale, ma piuttosto un insieme di regole e suggerimenti di come ci si dovrebbe comportare su determinate tematiche.
• Ogni volta che un nuovo sistema viene rilasciato deve essere verificato che rispetti le regole definite a livello aziendale, per quanto riguarda la security SAP

Affinché sia sempre utilizzabile è importante mantenere il documento aggiornato. Normalmente non sono necessarie parecchie attività di manutenzione dopo la definizione dello stesso.