S-Filer Portal™ est une solution complète qui permet aux grandes et petites organisations de combler l’ensemble de leurs besoins d’entreprise en matière de transfert et de stockage sécurisé de fichiers.
Okiok publie la version 4.17.0 de S-Filer/Portal™ solution de transferts sécurisés.
Améliorations importantes
Cette version introduit de nouvelles fonctionnalités dans la solution.
Plus grande flexibilité pour les espaces de partage
Les espaces de partage ont pour objectif de faciliter le partage de fichiers avec des utilisateurs externes. La nouvelle version de la fonctionnalité ajoute plus de flexibilité.
- Il est maintenant possible d’envoyer des invitations en spécifiant le nom, la langue et le rôle de l’utilisateur dans l’espace de partage.
- Il est aussi possible de transférer la propriété d’un espace de partage vers un autre utilisateur que son créateur.
- RAPPEL: La fonctionnalité d’espace de partage n’est pas activée par défaut dans l’application.
Le processus de création d’un espace de partage se fait en deux étapes:
La première étape consiste uniquement à donner un nom à l’espace de partage et une potentielle date d’expiration.
C’est à la seconde étape que le processus d’invitation d’utilisateurs prend place. Vous devez débuter le processus en écrivant les adresses courriel des utilisateurs invités ou le nom des utilisateurs faisant déjà partie de la base d’utilisateurs. Une fois ceux-ci sélectionnés, après avoir appuyé sur « Ajouter », une fenêtre modale vous sera proposée et vous permettra de sélectionner les caractéristiques des membres de l’espace de partage. Vous pourrez écrire un message personnalisé aux utilisateurs qui recevront un courriel les invitant à se connecter.
Une fois l’invitation terminée, vous allez revenir à l’écran de configuration de l’espace de partage. Vous allez pouvoir lancer de nouvelles invitations au besoin et supprimer les utilisateurs ne devant plus faire partie de l’espace de partage.
Il est aussi maintenant possible de transférer la propriété d’un espace de partage vers un autre utilisateur. Il y a deux façons possibles d’y arriver :
La première, un administrateur de l’espace de partage peut prendre lui-même l’initiative de devenir propriétaire de l’espace de partage. Le propriétaire précédent restera administrateur dans la communauté associée à l’espace de partage, mais n’en sera plus le propriétaire.
La seconde, un administrateur système, à travers les écrans de gestion des communautés, peut attribuer l’espace de partage à un autre utilisateur. En procédant, le nouveau propriétaire de l’espace de partage deviendra automatiquement un administrateur de celui-ci.
Disponibilité d’un API REST pour la gestion des espaces de partage
Un nouvel API REST dédié aux espaces de partage est maintenant disponible. Vous pouvez visualiser celui-ci en utilisant la page web documentaire de l’API se trouvant sur votre serveur S-Filer Portal. Pour l’obtenir, vous n’avez qu’à ouvrir votre navigateur et utiliser l’url suivante : https://SERVER_URL:8088/api/docs/ (il faut remplacer SERVER_URL par l’adresse de votre serveur et valider que le protocole et le port sont conformes à votre environnement).
Plus de flexibilité dans la configuration des algorithmes de chiffrement des différents protocoles
Il est maintenant possible d’être beaucoup plus précis lors de la configuration TLS des différents protocoles d’échange de fichiers. Lors d’une connexion sécurisée, le client et le serveur négocient quel algorithme de chiffrement ils utiliseront à partir des listes d’algorithme supportées par chacun d’eux. Le serveur commence l’échange en envoyant la liste des algorithmes qu’il supporte et ensuite le client choisit l’algorithme à utiliser dans cette liste. Normalement, un client choisit toujours celui qui est le plus sécuritaire à partir des algorithmes communs entre ceux qu’il supporte et ceux que le serveur supporte. Les configurations suivantes modifient la liste des algorithmes supportés par le serveur.
Pour HTTPS et FTPS, les trois modes de fonctionnement sont les suivants:
1. Défaut de la JVM, le serveur supporte tous les algorithmes de chiffrement activés dans la JVM.
2. Automatique, OKIOK détermine la liste des algorithmes de chiffrement considérés les plus sécuritaires et ne permet pas l’utilisation d’algorithmes de chiffrement jugés faibles ou ayant des vulnérabilités ou attaques connues.
3. Personnalisé, le client peut déterminer la liste exacte des algorithmes de chiffrement à permettre.
Voici un lien qui décrit les algorithmes de chiffrement supportés par la JVM (voir la section SunJSSE Cipher Suites):
https://docs.oracle.com/en/java/javase/18/security/oracle-providers.html
Pour SFTP, les trois modes de fonctionnement sont les suivants:
1. Autorisé faible, le serveur supporte tous les algorithmes de chiffrement activé dans la JVM.
2. Automatique, OKIOK détermine la liste des algorithmes de chiffrement considérés comme les plus sécuritaires et le serveur ne permet que ceux-ci.
3. Personnalisé, le client détermine la liste des algorithmes de chiffrement à utiliser.
Voici un lien qui décrit les algorithmes supportés par la librairie SFTP (voir la section Ciphers):
https://jadaptive.com/app/manpage/en/article/199483
Ajout de nouveaux paramètres pour le protocole SFTP
Il existait certaines variables d’environnement qui permettaient de modifier le comportement par défaut du serveur SFTP. Si vous utilisiez ces variables d’environnement, vous devez maintenant aller les configurer dans la console administrative. Il s’agit des variables suivantes :
1. « Nombre maximal de transferts simultanés » qui était préalablement associé à la variable d’environnement : sfiler.sftp.max.concurrent.transfers
2. « Threads de transfert permanent » qui était préalablement associé à la variable d’environnement : SSHD_PERMANENT_TRANSFER_THREADS
3. « Délai maximal d’inactivité » qui était préalablement associé à la variable d’environnement : SSHD_IDLE_CONNEXION_TIMEOUT_SECONDS
Possibilité de sauter l’authentification multifacteurs sur des appareils de confiance
Lors d’une authentification complète avec multifacteurs, l’utilisateur aura la possibilité de spécifier qu’il est sur un appareil de confiance. Dans ce cas, la solution génèrera un jeton identifiant l’appareil de confiance et l’utilisateur n’aura plus à spécifier son 2e facteur d’authentification sur cet appareil tant que le jeton est valide.
La durée de validité du jeton des appareils de confiance est configurable dans la page « Sécurité » associée au serveur :
Améliorations mineures et corrections de bogues
- Il est maintenant possible de visualiser le rôle d’un utilisateur dans la liste d’utilisateurs.
- Le processus de validation des dates dans les écrans de rapport a été revu et corrigé.
- Le processus de validation des quotas dans l’écran des communautés a été revu et corrigé.
- Une nouvelle validation a été ajoutée afin de s’assurer qu’il n’est pas possible de supprimer un utilisateur propriétaire d’un espace de partage.
- Un correctif a été effectué afin de permettre le téléversement d’un répertoire à l’aide de l’interface web (« drag-and-drop »).
- Un correctif a été effectué afin de ne plus envoyer de notifications par courriels à un utilisateur inactif.
- La gestion des erreurs dans la console administrative a été revue et corrigée afin de donner un meilleur retour à l’utilisateur lorsqu’une erreur se produit.
- Le bouton « Démarrer Maintenant » des différentes tâches du Programmateur de la Console Administrative a été corrigé afin qu’il puisse être possible de l’utiliser à plus d’une reprise sans devoir sortir de l’écran.
- Les écrans de Gestion des Certificats SSL ont été revus afin d’éviter la suppression de certificats ou de paires de clés qui sont en cours d’utilisation. Le certificat du serveur qui se trouvait de façon automatique dans la liste des certificats a été retiré de celle-ci afin d’éviter de le supprimer par erreur.
- Un correctif a été effectué sur la commande list-domains du sfiler-admin-cli afin d’éviter l’apparition d’un message d’erreur lors de l’affichage du résultat.
- L’algorithme de key exchange rsa1024-sha1 qui était considéré comme fort est maintenant considéré comme faible.
Modifications de l’API et de la compatibilité
- Un code de retour 206 est maintenant retourné au moment de l’authentification si le mot de passe de l’utilisateur est expiré.
Problèmes connus
- En cas normal, si SSL est activé, S-Filer Portal va tenter d’utiliser TLS 1.3 (à moins d’utiliser le mode personnalisé et d’exclure les Ciphers 1.3). Cependant, l’utilisation du protocole TLS 1.3 en FTPS peut potentiellement causer des problèmes avec certains clients lorsque le mode de gestion des algorithmes de chiffrements SSL/TLS est à l’option « Défaut de la JVM ». Il est recommandé de laisser la valeur « Automatique » de façon à exclure les algorithmes de chiffrement TLS 1.3. Il est aussi recommandé de ne pas inclure les algorithmes de chiffrement TLS 1.3 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 et TLS_CHACHA20_POLY1305_SHA256 lorsque le mode « Personnalisé » est utilisé. Cette problématique sera corrigée dans la version 4.18.0 lors du passage à la version 17 de la JVM.
Ruptures fonctionnelles
- L’applet a été retiré de la solution. Il est recommandé de migrer vers la technologie de chiffrement de bout en bout introduite dans la solution et disponible avec les navigateurs modernes.
- Le comportement de l’API REST a été modifié de sorte que le code de retour 200, souvent utilisé pour signifier le succès d’un appel, ne retourne plus aucun message dans la réponse.
- Le service web « Password Policy » sera bientôt retiré de la solution et remplacé par un service REST de notre API régulière. L’ensemble des fonctionnalités offertes seront reproduites à travers le nouveau service REST.
Mise à jour
Cette version introduit un changement au modèle de la base donnée et requiert l’utilisation du sfiler-config-cli pour effectuer la mise à jour. Nous vous conseillons vivement d’effectuer une sauvegarde complète de la solution avant la mise à niveau. N’hésitez pas à communiquer avec notre groupe de soutien si vous avez des questions concernant cette mise à niveau. support@okiok.com
