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.
- La configuration de la sécurité du domaine d'administration pour les collectivités se composent de deux parties :
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 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.
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 :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.