[z/OS]

IBM HTTP Server V5.3 for z/OS : Partie 4 : Configuration de base

De nombreuses fonctions d'IBM® HTTP Server V5.3 for z/OS sont disponibles dans IBM HTTP Server, mais implémentées différemment. Vous allez apprendre quelles sont les différences clés de la configuration de base entre les deux serveurs Web.

Les parties et chapitres correspondent aux parties et chapitres de la publication numéro SC34-4826-09 du manuel z/OS HTTP Server Planning, Install, and Using d'IBM HTTP Server V5.3 for z/OS.

Utilisation des fichiers

IBM HTTP Server peut utiliser des fichiers statiques ou exécuter des fichiers script CGI. Ces fichiers peuvent se trouver dans des répertoires par défaut ou dans des répertoires que vous spécifiez. Vous pouvez utiliser divers directives pour ces fichiers. Utilisez la section Directory pour regrouper les directives et indiquer qu'elles s'appliquent à un répertoire particulier.

Les fichiers statiques se trouvent dans le répertoire install_root/htdocs par défaut. Vous pouvez indiquer un répertoire de remplacement dans la directive Alias afin de le mapper à un préfixe d'adresse Web. Vous pouvez ensuite créer ou copier une section Directory et la faire pointer vers le répertoire de remplacement. Par exemple, vous pouvez copier la directive Directory indiquant le répertoire par défaut install_root/htdocs et passer du répertoire par défaut au répertoire install_root/static.

Les scripts CGI s'exécutent à partir du répertoire install_root/cgi-bin/ par défaut. Vous pouvez indiquer un répertoire de remplacement sur la directive ScriptAlias pour mapper le répertoire de remplacement vers un préfixe d'adresse Web. Vous pouvez ensuite créer ou copier une section Directory et la faire pointer vers le répertoire de remplacement. Par exemple, vous pouvez copier la directive Directory indiquant le répertoire par défaut install_root/cgi-bin/ et passer du répertoire par défaut au répertoire install_root/cgi2.

Pour plus d'informations sur les directives, consultez la documentation sur Apache HTTP Server.

Utilisation de listes de répertoires

La directive DirectoryIndex étant définie sur index.html dans le fichier httpd.conf par défaut, IBM HTTP Server utilise le fichier d'index de répertoire index.html pour les demandes de répertoire. Vous pouvez définir la directive DirectoryIndex dans d'autres fichiers pour utiliser IBM HTTP Server. Vous pouvez également ajouter la directive Options avec l'argument Indexes à la section Directory existante ou à une nouvelle section Directory afin que le serveur Web renvoie des informations pour ce répertoire. Si vous incluez un signe + devant l'argument Indexes, la section Directory hérite d'arguments qui sont définis sur d'autres directives Options. Si aucune des directives DirectoryIndex et Options n'est définie, le serveur Web renvoie une erreur 403.

Pour plus d'informations sur les directives, consultez la documentation sur Apache HTTP Server.

Configuration du serveur

Vous ne pouvez administrer IBM HTTP Server qu'en mettant à jour les fichiers de configuration EBCDIC.

Le fichier de configuration IBM HTTP Server par défaut est install_root/conf/httpd.conf. Si vous souhaitez revoir ou récupérer les valeurs par défaut définies, vous pouvez les consulter dans le fichier install_root/conf/httpd.conf.default.

Fichiers à sauvegarder

Sauvegardez régulièrement les fichiers suivants :
  • Le fichier de configuration (fichier install_root/conf/httpd.conf par défaut)
  • Le fichier de variable d'environnement (fichier install_root/bin/envvars)
  • Les fichiers SSL (Secure Sockets Layer), tels que les fichiers suivants :
    • Les fichiers de clés comportant l'extension kdb
    • Les fichiers de dissimulation comportant l'extension sth
    • Les fichiers de base de données relationnelle comportant l'extension rdb
    • Les fichiers de liste de révocation de certificat comportant l'extension crl
    • Les fichiers certificats comportant l'extension arm
  • La sortie des commandes telles que la commande install_root/bin/htpasswd, que vous pouvez utiliser pour le contrôle d'accès
  • Des listes de groupes éditées manuellement
  • Tout contenu utilisé dans des demandes HTTP, par exemple des fichiers HTML, des images, des scripts Java™, des feuilles de style en cascade et des scripts CGI

Prise en charge du chiffrement

Le gouvernement américain, ainsi que d'autres gouvernements, régulent les produits utilisés pour le chiffrement et interdisent leur exportation tant que la taille des clés n'est pas strictement limitée. Lorsque le gouvernement américain met à jour les lois sur l'exportation et que les autres gouvernements mettent à jour leurs lois sur l'importation, les longueurs de clé et les spécifications de chiffrement prises en charge peuvent changer.

IBM HTTP Server prend en charge les chiffrements SSL répertoriés dans la rubrique Spécifications de chiffrement SSL.

Chiffrement du matériel

Vous pouvez utiliser le chiffrement du matériel pour améliorer la performance des sessions SSL entre le client et le serveur. Le plus important gain de performance pour le serveur est du à l'établissement de liaison SSL. L'établissement de liaison utilise des clés et des fonctions asymétriques. Le serveur Web utilise la technologie RSA pour implémenter la capacité d'asymétrie. Lorsque vous implémentez SSL sans chiffrement du matériel, les fonctions asymétriques sont beaucoup plus lentes que les fonctions symétriques. Par conséquent, lorsque vous implémentez le chiffrement du matériel avec le serveur Web, vérifiez que vos clés principales asymétriques sont correctement configurées. Utilisez le logiciel ICSF (Integrated Cryptographic Services Facility) pour pouvoir tirer avantage de l'augmentation des performances. Les clés principales asymétriques ne sont pas identiques aux clés RSA du serveur Web.

Les spécifications de chiffrement DES (Data Encryption Standard) et DES triple utilisent des clés asymétriques pour gérer la transmission de données. La transmission de données peut être plus rapide dans le matériel, ou pas. La meilleure rapidité de la transmission de données dans le matériel ou les logiciels dépend de la taille du flux de données. SSL doit envoyer des flux de données relativement petits, le plus souvent de 4 Ko ou moins. Les flux de données moins volumineux sont généralement plus rapides dans les logiciels. Les flux de taille moyenne peuvent être plus rapides dans le matériel ou les logiciels. Les flux très volumineux sont plus rapides dans le matériel.

Lorsque vous implémentez le chiffrement du matériel, gardez en mémoire les points suivants :
  • Le serveur Web utilise la technologie RSA pour l'établissement de liaison SSL. L'établissement de liaison est une fonction asymétrique qui utilise des paires de clés publiques/privées RSA. Vous pouvez générer des clés RSA dans des logiciels ou le matériel.
  • Si vous générez les clés RSA dans des logiciels, vous pouvez utiliser des commandes RACF ou l'utilitaire gskkyman.
  • Définissez des commandes RACF pour autoriser des ID utilisateur et l'ID du serveur Web sur des profils dans la classe de ressource générale CSFSERV. La classe de ressource générale CSFSERV contrôle l'utilisation du logiciel ICSF.

Pour plus d'informations sur l'implémentation du chiffrement du matériel, consultez les manuels appropriés. Par exemple, consultez le manuel z/OS Processor Resource/Systems Management Planning Guide sur le portail de support IBM.. Vous pouvez également consulter les manuels z/OS Cryptographic Services ICSF Administrator's Guide et z/OS Cryptographic Services ICSF System Programmer's Guide, disponibles dans la bibliothèque Internet z/OS .

Vérification de l'utilisation du chiffrement du matériel pour le chiffrement du serveur Web

ICSF est l'interface logicielle du matériel de cryptographie. Utilisez la liste de contrôle suivante si vous utilisez le chiffrement du matériel.
  • Vérifiez que les ID utilisateur et l'ID du serveur Web ont un accès à ICSF.
  • Vérifiez que la tâche démarrée d'ICSF est active.
  • Exécutez l'une ou les deux tâches suivantes via les panneaux ICSF TSO pour vous assurer qu'ICSF fonctionne correctement :
    • Vérifiez que des clés principales PKA sont définies dans ICSF.
    • Générez une clé principale PKA.

Liste de contrôle pour la configuration d'un serveur sécurisé

Pour activer TLS (Transport Layer Security), utilisez l'exemple d'hôte virtuel SSL dans le fichier conf/httpd.conf.default. L'exemple contient des éléments requis pour l'activation de TLS, notamment une directive Listen, la directive SSLEnable et un module mod_ibm_ssl.

IBM HTTP Server utilise des fichiers de clés CMS SSL comportant l'extension kdb. Vous pouvez utiliser l'utilitaire gskkyman ou la commande RACF RACDCERT pour créer et administrer un fichier de clés.
Avertissement : Ne partagez pas ces fichiers de clés entre z/OS et des plateformes réparties.

Modification de l'ordre par défaut des niveaux de chiffrement utilisés par le serveur Web

Vous pouvez utiliser la directive SSLCipherSpec pour contrôler l'ordre des niveaux de chiffrement. IBM HTTP Server impose toujours l'ordre de préférence. Consultez la directive SSLCipherSpec dans la rubrique sur les directives SSL.

Configuration du verrouillage pour les ressources du serveur

Les étapes suivantes se trouvent dans le document z/OS HTTP Server Planning, Install, and Using d'IBM HTTP Server V5.3 for z/OS. Les informations associées à chaque étape sont nécessaires à l'exécution de l'étape dans IBM HTTP Server.
  • Etape 1. Activez le verrouillage sur le serveur.

    Aucune action de votre part n'est nécessaire pour cette étape car IBM HTTP Server charge par défaut les modules communs limitant l'accès aux ressources.

  • Etape 2. Indiquez quelles demandes vous souhaitez que le serveur accepte.

    Utilisez des sections de configuration pour inclure des directives de configuration relatives au verrouillage. Consultez les sections sur la configuration dans la documentation Apache HTTP Server.

    Pour les ressources du système hiérarchique de fichiers (HFS), utilisez les directives <Directory> et <DirectoryMatch> pour inclure des directives de protection. Pour les autres ressources ne se trouvant pas dans HFS, telles que celles utilisées par les plug-ins, utilisez les directives <Location> et <LocationMatch>.

  • Etape 3. Décidez quelles sont les options de verrouillage à utiliser.
    IBM HTTP Server offre un certain nombre de mécanismes de verrouillage différents à partir desquels vous pouvez choisir :
    • Un contrôle d'accès basé sur l'hôte via le module mod_authz_host. Le module mod_authz_host autorise ou refuse des adresses IP individuelles ou des sous-réseaux.
    • Différents modules qui interopèrent pour fournir un ID utilisateur et une authentification par mot de passe. Ces fonctions incluent l'authentification de base HTTP pour des bases de données de fichiers et LDAP, l'authentification simplifiée HTTP et l'authentification par certificat client SSL.
    • Différents modules qui interopèrent pour fournir une autorisation. Ces fonctions incluent des groupes, Lightweight Directory Access Protocol (LDAP) et des certificats client SSL.
    Le serveur traite des demandes en commençant par vérifier le contrôle d'accès basé sur l'hôte. Il vérifie ensuite l'authentification et le contrôle d'accès. Si la directive Satisfy est définie sur any, la demande doit seulement répondre aux exigences de contrôle d'accès basé sur l'hôte ou d'autorisation. Toute correspondance d'une directive d'autorisation Require autorise l'accès. Cependant, l'accord de l'accès en fonction de la correspondance de plusieurs directives Require n'est pas possible.
    ATTENTION :
    Vous pouvez utiliser les directives <Limit> et <LimitExcept> pour imposer des méthodes de protection aux méthodes de demande HTTP individuelle (testez précautionneusement cette approche).
  • Etape 4. Créez des configurations de verrouillage.

    Vous pouvez vérifier les mots de passe IBM HTTP Server par rapport aux fichiers de mots de passe utilisateur et groupe. Cependant, si vous souhaitez vérifier les mots de passe IBM HTTP Server par rapport au système local, spécifiez la directive AuthBasicProvider SAF. Si vous le souhaitez, vous pouvez modifier l'ID utilisateur SAF sous lequel une demande est utilisée en spécifiant la directive SAFRunAs.

    Si vous souhaitez demander l'authentification de client SSL sur un hôte virtuel, spécifiez la directive SSLCLientAuth required. Utilisez la directive SSLClientAuthRequire pour spécifier des valeurs d'attribut, ou des groupes de valeurs d'attribut, qui doivent être validées par rapport à un certificat client pour que le serveur autorise l'accès à la ressource protégée.

    Utilisez les exemples suivants pour vous aider à créer vos configurations de verrouillage :

    • Contrôle d'accès aux ressources à l'aide des directives Order, allow et deny :
      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>
    • Contrôle d'accès aux ressources à l'aide des directives order, allow et deny. Utilisez en plus l'authentification de base pour qu'un utilisateur fournisse un ID utilisateur et un mot de passe pour accéder aux ressources. Indiquez le fichier contenant les ID utilisateur et les mots de passe.
      <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>
    • Autorisez uniquement l'ID utilisateur administrator à accéder aux ressources.
      <Directory /opt/my-app/htdocs/admin>
           ...
           Require user administrator
        </Directory>
    • Autorisez uniquement le groupe d'utilisateurs admins à accéder aux ressources. Indiquez le fichier contenant les groupes d'utilisateurs.
      <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>
    • Autorisez l'hôte local à accéder aux ressources en tant qu'administrateur.
        <Directory /opt/my-app/htdocs/admin>
           ...
           Require group admins
           Satisfy any
           Order allow,deny
           Allow from 127.0.0.1
        </Directory>
  • Etape 5. Limitez l'accès aux fichiers individuels.

    Vous pouvez limiter les fichiers auxquels un utilisateur peut accéder en intégrant la directive <Files> ou la directive <FilesMatch> à la directive <Directory> ou à la directive <DirectoryMatch>.

Règles de spécification des noms d'utilisateur, des noms de groupe et des modèles d'adresse

Vous ne pouvez pas autoriser l'accès en fonction de la combinaison d'un nom d'utilisateur et d'une adresse, par exemple bob@192.168.1.1 et steve@192.168.2.2, sans inscrire votre propre module Apache pour l'autorisation.

Utilisation de fichiers de groupe dans des configuration de verrouillage

Un fichier de groupe dans IBM HTTP Server n'est que le mappage d'un nom de groupe vers une liste d'utilisateurs. Il ne peut pas contenir de définitions imbriquées ou inclure des spécifications d'adresse.

Fichiers de listes de contrôle d'accès

IBM HTTP Server ne dispose pas de fichiers de liste de contrôle d'accès. Vous pouvez utiliser des fichiers .htaccess pour limiter l'accès aux ressources. Cependant, évitez d'utiliser ces fichiers si vous pouvez mettre à jour le fichier httpd.conf ; l'utilisation de fichiers .htaccess ralentissant votre serveur. Comme alternative, vous pouvez inclure des directives à une directive <Directory> et placer toutes les directives dans le fichier httpd.conf.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=ihs-dist&topic=rihs_dgwbconfig
Nom du fichier : rihs_dgwbconfig.html