Visão Geral do Planejamento de Segurança

Ao acessar informações na Internet, você se conecta por meio de servidores da Web e de servidores do produto aos dados corporativos no backend. Esta seção examina algumas configurações típicas e práticas comuns de segurança.

Esta seção também examina a proteção de segurança que é oferecida por cada camada de segurança e práticas comuns de segurança para uma boa qualidade de proteção na segurança de ponta a ponta. A figura a seguir ilustra os blocos de construção que compreendem o ambiente operacional para segurança no WebSphere Application Server:

Esta seção também examina a proteção de segurança que é oferecida por cada camada de segurança e práticas comuns de segurança para uma boa qualidade de proteção na segurança de ponta a ponta. A figura a seguir ilustra os blocos de construção que compõem o ambiente operacional para segurança dentro do WebSphere® Application Server

As informações a seguir descrevem cada um dos componentes da segurança do WebSphere Application Server, segurança Java™, e segurança da Plataforma que são ilustrados na figura anterior.
Segurança do WebSphere Application Server
Segurança do WebSphere
A segurança do WebSphere Application Server aplica as políticas e os serviços de segurança de forma unificada no acesso a recursos da Web, enterprise beans e recursos administrativos JMX. Ela consiste em tecnologias e recursos de segurança do WebSphere Application Server para suportar as necessidades de um ambiente corporativo seguro.
Segurança Java
Application programming interface (API) da segurança Java Platform, Enterprise Edition (Java EE)
O colaborador de segurança força as políticas de segurança baseadas em Java Platform, Enterprise Edition (Java EE) e suporta APIs de segurança do Java EE.
Segurança EJB usando Common Secure Interoperability Protocol Versão 2 (CSIv2)
O CSIv2 (Common Secure Interoperability Versão 2) é um protocolo de segurança baseado em IIOP, de três camadas, desenvolvido pelo OMG (Object Management Group). Este protocolo fornece proteção de mensagens, autenticação interoperável e delegação. Os três níveis incluem um nível de segurança de transporte base, um nível de autenticação de cliente suplementar e um nível de atributo de segurança. O WebSphere Application Server para z/OS suporta CSIv2, nível de conformidade 0.
Segurança do Java 2
O modelo Java 2 Security oferece controle de acesso de granularidade fina para recursos do sistema, incluindo sistema de arquivo, propriedade do sistema, conexão de soquete, encadeamento, carregamento de classe, entre outros. O código do aplicativo concede, explicitamente, a permissão requerida para acessar um recurso protegido.
Java Virtual Machine (JVM) 5.0
O modelo de segurança da JVM fornece uma camada de segurança acima da camada do sistema operacional. Por exemplo, a segurança da JVM protege a memória contra acesso irrestrito, cria exceções quando ocorrem erros em um encadeamento e define tipos de matrizes.
Segurança de Plataforma
[AIX Solaris HP-UX Linux Windows][IBM i]Segurança do Sistema Operacional

A infraestrutura de segurança do sistema operacional subjacente fornece determinados serviços de segurança para o WebSphere Application Server. Esses serviços incluem o suporte de segurança do sistema de arquivos que protege arquivos sigilosos na instalação do produto para o WebSphere Application Server. O administrador do sistema pode configurar o produto para obter informações sobre autenticação diretamente do registro do usuário do sistema operacional.

[z/OS]Segurança do Sistema Operacional

A infraestrutura de segurança do sistema operacional subjacente fornece determinados serviços de segurança para o WebSphere Application Server. A identidade do sistema operacional do servidor, controlador e daemon Tarefa Iniciada, conforme estabelecido pelo perfil STARTED, é a identidade que é usada para controlar o acesso aos recursos do sistema, tais como arquivos ou soquetes. Opcionalmente, a segurança do sistema operacional pode fornecer serviços de autenticação utilizando o Registro do Usuário do sistema operacional local e/ou serviços de autorização utilizando Autorização SAF para o console de administração do WebSphere e para aplicativos em execução no servidor de aplicativos.

Além de ter conhecimento sobre Secure Sockets Layer (SSL) e Transport Layer Security (TLS), o administrador deve estar familiarizado com o System Authorization Facility (SAF) e o Resource Access Control Facility (RACF), ou com um produto baseado em SAF equivalente.

A identidade e a verificação de usuários podem ser gerenciadas por meio do uso de um Sistema Operacional Local como o Registro do Usuário, RACF ou produto baseado em SAF equivalente. Alternativamente, é possível utilizar um Registro de Usuário LDAP, Customizado ou Federado.

O WebSphere pode ser configurado para utilizar Autorização SAF, que utilizará RACF ou um produto baseado em SAF equivalente para gerenciar e proteger recursos de usuários e grupos. Alternativamente, o WebSphere pode ser configurado para utilizar Autorização WebSphere ou um Provedor de Autorização Externo JACC.

Ao utilizar Sistema Operacional Local como o Registro do Usuário e/ou Autorização SAF, a auditoria de segurança é um recurso herdado do RACF ou produtos baseados em SAF equivalentes.

Segurança da Rede
As camadas de Segurança da Rede fornecem autenticação de nível de transporte e integridade e sigilo de mensagens. É possível configurar a comunicação entre servidores de aplicativos separados para utilizar SSL (Secure Sockets Layer). Adicionalmente, é possível utilizar a Segurança IP e VPN (Virtual Private Network) para proteção adicional das mensagens.
Instalação do WebSphere Application Server, Network Deployment
Importante: Existe uma instância de agente do nó em cada nó do computador.

Cada servidor de aplicativos de produtos consiste em um contêiner da Web, um contêiner Enterprise Java Beans (EJB) e o subsistema administrativo.

O gerenciador de implementação do WebSphere Application Server contém apenas o código administrativo e o console de administração do WebSphere Application Server.

O console administrativo é um aplicativo da Web especial do Java EE que fornece a interface para a realização de funções administrativas. Os dados de configuração do WebSphere Application Server são armazenados nos arquivos do descritor XML, que devem ser protegidos pela segurança do sistema operacional. Senhas e outros dados de configuração sensíveis podem ser modificados utilizando o Administrative Console. No entanto, é preciso proteger essas senhas e dados sensíveis. Para obter informações adicionais, consulte Codificando as Senhas nos Arquivos.

O aplicativo da Web do console administrativo possui uma restrição de dados de configuração que requer acesso aos servlets do console administrativo e aos arquivos JavaServer Pages (JSP) apenas por meio de uma conexão SSL quando o segurança administrativa estiver ativado.

[AIX Solaris HP-UX Linux Windows][IBM i]No WebSphere Application Server Versão 6.0.x e anterior, a porta HTTPS do console do administrador era configurada para usar DummyServerKeyFile.jks e DummyServerTrustFile.jks com o certificado autoassinado padrão. As chaves e os certificados simulados devem ser substituídos imediatamente após a instalação do WebSphere Application Server; as chaves são comuns em toda a instalação e, portanto, não são seguras. O WebSphere Application Server Versão 6.1 fornece certificado integrado e gerenciamento de chaves, que geram chave privada distinta e certificado autoassinado com nome do host do servidor integrado para possibilitar a verificação do nome do host. O WebSphere Application Server Versão 6.1 também permite a integração com autoridade de certificação (CA) externa para usar certificados emitidos por CA. O processo de instalação de WebSphere Application Servers Versão 6.1 fornece uma opção para possibilitar a segurança administrativa durante a instalação. Como resultado, um processo do WebSphere Application Server é protegido imediatamente após a instalação. O WebSphere Application Server Versão 7.0 estende os recursos de gerenciamento de certificado integrados criando um certificado em cadeias (certificado pessoal assinado por um certificado raiz) para permitir a atualização do certificado pessoal sem afetar a confiança estabelecida. Permite também a adaptação do certificado durante a criação do perfil (você pode importar seu próprio ou alterar o nome distinto (DN) de um criado por padrão) bem como a capacidade de alterar a senha do armazenamento de chaves padrão.

[AIX Solaris HP-UX Linux Windows][IBM i]A figura a seguir mostra um típico ambiente computacional de negócios com várias camadas.Uma instância de agente de nó existe em cada nó do computador. Cada servidor de aplicativos de produto consiste em um contêiner da Web, um contêiner Enterprise Java Beans (EJB) e o subsistema administrativo. O gerenciador de implementação do WebSphere Application Server contém apenas o código administrativo e o console administrativo do WebSphere Application Server.

[z/OS]A figura a seguir mostra um típico ambiente computacional de negócios com várias camadas.Uma instância de agente de nó existe em cada nó do computador. Cada servidor de aplicativos de produto consiste em um contêiner da Web, um contêiner Enterprise Java Beans (EJB) e o subsistema administrativo. O gerenciador de implementação do WebSphere Application Server contém apenas o código administrativo e o console administrativo do WebSphere Application Server.

Segurança Administrativa

[AIX Solaris HP-UX Linux Windows][IBM i]Os WebSphere Application Server interagem uns com os outros por meio dos protocolos CSIv2 e Secure Authentication Services (SAS), bem como os protocolos HTTP e HTTPS.
Importante: SAS é suportado apenas entre servidores Versão 6.0.x e de versões anteriores que foram federados em uma célula Versão 6.1.
[z/OS]Os WebSphere Application Server interagem uns com os outros por meio dos protocolos de segurança CSIv2 e z/OS Secure Authentication Services (z/SAS), bem como os protocolos HTTP e HTTPS.
Importante: O z/SAS é suportado somente entre os servidores Versão 6.0.x e anterior que foram associados a uma célula Versão 6.1.

É possível configurar esses protocolos para usar Secure Sockets Layer (SSL) quando ativar o WebSphere Application Server segurança administrativa. O subsistema administrativo do WebSphere Application Server em cada servidor usa SOAP, conectores Java Management Extensions (JMX) e a Chamada de Método Remoto sobre os conectores JMX Internet Inter-ORB Protocol (RMI/IIOP) para passar comandos administrativos e dados de configuração. Quando a segurança administrativa está desativada, o conector JMX SOAP utiliza o protocolo HTTP e o conector RMI/IIOP utiliza o protocolo TCP/IP. Quando a segurança administrativa está ativada, o conector JMX SOAP sempre utiliza o protocolo HTTPS. Quando a segurança administrativa está ativada, é possível configurar o conector JMX do RMI/IIOP para utilizar SSL ou TCP/IP. Recomenda-se ativar a segurança administrativa e ativar o SSL para proteger os dados de configuração sensíveis.

[z/OS]É possível ativar o HTTPS para aplicativos, mesmo quando a segurança administrativa está desativada. É possível configurar a porta SSL para um determinado servidor incluindo a porta SSL na lista de portas HTTP no contêiner da Web do servidor, além de onde ela é incluída nos hosts virtuais na Configuração do Ambiente. É possível conectar-se ao aplicativo da Web usando HTTPS e a porta correta. A comunicação interna do WebSphere Application Server para z/OS não usa SSL, a menos que você ative o segurança administrativa.

Quando a segurança administrativa está ativada, é possível desativar a segurança do aplicativo em cada servidor de aplicativos individual limpando a opção Ativar Segurança Administrativa no nível do servidor. Para obter informações adicionais, consulte Protegendo Servidores de Aplicativos Específicos. A desativação da segurança do servidor de aplicativos não afeta o subsistema administrativo nesse servidor de aplicativos, que é controlado somente pela configuração de segurança. O subsistema administrativo e o código do aplicativo de um servidor de aplicativos compartilham a configuração opcional do protocolo de segurança por servidor.

Recursos de Segurança do Java EE

Os recursos de segurança para o Java EE são fornecidos pelo contêiner da Web e o contêiner EJB. Cada contêiner fornece dois tipos de segurança: segurança declarativa e segurança programática.

Em segurança declarativa, uma estrutura de segurança de aplicativo inclui integridade e confidência de mensagens da rede, requisitos de autenticação, funções de segurança e controle de acesso. O controle de acesso é expresso em um formulário externo ao aplicativo. Em particular, o descritor de implementação é o principal veículo para segurança declarativa na plataforma Java EE. O WebSphere Application Server mantém a política de segurança do Java EE, incluindo informações que são derivadas do descritor de implementação e especificadas por implementadores e administradores em um conjunto de arquivos do descritor XML. No tempo de execução, o contêiner utiliza a política de segurança definida nos arquivos do descritor XML para aplicar restrições e controle de acesso a dados.

Quando a segurança declarativa por si só não é suficiente para expressar o modelo de segurança de um aplicativo, você pode utilizar a segurança programática para tomar decisões sobre acesso. Quando a segurança administrativa está ativada e a segurança do servidor de aplicativos não está desativada no nível do servidor, a segurança de aplicativos Java EE é forçada. Quando a política de segurança for especificada para um recurso da Web, o contêiner da Web executa o controle de acesso quando o recurso é solicitado por um Web client. O contêiner da Web solicita ao Web client os dados de autenticação se nenhum estiver presente de acordo com o método de autenticação especificado, assegura que as restrições de dados sejam atendidas e determina se o usuário autenticado tem a função de segurança necessária. O colaborador de segurança da Web aplica o controle de acesso com base em função usando uma implementação de gerenciador de acesso. Um gerenciador de acesso toma decisão de autorização com base na política de segurança derivada do descritor de implementação. Um proprietário de usuário autenticado pode acessar o servlet ou arquivo JSP solicitado se o proprietário do usuário tiver uma das funções de segurança requeridas. Os servlets e arquivos JSP podem utilizar os métodos HttpServletRequest, isUserInRole e getUserPrincipal.

[AIX Solaris HP-UX Linux Windows][IBM i]Quando a segurança administrativa e a segurança do aplicativo estiverem ativadas e a segurança do aplicativo no nível do servidor de aplicativos não estiver desativada, o contêiner de EJB aplicará o controle de acesso na solicitação de método EJB.

[z/OS]Quando a segurança no nível de célula estiver ativada, a menos que a segurança do servidor esteja desativada, o contêiner EJB executa o controle de acesso na chamada de método EJB.

A autenticação ocorre, independentemente da permissão de método estar definida para o método EJB específico. O colaborador de segurança EJB utiliza o controle de acesso baseado em função utilizando uma implementação do gerenciador de acesso. Um gerenciador de acesso toma decisão de autorização com base na política de segurança derivada do descritor de implementação. Um usuário autenticado principal pode acessar o método EJB solicitado se tiver uma das funções de segurança requeridas. O código EJB pode utilizar os métodos EJBContext, isCallerInRole e getCallerPrincipal. Utilize o controle de acesso baseado em função do Java EE para proteger dados comerciais valiosos contra o acesso de usuários desautorizados através de Internet e intranet. Consulte Protegendo Aplicativos da Web Usando uma Ferramenta de Montagem e Protegendo Aplicativos de Beans Corporativos.

Segurança Baseada em Função

O WebSphere Application Server estende o controle de acesso com base em função e segurança para recursos administrativos, incluindo o subsistema de gerenciamento de sistemas JMX, registros de usuários e o namespace Java Naming and Directory Interface (JNDI). O subsistema administrativo WebSphere define quatro funções de segurança administrativa:
Função Monitor
Um monitor pode visualizar as informações de configuração e o status, mas não pode fazer nenhuma alteração.
Função Operador
Um operador pode acionar mudanças do estado do tempo de execução, como iniciar um servidor de aplicativos ou parar um aplicativo, mas não pode fazer mudanças na configuração.
Função Configurador
Um configurador pode modificar as informações de configuração, mas não pode alterar o estado do tempo de execução.
Função Administrador
Um operador, bem como um configurador, que pode, adicionalmente, modificar a configuração de segurança e a política de segurança sensíveis, como a configuração de senhas e IDs de servidor, ativar ou desativar a segurança administrativa e a segurança do Java 2, além de mapear usuários e grupos para a função administrativa.
iscadmins
A função iscadmins tem privilégios de administrador para gerenciar usuários e grupos a partir somente do console administrativo.
O WebSphere Application Server define duas funções adicionais que estão disponíveis apenas quando usa o script wsadmin.
Implementador
Um implementador pode executar ações de configuração e operações de tempo de execução nos aplicativos.
Adminsecuritymanager
Um gerenciador de segurança administrativo pode mapear usuários para funções administrativas. Além disso, quando a segurança admin fina é utilizada, os usuários com essa função podem gerenciar grupos de autorização.
Auditor
Um auditor pode visualizar e modificar as definições de configuração para o subsistema de auditoria de segurança.

Um usuário com a função de configurador pode executar a maioria do trabalho administrativo, incluindo a instalação de novos aplicativos e servidores de aplicativos. Existem determinadas tarefas de configuração que um configurador não possui autoridade suficiente para realizar quando a segurança administrativa está ativada, incluindo as modificações de uma identidade e senha do WebSphere Application Server, senha e chaves Lightweight Third-Party Authentication (LTPA) e designação de usuários a funções de segurança administrativa. Essas tarefas sensíveis de configuração exigem a função administrativa porque o ID do servidor é mapeado para a função de administrador.

Ative a segurança administrativa do WebSphere Application Server para proteger a integridade do subsistema administrativo. A segurança do servidor de aplicativos pode ser seletivamente desativada se nenhuma informação sigilosa estiver disponível para ser protegida. Para proteger a segurança administrativa, consulte Autorizando Acesso a Funções Administrativas e Atribuindo usuários e grupos a funções.

Permissões de Segurança Java 2

O WebSphere Application Server usa o modelo de segurança Java 2 para criar um ambiente seguro para executar o código do aplicativo. A segurança Java 2 fornece um controle de acesso de granularidade fina e baseado em política para proteger recursos do sistema como arquivos, propriedades de sistemas, abertura de conexões do soquete, carregamento de bibliotecas, entre outros. A especificação Java EE Versão 1.4 define um conjunto típico de permissões de segurança Java 2 que os componentes da Web e EJB devem ter.

Tabela 1. Permissões de Segurança Java EE Configuradas para Componentes da Web. As permissões de segurança Java EE configuradas para componentes da Web são mostradas na tabela a seguir.
Permissão da Segurança Destino Ação
java.lang.RuntimePermission loadLibrary  
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * conectar
java.io.FilePermission * leitura, gravação
java.util.PropertyPermission * read
Tabela 2. Conjunto de Permissões de Segurança Java EE para Componentes de EJB. As permissões de segurança Java EE configuradas para componentes EJB são mostradas na tabela a seguir.
Permissão da Segurança Destino Ação
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * connect
java.util.PropertyPermission * ler
As políticas padrão de segurança WebSphere Application Server Java 2 são baseadas na especificação do Java EE Versão 1.4. A especificação concede a componentes da Web a permissão de acesso de leitura e gravação de arquivo a qualquer arquivo no sistema de arquivos, o que pode ser muito amplo. A política padrão do WebSphere Application Server fornece a componentes da Web a permissão de leitura e gravação para o subdiretório e a subárvore em que o módulo da Web está instalado. As políticas de segurança padrão Java 2 para todas as Java virtual machines e processos do WebSphere Application Server estão contidos nos seguintes arquivos de políticas:
[IBM i]/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
[IBM i]Utilizado como política padrão para a Java virtual machine (JVM).
[AIX Solaris HP-UX Linux Windows][z/OS]${java.home}/jre/lib/security/java.policy
[AIX Solaris HP-UX Linux Windows][z/OS]Esse arquivo é utilizado como a política padrão para a Java virtual machine (JVM).
[AIX Solaris HP-UX Linux Windows][IBM i]${USER_INSTALL_ROOT}/properties/server.policy
[AIX Solaris HP-UX Linux Windows][IBM i]Este arquivo é utilizado como a política padrão para todos os processos de servidor do produto.
[z/OS]$WAS_HOME/properties/server.policy
[z/OS]Este arquivo é utilizado como a política padrão para todos os processos de servidor do produto.

Para simplificar o gerenciamento de políticas, a política do WebSphere Application Server tem como base o tipo de recurso em vez da base de código (local). Os arquivos a seguir são os arquivos de políticas padrão para um subsistema do WebSphere Application Server. Esses arquivos de políticas, que são uma extensão do tempo de execução do WebSphere Application Server, são chamados de Service Provider Programming Interfaces (SPI) e compartilhados por diversos aplicativos Java EE:

[AIX Solaris HP-UX Linux Windows]
  • profile_root/config/cells/cell_name/nodes/node_name/spi.policy

    Esse arquivo é utilizado para recursos integrados definidos no arquivo resources.xml, como os drivers Java Message Service (JMS), JavaMail e JDBC.

  • profile_root/config/cells/cell_name/nodes/node_name/library.policy

    Esse arquivo é usado pela biblioteca compartilhada definida pelo console administrativo do WebSphere Application Server.

  • profile_root/config/cells/cell_name/nodes/node_name/app.policy

    Esse arquivo é utilizado como a política padrão para aplicativos Java EE.

[z/OS]
  • $WAS_HOME/config/cells/cell_name/nodes/node_name/spi.policy

    Esse arquivo é utilizado para recursos integrados que são definidos no arquivo resources.xml, como os drivers Java Message Service (JMS), JavaMail API e JDBC.

  • $WAS_HOME/config/cells/cell_name/nodes/node_name/library.policy

    Esse arquivo é usado pela biblioteca compartilhada definida pelo console administrativo do WebSphere Application Server.

  • $WAS_HOME/config/cells/cell_name/nodes/node_name/app.policy

    Esse arquivo é utilizado como a política padrão para aplicativos Java EE.

[IBM i]
  • profile_root/config/cells/cell_name/nodes/node_name/spi.policy

    Utilizado para recursos integrados definidos no arquivo resources.xml, como os drivers Java Message Service (JMS), JavaMail e JDBC.

  • profile_root/config/cells/cell_name/nodes/node_name/library.policy

    Usado pela biblioteca compartilhada definida pelo console administrativo do WebSphere Application Server.

  • profile_root/config/cells/cell_name/nodes/node_name/app.policy

    Utilizado como a política padrão para aplicativos Java EE.

Em geral, aplicativos não requerem mais permissões para execução do que as recomendadas pela especificação do Java EE para serem portáteis entre diversos servidores de aplicativos. No entanto, alguns aplicativos podem exigir mais permissões. O WebSphere Application Server suporta o empacotamento de um arquivo was.policy com cada aplicativo para conceder permissões adicionais a esse aplicativo.
Atenção: Conceda permissões extras a um aplicativo somente depois de uma análise cuidadosa, devido à possibilidade de comprometer a integridade do sistema.

O carregamento de bibliotecas no WebSphere Application Server permite que os aplicativos deixem o ambiente de simulação Java. O WebSphere Application Server usa um arquivo de políticas de filtragem de permissões para alertá-lo quando uma instalação de aplicativo falhar em virtude de requisitos de permissão adicionais. Por exemplo, é recomendado não fornecer a permissão java.lang.RuntimePermission exitVM para um aplicativo de modo que o código do aplicativo não possa finalizar o WebSphere Application Server.

A política de filtragem é definida pela máscara de filtro no arquivo profile_root/config/cells/cell_name/filter.policy. Além disso, o WebSphere Application Server também realiza a filtragem de permissões do tempo de execução que tem como base a política de filtragem do tempo de execução para garantir que o código do aplicativo não receba uma permissão considerada prejudicial à integridade do sistema.

Portanto, muitos aplicativos desenvolvidos para releases anteriores do WebSphere Application Server talvez não estejam prontos para a segurança Java 2. Para migrar rapidamente esses aplicativos para a versão mais recente do WebSphere Application Server, é possível fornecer temporariamente a esses aplicativos a permissão java.security.AllPermission no arquivo was.policy. Teste esses aplicativos para garantir que eles sejam executados em um ambiente no qual a segurança Java 2 está ativa. Por exemplo, identifique quais permissões extras, se houver alguma, são requeridas e conceda apenas estas permissões a um aplicativo específico. Não conceder a permissão AllPermission a aplicativos pode reduzir o risco de comprometimento da integridade do sistema. Para obter informações adicionais sobre a migração de aplicativos, consulte Migrando a Política de Segurança do Java 2.

O tempo de execução do WebSphere Application Server usa a segurança Java 2 para proteger funções sensíveis do tempo de execução. Aplicativos que recebem a permissão AllPermission não só podem ter acesso aos recursos sensíveis do sistema, mas também aos recursos de tempo de execução do WebSphere Application Server, além de poderem causar danos a ambos. Em casos em que um aplicativo pode ser confiável como seguro, o WebSphere Application Server suporta a desativação da segurança Java 2 por servidor de aplicativos. É possível forçar a segurança Java 2 por padrão no console administrativo e desmarcar o sinalizador de segurança Java 2 para desativá-lo no servidor de aplicativos específico.

Quando você especifica as opções Ativar Segurança Administrativa e Usar segurança Java 2 para restringir o acesso do aplicativo aos recursos locais no painel Segurança Global do console administrativo, as informações e outros dados de configuração sensíveis são armazenados em um conjunto de arquivos de configuração XML. O controle de acesso baseado em função e o controle de acesso baseado em permissão de segurança Java 2 são empregados para proteger a integridade dos dados de configuração. O exemplo utiliza proteção de dados de configuração para ilustrar como a integridade do sistema é mantida.
Atenção: A opção Ativar segurança global nos releases anteriores do WebSphere Application Server é a mesma que a opção Ativar segurança administrativa no Versão 9.0. Além disso, a opção Ativar Segurança Java 2 em liberações anteriores é a mesma que a opção Usar segurança Java 2 para restringir o acesso do aplicativo aos recursos locais na Versão 9.0.
  • Quando a segurança Java 2 é aplicada, o código do aplicativo não pode acessar as classes do tempo de execução do WebSphere Application Server que gerenciam os dados de configuração, a menos que o código receba as permissões de tempo de execução necessárias do WebSphere Application Server.
  • Quando a segurança Java 2 é aplicada, o código do aplicativo não pode acessar os arquivos XML de configuração do WebSphere Application Server, a menos que código receba a permissão de leitura e gravação de arquivo necessária.
  • O subsistema administrativo JMX fornece SOAP sobre HTTP ou HTTPS e uma interface remota RMI/IIOP para permitir que os programas aplicativos extraiam e modifiquem arquivos e dados de configuração. Quando a segurança administrativa estiver ativada, um programa de aplicativo poderá modificar a configuração do WebSphere Application Server se o programa de aplicativo tiver apresentado dados de autenticação válidos e a identidade de segurança tiver as funções de segurança necessárias.
  • Se um usuário puder desativar a segurança Java 2, o usuário também poderá modificar a configuração do WebSphere Application Server, incluindo a identidade de segurança e os dados de autenticação do WebSphere Application Server com outros dados sensíveis. Somente os usuários com a função de segurança de administrador podem desativar a segurança Java 2.
  • Como a identidade de segurança do WebSphere Application Server é fornecida à função de administrador, apenas usuários com a função de administrador podem desativar a segurança administrativa, alterar IDs e senhas de servidores e mapear usuários e grupos para funções administrativas, entre outras coisas.
[AIX Solaris HP-UX Linux Windows][IBM i]

Outros Recursos de Tempo de Execução

Outros recursos de tempo de execução do WebSphere Application Server são protegidos por um mecanismo semelhante, conforme descrito anteriormente. É muito importante ativar a segurança administrativa do WebSphere Application Server e usar a segurança Java 2 para restringir o acesso do aplicativo aos recursos locais. A Especificação Java EE define diversos métodos de autenticação para componentes da Web: Autenticação Básica HTTP, Autenticação Baseada em Formulário e Autenticação por Certificado de Cliente HTTPS. Ao usar o login de certificado de cliente, é mais conveniente para o cliente do navegador se os recursos da Web tiverem restrição de dados integral ou confidencial. Se um navegador usar HTTP para acessar o recurso da Web, o contêiner da Web redirecionará automaticamente o navegador para a porta HTTPS. O protocolo de segurança CSIv2 também suporta autenticação do certificado do cliente. Você também pode utilizar a autenticação de cliente SSL para configurar a comunicação segura entre um conjunto de servidores selecionado, com base em um relacionamento de confiança.

[z/OS]O protocolo de segurança CSIv2 também suporta autenticação do certificado do cliente. A autenticação de cliente SSL também pode ser utilizada para configurar a comunicação segura entre um conjunto de servidores selecionados com base em um relacionamento confiável.

Se você iniciar a partir do plug-in do WebSphere Application Server no servidor da Web, poderá configurar a autenticação mútua SSL entre ele e o servidor HTTPS do WebSphere Application Server. Ao usar um certificado, é possível restringir o plug-in do WebSphere Application Server para se comunicar somente com os dois WebSphere Application Servers selecionados, conforme mostrado na figura a seguir. Observe que você pode utilizar certificados auto-assinados para reduzir a administração e o custo.
Por exemplo, você deseja restringir o servidor HTTPS no WebSphere Application Serve A e no WebSphere Application Server B para aceitar conexões do soquete seguro somente do plug-in do WebSphere Application Server W.
Por exemplo, você deseja restringir o servidor HTTPS no WebSphere Application Server A e no WebSphere Application Server B a aceitar somente conexões de soquete seguras do plug-in W do WebSphere Application Server.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Para concluir essa tarefa, você pode gerar três certificados usando o IKEYMAN e os utilitários de gerenciamento de certificado. Além disso, é possível usar o certificado W e os certificados de confiança A e B. Configure o servidor HTTPS do WebSphere Application Server A para usar o certificado A e confiar no certificado W.
  • [z/OS]Para concluir essa tarefa, é possível gerar três certificados usando o Resource Access Control Facility (RACF), chamados de certificados W, A e B. Configure o plug-in do WebSphere Application Server para usar o certificado W e os certificados de confiança A e B. Configure o servidor HTTPS do WebSphere Application Server A para usar o certificado A e confiar no certificado W.
Configure o servidor HTTPS do WebSphere Application Server B para usar o certificado B e confiar no certificado W.
Tabela 3. Relacionamentos Confiáveis do Exemplo. O relacionamento confiável descrito na figura anterior é mostrado na tabela a seguir.
Servidor Chave Confiança
Plug-in WebSphere Application Server W A, B
WebSphere Application Server A Uma célula do W
WebSphere Application Server B B W

O WebSphere Application Server Deployment Manager é um ponto central de administração. Os comandos de gerenciamento de sistemas são enviados do Deployment Manager para cada servidor de aplicativos individual. Quando o segurança administrativa estiver ativado, será possível configurar o WebSphere Application Server para requerer SSL e autenticação mútua.

Você talvez deseje restringir o WebSphere Application Server A para que ele possa se comunicar apenas com o WebSphere Application Server C e o WebSphere Application Server B possa se comunicar apenas com o WebSphere Application Server D. Todo o WebSphere Application Server deve poder comunicar-se com o gerenciador de implementação do WebSphere Application Server E; portanto, ao usar certificados autoassinados, você poderá configurar o CSIv2 e a Chave SOAP/HTTPS e o relacionamento confiável, conforme mostrado na tabela a seguir.
Tabela 4. CSIv2 e Chave SOAP/HTTPS e relacionamentos de confiança de exemplo. O CSIv2 e a Chave SOAP/HTTPS e os relacionamentos confiáveis são mostrados na tabela a seguir.
Servidor Chave Confiança
WebSphere Application Server A S C, E
WebSphere Application Server B B D, E
WebSphere Application Server C As A, E
WebSphere Application Server D D B, E
WebSphere Application Server Deployment Manager E E A, B, C, D

Quando o WebSphere Application Server está configurado para usar o registro de usuário Protocolo LDAP, também é possível configurar SSL com autenticação mútua entre cada servidor de aplicativos e o servidor LDAP com certificados autoassinados para que a senha não esteja visível quando for passada do WebSphere Application Server para o servidor LDAP.

Neste exemplo, os processos do agente de nó não são discutidos. Cada agente do nó deve comunicar-se com servidores de aplicativos no mesmo nó e com o Deployment Manager. Os agentes de nó também precisam comunicar-se com os servidores LDAP quando forem configurados para utilizar um registro do usuário LDAP. É razoável permitir que o gerenciador de implementação e os agentes de nó utilizem o mesmo certificado. Suponha que os servidores de aplicativos A e C estejam no mesmo nó de computador. O agente do nó nesse nó precisa ter certificados A e C em seu truststore.

[AIX Solaris HP-UX Linux Windows][IBM i]O WebSphere Application Server não fornece um utilitário de configuração ou gerenciamento de registro. Além disso, ele não determina a política de senha do registro. Recomenda-se utilizar a política de senha sugerida por seu registro, incluindo o comprimento da senha e o período de expiração.


Í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_plan
Nome do arquivo: csec_plan.html