Segurança Baseada em Tópico

Utilize a segurança baseada em tópico para controlar quais aplicativos no sistema de Publicação/Assinatura podem acessar informações e em quais tópicos.

Para cada tópico ao qual você deseja restringir o acesso, é possível especificar quais proprietários (IDs de usuários e grupos de IDs de usuários) podem publicar no tópico e quais proprietários podem assinar o tópico. Também é possível especificar quais proprietários podem pedir a entrega persistente de mensagens.

Qualquer proprietário pode publicar, assinar e pedir a entrega persistente de mensagens sobre qualquer tópico cujo acesso não for restringido explicitamente.

A segurança baseada em tópico é gerenciada por um Servidor de Nome de Usuário que utiliza as ACLs (Access Control Lists) que você criar para decidir quais autorizações são aplicadas.

Proprietários e o Servidor de Nomes do Usuário

O Servidor de Nome de Usuário no WebSphere Message Broker gerencia o conjunto de proprietários que já estão definidos na rede, em nome dos intermediários e do Configuration Manager, para uso em Publicação/Assinatura.No Windows, essa lista de usuários é obtida do domínio especificado no comando mqsicreateusernameserver.

O Servidor de Nome de Usuário é tornado conhecido ao intermediário e ao Configuration Manager especificando o gerenciador de filas do Servidor de Nome de Usuário nos comandos mqsicreatebroker e mqsicreateconfigmgr.

Os intermediários de mensagens dentro do domínio do intermediário interagem com o Servidor de Nome de Usuário para recuperar o conjunto total de usuários e grupos dos quais as Access Control Lists são criadas e em relação aos quais os pedidos de Publicação/Assinatura são validados. O Configuration Manager interage com o Servidor de Nome de Usuário para exibir os usuários e grupos de usuários nas ACLs que são criados utilizando o Editor de Hierarquia de Tópicos fornecido na Perspectiva de Administração do Intermediário do workbench.

Access Control Lists

As Access Control Lists são utilizadas para definir, para qualquer tópico e proprietário, o direito desse proprietário publicar nesse tópico ou assiná-lo ou de pedir a entrega persistente de uma publicação sobre esse tópico.

Também é possível utilizar a ACL para definir o nível de proteção de mensagem que você deseja aplicar a cada tópico.

Especifique essas definições utilizando o Editor de Hierarquia de Tópicos na Perspectiva de Administração do Intermediário do workbench.

O controle de acesso pode ser definido explicitamente para cada tópico individual. Contudo, se nenhuma ACL explícita for definida para um tópico, o controle de acesso será herdado de um tópico ancestral ou pai, conforme definido pela estrutura hierárquica da árvore de tópicos. Se nenhum tópico na hierarquia até a raiz do tópico tiver uma ACL explícita, o tópico herdará a ACL da raiz do tópico.

Qualquer proprietário definido que seja conhecido para o Servidor de Nome de Usuário pode ser associado a um tópico dessa maneira.

Resolução de Conflitos de ACL

Se os proprietários em seu domínio do intermediário incluírem um ou mais usuários em mais de um grupo, pode haver conflito entre os valores de ACL explícitos ou herdados. As seguintes regras indicam como um conflito é resolvido:
  • Se o usuário tiver uma ACL de usuário explícita no tópico de interesse, isto sempre tem prioridade e o intermediário verifica a operação atual com base nisto.
  • Se o usuário não tiver uma ACL de usuário explícita no tópico de interesse, mas tiver ACLs de usuário explícitas em relação a um ancestral na árvore de tópico, a ACL do ancestral mais próximo deste usuário tem prioridade e o intermediário verifica a operação atual com base nela.
  • Se não houver ACLs de usuário explícitas para o usuário no tópico de interesse ou de seus ascendentes, o intermediário tentará verificar a operação atual com base nas ACLs de grupo:
    • Se o usuário for membro de um grupo que tenha uma ACL de grupo explícita no tópico de interesse, o intermediário verificará a operação atual com base nessa ACL de grupo.
    • Se o usuário não for membro de um grupo que possui uma ACL de grupo explícita no tópico de interesse, mas for membro de um grupo com ACLs de grupo explícitas em relação a um ancestral na árvore de tópico, a ACL do ancestral mais próximo tem prioridade e o intermediário verifica a operação atual com base nela.
    • Se, em um determinado nível na árvore de tópicos, o ID do usuário estiver contido em mais de um grupo com uma ACL explícita, a permissão é concedida se qualquer das especificações for positiva; caso contrário, ela é negada.

Não é possível associar ACLs a tópicos que incluam um ou mais caracteres curinga. Contudo, o acesso do aplicativo cliente é resolvido corretamente quando o registro de assinatura for efetuado, mesmo quando esse aplicativo especificar um caractere curinga no tópico.

Autorizações PublicGroup

Além dos grupos que você define, o WebSphere Message Broker fornece um grupo implícito, PublicGroup, ao qual os usuários pertencem automaticamente. Este grupo implícito simplifica a especificação de ACLs em uma árvore de tópico. Particularmente, este grupo é utilizado na especificação da ACL para a raiz de tópico. Observe que a configuração padrão da raiz do tópico permite operações de publicação e assinatura para o PublicGroup. Você pode exibir e alterar esta ACL utilizando o workbench, mas não pode removê-la. Ela determina as permissões padrão para toda a árvore de tópico. É possível especificar ACLs para o PublicGroup em qualquer outro lugar da árvore de tópicos, onde desejar definir permissões para todos os usuários.

Se você tiver um proprietário denominado Público definido em seu ambiente de segurança existente, você não pode utilizá-lo para segurança baseada em tópico. Se você especificar esse proprietário dentro de uma ACL, ele será igualado ao PublicGroup e, portanto, sempre permitirá acesso global.

Autorizações mqbrkrs

O WebSphere Message Broker concede privilégios especiais de controle de acesso de Publicação/Assinatura a membros do grupo mqbrkrs e ao grupo global Domínio mqbrkrs correspondente, se apropriado.

Os intermediários precisam de privilégios especiais para realizar operações de publicação e assinatura internas em redes em que houver controle de acesso. Quando você cria um intermediário em uma rede dessas, é necessário especificar um ID de usuário que pertença ao grupo mqbrkrs como o ID do usuário do serviço para o intermediário. O grupo mqbrkrs recebe privilégios implícitos para que seus membros possam publicar, assinar e solicitar a entrega persistente de mensagens na raiz de tópico (""). Todos os outros tópicos herdam essas permissões. Se você tentar configurar uma ACL para o grupo mqbrkrs utilizando o workbench, essa ACL será ignorada pelo WebSphere Message Broker.

ACLs e Tópicos do Sistema

Mensagens que são utilizadas para operações de publicação e assinatura internas são publicadas através do domínio do intermediário utilizando tópicos do sistema, que começam com as cadeias "$SYS" e "$ISYS".

Esses tópicos podem ser publicados somente a partir de, e assinados para, membros do grupo mqbrkrs, exceto para os dois cenários a seguir:
  1. Se você estiver migrando tópicos do WebSphere MQ Publicação/Assinatura, poderá configurar ACLs em tópicos que comecem com a cadeia "$SYS/STREAM".
  2. Clientes podem assinar tópicos que começam com a cadeia "$SYS", isso significa que aplicativos que fornecem uma função de gerenciamento podem assinar eventos administrativos para o intermediário.

Não configure ACLs em tópicos que iniciem com a cadeia "$ISYS". Você não é impedido de fazer isso, mas as ACLs são ignoradas.

Definição de Controle de Acesso em Tópicos

Qualquer usuário que possui uma ACL de segurança no nível de objeto que fornece permissão de controle total ao objeto de tópico de raiz pode definir e manipular as ACLs que definem quais proprietários podem publicar em, e assinar quais tópicos. As ACLs também podem limitar a entrega de mensagens persistentes e definir o nível de proteção de mensagem.

Todos os proprietários definidos podem ser associados a qualquer tópico; as permissões que podem ser definidas são mostradas na tabela a seguir:
Opção Descrição
Publish Permite ou nega que o proprietário publique mensagens neste tópico.
Assinar Permite ou nega que o proprietário assine mensagens neste tópico.
Persistente Especifica se o proprietário pode receber mensagens persistentemente. Se o proprietário não tiver permissão, todas as mensagens serão enviadas de maneira não persistente. Cada assinatura individual indica se o assinante requer mensagens persistentes.
Nível de QoP Especifica o nível de proteção de mensagem que é aplicado. Um dos seguintes quatro valores pode ser escolhido:
  • Nenhum(a)
  • Integridade de Canal
  • Integridade de Mensagem
  • Criptografado
O valor padrão é 'Nenhum'.
O comportamento de controle de acesso persistente não é idêntico ao controle de publicação e assinatura:
  • Clientes que têm acesso de Publicação negado têm suas mensagens de publicação recusadas.
  • Clientes que tem acesso de Assinatura negado não recebem a publicação.
  • O controle de acesso persistente não nega a mensagem a assinantes, mas nega a eles persistência, portanto, assinantes negados sempre recebem mensagens, sujeitos a seu controle de acesso de assinatura, mas sempre têm a mensagem enviada para eles sem persistência, independente da persistência da mensagem original.

Herança de Critérios de Segurança

Em geral, os tópicos são organizados em uma árvore hierárquica. A ACL de um tópico pai pode ser herdada por alguns ou por todos os tópicos descendentes que não têm uma ACL explícita. Portanto, não é necessário ter uma ACL explícita associada com cada um dos tópicos. Cada tópico tem um critério de ACL que é o mesmo de seu pai. Se todos os tópicos pais até o tópico raiz não tiverem ACLs, este tópico herda a ACL do tópico raiz.

Por exemplo, na árvore de tópicos mostrada a seguir, a raiz de tópico não é mostrada mas é suposto que haja uma ACL para PublicGroup cujos membros podem publicar, assinar e receber publicações persistentes. (O símbolo "¬" significa "não".)

Herdando ACLs em uma Árvore de Tópico


A figura mostra uma árvore de tópico com a estrutura a seguir. A é o nível superior, com B, K e P no próximo nível. De K há outros níveis com nós M e N. Em alguns nós na árvore, as ACLs são mostradas. O nó A tem uma ACL Publicação contendo joe, uma ACL Assinatura contendo Grupo Público e uma ACL Persistência contendo Grupo ¬Público. O Nó B tem uma ACL Publicação contendo allen e uma ACL Assinatura contendo HR e ¬Grupo Público. Não há ACL Persistente definida explicitamente. O nó P tem uma ACL Publicação contendo joe, nenhuma ACL Assinatura definida explicitamente e uma ACL Persistente contendo joe. O nó N tem uma ACL Publicação contendo mary e joe, uma ACL Assinatura contendo nat e uma ACL Persistente contendo Grupo Público e ¬nat. Os nós K e M não têm ACLs definidas explicitamente.
A tabela a seguir mostra as ACLs, herdadas em alguns casos, que resultam da árvore de tópico mostrada na figura:
Tópico Publicadores Assinantes Persistente
A apenas joe todos ninguém
A/P apenas joe todos apenas joe
A/K apenas joe todos ninguém
A/K/M apenas joe todos ninguém
A/K/M/N apenas mary e joe todos todos exceto nat
A/B allen, joe HR ninguém

Tópicos Criados Dinamicamente

Tópicos que não são criados explicitamente pelo administrador do sistema, mas são criados dinamicamente quando um cliente publica ou assina mensagens, são tratados da mesma forma que os criados pelo administrador do sistema, mas não têm ACL definidas explicitamente. Ou seja, as ACLs para tópicos criados dinamicamente são herdadas do ancestral mais próximo na árvore de tópico que possui um critério explícito. Portanto, não é necessário definir tópicos de folhas na árvore se eles não tiverem ACLs explícitas.

ACLs e Tópicos de Caractere Curinga

Com o WebSphere Message Broker não é possível associar um critério de segurança explícito a um tópico de caractere curinga.Por exemplo, não é possível associar uma ACL com o tópico "A/+", que representa uma hierarquia de dois níveis, além de incluir "A/B", "A/K" e "A/P".

Entretanto, o WebSphere Message Broker garante mediação de acesso correta quando um aplicativo cliente assina um tópico de caractere curinga.

Por exemplo, o tópico "A/+" não tem, e não pode ter, um critério de segurança associado explicitamente a ele. Portanto, "A/+" herda sua política de "A". Qualquer usuário pode assinar "A+" porque a ACL de assinante inclui todos.

Quando uma mensagem é publicada em "A/P" ou "A/K", o intermediário a entrega para o usuário que assinou "A/+". No entanto, quando uma mensagem é publicada em "A/B", esta mensagem é entregue apenas para assinantes que estão no grupo HR.

Se o administrador do sistema alterar a ACL de assinatura de qualquer tópico que corresponda a "A/+", o intermediário reforça a ACL quando a mensagem é entregue. A assinatura de um tópico curinga tem a semântica para entregar mensagens em todos os tópicos que correspondam ao curinga e para os quais o assinante tenha autorização para receber a mensagem.

ACLs e Resolução de Assinatura

O intermediário reforça o controle de acesso através do tópico de uma mensagem a ser entregue. As mensagens são entregues somente aos clientes que não tiveram o acesso de assinatura a esse tópico negado, explicitamente ou através de herança. Como uma assinatura pode conter um caractere curinga, a correspondência real em relação ao espaço de nomes do tópico, e portanto às ACLs dos tópicos, não pode ser feita quando a assinatura é recebida. A decisão de entregar uma mensagem a um assinante é feita somente quando uma mensagem específica com um tópico está sendo processada pelo intermediário de mensagem.

Ativando as Atualizações de ACL de Tópico

Atualizações a uma ACL de tópico não tornam-se ativas até que sejam implementadas e ativadas através do domínio do intermediário do WebSphere Message Broker workbench.

Você deve ter uma ACL de segurança no nível de objeto que fornece permissão de controle total para o objeto de tópico raiz.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
aq01203_