[z/OS]

Segurança SSL (Secure Sockets Layer) do WebSphere Application Server para z/OS

Este tópico presume que você entenda sobre protocolo SSL (Secure Sockets Layer) e como o SSL do sistema de serviços criptográficos funciona no z/OS. SSL é utilizado por vários componentes do WebSphere Application Server para oferecer confiança e privacidade. Esses componentes incluem o transporte HTTP interno, o ORB (Object Request Broker) (cliente e servidor) e o cliente LDAP (Lightweight Directory Access Protocol) seguro. A configuração do SSL é diferente entre cliente e servidor com o WebSphere Application Server. Se você quiser a segurança adicional de comunicações protegidas e autenticação de usuários em uma rede, poderá utilizar a segurança do SSL.

SSL é parte integral da segurança fornecida pelo WebSphere Application Server para z/OS. Ele é ativado quando a segurança administrativa é ativada. Quando o segurança administrativa está ativado, o SSL é sempre utilizado pelo subsistema administrativo para proteger comandos administrativos, o console de administração e as comunicações entre os processos do WebSphere Application Server.

O tempo de execução do WebSphere Application Server para z/OS pode opcionalmente utilizar SSL quando a segurança do servidor está ativada nestes casos:
  • SSL é utilizado para proteger o aplicativo da Web quando a confidencialidade é especificada como uma Restrição de Segurança do Aplicativo da Web. Uma garantia de transporte CONFIDENCIAL ou INTEGRAL garante que a comunicação entre o Web client e o servidor da Web será segura e transportada sobre HTTPS (HTTP SSL). Além disso, você pode utilizar o SSL para executar a autenticação do cliente quando a restrição de segurança (CLIENT_CERT) for especificada durante a implantação do aplicativo.
  • O SSL pode ser utilizado para proteger pedidos IIOP (Inter-ORB Protocol) quando o SSL/TLS é suportado (ou requerido) nas configurações de transporte de CSIv2 (Common Secure Interoperability Versão 2). Essas são configuradas clicando em Segurança > Segurança Global. Em Segurança RMI/IIOP, clique em Transporte de entrada de CSIv2 ou em Transporte de saída de CSIv2.
  • SSL pode ser utilizado para proteger comunicações entre um cliente e um servidor LDAP quando o registro de usuários ativo for LDAP.
Ao configurar o SSL, há dois tipos de repertórios SSL no WebSphere Application Server para z/OS. O tipo de repertório está relacionado aos serviços subjacentes utilizados para processar SSL.
  • JSSE (Java™ Secure Socket Extension) deve ser selecionado como o tipo de repertório SSL para pedidos administrativos utilizando o Conector HTTP/SOAP. Os repertórios JSSE podem (com o APAR PQ77586 aplicado) especificar um anel de chaves do SAF para o armazenamento de chaves ou o armazenamento confiável ou um arquivo HFS (Hierarchical File System).
Nota: Todos os repertórios de configuração do SSL do tipo SSSL (System Secure Sockets Layer), exceto aqueles pertencentes ao daemon, são convertidos no tipo JSSE (Java Secure Socket Extension). Agora o sistema SSL é usado somente pelo Espaço de Endereço do Daemon, visto que o daemon é executado sem uma JVM e o JSSE só é suportado em Java.

Este tópico oferece uma explicação resumida do protocolo SSL e como o SSL funciona no z/OS. Para obter informações sobre o protocolo SSL, acesse o seguinte Web site: http://home.netscape.com/eng/ssl3/ssl-4toc.html

SSL (Secure Sockets Layer) é utilizado por vários componentes do WebSphere Application Server para oferecer confiança e privacidade. Esses componentes são o Transporte HTTP incorporado, o ORB (cliente e servidor) e o cliente LDAP protegido. A configuração do SSL é diferente entre cliente e servidor com o WebSphere Application Server. Se você quiser a segurança adicional de comunicações protegidas e autenticação de usuários em uma rede, poderá utilizar a segurança de SSL. O suporte SSL no WebSphere Application Server para z/OS tem diversos objetivos:
  • Fornecer formas aceitas pelo mercado para proteger a segurança de mensagens conforme elas fluem pela rede. Isto é muitas vezes chamado de segurança da camada de transporte. TLS (Transport Layer Security) é uma função que fornece privacidade e integridade de dados entre dois aplicativos em comunicação. A proteção ocorre em uma camada de software acima do protocolo de transporte de base (por exemplo, acima do TCP/IP).

    O SSL fornece segurança no link de comunicação através de tecnologia de criptografia, assegurando a integridade das mensagens em uma rede. Como as comunicações são criptografadas entre duas partes, uma terceira parte não pode violar as mensagens. O SSL também fornece confidencialidade (assegurando que o conteúdo da mensagem não possa ser lido), detecção de reprodução e detecção de fora de sequência.

  • Fornecer um meio de comunicação seguro através do qual vários protocolos de autenticação possam operar. Uma única sessão SSL pode carregar vários protocolos de autenticação, ou seja, métodos para comprovar as identidades das partes em comunicação.
    O suporte de SSL sempre fornece um mecanismo pelo qual o servidor prova sua identidade. O suporte SSL no WebSphere Application Server para z/OS oferece as seguintes opções para que o cliente prove sua identidade:
    • Autenticação básica (também conhecida como autenticação SSL Tipo 1), na qual um cliente prova sua identidade ao servidor, transmitindo uma identidade e senha de usuário (ou passphrase) conhecidas pelo servidor de destino.
      Com a autenticação básica de SSL:
      • Um cliente z/OS pode se comunicar com segurança com o WebSphere Application Server para z/OS com um ID do usuário e uma senha, conforme definido pelo mecanismo de nome de usuário e senha do CSIv2, GSSUP (Generic Security Services Username Password).
      • Um cliente WebSphere Application Server pode se communicar com segurança com um servidor WebSphere Application Server para z/OS usando um ID do usuário e uma senha MVS (ou passphrase).
      • Como uma senha é sempre exigida em um pedido, somente conexões simples de cliente a servidor podem ser feitas. Ou seja, o servidor não pode enviar o ID de usuário de um cliente a outro servidor para uma resposta a um pedido.
    • Suporte de certificado de cliente, no qual tanto o servidor quanto o cliente fornecem certificados digitais para provar suas identidades um ao outro.

      Quando certificados digitais são fornecidos para autenticação ao WebSphere Application Server para z/OS, o certificado decriptografado é mapeado para uma identidade de usuário válida no repositório do usuário ativado. Os aplicativos de Web podem ter milhares de clientes, o que torna o gerenciamento da autenticação de clientes uma pesada carga administrativa. Quando o sistema operacional local é o repositório do usuário ativado no WebSphere Application Server para z/OS, a filtragem de nome de certificado SAF permite mapear certificados do cliente, sem armazená-los, para IDs de usuário do MVS. Por meio da filtragem de nome de certificado, você pode autorizar conjuntos de usuários a acessar servidores sem a sobrecarga administrativa de criar IDs de usuário do MVS e gerenciar certificados cliente para cada usuário.

    • O suporte de SSL sempre fornece um mecanismo pelo qual o servidor prova sua identidade. Uma variedade de mecanismos podem ser utilizados para provar a identidade do cliente. O protocolo SSL v3 (e TLS) fornece a capacidade para que certificados digitais de clientes sejam opcionalmente trocados. Esses certificados podem ser utilizados para autenticação.
    • Asserção de identidade do CSIv2, que fornece suporte para proprietários do z/OS, nomes distintos X501 e certificados X509.
    • A asserção de identidade, ou associação de confiança, na qual um servidor intermediário pode enviar as identidades de seus clientes a um servidor de destino de uma maneira protegida e, ainda assim, eficiente. Esse suporte utiliza certificados de clientes para estabelecer o servidor intermediário como o proprietário de uma sessão SSL. Através do RACF (Resource Access Control Facility), o sistema pode verificar se o servidor intermediário é de confiança (para conferir esse nível de confiança, a autorização CBIND é concedida pelos administradores aos IDs do RACF que executam código de sistema seguro exclusivamente). Depois que a confiança nesse servidor intermediário é estabelecida, as identidades do cliente (IDs de usuário do MVS) não precisam ser verificadas separadamente pelo servidor de destino; essas identidades do cliente simplesmente são declaradas sem exigir autenticação.
  • Ser interoperável de forma protegida com outros produtos, tais como:
    • CICS (Customer Information Control System) Transaction Server para z/OS
    • Outras versões do WebSphere Application Server
    • Agentes de pedido de objetos compatíveis com CORBA (Common Object Request Broker Architecture)

O SSL está desativado por padrão e o suporte de SSL é opcional. Se você estiver executando o WebSphere Application Server para z/OS com a segurança ativada, o SSL será exigido pelo console administrativo. O Java Secure Socket Extension (JSSE) é do tipo de repertório SSL usado.

Tabela 1. Sequência da Conexão SSL.

Essa tabela descreve como uma conexão SSL funciona.

Estágio Description
Negociação Depois que o cliente localiza o servidor, o cliente e o servidor negociam o tipo de segurança para as comunicações. Se SSL deve ser utilizado, o cliente é instruído a conectar-se a uma porta especial de SSL.
Protocolo de reconhecimento O cliente se conecta à porta SSL e o protocolo de reconhecimento SSL ocorre. Se obtiver êxito, a comunicação criptografada é iniciada. O cliente autentica o servidor, inspecionando o certificado digital do servidor.

Se certificados de cliente forem utilizados durante o protocolo de reconhecimento, o servidor autentica o cliente, inspecionando o certificado digital do cliente.

Comunicação em andamento Durante o protocolo de reconhecimento SSL, o cliente e o servidor negociam uma especificação de cifra a ser utilizada para criptografar as comunicações.
Primeiro pedido do cliente A determinação da identidade do cliente depende do mecanismo de autenticação de cliente escolhido, que é um dos seguintes:
  • ID do usuário e senha CSIv2 (GSSUP)
  • Identidade declarada CSIv2

Regras

  • Um cliente Java ou C++ no z/OS é interoperável com um WebSphere Application Server para z/OS ou um Servidor de Aplicativos de estação de trabalho e pode utilizar SSL. A segurança CSIv2 suporta apenas clientes Java no z/OS.
  • Parte do protocolo de reconhecimento é negociar as especificações criptográficas utilizadas por SSL para proteção de mensagens. Há dois fatores que determinam as especificações de cifra e tamanhos de chaves utilizados:
    • O nível de segurança dos serviços criptográficos instalados no sistema, que determina especificações de cifra e tamanhos de chave disponíveis ao WebSphere Application Server para z/OS.
    • A configuração do servidor por meio do console administrativo permite especificar conjuntos de criptografia SSL.
    Para obter mais informações, consulte z/OS System Secure Sockets Layer Programming.
  • Para soquetes SSL do sistema z/OS, você deve utilizar o RACF ou um equivalente para armazenar certificados digitais e chaves. A colocação de certificados digitais e chaves em um banco de dados de chaves no HFS não é uma opção.
Dica: Para definir a segurança de autenticação básica SSL, é preciso primeiro pedir um certificado assinado para o servidor e um certificado de CA (Autoridade de Certificação) da autoridade de certificação que assinou o certificado do servidor. Depois de ter recebido um certificado assinado para o servidor e um certificado CA da autoridade de certificação, você deve utilizar o RACF para autorizar o uso de certificados digitais, armazenar certificados do servidor e conjuntos de chave do servidor no RACF, criar um alias de repertório SSL e definir propriedades de segurança SSL para o servidor utilizando o console administrativo.

Para clientes, é preciso criar um anel de chaves e anexar a ele o certificado de CA da autoridade de certificação que emitiu o certificado do servidor. Para um cliente z/OS, é necessário utilizar o RACF para criar um conjunto de chaves do cliente e anexar o certificado CA a esse conjunto de chaves. Para o cliente autenticar o servidor, este (na verdade, o ID do usuário do controlador) deve possuir um certificado assinado, criado por uma autoridade de certificação. O servidor transmite o certificado assinado para provar sua identidade ao cliente. O cliente deve possuir o certificado de CA da mesma autoridade de certificação que emitiu o certificado do servidor. O cliente utiliza o certificado da CA para verificar que o certificado do servidor é autêntico. Depois de verificado, o cliente pode ter certeza de que as mensagens estão vindo realmente desse servidor, e não de outra pessoa qualquer. Para o servidor autenticar o cliente, observe que não existe um certificado de cliente que o cliente transmita para provar sua identidade ao servidor. No esquema de autenticação básica de SSL, o servidor autentica o cliente exigindo do cliente um ID de usuário e uma senha (ou passphrase).

Consulte Configurando um Conjunto de Chaves pelo Daemon Secure Sockets Layer para obter informações sobre como criar um conjunto de chaves para o ID do usuário MVS do daemon.


Í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_settingupssl
Nome do arquivo: csec_settingupssl.html