Seguridad

Amazon Web Services (AWS)

Infraestructura de alojamiento principal. AWS cuenta con las certificaciones SOC 2, ISO 27001 y otras certificaciones de cumplimiento.

Neon (PostgreSQL)

Alojamiento de bases de datos con copias de seguridad automáticas, cifrado en reposo y aislamiento de red seguro.

Vercel

Alojamiento de aplicaciones con HTTPS automático, protección contra DDoS y seguridad de red perimetral (edge).

Stripe

Procesamiento de pagos con certificación PCI DSS Nivel 1. Nunca almacenamos números de tarjeta.

Cifrado en tránsito

Todos los datos transmitidos entre tu navegador y nuestros servidores se cifran con TLS 1.2 o superior. Aplicamos HTTPS en todas las conexiones y usamos HSTS para evitar ataques de degradación.

Cifrado en reposo

Todos los datos almacenados en nuestras bases de datos y en el almacenamiento de archivos se cifran en reposo con cifrado AES-256. Las copias de seguridad de las bases de datos también están cifradas.

Seguridad de las credenciales

No almacenamos nombres de usuario ni contraseñas. Toda la autenticación se gestiona a través de proveedores OAuth (Google y Microsoft), por lo que tus credenciales permanecen protegidas y administradas por tu proveedor de identidad.

Anthropic (Claude)

• Sin retención de datos para entrenamiento mediante la API
• Certificación SOC 2 Tipo II
• Controles de seguridad empresariales

Google (Gemini)

• Sin retención de datos para entrenamiento mediante la API
• Seguridad de nivel empresarial
• Certificado ISO 27001 y SOC 2

Amazon Bedrock

• Ejecuta los mismos modelos de Claude cuando el proveedor principal no está disponible
• Sin retención de datos para entrenamiento, según los términos del servicio de AWS
• Certificado ISO 27001 y SOC 2

Replicate

• Solo generación de iconos
• Recibe el texto que describe el icono, nunca tus datos

Autenticación

Usamos autenticación exclusivamente mediante OAuth, lo que significa que nunca gestionamos ni almacenamos sus contraseñas:

• Google OAuth: Inicia sesión de forma segura con tu cuenta de Google.
• Microsoft OAuth: Inicia sesión de forma segura con tu cuenta de Microsoft.
• Inicio de sesión único: En el plan Business, inicia sesión con tu propio proveedor de identidad. Se admiten Okta y Microsoft Entra, tanto con SAML como con OIDC.

Inicio de sesión único y autenticación multifactor

Flitch no ejecuta su propio segundo factor de autenticación y no almacena ninguna contraseña. La autenticación está delegada, de modo que los controles que ya aplica su organización son los que rigen:

• Su política de autenticación multifactor, las reglas de acceso condicional, los requisitos de cumplimiento de dispositivos y la duración de las sesiones se aplican a Flitch sin cambios.
• Al eliminar a alguien en su proveedor de identidad, se elimina su forma de iniciar sesión en Flitch. No existe una contraseña de Flitch independiente que revocar. Las claves de API son la excepción y se tratan más abajo.
• El inicio de sesión único (SSO) solo se activa cuando demuestras que eres el propietario de tu dominio de correo electrónico con un registro DNS, así nadie puede reclamar un dominio que no controla.
• Un proveedor está limitado a una sola empresa y solo enruta el dominio que ha verificado.
• SAML se puede configurar según lo que requiera su proveedor: solicitudes de autenticación firmadas, aserciones cifradas y varios certificados de firma para renovar un certificado sin tiempo de inactividad. Solicítelo y lo activaremos para su conexión.

Claves de API y baja de usuarios

Una clave de API pertenece al equipo y no a la persona que la creó, de modo que la salida de un miembro no interrumpa sin aviso una integración de la que depende el equipo. Esto tiene una consecuencia que conviene aclarar:

• Eliminar a una persona de su proveedor de identidad no revoca una clave que haya emitido. La clave sigue funcionando hasta que un administrador del equipo la revoque, algo que puede hacer en cualquier momento desde Configuración, Claves de API.
• Solo los administradores del equipo pueden emitir o revocar claves, y cada clave indica el nombre de la persona que la creó, por lo que la lista sirve también como lista de verificación de baja de usuarios.
• Las claves pueden tener una fecha de caducidad al crearlas, lo cual es la forma más sencilla de hacer que esto se corrija automáticamente.
• Una clave solo accede a los conjuntos de datos que se le han concedido, nunca a todos los conjuntos de datos del equipo y nunca a nada fuera del equipo al que pertenece.
• El alcance del registro de auditoría es la excepción a todo lo anterior: se vuelve a comprobar con su creador en cada solicitud, por lo que deja de funcionar en el momento en que esa persona deja de ser administrador de la empresa.

Seguridad de la sesión

• Cookies de sesión seguras y httpOnly
• Caducidad automática de la sesión
• Gestión de sesiones desde la configuración de la cuenta

Controles de acceso del equipo

Las cuentas de equipo admiten control de acceso basado en roles, con los roles de administrador y miembro. Los administradores pueden gestionar a los miembros del equipo y controlar el acceso a lo que crea el equipo.

Registro de auditoría

En el plan Business, un administrador de empresa puede consultar y exportar todo lo que ocurrió en cada uno de los equipos que administra:

• Inicios de sesión, cambios de membresía y de roles, uso compartido y publicación, cambios en fuentes de datos y credenciales, y eventos de facturación, cada uno con la persona, la hora y el resultado.
• Exporta en CSV, JSON Lines u OCSF, el esquema que AWS, Splunk y CrowdStrike crearon en conjunto, para que llegue a tu SIEM sin necesidad de un parser escrito para nosotros.
• Una API de sondeo para la ingesta continua, que entrega cada evento exactamente una vez.
• Los eventos se conservan durante 365 días.

Cuando el soporte de Flitch necesita acceso

Nuestro personal no puede entrar por su cuenta en su espacio. Soporte lo solicita, un administrador de ese espacio lo aprueba y el acceso caduca automáticamente. Cada solicitud, aprobación, rechazo y acceso se registra en su propio registro de auditoría, y puede finalizarlo en cualquier momento. En caso de emergencia, por ejemplo si nadie puede iniciar sesión para aprobar, el acceso puede abrirse sin esperar: dura una hora, se le avisa por correo electrónico en el mismo momento en que ocurre y queda registrado de la misma forma.

Encabezados de seguridad

• Política de seguridad de contenido (CSP)
• X-Frame-Options (protección contra clickjacking)
• X-Content-Type-Options
• Strict-Transport-Security (HSTS)
• X-XSS-Protection

Prácticas de seguridad

• Validación y saneamiento de entradas
• Consultas parametrizadas a la base de datos
• Protección con token CSRF
• Limitación de tasa en endpoints sensibles
• Actualizaciones periódicas de dependencias

Llamada a una dirección

• Se rechazan las direcciones privadas. Antes de que un webhook o un paso de API llame a una dirección, se resuelve el host y se rechaza toda dirección privada, de loopback, link-local o de metadatos de la nube, incluido un nombre público que se resuelva a una de ellas. Un rechazo nunca repite la dirección, porque a menudo contiene un token en su ruta y todo tu espacio puede leer el historial de ejecuciones.
• Se comprueba en cada ejecución, no al guardar. Un nombre que ayer apuntaba a una dirección pública hoy puede apuntar a otro lugar, por eso la comprobación se ejecuta cada vez y no solo una vez, cuando se creó el paso.
• No se siguen las redirecciones. Una respuesta que redirija a una dirección privada eludiría directamente la comprobación que se acaba de hacer, así que una redirección finaliza la llamada.
• Un secreto de webhook es de solo escritura. El encabezado secreto que defines para poder verificar el otro extremo se guarda y no vuelve a mostrarse nunca. Además, se elimina de cualquier copia del flujo de trabajo, de modo que al duplicar uno, su credencial nunca llega a quien lo duplicó.

Envío de correo electrónico

• Solo los miembros de tu espacio. Un paso de correo solo llega a las personas de tu propio espacio y a nadie más. Si se le pide enviar a cada cliente su propia fila, se niega al ejecutarse en lugar de enviar.
• Nada se envía dos veces. Un paso que envía datos conserva una marca de agua, de modo que un envío nocturno no vuelva a enviar las filas de ayer. Una ejecución que envió algunas filas y luego falló se notifica como parcialmente completada en lugar de fallida, porque lo que ya se envió no se puede deshacer y un reintento volvería a enviar las primeras filas.

Quién puede iniciar una ejecución

• Un dashboard no puede acceder a un flujo de trabajo a menos que tú lo permitas. Un flujo de trabajo solo es accesible desde un dashboard o una aplicación cuando tiene el activador que lo permite. Sin él, ninguna página publicada puede iniciarlo. Está desactivado hasta que alguien lo agregue.
• Una página publicada controla las ejecuciones dos veces. Un lector con sesión iniciada es alguien a quien podemos identificar; a un visitante anónimo se le pide que inicie sesión. Permitir que cualquiera lo ejecute es un ajuste independiente que está desactivado hasta que lo actives, y en ambos casos las ejecuciones tienen un límite de frecuencia por usuario que las solicita.
• Una ejecución pertenece a quien creó el flujo de trabajo. Las ejecuciones se autorizan y se facturan al propietario del flujo de trabajo, y no a quien pulsó el botón; por eso, un flujo de trabajo cuyo propietario ha dejado el espacio no es accesible para nadie.

Qué se registra y qué se detiene

• Cada ejecución conserva un registro de seguimiento. Paso a paso: qué entró, qué salió y una muestra de las filas. Si un paso actuó sobre el mundo exterior, registra qué se envió e indica el host, no la dirección completa. Una ejecución iniciada por una programación no registra a nadie como autor, porque nadie la estaba supervisando; una que inicia una persona la registra a ella.
• Un flujo de trabajo que falla se desactiva. Tras varios fallos consecutivos, deja de ejecutarse según su programación y se envía por correo al propietario el motivo, de modo que una integración averiada no se reintente indefinidamente ni falle en silencio.
• El SQL se ejecuta separado de cualquier credencial. Una consulta escrita en un flujo de trabajo se ejecuta en un servicio aparte y no en el worker, porque el worker guarda las credenciales de la base de datos, del almacén de archivos y de los modelos, y una consulta escrita por una persona no debe ejecutarse junto a ninguna de ellas. Se ejecuta en un motor de base de datos bloqueado: un único SELECT, verificado por el propio analizador del motor, con el acceso a la red y al sistema de archivos desactivado, sin extensiones, con un límite de memoria, sin escribir nada en disco y con la configuración bloqueada para que la consulta no pueda reactivar nada de eso.