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.

Por exemplo, os usuários podem receber acesso de configurador para uma instância específica de apenas um recurso (um aplicativo, um servidor de aplicativos ou um nó). Os usuários não podem acessar nenhum outro recurso fora dos recursos designados a eles. As funções administrativas agora são por recurso, e não para a célula inteira. No entanto, há um grupo de autorização em toda a célula para compatibilidade com versões anteriores. Os usuários designados a funções administrativas no grupo de autorização da célula ainda podem acessar todos os recursos na célula.
Nota: Os nós anteriores ao WebSphere Application Server Versão 6.1 em um ambiente de célula mista são filtrados fora do mapeamento de 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.

Há vários comandos de segurança administrativa que podem ser utilizados para criar grupos de autorização, mapear recursos para grupos de autorização e designar usuários a funções administrativas nos grupos de autorização. A seguir estão alguns exemplos do uso de wsadmin:
  • 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

Só é possível incluir recursos dos seguintes tipos em um grupo de autorização:
  • Célula
  • 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:

Diagrama do Relacionamento de Restrição

Os privilégios necessários para ações em recursos dependem de dois fatores:
  • 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.

Tabela 1. Privilégios Necessários para Acessar vários Recursos Administrativos. Os privilégios necessários para se acessar vários recursos administrativos são mostrados na seguinte tabela:
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
Reiniciar, parar, sincronizar Operador de nó, operador de célula
Incluir, excluir Configurador de célula
Editar configuração Configurador de nó, configurador de célula
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.

Nota: Nesse caso, é recomendável ter um aplicativo em um grupo e seu servidor de destino em outro grupo. Contudo, isso nem sempre é possível. É comum ter vários aplicativos em um servidor. Algumas vezes, é necessário isolar a administração dos aplicativos que executam no mesmo servidor.

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.

Tabela 2. Aplicativos do Cenário 1 - Função de Implementação.

Esta tabela lista os aplicativos do cenário 1 de Função de implementação.

Aplicativo Servidor
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 a partir de um grupo de autorização G1 para o user1, do grupo de autorização G2 para o user2 e do grupo de autorização G3 para o user3.

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.

Tabela 3. Aplicativos do Cenário 2 - Função de Implementação.

Esta tabela lista os aplicativos do cenário 2 de Função de implementação.

Aplicativo Servidor
A1 S1 N1
A2 S1 N1
A3 S2 N2
A4 S3 N3
No seguinte cenário, um grupo de aplicativos requer as mesmas funções administrativas para um servidor, Neste exemplo, os aplicativos A1 e A2 estão relacionados aos aplicativos e podem ser administrados por um grupo de administradores. Eles estão em execução no mesmo servidor (S1). Os aplicativos A3 e A4 requerem um conjunto diferente de administradores e estão em execução nos servidores S2 e S3 respectivamente.
Cenários que podem ser aplicados diretamente em ambientes do cliente.

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.

Os desenvolvedores devem poder configurar o servidor para que possam depurar quaisquer problemas de execução. Eles devem poder 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).

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 nos servidores dentro do grupo de autorização G1. Além disso, eles podem colocar esse novo aplicativo no grupo de autorização G1.
Cenário do ambiente ASP.

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.

O seguinte diagrama contém um cenário no qual dois clientes diferentes possuem dois tipos diferentes de aplicativos e podem gerenciar seus próprios aplicativos. Porém, os servidores e nós no qual os aplicativos estão em execução são isolados dos seus clientes. Os servidores e nós podem ser mantidos apenas pelos administradores internos, Além disso, os clientes não podem destinar seus aplicativos para um servidor diferente. Isso pode ser feito apenas pelo administrador interno ou pelos implementadores internos.
Cenário da organização regional.

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 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:

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:

O mesmo sistema pode ser configurado de outro modo, conforme descrito abaixo

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

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

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_fineg_admsec
Nome do arquivo: csec_fineg_admsec.html