x

Di solito il soggetto di una regola è un gruppo. È possibile applicare una regola ad un solo utente, ma non si consiglia, poiché la gestione delle regole di un utente individuale può risultare difficile. È più facile modificare le regole che si applicano ad un utente, aggiungendo o rimuovendo l'utente da un gruppo, senza dover cambiare le regole stesse. Questo argomento suppone che la propria normativa di sicurezza si baserà sui gruppi, ma è sempre possibile sintonizzare una normativa, aggiungeno regole a utenti individuali, se si desidera.

Le maschere dominio definiscono quattro ruoli (Utente di Base, Utente Avanzato, Sviluppatore e Amministratore Gruppi), implementate come sottogruppi annidati al di sotto di un gruppo principale per il dominio. Le capacità degli utenti nel gruppo Utenti di Base sono determinati da regole assiociate con il ruolo Utente di Base, mentre le capacità di utenti nel gruppo Utenti Avanzati sono determinate sia da regole associate con il ruolo Utente di Base e da regole associate con il ruolo Utenti Avanzati. Le capacità Utenti Avanzati includono quelle di proprietà degli Utenti di Base e le capacità Sviluppatori includono quelle di proprietà degli Utenti Avanzati, come illustrato nella seguente immagine. Gli amministratori dei gruppi non hanno il consenso di eseguire prospetti o visualizzare emissioni di libreria, quindi le proprie capacità non si sovrappongono con quelle di altri sottogruppi.

L'annidamento di ruoli semplifica il design delle normative. Un utente necessita solo si appartenere a uno di questi gruppi per avere le capacità complete di quel tipo di utente. È inoltre possibile aggiungere un utente ai gruppi Ammnistratore Gruppi e ad uno degli altri gruppi, se è presente un requisito per un individuo di avere questo set misto di capacità. È possibile applicare regole ad un gruppo principale, per consentire a tutti i propri utenti di condividere contenuto tra di loro, o per concedere controllo agli amministratori dei gruppi sul gruppo principale ed i propri sottogruppi.

In alternativa, è possibile partizionare le capacità utenti in ruoli distinti senza sovrapposizione di privilegi. Anche se questo modello consente grande flessibilità, è più difficile gestire, in quanto le capacità di ciascun utente sono una composizione di molti ruoli e regole.

Inoltre, si potrebbe dover avere gruppi di infrastruttura per organizzare utenti che richiedono accesso a tutte le risorse nel sistema. Per esempio, un gruppo Amministratori, o un gruppo Modifica Controllo ha l'autorità di esportare risorse nel contenitore, ma non di eseguire o cancellare risorse.

Per ulteriori informazioni sui gruppi, consultare Gestione Utenti e Gruppi.

x

I ruoli si usano per unire un set di privilegi, che di solito si usano insieme. Una regola di sicurezza consente o nega il ruolo per un soggetto ad una risorsa, come illustrato nella seguente immagine.

Dopo aver determinato come organizzare gli utenti in un gruppo, è possibile progettare i ruoli che saranno utili per questi gruppi. Se è presente un gruppo per tipo di utente, come nelle maschere dominio, un modo semplice è quello di iniziare a creare un ruolo per titpo di utente. È possibile quindi creare regole che consentono o negano ogni ruolo al proprio gruppo rispettivo per una risorsa specifica.

Per esempio, le maschere dominio già creano una regola che rende disponibile il ruolo DomaniBasicUser al gruppo BasicUser nella cartella dominio e nelle proprie sottocartelle. Il gruppo AdvancedUser ha accesso al ruolo DomainAdvancedUser nella cartella dominio e nelle proprie sottocartelle. È possibile progettare simili regole per fornire i sottogruppo personalizzati creati con l'accesso appropriato al portale dominio, o ad una pagine dominio su un portale comune. Per assicurare agli sviluppatori l'accesso al Reporting Server, è possibile creare una regola che da accesso al ruolo DomainDeveloper al gruppo Developer sul nodo Reporting Server nell'albero delle risorse.

È possibile usare un ruolo in varie regole, come quando si desidera concedere privilegi ad un gruppo su diversi tipi di risorse. Se si desidera concedere privilegi agli sviluppatori su una cartella, un portale e un nodo Reporting Server, è possibile creare un ruolo che raccoglie tutti i rilevanti privilegi e quindi crea una regola separata per applicare il ruolo ad ogni risorsa. WebFOCUS ignora i privilegi che non si applicano ad un dato sottosistema. È inoltre possibile creare un ruolo separato per sviluppatori su ogni risorsa, che raccoglie solo i privilegi rilevanti al sottosistema IBFS rilevante. Si creerebbe un ruolo per sviluppatori che specifica la cartella, un ruolo per sviluppatori che specifica il portale e un ruolo per sviluppatori che specifica il nodo del Reporting Server. Tuttavia, è più facile mantenere un solo ruolo.

Nota: I ruoli che includono privilegi di sessione non dovrebbero essere usati in regola impostate nelle sezioni inferiori di WFC. Per impostazione predefinita, WebFOCUS non controlla i privilegi di sessione al di sotto di una data profondità, per diminuire la richiesta sulle risorse di sistema. È possibile modificare la ricerca di profondità da un amministratore di sistema, ma non si consiglia.

Per ulteriori informazioni sulla modifica della ricerca di profondità, consultare Impostazioni protezione. Per ulteriori informazioni sui ruoli, consultare Gestione Ruoli.

x

Meno regole in un sistema si traduce in più facilità di comprensione e manutenzione. Il numero di regole che comprende la propria normativa di sicurezza dipende da molti fattori, come quali sottosistemi si desidera esporre agli utenti, il numero di ruoli diversi che la propria azienda richiede e quandi domini si hanno a disposizione. È possibile minimizzare il numero di regole nel propri sistema, applicando regole al livello più possibile nella gerarchia IBFS. In generale, questo significa consentire privilegi al livello più alto possibile, quindi negandoli ai livelli inferiori, come necessario.

Come esempio, considerare un semplice scenario dove ognuno in una installazione ha accesso a tutte le proprie risorse e gli utenti finali necessitano eseguire una di due azioni: sviluppare o eseguire prospetti. È possibile implementare questa azione usando due gruppi e due regole. I due gruppi sono il gruppo Report Developer e il gruppo Report Runner. Le due regole sono posizionate sul nodo radice IBFS e quindi, applicare tutte le cartelle di contenuto, i portali e le risorse di Reporting Server. Una regola consente il ruolo Report Developer al gruppo Report Developer sulla cartella radice IBFS e tutte le sottocartelle e l'altra regola consente il ruolo Report Runner al gruppo Report Runner con lo stesso ambito. Con una sola ulteriore regola, è possibile nascondere il nodo Reporting Server dal gruppo Report Runner, negando al gruppo il ruolo Elenco su quel nodo.

Di solito, gruppi diversi necessitano accesso a risorse diverse. La normativa di sicurezza fornita dalle maschere dominio supporta questo requisito. In ogni dominio, i gruppi hanno accesso alle proprie risorse e nessun gruppo risulta associato con le regole sopra le cartelle ed i portali dominio. Le regole specializzate possono esssere applicate per adattare la normativa, per supportare ulteriori necessità, come nascondere cartelle specifiche o pagine del portale.

Un requisito comune è che gli utenti necessitano di essere in grado di agire sui contenuti di un container, ma non di influenzare il contenuto stesso. Per esempio, gli sviluppatori potrebbero dover creare e cancellare cartelle in Sales, ma non di cancellare la cartella Sales stessa. È possibile assicurare questa caratteristica, limitando i privilegi specifici con una regola usata solo sulla cartella. Le maschere dominio limitano gli Amministratori Gruppo e gli Sviluppatori Dominio in questo modo, per non consentirgli di cancellare i container che definiscono i propri confini di sicurezza, come le cartelle di cui hanno controllo amministrativo.

Per ulteriori informazioni sulle regole, consultare Gestione Regole.

x

WebFOCUS consente di delegare la responsabilità per molte funzioni amministrative, incluse:

• Creazione di gruppi e utenti.
• Assegnazione di utenti ai gruppi.
• Creazione di regole di sicurezza limitate, come il divieto di accesso ad una sotto cartella di membri aventi accesso ad un gruppo specifico.
• Gestione contenuto privato per utenti.
• Riassegnazione di proprietà delle risorse, come pianificazioni o prospetti.

Le maschere dominio forniscono due esempi di come approcciare il design della normativa della gestione di un gruppo. Nella maschera Dominio Aziendale, gli amministratori di gruppo sono in grado di visualizzare tutti gli utenti in WebFOCUS, all'interno del centro di sicurezza, e di aggiungere qualsiasi utente ai propri gruppi in gestione. Tuttavia, nella maschera Dominio Titolare SaaS, gli amministratori di gruppo sono solo in grado di visualizzare e gestire l'appartenenza di utenti nel proprio gruppo titolare. La differenza di normativa viene implementata semplicemente cambiando se la regola che consente il ruolo DomainGroupAdminScope si applica al gruppo EVERYONE o al gruppo titolare. In modo simile, una regola che consente il ruolo Gestisci Utenti agli amministratori del gruppo aziendale sul proprio gruppo principale, consente loro anche di creare utenti.

Per ulteriori informazioni sui gruppi, consultare Gestione Utenti e Gruppi.

x

Si consiglia di usare le regole IBFS per nascondere o esporre i nodi del Reporting server quando necessario, ma di usare le funzioni Controllo Accesso e Ruoli Reporting Server per proteggere risorse specifiche sui server. Le regole applicate alle risorse del Reporting Server sotto al nodo non influenzeranno il rendering di altre parti dell'interfaccia utente WebFOCUS. Questi elementi si applicano solamente alla vista dell'albero delle risorse. Le funzioni Controllo Accesso del Reporting Server forniscono una migliore sicurezza per il controllo di accesso alle impostazioni del motore server, come comandi del sistema operativo o SQL pass-through, e a cartelle di applicazione che contegono metadati e dati caricati.

x

La sicurezza IBFS gestisce le risorse nel contenitore WebFOCUS e alcune risorse esterne, come i nodi del Reporting Server. Tuttavia, l'accesso alle righe dati in nomi database o campi nei metadati WebFOCUS è governato dalle funzioni Sicurezza Dati WebFOCUS (DBA). È possibile usare queste funzioni di sicurezza, passando i gruppi utenti e l'ID utente WebFOCUS al Reporting Server.

Per ulteriori informazioni sullo scambio di informazioni tra WebFOCUS Client e WebFOCUS Reporting Server, consultare Dettagli di elaborazione principale di WebFOCUS Reporting Server.