Notes de version
Cette version de Waarp Gateway est la première version majeure publiée depuis 1 an. Au cours de cette période, nous avons ajouté un grand nombre de fonctionnalités, d’optimisations et de correctifs.
La mise à jour est, comme toujours, fortement recommandée.
Principaux changements
Support des protocoles FTP et FTPS
Waarp Gateway 0.9.0 s'enrichit du support des protocoles FTP et FTPS, en plus des protocoles déjà supportés (R66, SFTP, HTTP, et HTTPS). Les modes actifs et passifs sont supportés pour le transfert de données. Les modes implicites et explicites sont supportés pour FTPS.
Le support de ces protocoles à quelques limitations. Veuillez vous référer à la documentation pour en savoir plus.
Méthodes d’authentification
Selon les protocoles, Waarp Gateway supporte l'authentification par mot de passe, par clef publique, par certificat, et/ou par certificat client.
Ces différentes méthodes ont été regroupées dans les méthodes d'authentification. Les mêmes possibilités sont disponibles, mais le paramétrage de l'authentification des comptes locaux et distants est maintenant uniforme et se fait de la même manière quelque soit la méthode choisie.
Ce regroupement offre aussi une base plus solide pour l'ajout de nouvelles méthodes d'authentification à l'avenir.
Paramétrage des clients
Dans Waarp Gateway, la configuration des serveurs protocolaires pour gérer les connexions entrantes peut déjà être gérée serveur par serveur selon les possibilités offertes par les protocoles (algorithmes de chiffrement, etc.). Ces possibilités n'étaient pas possibles pour les connexions sortantes (partie clientes de Gateway).
À partir de cette version 0.9.0 de Waarp Gateway, les clients doivent être créés et paramétrés avant d’entreprendre quelconques transferts. Cela offre ainsi de nombreux avantages, notamment en termes de sécurité (désactivation globale d'un algorithme compromis pour tous les transferts sortants, etc.), d’autres fonctionnalités seront également ajoutées à l'avenir.
Mise à jour de la clef de chiffrement AES
Pour des raisons de sécurité, tous les mots de passe sont chiffrés dans la base de données (ces derniers sont protégés même en cas de compromission de la base de données).
Les mots de passe de connexion aux serveurs distants sont chiffrés en AES, à l'aide d'une clef enregistrée sur disque. Si cette clef est compromise, une nouvelle clef doit être générée et les mots de passe doivent être réchauffés avec la nouvelle clef.
Cette opération peut maintenant être automatisée avec la nouvelle commande waarp-gatewayd change-aes-passphrase, qui permet de mettre à jour automatiquement tous les mots de passe concernés.
Préparation du support du stockage cloud
Le support des stockages cloud (Amazon S3, Microsoft Azure, Google Cloud Platform, etc.) nécessitait des travaux préparatoires afin de permettre l'utilisation d'un stockage distant ou local de manière transparente.
Ces travaux sont maintenant terminés et les connecteurs vers les différents prestataires de stockage Cloud seront ajoutés dans une prochaine version.
Liste des Changements
Nouvelles fonctionnalités
#399 Ajout d'un cache d'authentification, qui permet d'améliorer significativement les performances lorsqu'un grand nombre de demandes de transfert sont effectuées en même temps par un petit nombre de partenaires.
#132 Ajout du support des protocoles FTP et FTPS à la gateway. Il est désormais possible d'effectuer des transferts client et serveur avec ce protocole. Compte tenu du fonctionnement particulier de ce protocole, il est conseillé de lire la rubrique spécifiant les détails d'implémentation du protocole avant de l'utiliser.
#389 Ajout de la commande waarp-gatewayd change-aes-passphrase permettant de changer la passphrase AES utilisée par la Gateway pour chiffrer les mots de passe distants en base de données (voir la documentation de la commande pour plus de détails).
#289 Les certificats et les mots de passe sont remplacés par les plus génériques « méthodes d'authentification », permettant d'ajouter plus facilement de nouvelles formes d'authentification. Ajout également des « autorités d'authentification » permettant de déléguer l'authentification de certains types de partenaires à un tiers de confiance. Pour plus d'information voir le chapitre sur l'authentification.
Ajouter ou enlever des certificats TLS à un agent de transfert ne nécessite plus un redémarrage du service en question pour que les changements soient pris en compte.
Mettre à jour les services (serveurs ou clients) de la gateway provoque désormais automatiquement un redémarrage du service en question, afin que la nouvelle configuration soit prise en compte. À noter : cela interrompra tous les transferts en cours sur le service en question, il est donc déconseillé de redémarrer un service si des transferts sont en cours sur celui-ci.
Les configurations protocolaires client, serveur et partenaire sont maintenant séparées les unes des autres, afin qu'elles puissent (lorsque cela est nécessaire) avoir des options différentes. Voir le chapitre sur la configuration protocolaire pour plus de détails.
#332 Matérialisation des clients de transfert. Les clients de transfert de la gateway ne sont dorénavant plus créés à la volé au démarrage des transferts, ils doivent désormais avoir été créés au préalable. Par conséquent, initialiser un nouveau transfert requiert désormais de préciser quel client utiliser pour exécuter ce transfert. Par commodité, pour les installations existantes, un client par défaut sera créé pour chaque protocole en utilisation lors de la migration de la gateway.
Ajout de l'option d'activation/désactivation disabled à l'objet JSON de serveur local localAgent du fichier d'import/export. Il est donc désormais possible de spécifier si un serveur importé doit être activé ou désactivé.
#392 Ajout des argument copyInfo et info à la tâche TRANSFER permettant respectivement de copier les transfer info du transfert précédent, et de définir de nouvelles transfer info. Pour plus d'information, voir la documentation de la tâche TRANSFER.
#379 Ajout du support pour les instances cloud en remplacement du disque local pour le stockage des fichiers de transfert. Voir la section cloud pour avoir plus de détails sur l'implémentation des différents types d'instances, et la section gestion des dossiers pour plus de détails sur leur utilisation.
Correctifs
#398 Les clé publiques SSH utilisant les algorithmes rsa-sha2-256 et rsa-sha2-512 sont désormais correctement acceptées par le client SFTP lors de sa connexion à un partenaire. Précédemment, ces algorithmes étaient incorrectement refusés par le client SFTP de la gateway malgré le fait qu'ils soient supportés.
#391 Les mots de passe des serveurs locaux R66 sont maintenant bien exportés en clair (comme le reste des mots de passe non-hashés).
Les dossiers par défaut (spécifiés dans le fichier de configuration) créés par la gateway ont désormais les permission 740 au lieu de 744.
Dans le cas où la base de données de la gateway est partagée, les partenaires de transfert ne sont désormais plus communs à toutes les instances utilisant la base. Dans les faits, chaque instance de gateway possède donc désormais son propre annuaire de partenaires, indépendant de ceux des autres instances partageant la base de données.Lors de la migration de la gateway, pour éviter d'éventuels problèmes d'incompatibilité, tous les partenaires existants ainsi que leurs enfants (comptes distants, certificats, etc...) seront dupliqués entre toutes les instances de gateway connues utilisant la base de données.
Les nouveaux serveurs locaux créés sont désormais activés par défaut au lieu d'être désactivés comme c'était le cas précédemment.
Note: Le terme « activé » ici (enabled) ne doit pas être confondu avec « actif » (running). Les serveurs ne seront pas automatiquement démarrés immédiatement après leur création. En revanche, ils seront démarrés lors du prochain lancement de Gateway.
Les transfer infos transmises via HTTP(S) sont désormais bien prises en compte dans les tâches.
Les valeurs de substitution de transfer info dans les tâches ne sont plus substituées par leur représentation JSON. Cela avait pour effet que les valeurs de type string étaient substituées avec des guillemets (“). Désormais, les transfer info sont substituées par leur représentation textuelle brute.
Dépréciations
Dans le cas où la base de données de la gateway est partagée, les partenaires de transfert ne sont désormais plus communs à toutes les instances utilisant la base. Dans les faits, chaque instance de gateway possède donc désormais son propre annuaire de partenaires, indépendant de ceux des autres instances partageant la base de données.
Commentaires