![[z/OS]](../images/ngzos.gif)
IBM HTTP Server V5.3 para z/OS: Parte 4: Informações Básicas
Vários recursos no IBM® HTTP Server V5.3 para z/OS estão disponíveis no IBM HTTP Server, mas implementados de forma diferente. Saiba mais sobre as principais diferenças na configuração básica dos dois servidores da web.
A parte e os capítulos correspondem aos da publicação número SC34-4826-09 do guia z/OS HTTP Server Planning, Install, and Using para IBM HTTP Server V5.3 for z/OS.
Como Entregar Arquivos
O IBM HTTP Server pode entregar arquivos estáticos ou executar arquivos de script CGI. Estes arquivos podem estar em diretórios padrão ou em diretórios que forem especificados. É possível usar diversas diretivas para entregar estes arquivos. Use a seção Diretório para agrupar as diretivas e especificar que elas se aplicam a um determinado diretório.
Os arquivos estáticos estão no diretório install_root/htdocs por padrão. É possível especificar um diretório alternativo na diretiva de Alias para mapear o diretório alternativo em um prefixo de endereço da web. Em seguida, é possível criar ou copiar uma seção Diretório e fazê-lo apontar para o diretório alternativo. Por exemplo, é possível copiar a diretiva Diretório que especifica o diretório padrão install_root/htdocs e alterar do diretório padrão para o diretório install_root/static.
Os scripts CGI são executados a partir do diretório install_root/cgi-bin/ por padrão. É possível especificar um diretório alternativo na diretiva ScriptAlias para mapear o diretório alternativo em um prefixo de endereço da web. Em seguida, é possível criar ou copiar uma seção Diretório e fazê-lo apontar para o diretório alternativo. Por exemplo, é possível copiar a diretiva Diretório que especifica o diretório padrão install_root/cgi-bin/ e alterar do diretório padrão para o diretório install_root/cgi2.
Para obter mais informações sobre as diretivas, leia a documentação do Apache HTTP Server.
Como Entregar Listagens de Diretórios
Como a diretiva DirectoryIndex está configurada para index.html no arquivo padrão httpd.conf, o IBM HTTP Server entrega o arquivo de índice de diretório do index.html para solicitações de diretório. É possível configurar a diretiva DirectoryIndex para outros arquivos para o IBM HTTP Server entregar. É possível também incluir a diretiva Opções com o argumento Índices em uma seção de Diretório nova ou existente, para que o servidor retorne as informações para esse diretório. Se você incluir um + na frente do argumento Índices, então a seção Diretório herdará argumentos configurados em outras diretivas Opções. Se as diretivas DirectoryIndex e Opções não estiverem configuradas, o servidor da web retornará um erro 403.
Para obter mais informações sobre as diretivas, leia a documentação do Apache HTTP Server.
Como Configurar o Servidor
É possível administrar o IBM HTTP Server apenas adaptando os arquivos de configuração EBCDIC.
O arquivo de configuração padrão do IBM HTTP Server é install_root/conf/httpd.conf. Se deseja revisar ou recuperar os padrões enviados, é possível localizá-los no arquivo install_root/conf/httpd.conf.default.
Arquivos para Backup
- O arquivo de configuração que, por padrão, é o arquivo install_root/conf/httpd.conf
- O arquivo variável de ambiente, que é o arquivo install_root/bin/envvars
- Arquivos Secure Sockets Layer (SSL), tais como os seguintes arquivos:
- Arquivos de bancos de dados principais, que possuem uma extensão kdb
- Arquivos stash, que possuem uma extensão sth
- Arquivos de banco de dados de solicitação, que têm uma extensão rdb
- Arquivos de lista de revogação de certificado, que têm uma extensão crl
- Arquivos de certificados, que possuem uma extensão de suporte
- Saída de comandos como o comando install_root/bin/htpasswd, que pode ser usado para controle de acesso
- Listas de grupos editados à mão
- Qualquer conteúdo entregue em solicitações HTTP, como arquivos HTML, imagens, scripts Java™, folhas de estilo em cascata e scripts CGI
Suporte à Criptografia
O governo dos EUA e os governos fora dos EUA regulam os produtos usados para criptografia e proíbem a sua exportação, a menos que seu tamanho principal seja estritamente limitado. Como o governo dos EUA atualiza as suas leis de exportação e os governos fora dos EUA atualizam suas regras de importação, os comprimentos das chaves suportados e as especificações de códigos podem mudar.
O IBM HTTP Server suporta os códigos SSL listados no tópico Especificações de Cifras SSL.
Criptografia de Hardware
É possível usar a criptografia de hardware para melhorar o desempenho de sessões SSL entre o cliente e o servidor. De longe, o maior ganho em desempenho para o servidor da web é no handshake SSL. O handshake usa chaves assimétricas e funções. O servidor da web utiliza tecnologia RSA para implementar a capacidade assimétrica. Ao implementar o SSL sem criptografia de hardware, as funções assimétricas são muito mais lentas do que as funções simétricas. Assim, ao implementar a criptografia de hardware com o servidor da web, certifique-se de configurar corretamente suas Chaves Mestras. Use o software Integrated Cryptographic Services Facility (ICSF), para que você possa tirar proveito do boost de desempenho. As Chaves Mestras assimétricas não são as mesmas que as chaves RSA do servidor da web.
As especificações de códigos Data Encryption Standard (DES) Triple-DES usam chaves simétricas para manipular a transmissão de dados. A transmissão de dados pode ou não pode ser mais rápida em hardware. Se a transmissão de dados é mais rápida em hardware ou software, vai depender da dimensão do fluxo de dados. O SSL deve estar enviando fluxos relativamente pequenos, geralmente de 4K bytes, ou menos. Fluxos de dados menores tendem a ser mais rápidos em software. Fluxos mid-range podem ser mais rápidos em hardware ou software. Fluxos muito grandes são mais rápidos em hardware.
- O servidor da web usa tecnologia RSA para o handshake SSL. O handshake é um recurso assimétrico e usa pares de chaves RSA público-privadas. É possível gerar chaves RSA em software ou hardware.
- Se você gerar as chaves RSA em software, será possível usar os comandos RACF ou o utilitário gskkyman .
- Defina os comandos RACF para permitir IDs do usuário e o ID do servidor da web para os perfis na classe de recurso geral CSFSERV. A classe de recurso geral CSFSERV controla o uso de software ICSF.
Para obter informações sobre como implementar a criptografia de hardware, leia os manuais apropriados. Por exemplo, leia o z/OS Processor Resource/Systems Management Planning Guide no portal de suporte IBM.. Além disso, é possível ler o z/OS Cryptographic Services ICSF Administrator's Guide e o z/OS Cryptographic Services ICSF System Programmer's Guide, disponíveis no z/OS Internet Library.
Como Verificar se a Criptografia de Hardware É Usada para Criptografia do Servidor da Web.
- Verifique se IDs de usuário e a identificação do servidor da web têm acesso a ICSF.
- Verifique se a tarefa ICSF iniciada está ativa.
- Execute uma ou ambas as seguintes tarefas por meio dos painéis ICSF TSO, para assegurar que o ICSF esteja funcionando corretamente:
- Verifique se o ICSF possui Chaves Mestras PKA definidas.
- Gere uma Chave Mestra PKA com sucesso.
Verificação para Configurar um Servidor Seguro
Para ativar o Transport Layer Security (TLS), use o exemplo de host virtual SSL no arquivo conf/httpd.conf.default. O exemplo contém os elementos necessários para ativar o TLS, incluindo uma diretiva Listen, a diretiva SSLEnable e um módulo mod_ibm_ssl.
Como alterar a Ordem Padrão dos Níveis de Criptografia Utilizados pelo Servidor da Web
É possível usar a diretiva SSLCipherSpec para controlar a ordem dos níveis de criptografia. O IBM HTTP Server sempre aplica a ordem de preferência. Leia sobre a diretiva SSLCipherSpec no tópico das diretivas SSL.
Como Configurar a Proteção para Recursos do Servidor
As etapas a seguir estão no guia z/OS HTTP Server Planning, Install, and Using para IBM HTTP Server V5.3 for z/OS. As informações associadas a cada etapa são as informações necessárias para executar a etapa no IBM HTTP Server.- Etapa 1. Ativar proteção no servidor.
Não há nada a fazer nesta etapa, porque o IBM HTTP Server por padrão carrega os módulos comuns que limitam acesso aos recursos
- Etapa 2. Especificar quais solicitações deseja que o servidor aceite.
Use as seções de configuração para incluir as diretivas de configuração relacionadas à proteção. Leia sobre as seções de configuração na documentação do Apache HTTP Server.
Para obter recursos no Sistema de Arquivos Hierárquicos (HFS), use as diretivas <Directory> e <DirectoryMatch> para anexar as diretivas de proteção. Para outros recursos que não estejam no HFS, como os recursos que os plug-ins servem, use as diretivas <Location> e <LocationMatch>.
- Etapa 3. Decida que opções de proteção utilizar.O IBM HTTP Server oferece uma série de mecanismos diferentes de proteção, a partir dos quais é possível escolher:
- Controle de acesso baseado em host por meio do módulo mod_authz_host. O módulo mod_authz_host permite ou nega endereços IP individuais ou subredes.
- Vários módulos interoperam para fornecer autenticação de ID do usuário e de senha. Esses recursos incluem autenticação básica de HTTP para bancos de dados de arquivos e LDAP; autenticação de compilação HTTP; e autenticação por certificado de cliente SSL.
- Vários módulos interoperam para fornecer autorização. Estes recursos incluem grupos, Lightweight Directory Access Protocol (LDAP) e certificados de clientes SSL.
O servidor processa solicitações ao verificar primeiro o controle de acesso baseado em host. Em seguida, ele verifica a autenticação e o controle de acesso. Se a diretiva Satisfy estiver configurada como any, a solicitação apenas deverá atender aos requisitos de controle de acesso e autorização baseados em host. Qualquer correspondência de uma diretiva de autorização Requerer permitirá acesso. No entanto, não será possível conceder acesso baseado na correspondênciade diversas diretivas Requerer.CUIDADO:É possível usar as diretivas <Limit> e <LimitExcept> para restringir os métodos de proteção para os métodos de solicitação de HTTP individuais, mas teste cuidadosamente esta abordagem. - Etapa 4. Criar configurações de proteção.
É possível verificar as senhas do IBM HTTP Server em relação ao usuário e agrupar arquivos de senhas. No entanto, se desejar verificar as senhas do IBM HTTP Server em relação ao sistema local, especifique a diretiva AuthBasicProvider SAF. Opcionalmente, é possível alterar o ID do usuário do SAF sob o qual uma solicitação é servida especificando a diretiva SAFRunAs.
Se deseja solicitar autenticação de cliente SSL em uma base de host virtual, especifique a diretiva SSLCLientAuth solicitada. Use a diretiva SSLClientAuthRequire para especificar valores de atributos, ou grupos de valores de atributos, que devem ser validados em relação a um certificado de cliente, antes que o servidor permita o acesso ao recurso protegido.
Use os seguintes exemplos para guiá-lo na criação de suas configurações de proteção:
- Controlar o acesso a recursos ao usar a Ordem, permitir e negar
diretivas:
Alias /my-app /opt/my-app/htdocs <Directory /opt/my-app/htdocs> # Allow requests that match the allow directives. Then, deny requests that match the deny directives. # Then, deny requests that do not match the allow or deny directives. Order allow,deny # Allow access only to those users from the local host. Allow from 127.0.0.1 </Directory>
- Controlar o acesso aos recursos usando as diretivas de ordem, permitir e negar. Além disso, use a autenticação básica para que um usuário
forneça um ID e senha de usuário para acessar os recursos. Especifique o
arquivo que contenha os IDs e senhas de usuários.
<Directory /opt/my-app/htdocs/members-only> Order allow,deny Allow from 127.0.0.1 # Add HTTP basic authentication. AuthType Basic AuthBasicProvider file AuthName "Login with your example.com user ID." # Use the htpasswd utility in the <install_root>/bin/htpasswd file to maintain the passwords. # Store the userid and password file in a directory other than the one that it is protecting. AuthUserFile /opt/my-app/users.passwd Require valid-user </Directory>
- Permita somente o ID de usuário de administrador para acessar
os recursos.
<Directory /opt/my-app/htdocs/admin> ... Require user administrator </Directory>
- Permita somente que o grupo de usuários de admins acessem
os recursos. Especifique o arquivo que contenha os grupos de usuários.
<Directory /opt/my-app/htdocs/admin> ... # text file with multiple group-name: member1 member2... lines # Store the group file in a directory other than the one that it is protecting. AuthzGroupFile /auth/groups Require group admins </Directory>
- Permita que o host local host acesse os recursos como se ele fosse um administrador.
<Directory /opt/my-app/htdocs/admin> ... Require group admins Satisfy any Order allow,deny Allow from 127.0.0.1 </Directory>
- Controlar o acesso a recursos ao usar a Ordem, permitir e negar
diretivas:
- Etapa 5. Limite o acesso a arquivos individuais.
É possível limitar os arquivos acessados pelo usuário, aninhando a diretiva <Files> ou <FilesMatch> dentro da diretiva <Directory> ou <DirectoryMatch>.
Regras para Especificar Nomes de Usuários, Nomes de Grupos e Modelos de Endereços
Não é possível permitir acesso com base em uma combinação de nome de usuário e endereço, como bob@192.168.1.1 e steve@192.168.2.2, sem gravar seu próprio módulo Apache para autorização.
Uso de Arquivos de Grupos em Configurações de Proteção
Um arquivo de grupos no IBM HTTP Server é apenas um mapeamento a partir de um nome de grupo para uma lista de usuários. Ele não pode ter definições aninhadas ou incluir especificações de endereço.
Arquivos de Lista de Controle de Acesso
O IBM HTTP Server não possui arquivos de lista de controle de acesso. É possível usar os arquivos .htaccess para limitar o acesso aos recursos. No entanto, evite usar arquivos .htaccess se puder atualizar o arquivo httpd.conf, porque usar arquivos .htaccess deixa o seu servidor mais lento. Como alternativa, inclua diretivas em uma diretiva <Directory> e coloque todas as diretivas no arquivo httpd.conf.