Sécurité collective

Vous pouvez utiliser les principes de sécurité de collectivité dans le profil 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 :
  • La configuration de la sécurité du domaine d'administration

    Traite les données déplacées, l'authentification et l'autorisation

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

    Traite les données au repos, l'authentification et l'autorisation

Configuration de la sécurité du domaine d'administration
La configuration de la sécurité du domaine d'administration pour les collectivités se composent 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. Il peut être mappé à des utilisateurs dans le registre d'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 l'utilisateur possède le rôle Administrateur. Voir Configuration d'une connexion JMX sécurisée dans le profil 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é possède une identité unique dans la collectivité, composée de son nom d'hôte, du répertoire utilisateur et du nom de 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 sont copiées lorsqu'un contrôleur est répliqué ; par conséquent, 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 qui ne possèdent pas de signataire racine commun suffira à établir la confiance mais ne sera pas à 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 qui ne possèdent pas de signataire racine commun suffira à établir la confiance mais ne sera pas à 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". Il est recommandé de ne pas utiliser clientAuthenticationRequired="true" car ce paramètre empêche l'authentification avec des noms d'utilisateur et des mots de passe. Exemple :
<!-- clientAuthenticationSupported set to enable bidirectional trust -->
    <ssl id="defaultSSLConfig"
         keyStoreRef="defaultKeyStore"
         trustStoreRef="defaultTrustStore"
         clientAuthenticationSupported="true" />

Le bean géré CollectiveRegistration peut empêcher les membres de publier des informations dans le contrôleur de collectivité. Les méthodes avow et disavow empêchent l'authentification et l'activation, respectivement.

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. Il est conseillé d'éviter d'utiliser le préfixe sys. 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é soit lisible et inscriptible par l'utilisateur seulement, lisible par le groupe seulement, et inaccessible pour tous les autres (chmod 0640). Suivez les éventuelles instructions de sécurité établies par votre organisation.


Icône indiquant le type de rubrique Rubrique de concept

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_collective_sec
Nom du fichier : cwlp_collective_sec.html