Governance Risk and Compliance con One Identity in ambito SAP, ma non solo.
La Governance, Risk Management & Compliance è un approccio strategico il cui fine ultimo è garantire che un’azienda operi eticamente, gestisca i potenziali rischi in modo proattivo ed efficace, e che rispetti gli obblighi di legge imposti.
Questa condotta non solo deve proteggere l’azienda dai rischi d’impresa, ma deve anche incrementare la sua reputazione e l’efficienza operativa.
In passato, queste 3 aree venivano spesso gestite in modo separato: l'approccio GRC invece le integra in un unico framework, definendone una visione olistica e trasversale.
Guarda qui quali sono gli elementi fondamentali per costruire un modello autorizzativo in SAP!
In generale per l'adozione di uno strumenti di identity management è importante verificare che il modello autorizzativo SAP implementato seguendo le logiche RBAC (Role Based Access Control).
Il primo passo obbligatorio è, in qualsiasi caso, l'import degli oggetti autorizzativi da SAP verso l’Identity Provider scelto.
Tale risultato in One Identity si ottiene tramite la definizione del progetto di synchronization (se ti sei perso questa parte la trovi qui)
Nella immagine seguente puoi vedere due progetti di synchronization:
Ma quali sono le azioni in ambito GRC che puoi fare con One Identity Manager?
Gestione della SoD (Segregation of Duties)
Policy
Attestazioni e campagne di attestazione
Framework di Compliance
Risk Index Analysis
Web Service di integrazione a SAP GRC Access Control
Il principio cardine della SoD è che ad un utente non dovrebbero mai essere concesse combinazioni di entitlement per lo svolgimento di attività che sono concettualmente in contrasto fra loro.
Il classico esempio è quello di un utente che non dovrebbe avere (in contemporanea) la possibilità di:
One Identity permette di definire le regole di incompatibilità ed intercettarle.
Le regole possono anche essere basate su tutti gli entitlement censiti sia assegnati direttamente che indirettamente (come ad esempio assegnazioni annidate di gruppi).
In caso di conflitto intercettato, vi è la possibilità di configurare il comportamento di risposta:
Più in dettaglio una matrice dei rischi in One Identity è formata da questi elementi:
Una function è composte da vari elementi e rappresenta sostanzialmente una specifica business activity (o un task) all’interno di SAP con la sua combinazione di autorizzazioni, campi e valori, vedi esempio seguente
Una volta definiti gli elementi di una Function, One Identity è in grado di calcolare in automatico i gruppi e gli account (ruoli e/o profili nel contesto SAP) aventi tali combinazioni di permissions prendendo la funzione come parametro di ricerca.
Le SAP function diventano quindi il "mattone" con cui costruire le violation SoD (Rischi) in quanto ne costituiscono un parametro di input.
Le violation possono essere composte esclusivamente da SAP Function (se si vogliono costruire regole solo interne al perimetro SAP) o combinate con tutti gli altri entitlement definiti nella piattaforma.
Nelle regole è possibile definire condizioni complesse che intercettano trasversalmente qualsiasi tipo di abilitazione censita nei vari target system. Ad esempio per effettuare delle risk analysis cross system ad esempio una regola SOD che incrocia abilitazioni SAP (quindi Function) ed abilitazioni in Active Directory.
Più in generale nell'immagine seguente è possibile vedere la rappresentazione del modello dati Function, Violation, risk analysis.
Nel caso in cui durante l'import dei dati venga creata una relazione tra le utenze SAP ed i dipendenti (Person), il motore SoD di One Identity consentirebbe di verificare i casi di utente con identità multiple implementate magari per gestire la segregazione dei suoi account "standard user" da quelli amministrativi.
Chiaramente è possibile definire poi eseguire una analisi dei rischi in modalità puntuale oppure in modalità massiva su tutto il sistema (background).
Così come è possibile definire delle regole di mitigazione o definire delle approvatori per eventuali eccezioni. Esistono inoltre alcuni report standard che permettono di visionare l'analisi dei rischi nel tempo e i dettagli dei rischi per ruoli o applicazione.
Ma quali ulteriori funzioni di One Identity possono essere utili per l'area GRC?
Quante volte in azienda vengono definite delle regole (Policy) che, tuttavia, non sono sempre verificate.
One Identity consente quindi di attivare delle company policy dedicate per la compliance.
La logica di gestione delle policy è concettualmente simile a quella delle regole SoD: una volta definite, è possibile inizializzare il calcolo degli elementi impattati, impostarne schedulazioni, assegnare controlli di mitigazione, definire approvatori di eccezioni e controlli da IT Shop per i responsabili.
Alcuni esempi?
La piattaforma presenta già di default un set di policy “pronte all’uso” che possono servire anche come template iniziale per accelerarne la definizione di nuove.
Con il termine "campagne di attestazione" (o recertification) si intendono attestazioni eseguite ad intervalli regolari a garanzia del costante e continuativo allineamento alle policy aziendali.
Tali procedure in One Identity sono implementate tramite la definizione di attestation e di attestation policy.
Gli approvatori (es. Manager) ricevono specifici workflow (attestation case) che aiuta i referenti coinvolti nel percorso decisionale di approvazione da IT Shop. Tutti gli eventi di attestation e di approvazione sono poi registrati in modo da poter essere ricostruiti a fini di audit.
Le attestazioni in One Identity possono essere organizzate in categorie (types) per definizioni di gerarchie, e che ad una procedura di attestazione possono essere associate policy multiple.
Le policy, attestation e SoD possono essere aggregati fra loro in framework di compliance all’interno della piattaforma.
Questa possibilità offre un approccio ancora più organico e strutturato alla gestione di molteplici regole.
Quali i vantaggi?
Questa funzionalità serve per quantificare il rischio di sicurezza potenziale che ciascun oggetto (vedi elenco sotto) può rappresentare per l'azienda.
Identità
Account (AD, SAP, DB Oracle, etc)
Department
Locality
Centri di costo
Business e system role
Gerarchie nell’IT Shop
Violazioni di regole SoD
Gli amministratori della piattaforma possono assegnare ad ogni risorsa (entitlement) un valore di rischio da zero (nessun rischio) a uno (rischio massimo).
Il valore assegnato rappresenta il rischio potenziale della risorsa nel caso in cui un accesso non autorizzato riuscisse ad usarla.
Il calcolo si basa su funzioni predefinite nella piattaforma e l’indice di ritorno considera tutte le risorse assegnate direttamente o indirettamente all’utente (quindi anche assegnazioni di entitlement annidati).
Le funzioni predefinite determinano, tramite varie tipologie di algoritmi impostabili, il contributo di ciascuna risorsa al computo totale del rischio.
Qui sotto l’algoritmo di calcolo in caso di aggiunta di uno profilo per un account SAP.
Quali i vantaggi in questo caso?
Rintracciare, verificare e segregare gli utenti più a rischio e stabilire come priorità la messa in sicurezza dei loro account
Integrazione degli indici di rischio nei flussi di approvazione per l’abilitazione a risorse. Se la risorsa richiesta ha un indice di rischio elevato, il sistema può imporre processi di approvazione più rigorosi prima di concederla
Gli indici di rischio possono aiutare a dimostrare la conformità alle normative di sicurezza, fornendo una valutazione documentata dei privilegi di accesso degli utenti e dei rischi ad essi associati
Al momento le soluzioni SAP che permettono di svolgere l'analisi dei rischi sono le seguenti
One Identity offre la possibilità di interagire con tali servizi, recuperare dati e poi innescare workflow di processi in base alle esigenze stabilite. Esistono tre possibili scenari di integrazione:
One Identity permette tramite il Designer di testare i web service e gli output configurati in SAP GRC Access Control
generare in automatico il codice per la chiamata dei servizi.
Una volta testata l’integrazione, il codice per la chiamata può essere definito in uno script ed integrato con altri script in un workflow unico per la definizione dello scenario implementativo desiderato.
Vedi esempio seguente di processo per una richiesta verso SAP GRC Access Control.
Approfondisci le tecnologie Quest e competenze Itway su: