Funções Administrativas e Autorização de Serviço de Nomenclatura
O WebSphere Application Server estende o controle de acesso baseado na função de segurança do Java™ Platform, Enterprise Edition (Java EE) para proteger os subsistemas administrativos e de nomenclatura do produto.
Funções administrativas
Várias funções administrativas foram definidas para fornecer os graus de autoridade necessários para desempenhar algumas funções administrativas do WebSphere Application Server a partir do console administrativo ou da interface de script de gerenciamento de sistemas chamada wsadmin. A política de autorização é aplicada apenas quando a segurança administrativa está ativada. A tabela a seguir descreve as funções administrativas:
Função | Description |
---|---|
Monitor | Um indivíduo ou grupo que utiliza a função de monitor tem a menor quantidade de privilégios. Um monitor pode concluir as seguintes tarefas:
|
Configurador | Um indivíduo ou grupo que utiliza a função de configurador tem o privilégio
de monitor mais a capacidade de alterar a configuração do WebSphere Application Server. O configurador pode executar todas as tarefas de configuração do dia a dia. Por exemplo, um configurador pode concluir as seguintes tarefas:
|
Operador | Uma pessoa ou um grupo que utiliza a função de operador possui privilégios de monitor, além da capacidade de alterar o estado do tempo de execução. Por exemplo, um operador pode concluir as seguintes tarefas:
|
Administrator | Um indivíduo ou grupo que utiliza a função de administrador possui os privilégios de operador e configurador mais privilégios adicionais concedidos somente à função de administrador. Por exemplo, um administrador pode concluir as seguintes tarefas:
Nota:
Um administrador não pode mapear usuários e grupos para a função de administrador. Para obter informações sobre como designar direitos de gerenciamento do repositório federado aos usuários que não foram designados à função de Administrador do WebSphere Application Server, consulte o tópico Mapeando Usuários e Grupos para Funções para Designar Direitos de Gerenciamento do Repositório Federado no tópico Fornecendo Segurança. |
Adminsecuritymanager | Somente os usuários aos quais são concedidos essa função podem mapear usuários para funções administrativas. Além disso, quando a segurança administrativa refinada é utilizada, somente os usuários aos quais essa função é concedida podem gerenciar grupos de autorização. Consulte Funções Administrativas> para obter informações adicionais. |
Implementador | Os usuários aos quais é concedida essa função podem desempenhar ações de configuração e de tempo de execução nos aplicativos. |
Auditor | Os usuários que receberam esta função podem visualizar
e modificar as definições de configuração para o subsistema de auditoria de segurança. Por exemplo, um usuário com a função de auditor pode concluir as seguintes tarefas:
|
Função | Description |
---|---|
iscadmins | Essa função está disponível apenas para
usuários do console administrativo, não para usuários do wsadmin. Os usuários aos quais
é concedida essa função têm privilégios de administrador para gerenciar usuários e grupos nos
repositórios federados. Por exemplo, um usuário da função iscadmins pode concluir as seguintes tarefas:
|
Função | Description |
---|---|
Implementador | Essa função está disponível apenas para usuários do wsadmin, não para usuários do console administrativo. Os usuários aos quais é concedida essa função podem executar ações de configuração e operações do tempo de execução nos aplicativos. |
Quando a segurança administrativa está ativada, o controle de acesso baseado na função do subsistema administrativo é aplicado. O subsistema administrativo inclui o servidor de segurança, o console administrativo, a ferramenta de script wsadmin e todos os MBeans JMX (Java Management Extensions). Quando a segurança administrativa está ativada, o console administrativo e a ferramenta de script administrativa exigem que os usuários forneçam os dados de autenticação necessários. Além disso, o console administrativo é projetado de maneira que as funções de controle que são exibidas nas páginas sejam ajustadas de acordo com as funções de segurança que um usuário possui. Por exemplo, um usuário que tem somente a função de monitor só pode ver dados de configuração não-sensíveis. Um usuário com a função de operador pode alterar o estado do sistema.
Quando você estiver alterando registros (por exemplo, de repositório federado para LDAP), certifique-se de remover as informações relativas ao registro configurado anteriormente para usuários e grupos do console.
Os diálogos de customização de segurança do WebSphere Application
Server para z/OS preparam
o subsistema administrativo para aceitar as identidades do MVS de todas as tarefas do
sistema do WebSphere Application Server iniciadas (por
exemplo, controladores, empregados, etc.) como administradores do WebSphere e a identidade do administrador configurada. Se
um repositório associado, um registro de protocolo LDAP
independente, ou um registro customizado independente for
especificado, as identidades do servidor configurado são utilizadas
para o trabalho que é executado pelo sistema em vez do trabalho que é
executado pelas identidades de tarefa iniciada.
![[z/OS]](../images/ngzos.gif)
![[z/OS]](../images/ngzos.gif)
- O código de tempo de execução do WebSphere Application Server, que é executado na identidade do servidor, exige autorização para algumas operações de tempo de execução. É possível digitar explicitamente a identidade e a senha do servidor ou a identidade pode ser gerada automaticamente. No primeiro caso, a identidade do servidor é um usuário válido no registro. No último caso, utilize o recurso internalServerId para gerar uma identidade de servidor automaticamente. O painel de configuração de cada registro do usuário permite fazer essa escolha. Para um internalServerId, digite o ID do administrador ou adminID no campo Nome do Usuário Administrativo Primário. Esse adminID é um usuário válido no registro e a senha para esse ID não é exigida e não é salva na configuração. Consulte "ID Interno do Servidor" na seção a seguir.
- Se usuários ou grupos explícitos não
forem designados a funções administrativas, você poderá efetuar login no console
administrativo ou na ferramenta de script wsadmin utilizando a identidade do servidor ou adminID
ao utilizar o recurso internalServerId para executar operações administrativas
e para designar outros usuários ou grupos a funções administrativas. Isso é possível
porque a identidade do servidor (ou o adminID) é designada automaticamente para
a função adminsecuritymanager. Apenas os usuários/grupos associados a adminsecuritymanager
podem gerenciar os usuários/grupos para todas as funções administrativas. Depois que você efetua login utilizando
a identidade do servidor (ou adminID), a política de segurança administrativa permite
executar operações, como:
- Alterar o ID e a senha do servidor
- Ativar ou desativar o WebSphere Application Server segurança administrativa
- Aplicar a segurança Java 2 utilizando a opção Utilizar a segurança Java 2 para restringir o acesso do aplicativo a recursos locais.
- Alterar a senha de LTPA ou gerar chaves
- Não é necessária uma configuração especial para ativar a identidade do servidor, conforme especificado, ao ativar a segurança administrativa para uso administrativo, porque a identidade do servidor é mapeada automaticamente para a função de administrador. É possível incluir usuários e grupos ou removê-los das funções administrativas do console administrativo do WebSphere Application Server. No entanto, você deve reiniciar o servidor para que as alterações tenham efeito. Uma boa prática é mapear um grupo, em vez de usuários específicos, para funções administrativas, porque esta abordagem é mais flexível e mais fácil de administrar. No mapeamento de um grupo para uma função administrativa, a inclusão de usuários ou a remoção deles do grupo ocorre fora do WebSphere Application Server e não exige um reinício do servidor para que a alteração seja efetivada.
Quando o segurança administrativa for ativado, os WebSphere Application
Servers serão executados na identidade do servidor definida na configuração do registro do usuário ativo. Embora
ele não seja mostrado no console administrativo e em outras ferramentas, um assunto especial
Server é mapeado para a função de administrador. O código de tempo de execução do WebSphere Application
Server, que é executado na identidade do servidor, exige autorização para operações de tempo de
execução. Se não forem atribuídas funções
administrativa a nenhum outro usuário, será possível conectar-se ao console administrativo
ou à ferramenta de script wsadmin utilizando a identidade do servidor para executar operações
administrativas e para atribuir outros usuários ou grupos a funções administrativas. Como
a identidade do servidor é atribuída à função administrativa por padrão, o critério de
segurança administrativa exige a função administrativa para executar as
seguintes operações:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Alterar o ID e a senha do servidor
- Ativar ou desativar o WebSphere Application Server segurança administrativa
- Aplicar a segurança Java 2 utilizando a opção Utilizar a segurança Java 2 para restringir o acesso do aplicativo a recursos locais.
- Alterar a senha de LTPA ou gerar chaves
- Atribuir usuários e grupos a funções administrativas
- Um usuário administrativo, distinto da identidade do usuário do servidor, para aprimorar a auditabilidade das ações administrativas. O nome de usuário especifica um usuário com privilégios administrativos que é definido no sistema operacional local.
- Distinguir a identidade do servidor da identidade do usuário administrativo para melhorar a auditabilidade. A identidade do usuário do servidor é utilizada para autenticar comunicações entre servidores.
- O ID do servidor interno
permite a geração automática da identidade do usuário para autenticação entre
servidores. A geração automática da identidade do servidor suporta auditabilidade
aprimorada para células apenas para nós da Versão 6.1 ou posterior. No release da Versão
6.1 do WebSphere Application
Server, é possível salvar o ID do servidor gerado internamente, pois o modelo WCCM (Security WebSphere Common
Configuration Model) contém uma nova tag, internalServerId.
Não é necessário especificar um ID do usuário e uma senha do servidor durante a configuração de segurança, exceto em um ambiente de célula mista. Um Id de servidor gerado internamente inclui
um nível adicional de proteção no ambiente do servidor porque a senha do
servidor não é exposta como é em releases anteriores à Versão 6.1. Entretanto,
para manter a compatibilidade com versões anteriores, você deverá especificar o ID do usuário do servidor se utilizar versões anteriores do WebSphere Application Server.
Ao ativar a segurança, é possível designar um ou mais usuários e grupos a funções de nomenclatura. Para obter informações adicionais, consulte Atribuindo Usuários a Funções de Nomes. Entretanto, antes de atribuir usuários a funções de nomes, configure o registro de usuários ativos. A validação de usuários e grupos depende do registro de usuários ativos. Para obter informações adicionais, consulte Configurando Registros de Usuários.
- Possibilidade de mapear um assunto-especial para as funções administrativas. Um assunto especial é uma generalização de uma determinada classe de usuários. Os objetos especiais AllAuthenticated ou AllAuhenticatedInTrustedRealms (quando a região cruzada está envolvida) significa que a verificação de acesso da função administrativa assegura que o usuário que está fazendo o pedido seja pelo menos autenticado. O objeto especial Everyone significa que qualquer um, autenticado ou não, pode desempenhar a ação, como se a segurança não estivesse ativada.
Autorização do Serviço de Nomes
A segurança CosNaming oferece granularidade aprimorada do controle da segurança sobre funções de CosNaming. As funções de CosNaming estão disponíveis nos servidores CosNaming, como o WebSphere Application Server. Essas funções afetam o conteúdo no namespace do WebSphere Application Server. Geralmente, existem duas maneiras nas quais os programas clientes resultam em chamadas de CosNaming. A primeira é por meio da chamada JNDI (Java Naming and Directory Interface). A segunda é com clientes CORBA (Common Object Request Broker Architecture) que chamam métodos CosNaming diretamente.
- CosNamingRead
- CosNamingWrite
- CosNamingCreate
- CosNamingDelete
- CosNamingRead
- É possível consultar o namespace do WebSphere Application Server utilizando, por exemplo, o método de consulta de JNDI. O objeto especial, Everyone, é a política padrão para esta função.
- CosNamingWrite
- É possível executar operações de gravação como JNDI bind, rebind ou unbind e operações CosNamingRead. Como política padrão, os Assuntos não são designados com essa função.
- CosNamingCreate
- É possível criar novos objetos no namespace por meio de operações como operações JNDI createSubcontext e CosNamingWrite. Como política padrão, os Assuntos não são designados com essa função.
- CosNamingDelete
- É possível destruir objetos no espaço de nomes, por exemplo, utilizando o método JNDI destroySubcontext e operações CosNamingCreate. Como política padrão, os Assuntos não são designados com essa função.
Ao configurar um
registro do sistema operacional local com o WebSphere Application Server para z/OS,
os fatores exigirão algumas considerações adicionais. Consulte Selecionando um Registro ou Repositório e Configurando Registros do Sistema Operacional Local para obter informações adicionais.
Se especificar repositórios associados, um registro LDAP
independente, ou um registro customizado independente, você deve remover a customização do sistema
operacional local excluindo o grupo de configuração do WebSphere Application
Server pré-configurado e a identidade de administrador do grupo de
console e excluindo os usuários do console.
Um objeto especial Server é atribuído a todas as quatro funções CosNaming por padrão. O objeto especial do Servidor fornece um processo do WebSphere Application Server, que é executado na identidade do servidor, para acessar todas as operações do CosNaming. O objeto especial Server não é exibido e não pode ser modificado por meio do console administrativo ou de outras ferramentas administrativas.
Não é necessária uma configuração especial para ativar a identidade do servidor, conforme especificado, ao ativar a segurança administrativa para uso administrativo, porque a identidade do servidor é mapeada automaticamente para a função de administrador.
Usuários,
grupos ou os objetos especiais AllAuthenticated e Everyone podem ser incluídos ou removidos das funções
de nomeação do console administrativo do WebSphere Application Server a qualquer momento. No entanto, é necessário iniciar o servidor novamente para que as alterações tenham efeito.
Não é necessária
uma configuração para ativar a identidade do servidor(conforme especificado) ao ativar a segurança administrativa para uso administrativo, porque
a identidade do servidor é mapeada automaticamente para a função de administrador. Usuários,
grupos ou os objetos especiais AllAuthenticated e Everyone podem ser incluídos ou removidos das funções
de nomeação do console administrativo do WebSphere Application Server a qualquer momento. No entanto, é necessário iniciar o servidor novamente para que as alterações tenham efeito. Quando a Autorização do SAF é escolhida, não
é necessário reiniciar o servidor para autorizar usuários ou grupos adicionais.
Uma prática recomendável é mapear grupos ou um dos assuntos especiais, em vez de usuários específicos, para funções de nomes, porque é mais flexível e fácil de administrar a longo prazo. No mapeamento de um grupo para uma função de nomenclatura, a inclusão de usuários ou remoção deles do grupo ocorre fora do WebSphere Application Server e não exige um reinício do servidor para que a alteração seja efetivada.
A política de autorização CosNaming é aplicada somente quando a segurança administrativa está ativada. Quando a segurança administrativa está ativada, tentativas de executar operações CosNaming sem a designação de função apropriada resultarão em uma exceção org.omg.CORBA.NO_PERMISSION no servidor CosNaming.
Cada função
CosNaming é designada a apenas uma função. Portanto, os usuários a quem for atribuída a função
CosNamingCreate não poderão consultar o namespace a menos que também lhes seja
atribuída CosNamingRead. E, na maioria dos casos, um criador precisa ter atribuído três
funções: CosNamingRead, CosNamingWrite e CosNamingCreate. A atribuição das funções CosNamingRead
e CosNamingWrite para o exemplo do criador estão inclusas na
função CosNamingCreate.
Na maioria dos casos, os administradores do WebSphere Application
Server não precisa alterar a designação de funções de cada usuário ou grupo ao movê-los para esse release de um anterior.
Embora exista a capacidade de restringir enormemente o acesso ao namespace pela alteração da política padrão, podem ocorrer exceções org.omg.CORBA.NO_PERMISSION inesperadas no tempo de execução. Geralmente, os aplicativos Java EE acessam o namespace e a identidade que eles utilizam é a do usuário autenticado no WebSphere Application Server ao acessar o aplicativo Java EE. A menos que o provedor de aplicativos do Java EE comunique claramente as funções de nomenclatura esperadas, tenha cuidado ao alterar a política de autorização de nomenclatura padrão.