Segurança Administrativa Refinada
Em liberações ao WebSphere Application Server versão 6.1, usuários com concessão de funções administrativas podiam administrar todos os recursos sob a célula. O WebSphere Application Server agora tem granularidade mais baixa, o que significa que o acesso pode ser concedido a cada usuário por recurso.
Para obter esta segurança baseada em instância ou segurança de baixa granularidade, os recursos que requerem os mesmos privilégios são colocados em um grupo chamado de grupo de autorização administrativa ou grupo de autorização. Os usuários podem receber acesso ao grupo de autorização designando a eles a função administrativa requerida.
A segurança administrativa refinada também pode ser utilizada em ambientes de servidor único. Vários aplicativos no servidor único podem ser agrupados e colocados em grupos de autorização diferentes. Portanto, há restrições de autorização diferentes para aplicativos diferentes. Observe que o próprio servidor não pode fazer parte de nenhum grupo de autorização em um ambiente de servidor único.
É possível designar usuários e grupos à função adminsecuritymanager no nível de célula por meio de scripts wsadmin e do console administrativo. Usando a função adminsecuritymanager, é possível designar usuários administrativos e grupos às funções administrativas e às funções de grupo administrativo.
Quando a segurança administrativa refinada for utilizada, os usuários com a função adminsecuritymanager poderão gerenciar grupos de autorização. Consulte Funções Administrativas e Autorização de Serviço de Nomenclatura para obter explicações detalhadas de todas as funções administrativas.
Um administrador não pode designar usuários e grupos às funções de usuário administrativo e de grupo administrativo, incluindo a função adminsecuritymanager. Consulte Funções Administrativas> para obter detalhes adicionais.
- Crie um novo grupo de autorização:
$AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}
- Excluindo um grupo de autorização:
$AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}
- Inclua recursos em um grupo de autorização:
$AdminTask addResourceToAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- Remova recursos de um grupo de autorização:
$AdminTask removeResourceFromAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- Inclua IDs do usuário em funções em um grupo de autorização:
$AdminTask mapUsersToAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- Inclua IDs do grupo em funções em um grupo de autorização:
$AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
- Remova IDs do usuário de funções em um grupo de autorização:
AdminTask removeUsersFromAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- Remova IDs do grupo de funções em um grupo de autorização:
$AdminTask removeGroupsFromAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
Recursos que podem ser incluídos em um grupo de autorização
- Célula
- Nó
- ServerCluster
- Servidor
- Aplicativo
- NodeGroup
Se um recurso não for um dos tipos listados anteriormente, seu recurso pai será usado.
Um recurso só pode pertencer a um grupo de autorização. No entanto, há um relacionamento de restrição entre os recursos. Se um recurso pai pertencer a um grupo de autorização diferente daquele do recurso-filho, o recurso-filho pertencerá implicitamente a diversos grupos de autorização. Não é possível incluir o mesmo recurso em mais de um grupo de autorização.
O diagrama a seguir mostra o relacionamento de restrição entre os recursos:
- O grupo de autorização do recurso administrativo. Se um usuário receber acesso a um grupo de autorização, todos os recursos nesse grupo estarão incluídos.
- O relacionamento de restrição do recurso. Se um usuário receber acesso a um recurso pai, todos os recursos-filhos estarão incluídos.
O gerenciamento de armazenamento de chaves requer que um usuário tenha privilégios administrativos em nível de célula porque eles são criados e gerenciados no nível da célula. O acesso à segurança de granularidade fina a um recurso específico não permite o gerenciamento dos armazenamentos de chaves associados.
Recurso | Ação | Funções requeridas |
---|---|---|
Servidor | Operações de início, de parada, de tempo de execução | Operador de servidor, operador de nó, operador de célula |
Servidor | Novo, excluir | Configurador de nó, configurador de célula |
Servidor | Editar configuração | Configurador de servidor, configurador de nó, configurador de célula |
Servidor | Visualizar configuração, status do tempo de execução | Monitor de servidor, monitor de nó, monitor de célula |
Nó | Reiniciar, parar, sincronizar | Operador de nó, operador de célula |
Nó | Incluir, excluir | Configurador de célula |
Nó | Editar configuração | Configurador de nó, configurador de célula |
Nó | Visualizar configuração, status do tempo de execução | Monitor de nó, monitor de célula |
Cluster | Operações de início, de parada, de tempo de execução | Operador de cluster, operador de célula |
Cluster | Novo, excluir | Configurador de célula |
Cluster | Editar configuração | Configurador de cluster, configurador de célula |
Cluster | Visualizar configuração, status do tempo de execução | Monitor de cluster, monitor de célula |
Membro de cluster | Operações de início, de parada, de tempo de execução | Operador de servidor, operador de cluster, operador de nó, operador de célula |
Membro de cluster | Novo, excluir | Configurador de nó, configurador de célula |
Membro de cluster | Editar configuração | Configurador de servidor, configurador de cluster, configurador de nó, configurador de célula |
Membro de cluster | Visualizar configuração, status do tempo de execução | Monitor do servidor, monitor do cluster, monitor do nó, monitor da célula |
Aplicativo | Todas as operações | Consulte a seção "Funções do implementador" em Funções Administrativas>. |
Nó, cluster | Incluir, excluir | Configurador de célula |
A função de operador do servidor é a função de operador do grupo de autorização do qual a instância do servidor faz parte. De modo semelhante, a função de operador de nó está na função de operador do grupo de autorização do qual a instância do nó faz parte.
Para utilizar a segurança administrativa refinada no console administrativo, um usuário deve receber uma função de monitor no nível de célula, no mínimo. No entanto, para efetuar login utilizando wsadmin, um usuário deve receber uma função de monitor para qualquer grupo de autorização.
Exemplo: Utilizando a segurança de baixa granularidade.
Os cenários a seguir descrevem a utilização da segurança administrativa rígida, principalmente a nova função de implementação.
Cenário de função de implementação 1.No cenário a seguir, há quatro aplicativos configurados no servidor S1, conforme mostrado na seguinte tabela. Cada aplicativo deve ser isolado de modo que o administrador de um aplicativo não possa modificar outro aplicativo. Suponhamos que apenas o user1 possa gerenciar o aplicativo A1, o user2 possa gerenciar os aplicativos A2 e A3, e apenas o user3 possa gerenciar aplicativo A4.
Um exemplo é um ASP (Application Service Provider), em que um único servidor de aplicativos pode ter aplicativos de vários fornecedores. Nessa instância, o administrador do servidor é responsável para instalar todos os aplicativos do fornecedor. Uma vez instalados os aplicativos, cada fornecedor pode gerenciar seu próprio aplicativo sem interferir com aplicativos de outros fornecedores.
Aplicativo | Servidor | Nó |
---|---|---|
A1 | S1 | N1 |
A2 | S1 | N1 |
A3 | S1 | N1 |
A4 | S1 | N1 |
Podemos configurar grupos de autorização conforme mostrado no diagrama a seguir:

No diagrama, o aplicativo A1 está no grupo de autorização G1, os aplicativos A2 e A3 estão no grupo de autorização G2, e o aplicativo A4 está no grupo de autorização G3.
Uma função do implementador é designada do grupo G1 para o user1, do grupo de autorização G2 para user2 e do grupo de autorização G3 para user3.
Conseqüentemente, o user1 pode executar todas as operações no aplicativo A1, o user2 nos aplicativos A2 e A3, e o user3 no aplicativo A4. Visto que todos os aplicativos compartilham o mesmo servidor, não é possível colocar o mesmo servidor em todos os grupos de autorização. Apenas um administrador do nível de célula pode instalar um aplicativo. Depois da conclusão de um aplicativo, o implementador de cada aplicativo pode modificar seu próprio aplicativo. Para iniciar e parar o servidor, a autoridade administrativa de nível de célula é obrigatório. Esse tipo de cenário é útil em um ambiente ASP.
Cenário da função de implementação 2.No cenário a seguir, um grupo de aplicativos requer as mesmas funções administrativas que um servidor. Neste exemplo, os aplicativos A1 e A2 são aplicativos relacionados, e podem ser administrados por um conjunto de administradores. Estão executando no mesmo servidor (S1). Os aplicativos A3 e A4 requerem um conjunto de administradores diferente, e estão executando em servidores S2 e S3, respectivamente.
Aplicativo | Servidor | Nó |
---|---|---|
A1 | S1 | N1 |
A2 | S1 | N1 |
A3 | S2 | N2 |
A4 | S3 | N3 |

Cada desenvolvedor deve ser capaz de modificar a configuração do servidor e de instalar seu aplicativo nesse servidor. Eles também iniciam e param o servidor além do aplicativo no servidor.
Os desenvolvedores devem ser capazes de configurar o servidor de modo que possam depurar quaisquer problemas que enfrentarem. Eles devem ter a capacidade de atualizar ou modificar o aplicativo que está sendo desenvolvido. O grupo de autorização administrativo desse desenvolvedor inclui, pelo menos, um servidor e qualquer aplicativo que o desenvolvedor venha a instalar nele.

No exemplo a seguir, os desenvolvedores do grupo de autorização G1 têm um novo aplicativo (A11). Eles podem instalar e destinar esse novo aplicativo apenas em servidores dentro do grupo de autorização G1. Além disso, eles podem colocar o novo aplicativo no seu grupo de autorização (G1).

Nesse cenário, o cliente é um ASP. Eles têm seus próprios clientes para quem fornecem a função de manutenção de aplicativo. Desejam ativar seus clientes para administrar e monitorar seus aplicativos, mas não para consultar ou administrar aplicativos para clientes diferentes. Nesse exemplo, contudo, o ASP tem administradores de equipe internos cuja tarefa é manter os servidores.
Pode ser necessário esse administrador de equipe ASP para mover um aplicativo de um servidor para outro, no intuito de garantir a disponibilidade de um aplicativo. O administrador interno de equipe ASP deve ser capaz de parar e iniciar os servidores, e de alterar sua configuração.
Em contraste, o administrador de cliente ASP não deve ser capaz de parar ou iniciar servidores. Contudo, o administrador de cliente ASP deve ser capaz de atualizar os aplicativos em execução nesses servidores. O grupo de autorizações administrativas do administrador interno ASP pode ser toda a célula ou incluir um subconjunto de servidores, nós, clusters e aplicativos. O grupo de autorizações administrativas do administrador do cliente inclui apenas aqueles aplicativos pagos pelo cliente para serem atendidos por esse ASP.
Quando atualizar o repositório de configuração, execute os scripts admin do gerenciador de implementação para que as regras rígidas de segurança admin estejam em vigor quando scripts admin forem executados do lado do gerenciador de implementação.
O diagrama a seguir contém um cenário no qual dois clientes diferentes possuem dois tipos diferentes de aplicativos e podem gerenciar seus próprios aplicativos. Contudo, os servidores e nós nos quais os aplicativos estão em execução são isolados de seus clientes. Os servidores e nós podem apenas ser mantidos por administradores internos. Além disso, os clientes não podem destinar seus aplicativos em um servidor diferente. Isso pode ser executado pelo administrador interno ou implementadores internos.

Nesse cenário, o cliente é uma empresa global de grande porte. Os nós e servidores da empresa são organizados de modo a prover o serviço dos aplicativos para diferentes regiões (ou, alternativamente, para diferentes linhas de negócios). Eles querem que os representantes de diferentes áreas regionais sejam capazes de monitorar e administrar os nós e servidores associados a tal região. Contudo, eles não querem que o administrador regional seja capaz de influenciar qualquer nó e servidor associado a uma região diferente.
O grupo de autorização administrativa para cada representante regional inclui nós, servidores, clusters e aplicativos associados a essa região.
Por exemplo, considere uma empresa que forneça vários serviços, por exemplo, uma instituição financeira que forneça serviços como contas de cartão de crédito, contas de corretagem, contas bancárias ou contas de viagem. Cada um desses serviços podem ser aplicativos separados, e o administrador de cada um dos aplicativos também deve ser diferente. A figura a seguir mostra um modo para configurar, por exemplo, um sistema:

A figura a seguir mostra como os recursos nesse sistema podem ser agrupados para isolar administradores uns dos outros:

Observe se os nós não são integrantes de algum grupo de autorizações. Assim, um administrador de aplicativo comercial não pode parar um servidor em qualquer um dos nós, e é impedido de parar um aplicativo de viagem.
O mesmo sistema pode ser configurado de uma outra maneira, conforme a seguir:

A figura a seguir mostra como os recursos nesse sistema podem ser agrupados para isolar administradores uns dos outros:
