Cosa significa? Che cosa sono le autorizzazioni basate su degli attributi (paradigma ABAC)?

Qual è la differenza tra RBAC ed ABAC? Cosa significano queste sigle? Pro e contro?

Lo scopriamo in questo articolo.

RBAC ed ABAC cosa significa?

RBAC è un acronimo introdotto dal NIST (National Institute of Standards and Technology) che significa Role Based Access Control. Questo paradigma è stato introdotto nel 1992. Leggi qui il documento RBAC.

Si tratta di un meccanismo di controllo degli accessi basato sull'utilizzo dei ruoli per fornire l'accesso di risorse agli utenti ai quali sono assegnati.

ABAC è anch'esso un acronimo, introdotto dal NIST che significa Attribute Based Access Control. Definito nel documento NIST Special Publication 800-162.

Si tratta di un meccanismo di controllo degli accessi basato su attributi che possiede l'utente (anziché sui ruoli assegnati).

Ma in SAP come sono usati questi modelli?

Il modello autorizzativo SAP è basato sui ruoli, quindi Role Based Access Control.

Esistono tuttavia software di terze parti (vedi SAP DAM Dynamic Authorization Management di NextLabs) che permette controllare l'accesso ai dati in base ad attributi definiti sull'utente.

Facciamo un esempio.

Nel modello tradizionale SAP, se una società ha diverse centinaia di plant (divisioni) e deve effettuare una segregazione dei dati (ad esempio per la gestione delle anagrafiche materiali), questa richiesta deve essere gestita tramite l'utilizzo di ruoli derivati.

Andando a creare quindi tanti ruoli derivati quante sono le necessità di segregazione.

Ipotizzando un ruolo per ogni plant disponibile otteniamo 100 ruoli derivati (dal medesimo ruolo padre).

Utilizzando il modello ABAC, questa esplosione di ruoli potrebbe venire meno.

Come?

Andando a gestire appunto degli attributi sull'utente. Ipotizzando quindi di avere un attributo che definisca il plant dell'utente, questo potrebbe essere utilizzato come driver nell'autorizzare i dati o meno dell'anagrafica materiali di quel plant.

Tecnicamente vengono definite delle policy (in un sistema ad hoc) che permettono di dichiarare cosa un utente dovrebbe fare o vedere (a seconda dell'attività).

Se l'utente sta accedendo ad un dato (es. materiale) sul plant 1000, viene intercettata la policy che, in runtime, verifica se l'azione è permessa all'utente.

Davvero posso evitare di creare ruoli?

Sarebbe una rivoluzione, ma non sempre è così, quali sono i punti di attenzione?

• Affinché funzioni il tutto è necessario definire le policy (che hanno un costo di definizione e gestione).
• Se ne crei tante il rischio è di spostare la complessità da un sistema ad un altro.
• Non devi cablare costanti nelle policy devono essere il più possibile "parametriche"
• Meglio partire con poche policy e molto mirate
• Per ogni transazione coinvolta deve essere inserita una parte di codice ABAP/FIORI/Webdynpro a seconda della tecnologia per intercettare gli eventi (trigger)
• Il documentare se un utente ha o meno la possibilità di vedere o modificare qualcosa in SAP non passerebbe solo dalla SUIM ad esempio ma dovrebbe essere correlato con il motore di policy
• Il punto precedente è correlato in qualche modo anche con il sistema SAP GRC Access Control. In questo caso potrebbero essere generati falsi positivi (da gestire tramite controlli mitigativi ad hoc eventualmente)

Posso proteggere l'esportazione dei dati?

Tramite la soluzione SAP DAM, utilizzando degli attributi, è possibile proteggere l'esportazione dei dati da SAP.

Quanto sopra permette inoltre di introdurre delle logiche di Digital Rights Management (DRM). Ovvero i file esportati da SAP vengono "marchiati" o protetti per garantire il controllo e l'accesso dei dati da parte di terzi. O per conformità al GDPR.

La funzionalità è simile a quella di Microsoft chiamata Azure Information Protection.

Posso fare azioni di enforcement?

Si tramite l'utilizzo della soluzione è possibile bloccare in real-time degli accessi considerati critici, se si verificano determinate condizioni. Andando a tracciare questi eventi.

Posso usarlo anche per applicazioni diverse da SAP?

Sì, funziona anche per applicazioni diverse da SAP. L'idea è quella di scrivere delle policy, centralizzate, basate su attributi che siano valide per tutte le applicazioni aziendali, non solo SAP quindi.