Scenario 3: Accesso cliente con Public Queries ai database utente interni

Lo scopo di questo scenario è di consentire l'accesso cliente a una database ClearQuest interno, di visualizzare i record per i problemi, inoltrare i nuovi problemi e visualizzare altre importanti informazioni pubbliche.

È spesso utile consentire l'accesso cliente a un database ClearQuest interno, con l'intento di consentire la visualizzazione dei record associati ai problemi, l'inoltro dei nuovi problemi e la possibile visualizzazione di altre informazioni pubbliche non specifiche a un particolare cliente.

Contesto dello scenario 3

Un aspetto chiave di tale possibilità è che non è possibile consentire a un cliente di visualizzare o rilevare l'esistenza di qualsiasi altra informazione sul cliente. Inoltre, non è possibile consentire la visualizzazione o il rilevamento dell'esistenza di utenti o informazioni interni.

È importante notare che le autorizzazioni cartella dell'area di lavoro sono solo una parte della soluzione per l'ottenimento dello scopo globale. Molti schemi ClearQuest includono i record che contengono i dati che è preferibile non vengano visualizzati dal cliente.

La funzione Security Context di Rational ClearQuest deve essere utilizzata per limitare la visibilità dei record restituiti da una interrogazione. Le autorizzazioni cartella dell'area di lavoro non limitano in alcun modo i dati restituiti da una interrogazione. Inoltre, le autorizzazioni cartella dell'area di lavoro non limitano in alcun modo la capacità degli utenti di effettuare interrogazioni private. Solo la funzione Security Context di Rational ClearQuest può limitare i record restituiti da una interrogazione.

Lo sviluppatore di schemi deve modificare i tipi di record forniti dallo schema, aggiungendo i riferimenti ai record Security Context e possibilmente separando i tipi di record logici in più record in cui il contenuto logico di ciascun record possa essere controllato separatamente, per abilitare effettivamente l'accesso cliente a un database utente interno. (Ad esempio, se un record product dispone della descrizione del prodotto, del prezzo e del costo da produrre nel record logico, la funzione security context può solo limitare l'accesso all'intero record, non a parti del record. In questo modo, se un cliente non deve conoscere il costo per produrre il prodotto, allora tali informazioni devono essere su un record separato. Tale separazione di record può essere relativamente complessa e può portare ad altri problemi e, quindi, non è consigliata

Flusso di lavoro dello scenario 3

L'amministratore della sicurezza esegue le seguenti operazioni.

  1. Crea un gruppo per gli utenti cliente, CustUsers.
  2. Tutti gli utenti creati per il cliente sono resi membri solo del gruppo del cliente, CustUsers.
  3. Concede l'autorizzazione Limitata alla lettura a CustUsers nella cartella Public Queries.
  4. Crea una cartella in Public Queries per il cliente, CustFolder.
  5. Concede l'autorizzazione Sola lettura o Lettura-Scrittura a CustUsers in CustFolder

Gli utenti cliente sono solo in grado di visualizzare la propria cartella Personal Queries e CustFolder insieme a tutto il contenuto delle cartelle. Se l'autorizzazione di sola lettura è concessa a CustFolder, allora gli utenti cliente non possono creare o modificare alcun contenuto e la cartella deve essere gestita da un altro gruppo che disponeva dell'autorizzazione Lettura-Scrittura nella cartella.

Se essi dispongono anche dell'autorizzazione Lettura-Scrittura in CustFolder, possono creare o modificare gli elementi in tale cartella, inclusa la creazione di cartelle secondarie, gestendo in tal modo la cartella.

Scenario alternativo 3a: Gestione cliente della propria cartella

Una variazione dello scenario precedente consiste nel separare gli utenti cliente in due gruppi: uno per gli utenti normali e un altro in grado di gestire il contenuto della cartella cliente. Ciò consente di utilizzare CustFolder in modo simile a quello predefinito per Public Queries, ad esempio quando la maggior parte degli utenti dispone dell'accesso di sola lettura e gli utenti selezionati dispongono dell'accesso di lettura e scrittura.

Per ottenere ciò, l'Amministratore della sicurezza esegue le seguenti operazioni in aggiunta a quelle evidenziate in precedenza.

  1. Crea un gruppo per gli amministratori cliente, CustAdmin. Gli utenti creati per il cliente sono membri di CustUsers o CustAdmin, in base al ruolo. È più appropriato disporre di utenti membri di entrambi i gruppi.
  2. Concede l'autorizzazione Limitata alla lettura sia a CustAdmin che a CustUsers nella cartella Public Queries.
  3. Concede l'autorizzazione Sola lettura a CustUsers nella cartella CustFolder (nessuna opzione per Lettura-Scrittura come indicato nello scenario precedente).
  4. Concede l'autorizzazione Lettura-Scrittura a CustAdmin nella cartella CustFolder.

In questo caso i membri di CustAdmin possono modificare il contenuto di CustFolder, ma gli utenti membri solo di CustUsers non possono eseguire tale operazione.

Scenario alternativo 3b: Più gruppi di clienti

Un cliente elevato può disporre di diversi gruppi interni che devono disporre di accesso ad un database ClearQuest interno. In questa situazione, esistono due casi: i gruppi di clienti sono indipendenti o cooperativi.

Nel primo caso, i due gruppi di clienti sono indipendenti e non devono necessariamente conoscersi reciprocamente. Ciò viene gestito come due clienti del tutto indipendenti. L'unico vero problema è quali nomi utilizzare per i gruppi ClearQuest e le cartelle cliente in modo che non esistano dubbi sull'esistenza di più gruppi. Questo può essere o meno un punto critico per la politica di sicurezza richiesta. Ad esempio, l'uso di “Acme1” e “Acme2” suggerisce all'utente dell'uno o dell'altro, che esiste un numero qualsiasi di altri gruppi “AcmeN”. La denominazione appropriata per una situazione simile è da considerarsi come un esercizio di competenza per il lettore.

Nel secondo caso, i gruppi sono cooperativi e sono consapevoli che ciascuno sta utilizzando lo stesso database. In questa situazione i nomi del gruppo e della cartella sono meno importanti. Esistono alcune variazioni che possono essere utilizzate per questo caso, in base al livello di condivisione desiderato tra i gruppi. Il caso tipico è quello in cui ciascun gruppo o l'amministratore di ciascun gruppo, controlla la propria cartella cliente, ma consente all'altro gruppo l'accesso Sola lettura. Ciò richiede 2 o 4 gruppi, se ciascun gruppo disponeva di un gruppo separato per la gestione (come evidenziato nella sezione precedente: Scenario alternativo 3a: Gestione cliente della propria cartella. Un'altra variazione è la condivisione dei gruppi del ruolo di gestione. Ciò ha senso solo se il precedente flusso alternativo viene utilizzato; consente di utilizzare solo 3 gruppi ClearQuest invece di 4: 2 per i gruppi di clienti e uno per un amministratore comune.

Scenario alternativo 3c: Clienti cooperativi

In questa situazione, più di un cliente è interessato in un singolo progetto ed essi devono visualizzare gli stessi dati nel database ClearQuest interno. Esistono due soluzioni possibili.



Feedback