Migrando a Política de Segurança do Java 2

Utilize este tópico para obter orientação sobre a migração da política de segurança Java™ 2.

Sobre Esta Tarefa

Liberações anteriores do WebSphere Application Server

O WebSphere Application Server usa o gerenciador de segurança Java 2 no tempo de execução do servidor para evitar que os aplicativos corporativos chamem os métodos System.exit e System.setSecurityManager. Essas duas APIs (Interfaces de Programação de Aplicativos) Java têm conseqüências indesejáveis se chamadas por aplicativos corporativos. A API System.exit, por exemplo, faz com que a Java Virtual Machine (processo do servidor de aplicativos) saia prematuramente, o que não é uma operação benéfica para um servidor de aplicativos.

Para suportar a segurança Java 2 apropriadamente, é necessário marcar todo o tempo de execução do servidor como privilegiado (com as chamadas da API doPrivileged inseridas nos locais corretos) e identificar os conjuntos de permissões ou política padrão. O código do aplicativo não é privilegiado e está sujeito às permissões definidas nos arquivos de políticas. A instrumentação doPrivileged é importante e necessária para suportar a segurança Java 2. Sem ela, devem ser concedidas ao código do aplicativo as permissões requeridas pelo tempo de execução do servidor. Essa situação ocorre devido ao design e algoritmo utilizado pela segurança Java 2 para impor verificações de permissão. Consulte o algoritmo de permissão de verificação de segurança Java 2.

As duas permissões a seguir são impostas pelo gerenciador de segurança Java 2 (com código permanente) para WebSphere Application Server:
  • java.lang.RuntimePermission(exitVM)
  • java.lang.RuntimePermission(setSecurityManager)

O código do aplicativo tem o acesso negado para essas permissões, independentemente do que estiver na política de segurança Java 2. No entanto, essas permissões são concedidas no tempo de execução do servidor. Todas as outras verificações de permissões não são utilizadas.

Apenas duas permissões são suportadas:
  • java.net.SocketPermission
  • java.net.NetPermission

No entanto, nem todo tempo de execução do servidor de produtos é marcado corretamente como privilegiado. Você deve conceder ao código do aplicativo todas as outras permissões, além das duas listadas anteriormente ou o aplicativo corporativo terá a probabilidade de falhar na execução. Essa política de segurança Java 2 para aplicativos corporativos é liberal.

O Que Mudou

O Java 2 Security é totalmente suportado no WebSphere Application Server, o que significa que todas as permissões são impostas. A política de segurança Java 2 para um aplicativo corporativo é o conjunto de permissões recomendado definido pela especificação Java EE (Java Platform, Enterprise Edition) Versão 1.4. Consulte o arquivo profile_root/config/cells/cell_name/nodes/node_name/app.policy quanto à política de segurança Java 2 padrão que é concedida para aplicativos corporativos. Essa política é muito mais rigorosa comparada com releases anteriores.

Toda a política é declarativa. O gerenciador de segurança do produto honra todas as políticas declaradas nos arquivos de políticas. Há uma exceção a essa regra: é negado o acesso dos aplicativos corporativos às permissões declaradas no arquivo profile_root/config/cells/cell_name/filter.policy.

Nota: A política de segurança Java 2 padrão para os aplicativos corporativos é muito mais rigorosa e todas as permissões são impostas no WebSphere Application Server Versão 9.0. A política de segurança pode falhar porque o código do aplicativo não possui permissões necessárias concedidas quando os recursos do sistema, como a E/S do arquivo, forem acessados programaticamente e agora estão sujeitos à verificação de permissões.

No código do aplicativo, não utilize a permissão setSecurityManager para definir um gerenciador de segurança. Quando um aplicativo usa a permissão setSecurityManager, há um conflito com o gerenciador de segurança interno no WebSphere Application Server. Se você precisar configurar um gerenciador de segurança em um aplicativo para propósitos de RMI, também deverá ativar a opção Usar Segurança Java 2 para Restringir o Acesso do Aplicativo aos Recursos Locais na página Segurança Global no console administrativo do WebSphere Application Server. O WebSphere Application Server então registra um gerenciador de segurança. O código do aplicativo pode verificar se este gerenciador de segurança está registrado, utilizando a API (Application Programming Interface) System.getSecurityManager().

Migrando propriedades do sistema

As seguintes propriedades de sistema são utilizadas em releases anteriores com relação à segurança Java 2:
  • java.security.policy. O caminho absoluto do arquivo de políticas (ação requerida). Essa propriedade de sistema contém permissões do sistema (permissões concedidas à JVM (Java Virtual Machine) e ao tempo de execução do servidor do produto) e permissões do aplicativo corporativo. Migre a política de segurança Java 2 do aplicativo corporativo para Versão 9.0. Para migração da política de segurança Java 2, consulte as etapas para migrar a política de segurança Java 2.
  • enableJava2Security. Utilizado para ativar a imposição da segurança Java 2 (nenhuma ação é necessária). Essa propriedade de sistema está reprovada; um sinalizador na API (Interface de Programação de Aplicativos) de configuração do WebSphere é utilizado para controlar se a segurança Java 2 deve ser ativada. Ative essa opção por meio do console administrativo.
  • was.home. Expandido para o diretório de instalação do WebSphere Application Server (a ação pode ser necessária). Essa propriedade de sistema tornou-se obsoleta; substituída pelas propriedades ${user.install.root} and ${was.install.root}. Se o diretório contiver dados específicos da instância, então, ${user.install.root} será utilizada; caso contrário, ${was.install.root} será utilizada. Use essas propriedades de forma intercambiável para os ambientes do WebSphere Application Server ou WebSphere Application Server, Network Deployment. Consulte as etapas para migrar a política de segurança Java 2.

Migrando a Política de Segurança Java 2

Não existe uma maneira fácil de migrar o arquivo de políticas Java para Versão 9.0 automaticamente por causa de uma combinação de permissões do sistema e permissões do aplicativo no mesmo arquivo de políticas. Copie manualmente a política de segurança Java 2 de aplicativos corporativos para um arquivo was.policy ou app.policy. Entretanto, é preferível migrar a política de segurança Java 2 para um arquivo was.policy porque os símbolos ou o código base relativo são utilizados no lugar de um código base absoluto. Esse processo possui muitas vantagens. Conceda as permissões que são definidas no was.policy para aplicativo corporativo específico apenas, enquanto as permissões no arquivo app.policy se aplicam a todos os aplicativos corporativos que são executados no nó ao qual o arquivo app.policy pertence.

Consulte o tópico Arquivos de Política de Segurança Java 2 para obter detalhes adicionais sobre o gerenciamento da política.

O exemplo a seguir ilustra a migração da política de segurança Java 2 de um release anterior. O conteúdo inclui o arquivo de política de segurança Java 2 para o aplicativo corporativo app1.ear e as permissões do sistema, que são permissões concedidas à JVM (Java Virtual Machine) e ao tempo de execução do servidor do produto.

[AIX Solaris HP-UX Linux Windows][z/OS]O local padrão para o arquivo de política de segurança Java 2 é profile_root/properties/java.policy. As permissões padrão são omitidas para clareza:

[IBM i]O local padrão para o arquivo de política de segurança Java 2 é profile_root/properties/java.policy. As permissões padrão são omitidas para clareza:

// For product Samples
   grant codeBase "file:${app_server_root}/installedApps/app1.ear/-" {
     permission java.security.SecurityPermission "printIdentity";
     permission java.io.FilePermission "${app_server_root}${/}temp${/}somefile.txt", 
       "read";
   };

Para clareza de ilustração, todas as permissões são concedidas como permissões do nível do aplicativo nesse exemplo. Entretanto, você pode conceder permissões em um nível mais granular no nível de componente (nível de componente JAR (Arquivo de Java) de Web, de enterprise beans, de conector ou de utilitário) ou pode conceder permissões a um componente específico.

Procedimento

  1. Certifique-se de que a segurança Java 2 esteja desativada no servidor de aplicativos.
  2. Crie um novo arquivo was.policy, se ele não existir, ou atualize o arquivo was.policy para aplicativos migrados no repositório de configuração com o seguinte conteúdo:
    grant codeBase "file:${application}" {
         permission java.security.SecurityPermission "printIdentity";
         permission java.io.FilePermission "
                 ${user.install.root}${/}temp${/}somefile.txt", "read";
       };

    A terceira e quarta linhas na amostra de código anterior são apresentadas em duas linhas apenas para fins ilustrativos.

    O arquivo was.policy está localizado no diretório profile_root/config/cells/cell_name/applications/app.ear/deployments/app/META-INF/.

  3. Utilize uma ferramenta de montagem para anexar o arquivo was.policy ao arquivo EAR (Enterprise Archive).

    Você também pode utilizar uma ferramenta de montagem para validar o conteúdo do arquivo was.policy. Para obter informações adicionais, consulte Configurando o Arquivo was.policy para Segurança Java 2.

  4. Valide se o aplicativo corporativo não requer permissões adicionais para as permissões de segurança Java 2 migradas e o conjunto de permissões padrão declarado no arquivo ${user.install.root}/config/cells/cell_name/nodes/node_name/app.policy. Essa validação requer revisão de código, inspeção de código, revisão de documentação de aplicativo e teste de sandbox dos aplicativos corporativos migrados com a segurança Java 2 ativada em um ambiente de pré-produção. Consulte as APIs de Developer Kit protegidas pela segurança Java 2 para obter informações sobre quais APIs estão protegidas pela segurança Java 2. Se você utilizar bibliotecas de terceiros, consulte a documentação do fornecedor quanto às APIs protegidas pela segurança Java 2. Verifique se todas as permissões necessárias foram concedidas para o aplicativo, ou sua execução poderá falhar quando a segurança Java 2 estiver ativada.
  5. Desempenhe o teste de pré-produção do aplicativo corporativo migrado com a segurança Java 2 ativada. Ative o rastreio para o gerenciador de segurança WebSphere Application Server Java 2 em um ambiente de teste de pré-produção com a seguinte sequência de rastreio: com.ibm.ws.security.core.SecurityManager=all=enabled. Essa função de rastreio pode ser útil na depuração da exceção AccessControlException criada quando a permissão requerida não é concedida a um aplicativo ou algum código do sistema não está marcado corretamente como privilegiado. O rastreio faz o dump do rastreio de pilha e das permissões concedidas para as classes na pilha de chamada quando a exceção for criada.

    Para obter informações adicionais, consulte Exceção de Controle de Acesso para Segurança de Java 2.

    Nota: Como a política de segurança Java 2 é muito mais rigorosa em comparação com releases anteriores, o administrador ou implementador deve revisar seus aplicativos corporativos para saber se permissões extras são necessárias, antes de ativar a segurança Java 2. Se os aplicativos corporativos não tiverem as permissões requeridas concedidas, eles falham na execução.

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



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