Segurança para Recursos de Tempo de Execução: Listas de Controle de Acesso

Início da mudançaAs entradas da ACL (Lista de Controle de Acesso) permitem ou negam a um usuário acesso a recursos de tempo de execução específicos. Os recursos do tempo de execução são objetos do WebSphere Message Broker que existem no tempo de execução no domínio do intermediário.Fim da mudança

Início da mudançaCada objeto de tempo de execução possui uma ACL que determina quais usuários e grupos podem acessar o objeto. Utilizando entradas da ACL, você pode controlar o acesso de usuários a objetos específicos no domínio do intermediário e permitir que um usuário ou grupo visualize, modifique ou implemente o objeto. Você pode manipular as entradas da ACL utilizando o ambiente de trabalho, a API Java Configuration Manager Proxy ou os comandos mqsicreateaclentry, mqsideleteaclentry e mqsilistaclentry. Fim da mudança

Início da mudançaPor exemplo, o usuário USER1 pode receber acesso para modificar BROKERA, mas não ter direitos de acesso a BROKERB. Em um exemplo adicional, o mesmo usuário pode ter acesso para implementar no grupo de execução EXEGRP1, mas não em EXEGRP2, mesmo que os dois sejam membros de BROKERA.Fim da mudança

Ao tentar visualizar ou modificar um objeto para o qual você requer permissão, as informações a seguir são transmitidas para o Configuration Manager:

Início da mudançaO Configuration Manager verifica a tabela da ACL e, se seu ID do usuário estiver incluído na entrada da ACL para o objeto denominado, você estará autorizado para desempenhar a operação. Fim da mudança

Existem quatro diferentes níveis de acesso que podem ser concedidos para um usuário ou grupo: Controle total, Visualizar, Implementar e Editar. Nem todos os níveis de acesso são válidos para todos os tipos de objetos; consulte Permissões de ACL para obter uma lista das permissões que podem ser aplicadas a cada tipo de objeto e para obter um resumo das ações que o usuário ou grupo pode desempenhar.

Uma entrada da ACL contém o nome do usuário e pode especificar um nome de host ou nome de domínio. Por exemplo, é possível que um usuário obtenha acesso aos objetos, criando uma conta em um computador que tenha um nome do host que seja igual a um nome de domínio do Windows autorizado. Utilize as entradas da ACL para controlar o acesso aos objetos no domínio do intermediário, mas não dependa das entradas da ACL para proteger seus domínios de intermediário; utilize SSL ou saídas de segurança para assegurar os canais entre componentes no domínio do intermediário. Embora as entradas da ACL permitam ou neguem acesso a um objeto com base no ID do usuário, elas não protegem o objeto, porque uma entrada da ACL não pode verificar a identidade do usuário.

Para reduzir o número de entradas da ACL que um administrador do intermediário deve criar, as permissões da ACL operam de maneira hierárquica. A raiz da árvore é o objeto ConfigManangerProxy. que possui três crianças: RootTopic, Subscriptions e PubSubTopology. O objeto PubSubTopology possui zero ou mais intermediários como filhos e cada intermediário pode ter zero ou mais grupos de execução como filhos. Quando uma entrada da ACL é incluída em um objeto específico, a permissão é concedida a esse objeto e a todos os objetos abaixo dele na hierarquia, a menos que seja substituída por outra entrada da ACL. O diagrama a seguir mostra uma hierarquia de exemplo de entradas da lista de controle de acesso:

Este diagrama mostra uma hierarquia de exemplo. A raiz é CMP, que possui três filhos: RootTopic, Subscriptions e PubSubTopology. PubSubTopology possui dois filhos: Broker1 e Broker2. Cada intermediário possui dois filhos: Eg1A e Eg1B.

Início da mudançaPara obter exemplos que mostram como esta hierarquia funciona na prática, consulte Configurando a Segurança para Componentes de Domínio.Fim da mudança

Para alterar as entradas de controle de acesso para um objeto, um usuário deve ter autoridade Total sobre esse objeto ou qualquer pai na hierarquia. Isto significa que a permissão para alterar as próprias ACLs funciona da mesma maneira que a descrita anteriormente, com a exceção de que o acesso às ACLs não pode ser removido concedendo uma permissão inferior na árvore; isto é necessário porque, de outra maneira, um usuário poderia conceder a ele mesmo uma entrada Visualizar e não poderia removê-la.

No z/OS, você deve definir um segmento OMVS para IDs de usuários e grupos, para que um Configuration Manager possa obter informações sobre o ID do usuário e o grupo a partir do banco de dados do ESM (External Security Manager).

Entradas da ACL e Grupo

Em versões anteriores do WebSphere Message Broker, o acesso aos objetos do tempo de execução era controlado pela definição de um conjunto de grupos e pela designação de usuários a esses grupos. As entradas da ACL permitem que você controle o acesso com maior detalhamento do que nos grupos. As entradas da ACL também permitem que um único Configuration Manager gerencie sistemas de desenvolvimento, teste e produção separadamente, confirmando o acesso dos usuário a cada intermediário. Utilizando grupos, você teria de colocar os sistemas de desenvolvimento, teste e produção em domínios de intermediário separados, cada um controlado por um Configuration Manager separado.

Se você migrar um Configuration Manager de uma versão anterior doWebSphere Message Broker, as entradas da ACL são definidas automaticamente para os seguintes grupos:
  • mqbrkrs
  • mqbrops
  • mqbrdevt
  • mqbrasgn
  • mqbrtpic
Sem essas entradas da ACL, os usuários pertencentes a esses grupos não têm autoridade para executar ações nos objetos do domínio.

Ao utilizar ACLs de usuário único, você deve definir os usuários na estação de trabalho que está acessando os objetos (ou seja, a máquina na qual o Kit de Ferramentas está em execução), mas não é necessário defini-los na estação de trabalho que está executando o Configuration Manager. No entanto, quando estiver utilizando ACLs de Grupo, você deve definir os usuários em ambas estações de trabalho e, em seguida, definir os grupos na estação de trabalho que está executando o Configuration Manager, antes de incluir os usuários nos grupos. Isso é necessário, pois nenhuma informações de grupo é transmitida entre as estações de trabalho.

Conceitos relacionados
Visão Geral de Segurança
Ativando o Configuration Manager no z/OS para Obter Informações do ID do Usuário
Segurança Baseada em Tópico
Tarefas relacionadas
Configurando a Segurança para Componentes de Domínio
Configurando a Segurança no Domínio do Intermediário
Ativando a Segurança Baseada em Tópicos
Cancelando uma Implementação em Andamento
Referências relacionadas
Requisitos de Segurança para Tarefas Administrativas
Comando mqsicreateaclentry
Comando mqsideleteaclentry
Comando mqsilistaclentry
Permissões de ACL
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:12:58

ap01380_