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.
- La configuration de la sécurité du domaine d'administration est composée 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 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 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 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é 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.