Skip to main content

Proteger la capa de aplicación

Para proteger la capa de aplicación, ten en cuenta la autenticación del usuario y de la base de datos, los certificados digitales y el cifrado.

Autenticación de usuario integrada

Con la autenticación integrada de Server, los usuarios se autentican a través de JavaScript del lado del cliente que llama a una función local SHA256 para realizar hash y salt en la contraseña antes de enviar el hash a Server, todo con el propósito de compararlo con el hash de la contraseña en la base de datos del usuario (almacenada en MongoDB). Server solo almacena el valor hash; nunca ve la contraseña de un usuario en formato no cifrado.

Nota

Actualizamos el algoritmo utilizado en contraseñas con hash para la autenticación integrada. En versiones anteriores a 22.1, el cliente llamaba a una biblioteca Bcrypt local para realizar hash y sal en la contraseña antes de enviar el hash a Server.

Consulta la sección de Autenticación de esta guía para obtener más información sobre los otros métodos de autenticación disponibles en Server.

Autenticación de base de datos

Alteryx Server mantiene la mayor parte de la información de la aplicación en una base de datos de Mongo incrustada. Durante la instalación, se genera un ID de usuario y una contraseña de la aplicación para acceder a la información de la base de datos. Visita la página de ayuda del Controlador para informarte sobre otras opciones de la base de datos, como Mongo administrado por el usuario y MongoDB Atlas.

Cifrado de transporte

El cifrado evita la exposición y modificación de datos confidenciales durante el transporte, como las contraseñas, la información de sesión de usuario y las transacciones. Recomendamos cifrar las conexiones a Server usando HTTPS con TLS 1.2+ para evitar la interceptación por parte de personas no autorizadas. El funcionamiento HTTPS se puede ajustar en la configuración del sistema. Para asegurarte de que TLS se negocia en la versión 1.2 o superior, es posible que debas modificar los ajustes de Channel , como se menciona en la sección de esta guía titulada Asegurar la capa del sistema operativo .

Visita Configurar SSL/TLS para Server  a fin de obtener más información.

Seguridad de los datos en reposo

Durante la ejecución del proceso, Server crea pruebas duraderas en forma de archivos temporales, metadatos y archivos log. Estos datos en reposo se almacenan físicamente en la base de datos de MongoDB y en el almacenamiento local de Server. A continuación, encontrarás algunas preocupaciones comunes acerca de los datos en reposo y, además, técnicas que se pueden implementar para abordar dichas preocupaciones.

Nota

Las instancias de MongoDB Enterprise o MongoDB Atlas administradas por el usuario admiten el cifrado en reposo. Para obtener más información, visita la documentación de MongoDB .

Los archivos temporales en formato YXDB se utilizan para almacenar datos durante la ejecución del proceso de Alteryx. Estos archivos pueden contener datos reales que se transmiten a través del flujo de trabajo durante el tiempo de ejecución.

Los archivos temporales se fijan en el ámbito de las llamadas del motor y se eliminan tan pronto como los procesos posteriores ya no los necesitan, o después de que el flujo de trabajo de Alteryx haya terminado de ejecutarse. A veces, estos archivos pueden retrasarse si el proceso de Alteryx se bloquea. Incluso en este caso, los archivos temporales se eliminarán automáticamente cuando se reinicie el servicio.

El directorio principal en el que se almacenan los archivos temporales se establece en Alteryx Server Configuración del sistema Engine Settings  >  Temporary Directory . Cada llamada del motor almacena sus archivos temporales individuales en un subdirectorio independiente en esta ubicación.

Refuerzo del almacenamiento de archivos temporales

Sigue estas recomendaciones para proteger aún más los archivos temporales.

  • Debes contar con RAM (memoria) adecuada para que Alteryx utilice menos almacenamiento en disco (intercambio).

  • Desactiva la opción Allow Users to Override en Configuración del sistema  > Engine Settings para denegar a los usuarios la opción de escribir en otras ubicaciones. Consulta la página de ayuda Motor para obtener más información.

  • Desactiva la opción Browse Everywhere Settings en Configuración del sistema > Engine Settings para prevenir la creación del archivo Examinar en todas partes de Alteryx (YXBE).

  • Ubica el directorio de archivos temporales en una unidad cifrada (por ejemplo, utilizando BitLocker).

  • Excluye el directorio de archivos temporales de los respaldos automatizados.

Cuando se configura la autenticación para SSO o IWA, Server no posee ni almacena las credenciales utilizadas para iniciar sesión. Cuando se utiliza la autenticación integrada de Server, solo se almacenan hashes de contraseñas con sal.

Las contraseñas que Server utiliza para autenticarse en su respaldo MongoDB se cifran en reposo. Para ello, se utilizan las funciones criptográficas proporcionadas por el sistema operativo.

Los logs de Server te permiten rastrear errores, advertencias, información y mensajes de depuración. Los archivos log contienen información sobre los eventos de Server, los flujos de trabajo, los archivos de datos a los que se accedió y el número de registros que se están procesando en una tarea determinada. No contienen datos reales que se están consumiendo, procesando o generando como salida. Los logs se recopilan para el motor, el nodo de interfaz de usuario de Server y Alteryx Service.

Si los flujos de trabajo no se cargan, comunícate con el Servicio de asistencia al cliente para obtener ayuda.

Los logs se guardan en las siguientes ubicaciones:

  • Los logs del nodo de interfaz de usuario de Server se almacenan en C:\ProgramData\Alteryx\Gallery\Logs y tienen un nombre del tipo alteryx-2017-09-13.csv

  • Los logs de Server/Service se almacenan en C:\ProgramData\Alteryx\Service y tienen nombres como: AlteryxServiceLog_2017-06-04_00-46-07.log con el log más reciente denominado AlteryxServiceLog.log

  • Los logs del motor están desactivados de forma predeterminada, pero se pueden activar en Configuración del sistema.

    Nota

    Los logs del motor pueden contener seguimientos de pila o mensajes de error devueltos por los otros procesos que el motor llama o invoca durante la ejecución del flujo de trabajo, y esos mensajes podrían exponer datos o metadatos que se transfirieron al proceso externo. Por este motivo, se recomienda activar los logs del motor solo cuando el personal autorizado está solucionando problemas.

  • Los logs de nivel de sistema están disponibles en el visualizador de eventos de Windows.

Seguridad de los datos en tránsito

Los componentes de Alteryx Server transfieren datos y flujos de trabajo. Durante diferentes puntos del proceso de transferencia, los datos en tránsito se cifran o exponen en función de la configuración.

  • La interfaz de usuario de front-end de Server se establece de manera predeterminada en HTTP (texto sin formato en el puerto TCP 80). Se recomienda configurar Server para HTTPS (SSL/TLS en el puerto 443).

  • La comunicación entre nodos dentro de un clúster distribuido de Server (consulta Tipos de implementación en esta guía) también utiliza el puerto 80, pero se encripta con el cifrado AES-256 mediante la información del token de controlador, la sal y la hora. Esto garantiza una carga segura y urgente.

  • MongoDB incrustado que se ejecuta en el controlador recibe en un socket TCP/IP no cifrado (puerto TCP 27018). En una instancia todo en uno de Server, el elemento que recibe del socket es solo de localhost y no se debe exponer a la red. Si ejecutas un Server distribuido (consulta Tipos de implementación en esta guía) con MongoDB incrustado, las conexiones desde otros nodos del clúster al MongoDB del controlador no se cifrarán. Para cifrar las comunicaciones de la base de datos con TLS/SSL, debes cambiarte a un MongoDB administrado por el usuario (o MongoDB Atlas).

  • Los métodos de cifrado para las fuentes de datos (Oracle y SQL Server) y las plataformas de informes (Tableau y PowerBI) se definen mediante el controlador o conector ODBC de proveedores externos.

Los datos en tránsito se protegen mediante los procesos de hash y salt de las contraseñas y, además, con la generación de tokens de API del cliente en tiempo de ejecución documentados en la sección Refuerzo de Server de esta guía. Para una protección completa de los datos en tránsito, se recomienda cifrar las conexiones a Server con HTTPS mediante TLS 1.2 o superior.

Almacenamiento de credenciales

Según la configuración y el uso de Server, este puede almacenar varias credenciales. Revisa cómo se maneja esta información confidencial.

Un flujo de trabajo en ejecución puede conectarse a varias fuentes de datos externos durante la ejecución, usando las credenciales que pueden

  • incrustarse en línea dentro del flujo de trabajo y protegerse mediante el cifrado Ocultar o Usuario/máquina (DPAPI) (método heredado, no se recomienda).

  • obtenerse del almacenamiento cifrado DCMe durante el tiempo de ejecución.

  • almacenarse en una conexión de datos administrada o alias de Gallery.

Para las conexiones de datos administradas, verás “ __ENCPWD__ ” en el XML del flujo de trabajo. La credencial correspondiente se almacenará de forma cifrada en uno de los siguientes archivos XML, según cómo se configuró la conexión de datos:

  • %UserProfile%\AppData\Roaming\Alteryx\Engine\GalleryAlias.xml

  • %ProgramData%\Alteryx\Engine\SystemAlias.xml

  • %ProgramData%\Alteryx\Engine\SystemConnections.xml

Con la autenticación incorporada de Windows o SAML, las credenciales de usuario de Server no se almacenan en Server y, además, Server no es su propietario.

En la autenticación integrada, las credenciales de usuario de Server reciben hash, sal y nuevamente hash.

Los secretos internos, como la contraseña del token de controlador y MongoDB, se cifran por máquina mediante la API de cifrado de Windows. Sus claves se encuentran en esta ubicación:  %ProgramData%\Microsoft\Crypto\RSA\MachineKeys . Visita la página de ayuda Controlador para obtener más información.

Certificados digitales

Un certificado digital es una prueba de tu identidad de Server, firmada por una autoridad de certificación de confianza. Para admitir correctamente las conexiones cifradas desde el navegador del cliente a Server, debes crear un certificado digital para Server y, además, una autoridad de certificación en la que tu organización confíe debe firmarlo antes de instalarlo en los hosts de Server. Visita Configurar SSL/TLS para Server  a fin de obtener más información.