Secure the Application Layer
To secure the application layer, consider the user and database authentication, digital certificates, and encryption.
Built-In User Authentication
With Server’s built-in authentication, users are authenticated via client-side JavaScript that calls a local SHA256 function to hash and salt the password before sending the hash to Server for comparison to the password hash in the user database (stored in MongoDB). Server stores only the hashed value; it never sees the plaintext of a user's password.
Note
We have updated the algorithm used to hash passwords for built-in authentication. In versions prior to 2022.1, the client called a local bcrypt library to hash and salt the password before sending the hash to the Server.
See the Authentication section of this guide for more information on the other authentication methods available with Server.
Database Authentication
Alteryx Server persists most application information in an embedded Mongo database. During installation, an application user ID and password is generated to access information within the database. Go to the Controller help page for other database options including User-Managed Mongo and MongoDB Atlas.
Transport Encryption
Encryption prevents the exposure and modification of sensitive data during transport, such as passwords, user session information, and transactions. We recommend encrypting connections to Server using HTTPS with TLS 1.2+ to prevent interception by unauthorized persons. HTTPS operation can be configured in System Settings; to ensure TLS is negotiated at version 1.2 or better you may need to modify channel settings, as mentioned in the section of this guide titled Secure The Operating System Layer.
Go to Configure Server SSL/TLS for more information.
Security of Data at Rest
During process execution Server creates durable evidence in the form of temp files, meta-information, and log files. This data at rest is stored physically in the Mongo DB and on Server's local storage. Below, you'll find some common concerns around data at rest along with techniques that can be implemented to address them.
Note
User-managed MongoDB Enterprise or MongoDB Atlas instances support encryption at rest. For more information, go to MongoDB documentation.
Temp files in YXDB format are used for storing data during Alteryx process execution. These files can contain actual data that is streaming through the workflow at runtime.
Temp files are scoped to Engine invocations and deleted as soon as they are no longer needed by downstream processes or after the Alteryx workflow has finished running. These files can sometimes remain behind if the Alteryx process has crashed. Even in this case, temp files will still be deleted automatically when the service restarts.
The top-level directory where temp files are stored is set in the Alteryx Server System Settings > Engine Settings > Temporary Directory. Each Engine invocation stores its individual temp files in a separate subdirectory under this location.
Hardening Temp File Storage
Follow these recommendations to further secure temp files.
Have adequate RAM (memory) so Alteryx uses less disk storage (swapping).
Uncheck the Allow Users to Override option in System Settings > Engine Settings to deny users the option to write to other locations. Go to the Engine help page for more info.
Uncheck the Browse Everywhere Settings option in System Settings > Engine Settings to prevent the creation of the Alteryx Browse Everywhere file (YXBE).
Locate the temp file directory on an encrypted drive (for example, using BitLocker).
Exclude the temp file directory from automated backups.
When authentication is configured for SSO or IWA, Server does not own or store the credentials used to log in. When using Server’s built-in authentication only salted password hashes are stored.
The passwords which Server uses to authenticate to its backing MongoDB are encrypted at rest using cryptographic functions provided by the operating system.
Server logs let you trace errors, warnings, information, and debugging messages. Log files contain information about Server events, workflows, accessed data files, and the number of records being processed in a given job. They don’t contain actual data that is being consumed, processed, or output. Logs are collected for the Engine, Server UI node, and Alteryx Service.
If your workflows fail to load, contact customer support for assistance.
The logs are saved in the following locations:
Server UI node logs are stored in
C:\ProgramData\Alteryx\Gallery\Logsand have a name like: alteryx-2017-09-13.csvServer/service logs are stored in
C:\ProgramData\Alteryx\Serviceand have a name like: AlteryxServiceLog_2017-06-04_00-46-07.log, with the latest log being named: AlteryxServiceLog.logEngine logs are disabled by default but can be enabled in the System Settings.
Note
Engine logs might contain stack traces or error messages returned by other processes which Engine calls or invokes during workflow execution, and those messages can potentially expose data or metadata that was passed to the external process. For this reason, we recommend enabling Engine logs only during active troubleshooting by authorized personnel.
System-level logs are available in the Windows event viewer.
Security of Data in Transit
Alteryx Server's components transfer data and workflows. At different points in the transfer process, data in transit is encrypted or exposed depending on the configuration.
Server's front-end UI defaults to HTTP (plaintext on TCP port 80). We recommend configuring Server for HTTPS (SSL/TLS on port 443).
Inter-node communication within a distributed Server cluster (see Deployment Types in this guide) also uses port 80 but is encrypted with AES-256 encryption using the controller token, salt, and time information. This ensures a secure, time-sensitive payload.
Embedded MongoDB running on the Controller listens on an unencrypted TCP/IP socket (TCP port 27018). On an all-in-one Server instance, the socket listener is localhost-only and should not be exposed to the network. If you run a distributed Server (see Deployment Types in this guide) with Embedded MongoDB, connections from other cluster nodes to the Controller's MongoDB will be unencrypted. To encrypt database communications with TLS/SSL, you must switch to a User-Managed MongoDB (or MongoDB Atlas).
Encryption methods for Data sources (Oracle and SQL Server) and report platforms (Tableau and PowerBI) are defined by a 3rd-party ODBC driver or connector.
In-flight data is secured via password hashing and salting, as well as by the generation of runtime client API tokens documented in the Server Hardening section of this guide. For complete protection of in-flight data, we recommend encrypting connections to Server with HTTPS using TLS 1.2 or above.
Credential Storage
Depending on your Server configuration and usage Server may store various credentials. Review how this sensitive information is handled.
A running workflow may connect to multiple external data sources during execution, using credentials which can be
embedded inline within the workflow and protected using Hide or User/Machine (DPAPI) encryption (legacy method, not recommended)
obtained from DCMe encrypted storage at execution time
stored in a managed data connection or Gallery Alias.
For managed data connections, you will see "__ENCPWD__" in the workflow XML, and the corresponding credential will be stored in encrypted form in one of the following XML files depending on how the data connection was configured:
%UserProfile%\AppData\Roaming\Alteryx\Engine\GalleryAlias.xml%ProgramData%\Alteryx\Engine\SystemAlias.xml%ProgramData%\Alteryx\Engine\SystemConnections.xml
With Integrated Windows Authentication or SAML, Server user credentials aren’t owned or stored by Server.
For Built-In authentication, Server user credentials are hashed, salted, and hashed again.
Internal secrets, such as the Controller Token and Mongo DB password, are encrypted per machine using the Windows Crypto API with keys in this location: %ProgramData%\Microsoft\Crypto\RSA\MachineKeys. Go to the Controller help page for more info.
Digital Certificates
A digital certificate is proof of your Server's identity signed by a trusted Certificate Authority. To properly support encrypted connections from the client browser to Server, you have to create a digital certificate for Server and have it signed by a CA your organization trusts before installing it on Server hosts. Go to Configure Server SSL/TLS for more information.