Sicurezza basata sull'argomento

Utilizzare la sicurezza basata sull'argomento per verificare quali applicazioni nel sistema di pubblicazione/sottoscrizione possono accedere alle informazioni e su quali argomenti.

Per ciascun argomento per il quale si desidera limitare l'accesso, è possibile specificare quali principal (ID utente e gruppi di ID utente) possono pubblicare l'argomento e quali principal possono sottoscriverlo. E' possibile inoltre specificare quali principal possono richiedere la consegna permanente dei messaggi.

Qualsiasi principal può pubblicare, sottoscrivere e richiedere la consegna permanente dei messaggi su qualsiasi argomento il cui accesso non sia stato limitato esplicitamente.

La sicurezza basata sull'argomento viene gestita da un Server nomi utente che utilizza gli ACL (Access Control List) creati per stabilire le autorizzazioni applicate.

Principal e server nomi utente

Il Server nomi utente in WebSphere Message Broker gestisce la serie di principal già definiti nella rete in uso, per conto dei broker e di Gestione configurazione, da utilizzare nella pubblicazione/sottoscrizione. Su Windows, questo elenco di utenti viene preso dal dominio specificato nel comando mqsicreateusernameserver.

Il Server nomi utente viene reso noto al broker e a Gestione configurazione specificando il gestore code del Server nomi utente nei comandi mqsicreatebroker e mqsicreateconfigmgr.

I broker dei messaggi all'interno del dominio broker interagiscono con il Server nomi utente per richiamare la serie completa di utenti e gruppi da cui sono creati gli ACL (Access Control List) e mediante cui vengono convalidate le richieste di pubblicazione/sottoscrizione. Gestione configurazione interagisce con il Server nomi utente per visualizzare gli utenti ed i gruppi di utenti negli ACL creati utilizzando l'editor Gerarchia degli argomenti fornito nella Prospettiva Amministrazione broker del workbench.

ACL (Access Control List)

Gli ACL (Access Control List) vengono utilizzati per definire, per qualsiasi argomento e principal, il diritto di tale principal a pubblicare o sottoscrivere tale argomento o per richiedere la consegna permanente di una pubblicazione su tale argomento.

E' possibile inoltre utilizzare l'ACL per definire il livello di protezione del messaggio che si desidera applicare a ciascun argomento.

Specificare tali definizioni utilizzando l'editor Gerarchia degli argomenti nella Prospettiva Amministrazione broker del workbench.

Il controllo di accesso può essere impostato esplicitamente per ciascun argomento singolo. Tuttavia, se per un argomento non è definito alcun ACL esplicito, il controllo di accesso viene ereditato da un argomento parent o precedente, come definito dalla struttura gerarchica ad albero degli argomenti. Se nessun argomento nella gerarchia fino al root dell'argomento ha un ACL esplicito, l'argomento eredita l'ACL del root dell'argomento.

Qualsiasi principal definito, noto al Server nomi utente può essere associato ad un argomento in tale modo.

Risoluzione di conflitti ACL

Se i principal nel dominio broker in uso includono uno o più utenti in più di un gruppo, i valori ACL ereditati o espliciti possono essere in conflitto. Di seguito sono riportate delle regole che indicano come risolvere un conflitto:
  • Se l'utente dispone di un ACL esplicito di utente sull'argomento di interesse, questo ha sempre la priorità e il broker verifica l'operazione corrente su tali basi.
  • Se l'utente non dispone di un ACL esplicito di utente sull'argomento di interesse, ma dispone di ACL espliciti di utente su un predecessore nella struttura ad albero dell'argomento, ha priorità l'ACL del predecessore diretto di tale utente e il broker verifica l'operazione corrente su tali basi.
  • Se per l'utente non esistono ACL espliciti di utente sull'argomento di interesse o sui relativi predecessori, il broker tenta di verificare l'operazione corrente sulle basi degli ACL di gruppo:
    • Se l'utente è un membro di un gruppo che dispone di un ACL esplicito di gruppo sull'argomento di interesse, il broker verifica l'operazione corrente sulle basi di tale ACL di gruppo.
    • Se l'utente non è un membro di un gruppo che dispone di un ACL esplicito di gruppo sull'argomento di interesse, ma è un membro di un gruppo con ACL espliciti di gruppo su un predecessore nella struttura ad albero dell'argomento, ha priorità l'ACL del predecessore diretto e il broker verifica l'operazione corrente su tali basi.
    • Se, ad un determinato livello nella struttura ad albero dell'argomento, l'ID utente è presente in più di un gruppo con un ACL esplicito, l'autorizzazione viene assegnata se una qualsiasi delle specifiche è positiva; altrimenti viene negata.

Non è possibile associare gli ACL agli argomenti che includono uno o più caratteri wildcard. Tuttavia, l'accesso dall'applicazione client viene risolto correttamente quando viene eseguita la registrazione della sottoscrizione, anche quando l'applicazione specifica un carattere wildcard nell'argomento.

Autorizzazioni PublicGroup

Oltre ai gruppi che vengono definiti, WebSphere Message Broker fornisce un gruppo implicito, PublicGroup, di cui fanno automaticamente parte tutti gli utenti. Questo gruppo implicito semplifica la specifica di ACL in una struttura ad albero degli argomenti. In particolare, questo gruppo viene utilizzato nella specifica dell'ACL per il root dell'argomento. Tenere presente che l'impostazione predefinita del root dell'argomento consente le operazioni di pubblicazione e sottoscrizione per PublicGroup. E' possibile visualizzare e modificare tale ACL utilizzando il workbench, ma non è possibile eliminarlo. Esso determina le autorizzazioni predefinite per l'intera struttura ad albero dell'argomento. E' possibile specificare gli ACL per PublicGroup in qualsiasi punto della struttura ad albero dell'argomento, ovunque si desideri definire le autorizzazioni per tutti gli utenti.

Se si dispone di un principal denominato Public definito nell'ambiente di sicurezza esistente, non è possibile utilizzarlo per la sicurezza basata sull'argomento. Se questo principal viene specificato nell'ambito di un ACL, viene equiparato a PublicGroup e quindi consente sempre l'accesso globale.

Autorizzazioni mqbrkrs

WebSphere Message Broker assegna privilegi speciali nel controllo dell'accesso di pubblicazione/sottoscrizione ai membri del gruppo mqbrkrs e al corrispondente gruppo globale Domain mqbrkrs se appropriato.

I broker necessitano di privilegi speciali per eseguire operazioni interne di pubblicazione e sottoscrizione nelle reti in cui esiste il controllo dell'accesso. Quando si crea un broker in tale rete, è necessario specificare un ID utente che appartenga al gruppo mqbrkrs come ID utente del servizio per il broker. Al gruppo mqbrkrs vengono assegnati privilegi impliciti cosicché i propri membri possono pubblicare, sottoscrivere e richiedere la consegna permanente dei messaggi sul root dell'argomento (""). Tutti gli altri argomenti ereditano tali autorizzazioni. Se si tenta di configurare un ACL per il gruppo mqbrkrs utilizzando il workbench, questo ACL viene ignorato da WebSphere Message Broker.

ACL e argomenti di sistema

I messaggi che vengono utilizzati per operazioni interne di pubblicazione e sottoscrizione sono pubblicati nel dominio broker utilizzando argomenti di sistema, che iniziano con le stringhe "$SYS" e "$ISYS".

Tali argomenti possono essere pubblicati e sottoscritti solamente da membri del gruppo mqbrkrs, eccetto i due seguenti scenari:
  1. Se si sta eseguendo la migrazione di argomenti da WebSphere MQ Pubblicazione/Sottoscrizione, è possibile eseguire la configurazione di ACL su argomenti che iniziando con la stringa "$SYS/STREAM".
  2. I client possono eseguire la sottoscrizione degli argomenti che iniziano con la stringa "$SYS"; ciò significa che le applicazioni che forniscono una funzione di gestione possono eseguire la sottoscrizione al broker per eventi di amministrazione.

Non eseguire la configurazione degli ACL su argomenti che iniziano con la stringa "$ISYS". Ciò non viene impedito, ma gli ACL vengono ignorati.

Impostazione del controllo accessi sugli argomenti

Un qualsiasi utente che ha un ACL di sicurezza a livello di oggetto che fornisce l'autorizzazione di controllo totale sull'oggetto argomento root, può definire e manipolare gli ACL che definiscono i principal che possono eseguire la pubblicazione e la sottoscrizione di determinati argomenti. Gli ACL possono inoltre limitare la consegna dei messaggi permanenti e definiscono il livello di protezione dei messaggi.

Tutti i principal definiti possono essere associati ad un qualsiasi argomento; nella tabella riportata di seguito sono presenti le autorizzazioni che possono essere impostate:
Opzione Descrizione
Pubblica Consente o nega al principal la pubblicazione di messaggi su questo argomento.
Sottoscrivi Consente o nega al principal la sottoscrizione ai messaggi su questo argomento.
Permanente Specifica se il principal può ricevere i messaggi in modo permanente. Se il principal non è autorizzato, tutti i messaggi vengono inviati in modo non permanente. Ciascuna singola sottoscrizione indica se il sottoscrittore (subscriber) richiede messaggi permanenti.
Livello QoP Specifica il livello di protezione del messaggio applicato. E' possibile scegliere uno dei seguenti quattro valori:
  • Nessuno
  • Integrità canali
  • Integrità messaggi
  • Crittografato
Il valore predefinito è 'Nessuno'.
Il funzionamento del controllo accessi permanente non è identico al controllo di pubblicazione/sottoscrizione:
  • Ai client a cui è negato l'accesso Pubblica vengono respinti i relativi messaggi di pubblicazione.
  • I client a cui è negato l'accesso Sottoscrivi non ricevono la pubblicazione.
  • Il controllo accessi permanente non nega il messaggio ai sottoscrittori (subscriber), ma nega la permanenza; tali sottoscrittori (subscriber) ricevono quindi sempre i messaggi, soggetti al relativo controllo accessi di sottoscrizione, ma questi vengono inviati non in modo permanente, indipendentemente dalla permanenza del messaggio di origine.

Eredità delle politiche di sicurezza

Di solito, gli argomenti vengono organizzati in una struttura gerarchica ad albero. L'ACL di un argomento parent può essere ereditato da alcuni o da tutti i relativi argomenti discendenti che non hanno un ACL esplicito. Quindi, non è necessario avere un ACL esplicito associato ad ogni argomento. Ciascun argomento ha una politica ACL che è quella del relativo parent. Se tutti gli argomenti parent fino a quello root non dispongono di ACL espliciti, tale argomento eredita l'ACL dell'argomento root.

Ad esempio, nella struttura ad albero riportata di seguito, non è riportato il root dell'argomento, ma si assume che disponga di un ACL per PublicGroup i cui membri possono pubblicare, sottoscrivere e ricevere pubblicazioni permanenti (il simbolo "¬" significa "non".)

Eredità di ACL in una struttura ad albero degli argomenti


La figura mostra una struttura ad albero degli argomenti con la seguente struttura. A è il livello superiore con B, K e P al livello successivo. Da K ci sono ulteriori livelli con i nodi M e N. Per alcuni dei nodi nella struttura ad albero sono presenti gli ACL. Il nodo A ha un ACL Pubblica contenente joe, un ACL Sottoscrivi contenente Public Group e un ACL Permanente contenente ¬Public Group. Il nodo B ha un ACL Pubblica contenente allen e un ACL Sottoscrivi contenente HR e ¬Public Group. Non è presente alcun ACL Permanente definito in modo esplicito. Il nodo P ha un ACL Pubblica contenente joe, nessun ACL Sottoscrivi definito esplicitamente e un ACL Permanente contenete joe. Il nodo N ha un ACL Pubblica contenente mary e joe, un ACL Sottoscrivi contenente nat e un ACL Permanente contenente Public Group e ¬nat. I nodi K e M non hanno ACL definiti esplicitamente.
Nella tabella riportata di seguito sono presenti gli ACL, in alcuni casi ereditati, risultati dalla struttura ad albero degli argomenti mostrata nella figura:
Argomento Autori (publisher) Sottoscrittori (subscriber) Permanente
A solo joe tutti nessuno
A/P solo joe tutti solo joe
A/K solo joe tutti nessuno
A/K/M solo joe tutti nessuno
A/K/M/N solo mary e joe tutti tutti tranne nat
A/B allen e joe HR nessuno

Argomenti creati dinamicamente

Gli argomenti che non sono creati esplicitamente dall'amministratore del sistema, ma sono creati dinamicamente quando un client pubblica o sottoscrive messaggi, vengono trattati allo stesso modo di quelli creati dall'amministratore del sistema, ma non dispongono di ACL definiti esplicitamente. Ovvero, gli ACL per gli argomenti creati dinamicamente vengono ereditati dal predecessore diretto nella struttura ad albero degli argomenti che ha una politica esplicita. Non è quindi necessario definire argomenti foglia nella struttura ad albero se non hanno ACL espliciti.

ACL e argomenti wildcard

Con WebSphere Message Broker non è possibile associare una politica di sicurezza esplicita ad un argomento wildcard. Ad esempio, non è possibile associare un ACL all'argomento "A/+", che rappresenta una gerarchia a due livelli e include "A/B", "A/K" e "A/P".

Tuttavia, WebSphere Message Broker garantisce la mediazione di un accesso corretto quando un'applicazione client sottoscrive un argomento wildcard.

Ad esempio, l'argomento "A/+" non possiede e non può avere una politica di sicurezza associata esplicitamente ad esso. "A/+" eredita quindi la propria politica da "A". Qualsiasi utente può sottoscrivere "A/+" in quanto l'ACL di sottoscrizione include tutti.

Quando un messaggio viene pubblicato su "A/P" o "A/K", il broker lo consegna all'utente che ha sottoscritto "A/+". Tuttavia, quando un messaggio viene pubblicato su "A/B", tale messaggio viene consegnato solo ai sottoscrittori (subscriber) presenti nel gruppo HR.

Se l'amministratore del sistema modifica l'ACL di sottoscrizione di qualsiasi argomento corrispondente a "A/+", il broker applica correttamente l'ACL quando il messaggio viene consegnato. La sottoscrizione ad un argomento wildcard significa distribuire messaggi su tutti gli argomenti corrispondenti a quello wildcard e per i quali il sottoscrittore (subscriber) dispone dell'autorizzazione a ricevere tale messaggio.

ACL e risoluzione della sottoscrizione

Il broker applica il controllo accessi relativamente all'argomento del messaggio da consegnare. I messaggi vengono consegnati solo a quei client ai quali non è stato negato l'accesso di sottoscrizione a quell'argomento, in modo esplicito o in eredità. Poiché una sottoscrizione può contenere un carattere wildcard, la corrispondenza reale tra lo spazio dei nomi dell'argomento e gli ACL dell'argomento, non può essere eseguita quando viene ricevuta la sottoscrizione. La decisione di consegnare un messaggio ad un sottoscrittore (subscriber) viene effettuata solo quando un determinato messaggio con un argomento viene elaborato dal broker dei messaggi.

Attivazione di aggiornamenti di ACL di argomento

Gli aggiornamenti all'ACL di un argomento non diventano attivi finché non vengono distribuiti e attivati nel dominio broker dal workbench di WebSphere Message Broker.

E' necessario avere un ACL di sicurezza a livello di oggetto che fornisce l'autorizzazione di controllo totale sull'oggetto argomento root.

Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
aq01203_