Sécuriser la couche d'application
Pour sécuriser la couche d'application, tenez compte de l'authentification de l'utilisateur et de la base de données, des certificats numériques et du chiffrement.
Authentification de l'utilisateur intégrée
Avec l'authentification intégrée de Server, les utilisateurs sont authentifiés via JavaScript côté client qui appelle une fonction locale SHA256 pour hacher et saler le mot de passe. Puis, le mot de passe chiffré est envoyé au serveur pour le comparer avec le hachage présent dans la base de données utilisateur (stockée dans MongoDB). Server stocke uniquement le hachage et ne voit jamais le mot de passe en clair d'un utilisateur.
Note
Nous avons mis à jour l'algorithme utilisé pour le hachage des mots de passe pour l'authentification intégrée. Dans les versions antérieures à 22.1, le client appelait une bibliothèque bcrypt locale pour hacher et saler le mot de passe avant d'envoyer le hachage à Server.
Reportez-vous à la section authentification de ce guide pour plus d'informations sur les autres méthodes d'authentification disponibles avec Server.
Authentification de la base de données
Alteryx Server conserve la plupart des informations d'application dans une base de données Mongo intégrée. Lors de l'installation, un identifiant et un mot de passe d'application sont générés pour accéder aux informations de la base de données. Accédez à la page d'aide Contrôleur pour découvrir d'autres options de base de données, notamment MongoDB géré par l'utilisateur et MongoDB Atlas.
Chiffrement de transport
Le chiffrement empêche l'exposition et la modification des données sensibles pendant le transport, comme les mots de passe, les informations de session utilisateur et les transactions. Nous vous recommandons de chiffrer les connexions au serveur en utilisant HTTPS avec TLS 1.2+ afin d'empêcher l'interception de vos données par des personnes non autorisées. Le fonctionnement HTTPS peut être configuré dans les paramètres système. Pour garantir que TLS est négocié à la version 1.2 ou une version supérieure, vous devrez peut-être modifier les paramètres de channel , comme indiqué dans la section de ce guide intitulée Sécurisation de la couche du système d'exploitation .
Reportez-vous à la section Configurer SSL/TLS pour Server pour plus d'informations.
Sécurité des données inactives
Pendant l'exécution du processus, Server crée des preuves durables sous forme de fichiers temporaires, de méta-informations et de fichiers journaux. Ces données inactives sont stockées physiquement dans la base de données Mongo et dans la mémoire locale de Server. Vous trouverez ci-dessous quelques problèmes courants concernant les données inactives, ainsi que des techniques qui peuvent être mises en œuvre pour y remédier.
Note
Les instances MongoDB Enterprise ou MongoDB Atlas gérées par l'utilisateur prennent en charge le chiffrement au repos. Pour plus d'informations, accédez à la documentation sur MongoDB .
Les fichiers temporaires au format YXDB sont utilisés pour stocker les données pendant l'exécution du processus Alteryx. Ces fichiers peuvent contenir des données réelles qui sont diffusées dans le workflow lors de l'exécution.
Les fichiers temporaires se limitent aux invocations du moteur et sont supprimés dès qu'ils ne sont plus nécessaires aux processus en aval, ou après l'exécution du workflow Alteryx. Ces fichiers peuvent parfois demeurer si le processus Alteryx tombe en panne. Cependant, même dans ce cas, les fichiers temporaires seront toujours supprimés automatiquement au redémarrage du service.
Le répertoire de premier niveau où sont stockés les fichiers temporaires dans Alteryx Server est défini dans Paramètres système > Engine Settings (Paramètres du moteur) > Temporary Directory (Répertoire temporaire). À chaque invocation du moteur, les fichiers temporaires individuels sont stockés à cet emplacement, dans un sous-répertoire distinct.
Renforcement du stockage des fichiers temporaires
Suivez ces recommandations pour sécuriser davantage les fichiers temporaires.
Disposez d'une mémoire RAM suffisante pour qu'Alteryx utilise moins de stockage sur disque (swap).
Décochez l'option Allow Users to Override (Autoriser les utilisateurs à remplacer les fichiers) dans Paramètres système > Engine Settings (Paramètres du moteur) pour empêcher les utilisateurs d'écrire à d'autres emplacements. Consultez la page d'aide Moteur pour plus d'informations.
Décochez l'option Browse Everywhere Settings (Parcourir les paramètres partout) dans Paramètres système > Engine Settings (Paramètres du moteur) pour empêcher la création du fichier Alteryx Parcourir partout (YXBE).
Identifiez le répertoire du fichier temporaire sur un lecteur chiffré (par exemple, à l'aide de BitLocker).
Excluez le répertoire du fichier temporaire des sauvegardes automatiques.
Lorsque l'authentification est configurée pour SSO ou IWA, Server ne possède ou ne stocke pas les informations d'identification utilisées pour la connexion. Lors de l'utilisation de l'authentification intégrée de Server, seuls les mots de passe chiffrés sont stockés.
Les mots de passe utilisés par Server pour s'authentifier auprès de son système MongoDB de sauvegarde sont chiffrés au repos à l'aide des fonctions cryptographiques fournies par le système d'exploitation.
Les journaux de Server vous permettent de suivre les erreurs, les avertissements, les informations et les messages de débogage. Les fichiers journaux contiennent des informations sur les événements de Server, les workflows, les fichiers de données consultés et le nombre d'enregistrements traités dans une tâche donnée. Ils ne contiennent pas de données réelles consommées, traitées ou en sortie. Les journaux sont collectés pour le moteur, le nœud de l'interface utilisateur Server et le service Alteryx.
Si vos workflows ne se chargent pas, contactez le service clientèle pour obtenir de l'aide.
Les journaux sont enregistrés aux emplacements suivants :
Les journaux du nœud de l'interface utilisateur Server sont stockés sous
C:\ProgramData\Alteryx\Gallery\Logset portent le nom suivant : alteryx-2017-09-13.csvLes journaux de Server et de services sont stockés sous
C:\ProgramData\Alteryx\Serviceet portent le nom suivant : AlteryxServiceLog_2017-06-04_00-46-07.log, with the latest log being named: AlteryxServiceLog.logLes journaux du moteur sont désactivés par défaut mais peuvent être activés dans les paramètres système.
Note
Les journaux du moteur peuvent contenir des traces de pile ou des messages d'erreur renvoyés par d'autres processus que le moteur appelle ou invoque pendant l'exécution du workflow. Ces messages peuvent potentiellement exposer des données ou des métadonnées transmises au processus externe. Pour cette raison, nous vous recommandons d'activer les journaux du moteur uniquement lors du dépannage actif par le personnel autorisé.
Les journaux au niveau du système sont disponibles dans l'observateur d'événements de Windows.
Sécurité des données en transit
Les composants d'Alteryx Server transfèrent des données et des workflows. À différents moments du processus de transfert, les données en transit sont chiffrées ou exposées selon la configuration.
L'interface utilisateur front-end de Server est par défaut en HTTP (texte en clair sur le port TCP 80). Nous vous recommandons de configurer Server pour HTTPS (SSL/TLS sur le port 443).
La communication entre nœuds au sein d'un cluster distribué de Server (voir les types de déploiement dans ce guide) utilise également le port 80, mais est chiffrée avec le chiffrement AES-256 à l'aide du jeton contrôleur, du salage et des informations temporelles. Cela garantit des données utiles sécurisées et sensibles au temps.
MongoDB intégré qui s'exécute sur le contrôleur écoute sur un socket TCP/IP non chiffré (port TCP 27018). Sur une instance tout-en-un de Server, le socket d'écoute fonctionne sur localhost uniquement et ne doit pas être exposé au réseau. Si vous exécutez Server distribué (voir la section Types de déploiement de ce guide) avec MongoDB intégré, les connexions des autres nœuds du cluster au MongoDB du contrôleur ne seront pas chiffrées. Pour chiffrer les communications de base de données avec TLS/SSL, vous devez passer à un MongoDB géré par l'utilisateur (ou MongoDB Atlas).
Les méthodes de chiffrement pour les sources de données (Oracle et SQL Server) et les plateformes de rapports (Tableau et PowerBI) sont définies par un pilote ou un connecteur ODBC tiers.
Les données en transit sont sécurisées via le hachage et le salage du mot de passe, ainsi que par la génération de jetons API client d'exécution décrits dans la section Renforcement de Server de ce guide. Pour une protection complète des données en transit, nous vous recommandons de chiffrer les connexions à Server avec HTTPS à l'aide du protocole TLS 1.2 ou une version supérieure.
Stockage des informations d'identification
En fonction de la configuration de Server et de son utilisation, il peut stocker diverses informations d'identification. Passez en revue la manière dont ces informations sensibles sont traitées.
Un workflow peut se connecter à plusieurs sources de données externes pendant l'exécution, en utilisant des informations d'identification qui peuvent être :
intégrées en ligne dans le workflow et protégées à l'aide de Hide ou du chiffrement utilisateur/machine DPAPI (méthode traditionnelle, non recommandée) ;
obtenues à partir du stockage chiffré DCME au moment de l'exécution ;
stockées dans une connexion aux données gérée ou un Gallery Alias.
Pour les connexions aux données gérées, « __ENCPWD__ » s'affiche dans le fichier workflow XML et les informations d'identification correspondantes sont stockées sous forme chiffrée dans l'un des fichiers XML suivants, selon la configuration de la connexion aux données :
%UserProfile%\AppData\Roaming\Alteryx\Engine\GalleryAlias.xml%ProgramData%\Alteryx\Engine\SystemAlias.xml%ProgramData%\Alteryx\Engine\SystemConnections.xml
Avec l'authentification Windows intégrée ou SAML, les informations d'identification utilisateur de Server ne sont pas détenues ou stockées par le serveur.
Pour l'authentification intégrée, les informations d'identification de l'utilisateur de Server sont hachées, salées et à nouveau hachées.
Les secrets internes, tels que le jeton contrôleur et le mot de passe de MongoDB, sont chiffrés par machine à l'aide de l'API de chiffrement Windows avec des clés à cet emplacement :
%ProgramData%\Microsoft\Crypto\RSA\MachineKeys
. Pour plus d'informations, consultez la page d'aide
Contrôleur
.
Certificats numériques
Un certificat numérique est une preuve de l'identité de Server signée par une autorité de certification approuvée. Pour prendre en charge correctement les connexions chiffrées du navigateur client vers Server, vous devez créer un certificat numérique pour Server et le faire signer par une autorité de certification approuvée par votre organisation avant de l'installer sur le ou les hôtes de Server. Reportez-vous à la section Configurer SSL/TLS pour Server pour plus d'informations.