Sécurité de la collectivité

Vous pouvez utiliser les principes de sécurité de collectivité dans Liberty pour traiter les données en cours de déplacement et les données au repos.

Les deux zones principales de la sécurité de collectivité sont :
  • Configuration de la sécurité du domaine d'administration

    Traitement de données en mouvement, authentification et autorisation

  • La sécurité des données du référentiel de collectivité

    Traitement de données au repos, en phase d'authentification et d'autorisation

Configuration de la sécurité du domaine d'administration
La configuration de la sécurité du domaine d'administration est composée de deux parties :
  • Le domaine utilisateur

    Ce domaine s'appuie sur la sécurité basée sur les rôles Java™ qui définit le rôle Administrateur. Ce type de sécurité peut être mappé à des utilisateurs dans le registre utilisateurs configuré.

  • Le domaine de serveur

    Ce domaine s'appuie sur l'authentification par certificat SSL.

Pour que les utilisateurs puissent accéder aux beans gérés du contrôleur de collectivité, ils doivent être associés au rôle Administrateur. Toutes les actions d'administration effectuées via la collectivité requièrent que le rôle Administrateur soit affecté à l'utilisateur. Voir Configuration d'une connexion JMX sécurisée à Liberty pour des détails complets.

La communication de serveur à serveur dépend du domaine de serveur et, par conséquent, les identités d'utilisateur et les mots de passe ne sont pas utilisés pour la communication entre les membres d'une collectivité. Chaque membre de la collectivité détient une identité unique dans la collectivité, composée de son nom d'hôte, du répertoire utilisateur et du nom du serveur. Chaque membre de la collectivité définit sa configuration de domaine de serveur, constituée des fichiers serverIdentity.jks et collectiveTrust.jks. Ces fichiers contiennent les certificats SSL qui sont nécessaires pour établir la communication sécurisée dans la collectivité. La configuration de clé HTTPS doit comporter des paramètres de confiance qui sont établis par défaut.

Vous pouvez personnaliser la configuration SSL du domaine de serveur en ajoutant des entrées de certificat sécurisé au fichier de clés collectiveTrust.jks. Toutes les données sécurisées étant copiées lorsqu'un contrôleur est répliqué, la personnalisation SSL doit être appliquée au contrôleur initial. L'ajout de données sécurisées au fichier de clés collectiveTrust.jks n'est nécessaire que si les certificats HTTPS par défaut ne sont pas utilisés. Si la configuration SSL HTTPS est modifiée, les règles de certificat suivantes s'appliquent :
  • La confiance HTTPS doit être établie par tous les contrôleurs et membres de la collectivité. Si les certificats SSL HTTPS sont modifiés, les signataires racine du contrôleur de collectivité doivent être ajoutés au fichier de clés certifiées SSL HTTPS :
    • Le signataire controllerRoot qui se trouve dans le fichier de clés rootKeys.jks doit être ajouté au fichier de clés certifiées SSL HTTPS de tous les membres de la collectivité.
    • Le signataire controllerRoot et le signataire memberRoot qui se trouvent dans le fichier de clés rootKeys.jks doivent être ajoutés au fichier de clés certifiées SSL HTTPS de tous les contrôleurs de collectivité.
  • Chaque membre peut établir une connexion sortante vers un contrôleur de collectivité. Le magasin de clés  collectiveTrust.jks du contrôleur de collectivité doit contenir une chaîne de certificat qui fait confiance au certificat SSL HTTPS pour chaque membre. Il est fortement recommandé que tous les certificats HTTPS soient signés par un signataire racine, qui peuvent ensuite être ajoutés au magasin de clés collectiveTrust.jks. L'utilisation de certificats SSL individuels dépourvus de signataire racine commun est suffisante pour établir la relation de confiance mais sans mise à l'échelle.
  • Chaque contrôleur peut établir une connexion sortante vers un membre de collectivité. Le magasin de clés  collectiveTrust.jks du membre de collectivité doit contenir une chaîne de certificat qui fait confiance au certificat SSL HTTPS pour chaque contrôleur. Il est fortement recommandé que tous les certificats HTTPS soient signés par un signataire racine, qui peuvent ensuite être ajoutés au magasin de clés collectiveTrust.jks. L'utilisation de certificats SSL individuels dépourvus de signataire racine commun est suffisante pour établir la relation de confiance mais sans mise à l'échelle.
La communication de serveur à serveur requiert la prise en charge de l'authentification SSL. Si la configuration SSL HTTPS est personnalisée, la configuration SSL doit spécifier clientAuthenticationSupported="true". Exemple :
<!-- clientAuthenticationSupported set to enable bidirectional trust -->
    <ssl id="defaultSSLConfig"
         keyStoreRef="defaultKeyStore"
         trustStoreRef="defaultTrustStore"
         clientAuthenticationSupported="true" />

La configuration clientAuthentication="true" sur le contrôleur de collectivité n'est pas recommandée car elle empêche certains comportements communs attendus. Par exemple, cette configuration empêche l'authentification avec les noms d'utilisateurs et les mots de passe dans le Centre d'administration ainsi que les utilitaires de ligne de commande de la collectivité.

La configuration clientAuthentication="true" sur un membre de collectivité peut être souhaitable pour empêcher les connexions via un nom d'utilisateur et un mot de passe. Cette configuration n'interrompt pas les opérations de la collectivité car toutes les opérations venant du contrôleur sont authentifiées à l'aide du certificat.

Les membres doivent être empêchés de publier des informations au contrôleur de la collectivité via le bean géré CollectiveRegistration. Les méthodes d'interdiction et d'autorisation empêchent ou autorisent respectivement l'authentification.

La sécurité des données du référentiel de collectivité

La stratégie de sécurité des données du référentiel de collectivité couvre les données au repos, notamment la règle d'accès au contenu du référentiel de collectivité.

La stratégie de sécurité actuelle appliquée aux données de collectivité est la suivante :
  • Le système réserve trois noms de noeud : sys.host.auth.info, sys.jmx.auth.info et sys.nologin. Ces noeuds se trouvent dans un espace de nom de référentiel d'hôte ou de serveur. Le préfixe sys. doit être évité pour les noeuds créés par les utilisateurs.
  • Les noeuds sys.host.auth.info et sys.jmx.auth.info ne sont pas accessibles via le bean géré afin d'éviter la divulgation des données d'identification du système. L'accès aux données stockées sur ces noeuds génère une réponse de type Null.
  • Un membre de collectivité ne peut modifier que ses propres informations dans le référentiel. Les administrateurs authentifiés peuvent accéder sans restriction aux informations figurant dans le référentiel, à l'exception mentionnée précédemment. Il s'agit des utilisateurs associés au rôle Administrateur.

Etant donné que le référentiel de collectivité se trouve finalement sur le disque, les paramètres de droits d'accès au système de fichiers doivent être sécurisés pour l'environnement. Il est recommandé que la configuration du contrôleur de collectivité ne soit accessible en lecture et écriture que par le seul utilisateur, accessible uniquement en lecture par le groupe et ne soit pas accessible du tout aux autres (en d'autres termes, chmod 0640). Suivez les éventuelles instructions de sécurité établies par votre organisation.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_collective_sec
Nom du fichier : cwlp_collective_sec.html