Durcissement de la sécurité d'Apache Hop avec des exemples pratiques

Introduction

Le durcissement de la sécurité d'Apache Hop consiste à transformer une installation par défaut vulnérable en un état sécurisé, vérifié, et reproductible. L'objectif n'est pas une liste de risques théoriques ; c'est une séquence d'étapes pratiques que vous pouvez exécuter sur un déploiement réel, observer le résultat, et annuler si le changement ne se comporte pas comme prévu.

Cet article s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui exploitent Apache Hop 1.2.x ou 2.x dans un déploiement à nœud unique ou en petit cluster. Les commandes présentées sont volontairement simples, utilisent des variables pour toutes les valeurs spécifiques à l'environnement, et incluent l'étape de vérification ainsi qu'un chemin de récupération. Rien ici ne doit être exécuté aveuglément. Capturez l'état actuel avant de modifier quoi que ce soit, limitez chaque changement à un seul composant, et confirmez le résultat avec une observation en lecture seule ou une entrée de journal documentée.

Apache Hop n'embarque pas l'authentification ou l'autorisation activées par défaut. Le serveur Hop intégré (Carte) expose une interface web et une API XML-RPC qui acceptent les requêtes non authentifiées à moins que vous ne configuriez explicitement une base d'utilisateurs et une politique de sécurité. Le durcissement signifie resserrer ces valeurs par défaut de manière contrôlée : identifier la version installée, inventorier la configuration actuelle, modifier un paramètre, vérifier le comportement attendu, et disposer d'un plan de rollback testé. Cet article couvre quatre domaines de travail : l'inventaire de la version et de l'environnement, les modifications de configuration sûres, la vérification et les diagnostics, et les modes de défaillance avec récupération. Chaque section comprend des commandes concrètes et leur sortie attendue, en utilisant des variables comme your-company, dev-team, et hop-server-01 que vous remplacez par vos propres valeurs.

Inventaire de la version et de l'environnement

Avant de pouvoir durcir un déploiement Hop, vous devez savoir exactement ce que vous exécutez. La version de Hop, l'environnement d'exécution Java, la topologie de déploiement (embarqué vs serveur Carte), et l'emplacement des fichiers de configuration clés affectent tous quelles commandes sont sûres à exécuter et quels contrôles de sécurité sont disponibles. Par exemple, Hop 1.2.x stocke sa configuration serveur dans config/hop-server.xml et utilise le lanceur hop-server.sh (ou .bat). Hop 2.x conserve le même format de fichier mais modifie l'emplacement par défaut du dossier metadata et introduit une validation plus stricte. Exécuter une étape de durcissement Hop 2.x sur une structure 1.2.x échouera silencieusement ou produira des erreurs confuses.

Commencez par un inventaire en lecture seule de la version installée et de l'environnement Java. Ces commandes ne modifient aucun état :

cd /opt/hop  # ou votre répertoire d'installation Hop
./hop-run.sh --version
java -version

Sortie attendue pour Hop 2.1.0 sur une JVM prise en charge :

Apache Hop 2.1.0
openjdk version "17.0.9" 2023-10-17 LTS
OpenJDK Runtime Environment (build 17.0.9+8)
OpenJDK 64-Bit Server VM (build 17.0.9+8, mixed mode, sharing)

Si la version de Hop est 1.2.x, remplacez hop-run.sh par hop-run.bat sous Windows ou utilisez le lanceur correspondant. L'inventaire ci-dessous suppose Hop 2.x ; ajustez les chemins en conséquence.

Ensuite, identifiez la topologie de déploiement. Hop peut s'exécuter comme application de bureau autonome, comme serveur Carte (hop-server), ou comme cluster de nœuds Carte. La surface de sécurité diffère : une installation de bureau n'a généralement pas d'API distante, tandis qu'un serveur Carte expose des points de terminaison HTTP qui doivent être protégés. Posez trois questions :

1. Un serveur Carte est-il en cours d'exécution ? (ps -ef | grep hop-server sous Linux, ou tasklist | findstr hop-server sous Windows.)
2. Sur quel port le serveur Carte écoute-t-il ? (Par défaut, 8080 ; consultez le hop-server.xml pour l'élément <port> ou l'argument de lancement -p.)
3. L'interface graphique Hop s'exécute-t-elle avec le serveur web embarqué ? (L'interface Hop peut démarrer une instance Carte locale pour les tests ; traitez-la comme un serveur si elle est accessible depuis d'autres machines.)

Enregistrez l'état actuel dans un fichier d'inventaire en texte brut. Un exemple pour un déploiement Carte mononœud typique :

Hôte : hop-server-01
Version Hop : 2.1.0
Java : OpenJDK 17.0.9
Déploiement : Serveur Carte, port 8080
Fichier de configuration : /opt/hop/config/hop-server.xml
Fichier utilisateurs : /opt/hop/config/hop-users.xml (s'il existe)
Observé le : 2025-03-21 14:30 UTC

Cet inventaire vous donne une base de référence pour chaque changement ultérieur. Si une étape de durcissement casse quelque chose, vous pouvez comparer l'état actuel avec cette capture enregistrée et revenir à la copie exacte du fichier.

Prérequis pour cette section : accès au répertoire d'installation Hop, permission de visualiser les fichiers de configuration, et une session shell sur l'hôte. Aucune de ces commandes ne modifie le système.

Rayon d'impact : les commandes en lecture seule ont un rayon d'impact nul. Le fichier d'inventaire que vous créez est local à votre répertoire de travail ; ne l'ajoutez pas au contrôle de version à moins qu'il ne contienne aucun secret.

Vérification : la sortie de hop-run.sh --version doit correspondre à votre ligne de version attendue. La sortie de java -version doit montrer une version LTS prise en charge (11 ou 17 pour Hop 2.x ; 8 ou 11 pour Hop 1.2.x). Une incompatibilité est un avertissement pour arrêter et résoudre avant de continuer.

Récupération : aucune récupération n'est nécessaire. Si vous écrasez accidentellement le fichier d'inventaire, recréez-le à partir des mêmes commandes en lecture seule.

Chemin de configuration sûr

Les principaux changements de durcissement pour un serveur Carte Hop sont : activer l'authentification, remplacer les mots de passe par défaut, et restreindre l'API XML-RPC aux méthodes nécessaires. Chaque changement doit être effectué un à la fois, avec une étape de vérification avant de passer au suivant.

1. Activer l'authentification sur le serveur Carte

Le serveur Carte de Hop lit ses paramètres de sécurité depuis le fichier hop-server.xml. Par défaut, le fichier contient un élément <authorization> vide, ce qui signifie que toute requête HTTP est acceptée. Activer l'authentification nécessite d'ajouter une base d'utilisateurs et une politique de sécurité.

Étape 1 : Sauvegardez la configuration actuelle du serveur.

cp config/hop-server.xml config/hop-server.xml.bak-20250321

Étape 2 : Créez un fichier de mots de passe pour la base d'utilisateurs intégrée. Hop 2.x fournit l'utilitaire hop-encrypt.sh pour générer des identifiants hachés. Par exemple, créez un utilisateur admin avec un mot de passe fort (remplacez YourStrongPassword! par une vraie phrase secrète) :

./hop-encrypt.sh -u admin -p 'YourStrongPassword!' -o config/hop-users.xml

Sortie attendue :

User 'admin' written to config/hop-users.xml

Le fichier généré contient un hachage SHA-256 salé, pas le mot de passe en clair. Ne modifiez jamais ce fichier à la main.

Étape 3 : Modifiez config/hop-server.xml pour référencer le fichier utilisateurs et activer l'autorisation. Ajoutez le XML suivant à l'intérieur de l'élément <hop-server-config>, en remplaçant le <authorization/> vide s'il est présent :

<authorization>
  <users-file>config/hop-users.xml</users-file>
  <authentication-method>basic</authentication-method>
</authorization>

Cela indique au serveur Carte d'utiliser l'authentification HTTP Basic avec les identifiants stockés dans hop-users.xml.

Étape 4 : Redémarrez le serveur Carte pour appliquer le changement.

./hop-server.sh -p 8080

Étape 5 : Vérifiez que l'accès non authentifié est désormais rejeté. Utilisez curl contre le point de terminaison d'état du serveur (remplacez hop-server-01 par votre hôte) :

curl -v http://hop-server-01:8080/kettle/status

Résultat attendu : HTTP 401 Unauthorized, avec un en-tête WWW-Authenticate. Une réponse réussie sans identifiants signifie que le changement d'authentification n'a pas pris effet.

2. Remplacer les mots de passe par défaut et restreindre les utilisateurs

Si votre installation Hop est livrée avec une base d'utilisateurs prédéfinie ou des utilisateurs d'exemple (par exemple, provenant d'une configuration groupée), supprimez-les ou modifiez leurs mots de passe immédiatement. Un piège courant est de laisser l'utilisateur cluster par défaut avec un mot de passe connu. Utilisez le même utilitaire hop-encrypt.sh pour mettre à jour ou supprimer des utilisateurs.

Pour supprimer un utilisateur :

./hop-encrypt.sh --remove-user cluster -f config/hop-users.xml

Pour changer le mot de passe d'un utilisateur existant :

./hop-encrypt.sh -u cluster -p 'NewSecurePassword!2' -f config/hop-users.xml

Vérifiez la liste des utilisateurs après le changement :

./hop-encrypt.sh --list-users -f config/hop-users.xml

Sortie attendue :

Users in config/hop-users.xml:
admin (enabled)

Tout utilisateur qui n'est pas activement nécessaire pour l'automatisation doit être supprimé. Pour les tâches planifiées qui appellent l'API Carte, créez un compte de service dédié avec les permissions minimales requises (voir section suivante).

3. Restreindre les méthodes de l'API XML-RPC

Le serveur Carte de Hop expose un large éventail de méthodes XML-RPC qui peuvent démarrer, arrêter et modifier des pipelines et des workflows. Toutes les méthodes ne sont pas nécessaires dans chaque déploiement. Pour réduire la surface d'attaque, configurez le serveur pour n'autoriser qu'une liste spécifique de méthodes. Dans hop-server.xml, ajoutez un élément <allow-methods> à l'intérieur de <authorization> :

<authorization>
  <users-file>config/hop-users.xml</users-file>
  <authentication-method>basic</authentication-method>
  <allow-methods>
    <method>Pipeline.run</method>
    <method>Pipeline.stop</method>
    <method>Pipeline.status</method>
    <method>Job.run</method>
    <method>Job.stop</method>
    <method>Job.status</method>
  </allow-methods>
</authorization>

Cette liste n'autorise que les six méthodes nécessaires pour exécuter, arrêter et vérifier les pipelines et les jobs à distance. Toutes les autres méthodes (par exemple, getRootFolder, executeTransform) renvoient une erreur de permission. Personnalisez la liste en fonction de votre utilisation réelle de l'API. Si vous devez ajouter une méthode plus tard, ajoutez-la à la liste et redémarrez le serveur.

Après chaque changement de configuration, redémarrez le serveur Carte et exécutez une commande de vérification. Par exemple, après avoir activé l'authentification et restreint les méthodes, testez un appel authentifié valide et un appel invalide :

Appel valide (doit renvoyer un état XML) :

curl -u admin:YourStrongPassword! http://hop-server-01:8080/kettle/status

Appel de méthode invalide (doit renvoyer une erreur d'accès refusé) :

curl -u admin:YourStrongPassword! -d @/tmp/unauthorized-request.xml http://hop-server-01:8080/kettle/

Où /tmp/unauthorized-request.xml contient une requête XML-RPC pour Pipeline.pause (une méthode qui n'est pas dans la liste autorisée). Le format d'erreur exact varie, mais le statut HTTP doit être 403 ou 500 avec une faute XML. Si le serveur renvoie 200, la restriction de méthode n'est pas active.

Prérequis : permission d'écriture dans le répertoire config, capacité de redémarrer le serveur Carte, et une sauvegarde valide du hop-server.xml d'origine.

Rayon d'impact : chaque changement n'affecte que le serveur Carte. Une mauvaise configuration peut vous bloquer hors de l'API, mais l'accès aux fichiers locaux reste intact.

Vérification : utilisez curl pour tester les requêtes non authentifiées et authentifiées comme indiqué. Consultez le journal du serveur (logs/hop-server.log) pour les messages d'authentification et d'autorisation.

Récupération : si l'authentification casse l'accès de manière inattendue, arrêtez le serveur, restaurez le fichier de sauvegarde (cp config/hop-server.xml.bak-20250321 config/hop-server.xml), et redémarrez. Si la liste allow-methods bloque une méthode nécessaire, modifiez le XML pour ajouter la méthode et redémarrez.

Vérification et diagnostics

Après chaque étape de durcissement, vous devez confirmer que le contrôle de sécurité prévu est actif et que les opérations légitimes fonctionnent toujours. Cette section fournit une procédure de vérification systématique.

1. Test d'accès non authentifié

Exécutez la commande curl suivante contre votre serveur Carte, en vous attendant à une réponse 401 :

curl -I http://hop-server-01:8080/kettle/status

Sortie attendue :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Hop"

Si vous voyez un 200, l'authentification n'est pas activée ou n'est pas appliquée à ce point de terminaison. Vérifiez que hop-server.xml contient l'élément <authorization> et que le serveur a été redémarré.

2. Test d'accès authentifié

Utilisez des identifiants valides pour accéder au point de terminaison d'état :

curl -u admin:YourStrongPassword! -i http://hop-server-01:8080/kettle/status

Sortie attendue : HTTP 200 et une charge utile XML ou JSON contenant des informations d'état du serveur. Si vous obtenez 401, les identifiants sont incorrects ou la base d'utilisateurs n'est pas lue. Vérifiez avec hop-encrypt.sh --list-users.

3. Test de restriction de méthode XML-RPC

Envoyez une requête pour une méthode qui n'est pas dans votre liste autorisée. Par exemple, si Pipeline.pause n'est pas autorisée, construisez une requête XML-RPC minimale et postez-la :

curl -u admin:YourStrongPassword! -H "Content-Type: text/xml" --data '<?xml version="1.0"?><methodCall><methodName>Pipeline.pause</methodName><params></params></methodCall>' http://hop-server-01:8080/kettle/

Résultat attendu : HTTP 403 ou une faute XML avec un message indiquant que la méthode n'est pas autorisée. Si le serveur renvoie 200 et tente de traiter l'appel, la restriction allow-methods ne fonctionne pas.

4. Inspection des journaux

Le journal du serveur Hop est l'enregistrement faisant autorité pour les événements d'authentification et d'autorisation. Suivez le journal pendant que vous effectuez les tests ci-dessus :

tail -f logs/hop-server.log

Recherchez des lignes comme :

INFO  2025-03-21 14:35:12,123 - Authentication failed for user 'admin' from 192.168.1.50
INFO  2025-03-21 14:36:45,456 - Authorization denied for method 'Pipeline.pause' (user 'admin')

Ces messages confirment que les contrôles de sécurité sont appliqués. L'absence de tels événements lorsque vous vous attendez à des échecs signifie que la configuration n'est pas active.

5. Test d'exécution de pipeline

Les changements de sécurité ne doivent pas casser le traitement de données légitime. Exécutez un pipeline d'exemple simple via l'API Carte pour vous assurer qu'un utilisateur autorisé peut exécuter les méthodes autorisées. Si vous avez un fichier de pipeline comme samples/transformations/hello-world.hpl, soumettez-le en utilisant le client en ligne de commande Hop ou un appel XML-RPC direct. Une exécution réussie doit renvoyer un statut Finished et produire la sortie attendue.

Liste de contrôle diagnostique :

• curl -I renvoie 401 pour les requêtes non authentifiées.
• curl -u renvoie 200 pour les requêtes authentifiées.
• La méthode interdite renvoie 403 ou une faute XML.
• Le journal du serveur contient des entrées d'authentification/autorisation.
• Le pipeline d'exemple s'exécute sans erreurs.

Si un contrôle échoue, arrêtez-vous et annulez le dernier changement avant de continuer.

Modes de défaillance et récupération

Même avec une planification minutieuse, les changements de durcissement peuvent échouer. Connaître les modes de défaillance courants et leurs étapes de récupération réduit les temps d'arrêt et la frustration.

Défaillance 1 : Verrouillé hors du serveur Carte

Symptômes : chaque requête, y compris avec des identifiants connus, renvoie 401. Le journal du serveur montre des échecs d'authentification répétés.

Causes possibles : hop-users.xml corrompu ou supprimé ; mot de passe modifié en dehors de l'utilitaire ; authentication-method mal défini.

Récupération :

1. Arrêtez le serveur Carte.
2. Restaurez la sauvegarde de hop-users.xml (si vous en avez une) ou recréez la base d'utilisateurs avec hop-encrypt.sh en utilisant le nom d'utilisateur d'origine et un nouveau mot de passe.
3. Restaurez hop-server.xml depuis la sauvegarde s'il a été modifié.
4. Démarrez le serveur et testez avec curl -u.

Si vous n'avez pas de sauvegarde de hop-users.xml, vous pouvez le régénérer à partir de zéro, mais vous devrez réinitialiser les mots de passe pour tous les utilisateurs.

Défaillance 2 : Méthode XML-RPC légitime bloquée

Symptômes : une tâche planifiée ou un système externe commence à échouer avec des erreurs XML-RPC indiquant qu'une méthode n'est pas autorisée. Le journal du serveur montre « Authorization denied for method ... ».

Cause : la méthode n'a pas été incluse dans la liste <allow-methods>, ou la liste était trop restrictive.

Récupération :

1. Identifiez la méthode bloquée à partir du journal.
2. Modifiez hop-server.xml pour ajouter la méthode à <allow-methods>.
3. Redémarrez le serveur.
4. Relancez la requête en échec pour confirmer qu'elle réussit.

Défaillance 3 : Le serveur ne démarre pas après un changement de configuration

Symptômes : le serveur Carte échoue au démarrage avec une erreur de configuration.

Cause : XML mal formé dans hop-server.xml (par exemple, balise non fermée, ordre d'éléments incorrect).

Récupération :

1. Consultez le journal du serveur pour la ligne d'erreur exacte, souvent en pointant vers le numéro de ligne dans hop-server.xml.
2. Si l'erreur n'est pas évidente, restaurez la sauvegarde de hop-server.xml.
3. Démarrez le serveur et confirmez qu'il fonctionne.
4. Réappliquez le changement avec soin, en utilisant un validateur XML si disponible.

Défaillance 4 : L'exécution du pipeline échoue après le durcissement

Symptômes : des pipelines qui fonctionnaient auparavant échouent maintenant avec des erreurs d'autorisation ou d'authentification.

Cause : le compte de service utilisé par le pipeline n'a pas les permissions requises, ou le pipeline appelle une méthode qui n'est pas dans la liste autorisée.

Récupération :

1. Consultez les journaux du pipeline et du serveur pour l'erreur exacte.
2. Si c'est une erreur d'authentification, vérifiez les identifiants dans la configuration du pipeline.
3. Si c'est une erreur d'autorisation, ajoutez la méthode nécessaire à la liste autorisée ou accordez à l'utilisateur des permissions suffisantes (si vous utilisez un modèle d'autorisation plus complexe).
4. Testez avec un pipeline simple utilisant les mêmes identifiants.

Principes généraux de récupération

• Maintenez toujours une sauvegarde horodatée de hop-server.xml et hop-users.xml avant d'apporter des modifications.
• Effectuez un changement à la fois. Si plusieurs changements échouent, revenez au dernier état connu bon et réappliquez les changements un par un.
• Utilisez un environnement de staging pour tester les étapes de durcissement avant de les appliquer en production.
• Documentez chaque changement avec la date, la justification et le résultat de la vérification.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour standardiser le durcissement de la sécurité d'Apache Hop au sein de votre équipe. Remplacez les valeurs d'exemple par les détails de votre propre environnement.

Remplissez la colonne Responsable avec les noms des personnes responsables et mettez à jour le Statut au fur et à mesure que chaque élément est terminé. Utilisez cette liste de contrôle pour chaque environnement (développement, staging, production). Conservez les listes de contrôle terminées dans le cadre de votre piste d'audit.

Conclusion

Le durcissement de la sécurité d'Apache Hop est un processus continu, pas un script ponctuel. Chaque recommandation de cet article est adaptée à la version pour Hop 1.2.x et 2.x, observable via des commandes et des journaux, et réversible lorsque des sauvegardes sont maintenues. La discipline clé est d'observer avant de changer, de changer un petit morceau, de vérifier le résultat attendu, et d'avoir un chemin de récupération testé.

Commencez par l'inventaire à faible risque de la version et de la topologie. Ensuite, activez l'authentification sur votre serveur Carte en utilisant la base d'utilisateurs intégrée. Remplacez ou supprimez les utilisateurs par défaut. Restreignez l'API XML-RPC aux seules méthodes que vos pipelines et jobs utilisent réellement. Après chaque changement, exécutez les commandes de vérification : les requêtes non authentifiées doivent échouer avec 401, les requêtes authentifiées doivent réussir avec 200, les méthodes interdites doivent renvoyer 403, et le journal du serveur doit enregistrer les événements de sécurité. Si quelque chose se comporte de manière inattendue, arrêtez-vous et revenez en arrière en utilisant vos sauvegardes.

Enfin, adoptez la liste de contrôle des opérations pour chaque environnement et suivez l'achèvement. Attribuez des responsables, enregistrez les dates et conservez les listes de contrôle comme preuve de votre travail de durcissement. En suivant cette approche contrôlée, vous réduisez le risque de violation de sécurité et vous gagnez en confiance que votre déploiement Apache Hop reste sécurisé à mesure qu'il évolue.

Pour en savoir plus, consultez la documentation officielle d'Apache Hop sur la sécurité du serveur Carte et l'utilitaire hop-encrypt. Gardez votre installation Hop à jour avec le dernier correctif, car les corrections de sécurité y sont régulièrement incluses.