Segurança do Gerenciador de Tarefas

Em um ambiente de gerenciamento flexível, um ID do usuário deve ter a autorização necessária para usar o gerenciador de tarefa e para trabalhar com nós registrados.

Funções de Segurança Necessárias

São necessárias as seguintes funções para usar o gerenciador de tarefa:

Tabela 1. Funções de Segurança Necessárias para Tarefas do Gerenciador de Tarefa. As funções incluem administrador, operador, configurador e monitor.
Tarefas administrativas Funções de Segurança Necessárias
Registrar ou cancelar registro com o gerenciador de tarefa administrador
Enviar uma Tarefa operador
Alterar a configuração do gerenciador de tarefa configurador
Ler a configuração do gerenciador de tarefa ou o histórico da tarefa Monitor

Se os nós de servidor de aplicativos (independentes) que são gerenciados por um agente administrativo são registrados para um gerenciador de tarefa, são necessárias as seguintes funções para usar o agente administrativo e gerenciar seus nós:

Tabela 2. Funções de Segurança Necessárias para Tarefas do Agente Administrativo. As funções incluem o administrador e as funções necessários para a operação ou o nó.
Tarefas administrativas Funções de Segurança Necessárias
Registrar ou cancelar registro de um nó base (independente) com o agente administrativo administrador
Trabalhar com o agente administrativo: Funções administrativas necessárias para a operação que está sendo executada
Trabalhar com o subsistema administrativo, como nós registrados Funções administrativas necessárias para o nó base registrado

Quando uma tarefa é executada em um destino, o usuário deve ter privilégios que incluam a função requerida para a tarefa. Por exemplo, uma tarefa para criar um servidor de aplicativos requer uma função de configuração mínima no nó base ou na célula do WebSphere Application Server, Network Deployment.

Segurança para Tarefas do Installation Manager ou Liberty em Hosts Remotos

Quando o acesso a um host remoto tal como um Installation Manager ou Liberty requer um nome de usuário e senha, você deve fornecer um nome de usuário e uma senha do sistema operacional válidos para uma tarefa ser executada no host remoto. É possível fornecer os seguintes tipos de autorização:

Nome de Usuário e Senha do Sistema Operacional
O nome de usuário e a senha são os valores de login do host. Se o host não requerer uma senha, não será necessário fornecer uma senha ao submeter uma tarefa.
Sudo
Se desejar que um usuário substituto execute comandos no host, será possível usar sudo para alterar usuários antes de uma tarefa ser executada e, então, especificar o nome de usuário e a senha para o usuário substituto, conforme necessário. sudo significa "substitute user do". Se o host não requerer uma senha, não será necessário fornecer uma senha ao submeter uma tarefa.
Autenticação de Chave Pública-Privada
É possível usar autenticação de chave pública-privada. Ao submeter uma tarefa, especifique o caminho completo para o keystore e, se necessário para o keystore, a passphrase. Uma chave privada de Shell Seguro (SSH) permite que um administrador execute uma tarefa no host remoto sob um nome de usuário específico. A chave é criptografada por senha para evitar o uso por um usuário diferente.

Para servidores de perfil do Liberty, o tipo de autorização usado depende dos nomes de usuário que estão configurados para cada host:

Nome de Usuário Único
Se cada host usar somente um nome de usuário, você deverá assegurar somente que os diretórios para instalar os recursos do Liberty sejam graváveis pelo usuário. Para suportar o envio de tarefa para diferentes hosts, assegure que o mesmo nome de usuário seja configurado em cada host ou use uma chave SSH para autenticar-se como um nome de usuário diferente para cada host.
Alternando para o Nome de Usuário Único
Se os hosts suportarem diversos nomes de usuário, será possível submeter tarefas sob diferentes nomes de usuário, mas usar sudo para alternar para um único nome de usuário comum. Somente o nome de usuário comum pode gerenciar recursos do Liberty. Geralmente este nome de usuário é configurado para desativar o login.
Nomes de Usuário Diferentes
Em algumas configurações, é possível instalar cada recurso do Liberty sob um nome de usuário do sistema operacional diferente. Por exemplo, recursos compartilhados podem ser instalados sob um ou mais nomes de usuário e tornados somente leitura globalmente, ou somente leitura para um grupo de sistema operacional específico. Recursos de trabalho não compartilhados podem ser criados exclusivamente para nomes de usuário differentes.

É possível controlar quem pode instalar os recursos do Liberty controlando as permissões de arquivo do diretório raiz para cada recurso. Se você configurar o diretório como sendo gravável somente por um usuário, somente um usuário poderá instalar nesse diretório. Se você configurar o diretório para ser gravável por um grupo de usuários, os usuários pertencentes a esse grupo poderão instalar recursos sob o diretório raiz. Se o diretório for configurado para ser globalmente gravável, qualquer usuário poderá instalar nesse diretório.

Durante a instalação, é possível configurar permissões de arquivo que evitam que outros usuários modifiquem os recursos. Por exemplo, é possível pré-criar ${WLP_WORKING_DIR}/project1 com permissões de arquivo de forma que ele seja gravável somente por um usuário específico ou um grupo específico. Após o usuário instalar um novo Liberty, tal como server1, será possível configurar ${WLP_WORKING_DIR}/project1/server1 de forma que ele não possa ser alterado por um usuário diferente.

Quando diversos usuários podem acessar recursos, você deve configurar variáveis ou parâmetros da tarefa que permitem que uma tarefa de inventário localize todos os recursos disponíveis:

  • É necessário definir a variável WLP_ADDITIONAL_DIRS para que todos os caminhos relevantes sejam procurados para os recursos ou
  • Você deve assegurar que todos os recursos sejam legíveis pelo nome de usuário que é usado para executar a tarefa de inventário. Os recursos devem ser criados globalmente legíveis, os recursos devem ser um grupo de sistema operacional legível com o nome de usuário pertencente ao grupo, ou o nome de usuário raiz deve ser usado para executar a tarefa de inventário.

Configuração de Segurança Básica

O agente administrativo e o gerenciador de tarefa suportam duas configurações de segurança básicas:

  • Mesmo Domínio de Segurança

    Nessa configuração, todas as células na topologia compartilham o mesmo registro do usuário e, portanto, o mesmo domínio de segurança. O mesmo ocorre com o agente administrativo e seus nós base registrados, e também com qualquer gerenciador de tarefa ou células do WebSphere Application Server, Network Deployment na topologia.

  • Domínios de segurança diferentes

    Nessa configuração, todas as células são configuradas com registros do usuário diferentes e, portanto, domínios de segurança diferentes.

Para a topologia do agente administrativo, quando um usuário efetua login na porta do conector de JMX de um subsistema administrativo ou escolhe o nó registrado a partir do console administrativo, a tabela de autorização para o nó base é utilizada.

Por exemplo, suponha que o User1 seja autorizado como administrador para o primeiro nó base, mas não seja autorizado para o segundo nó. O User2 é autorizado como configurador para o segundo nó, mas não é autorizado para o primeiro nó. A figura Mesmo registro do usuário ilustra esse exemplo:

Mesma configuração de domínio de segurança

Além disso, suponha que o User1 possa efetuar login no gerenciador de tarefa como um operador com um nome do usuário e senha. O User1 também pode efetuar login no gerenciador de implementação como um monitor com um nome do usuário e senha. A figura Registro do usuário diferente ilustra esse exemplo:

Configuração de domínio de segurança diferente

Embora o User1 tenha o mesmo nome de usuário para o gerenciador de tarefa e para o gerenciador de implementação, o User1 provavelmente pode ter diferentes nomes de usuários e senhas.

Transferência de Informações de Segurança

Quando o produto transfere uma tarefa do gerenciador de tarefa para o agente administrativo, gerenciador de implementação ou computador host, ele também transfere as informações de segurança referentes ao requisitante da tarefa. Essa transferência autentica e autoriza o usuário enquanto executa a tarefa. As seguintes informações de segurança do usuário podem ser transmitidas com uma tarefa enviada:

  • Nome do usuário e senha

    Ao enviar uma tarefa, o usuário pode especificar um nome do usuário e senha. Quando a tarefa atinge o subsistema administrativo ou o gerenciador de implementação, o nome do usuário e senha são utilizados para efetuar login.

    Para a mesma configuração de registro do usuário, se John enviar uma tarefa contra o primeiro nó base, ele pode especificar seu nome do usuário e senha como parte da tarefa. O nome do usuário e senha são utilizados para efetuar login contra o primeiro subsistema administrativo e a tarefa é executada. Se John enviar uma tarefa contra a célula do gerenciador de implementação ou o segundo nó base, a tarefa falha porque John não está autorizado.

    Para a configuração do registro do usuário diferente, John pode enviar uma tarefa contra a célula do gerenciador de implementação, especificando seu nome do usuário e senha para a célula do gerenciador de implementação. Quando a tarefa atinge o gerenciador de implementação, o login é bem-sucedido e a tarefa é executada. Se John enviar uma tarefa contra os nós base, o acesso é negado e a tarefa falha.

  • Token de segurança

    Se o usuário não especificar o nome do usuário e senha com uma tarefa, a credencial do usuário é automaticamente persistida como um token de segurança no banco de dados de tarefas. O token contém os atributos de segurança do usuário, incluindo grupos. Quando uma tarefa é capturada, o token é utilizado para autenticar e autorizar administrativo o subsistema administrativo ou o gerenciador de implementação.

    Para a mesma configuração do registro do usuário, John pode enviar uma tarefa contra o primeiro nó base sem especificar o nome do usuário e senha. A tarefa é executada porque a credencial de John é propagada automaticamente como um token de segurança para o subsistema administrativo e usada para autenticar e autorizá-lo para a tarefa. Se John enviar uma tarefa contra o segundo nó base ou a célula do gerenciador de implementação, a tarefa falha porque o seu token de segurança não está autorizado nesses dois ambientes.

    Para a configuração do registro do usuário diferente, um token de segurança não permite automaticamente que a tarefa enviada seja executada contra o subsistema administrativo ou o gerenciador de implementação. Para ativar um token do usuário para um domínio diferente, você deve usar o recurso múltiplo de domínio de segurança. Primeiro, você deve estabelecer o domínio do gerenciador de tarefa como um domínio confiável para os nós base registrados e a célula do gerenciador de implementação. Além disso, você deve importar o ID de Acesso do usuário do gerenciador de tarefa para a tabela de autorizações locais e fornecer ao ID de acesso uma função. Em seguida, o usuário pode enviar uma tarefa sem transmitir o nome do usuário e senha.

    Suponha que John seja um operador no gerenciador de tarefa, mas seu ID de acesso é importado como um administrador na tabela de autorizações administrativas do primeiro nó base. Embora John não exista no registro do usuário do nó base, transmitindo o token de segurança e a definição de tabela de autorizações administrativas, John é autorizado como um administrador no nó base. John pode enviar uma tarefa para o primeiro nó base sem precisar especificar um nome de usuário ou senha.

    Se John enviar uma tarefa contra o gerenciador de implementação, a tarefa falha. O token de segurança de John é do domínio do gerenciador de tarefa e o ID de acesso de John não foi autorizado para o gerenciador de implementação. Nesse caso, o administrador pode exportar o ID de acesso de John a partir do gerenciador de tarefa e importá-lo para o gerenciador de implementação. Ou, John pode enviar uma tarefa transmitindo o nome do usuário e senha que tinha com o gerenciador de implementação, o que permite que John execute tarefas com a função monitor.

    O mesmo mecanismo funciona se o recurso de segurança de baixa granularidade estiver em uso. Você deve estar autorizado na tabela de autorizações para um novo grupo de autorização. A tabela de autorizações também pode conter um ID de acesso externo.

Configuração do Registro Misto

Em uma topologia mais complexa, em que algumas células compartilham o mesmo registro do usuário e algumas células não, as seguintes regras se aplicam:

  • É sempre possível especificar um nome do usuário e senha durante o envio da tarefa se o nó de destino ou o gerenciador de implementação reconhecer seu nome do usuário e senha.
  • Se o gerenciador de tarefa e o nó de destino ou o gerenciador de implementação têm o mesmo registro do usuário, o envio da tarefa não requer um nome do usuário e senha. No entanto, você deve estar autorizado para o nó de destino ou gerenciador de implementação.
  • Se o gerenciador de tarefa e o nó de destino ou o gerenciador de implementação possuem registros do usuário diferentes, domínios confiáveis foram estabelecidos e o ID de acesso do submissor da tarefa foi importado na tabela de autorizações administrativas do nó de destino ou gerenciador de implementação; assim, o envio da tarefa não requer um nome do usuário e senha.

Í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=cagt_jobmgr_security
Nome do arquivo: cagt_jobmgr_security.html