Cómo Transglot está protegido.
delimitadas.
Cómo Transglot está protegido.
Cifrado, control de acceso, aislamiento de inquilinos y registro de auditoría, cada uno nombra el mecanismo que lo aplica. Lo que aún no hemos construido se detalla aquí como brechas.
- TLS 1.2 o superior en tránsito
- Webhooks firmados con HMAC
- Filas de auditoría de solo anexión
- Cuatro roles, cinco capacidades de token
Cifrado, acceso, aislamiento y auditoría.
Cifrado antes de salir del host
Las copias de seguridad de la base de datos se cifran al exportarse. El repositorio de archivos de respaldo está cifrado con contraseña y se niega a ejecutarse sin su clave. Las credenciales de aplicaciones conectadas y los secretos de webhook se almacenan como columnas cifradas. Los tokens de despliegue se almacenan como un hash SHA-256 y se muestran una vez, al crearse. Los discos activos no están cifrados a nivel de volumen, porque no hemos implementado eso, y deberías saberlo aquí en lugar de durante la diligencia debida.
Firmado al salir
Los webhooks salientes se firman con HMAC-SHA256 sobre la marca de tiempo y el cuerpo. La marca de tiempo también se envía, para que puedas aplicar tu propia ventana de repetición.
Identidad y acceso
Cuatro roles de espacio de trabajo en todos los planes, incluido el gratuito: administrador, desarrollador, revisor y traductor, además de propietarios de cuenta y miembros de facturación. Los permisos por proyecto y por idioma se añaden encima, de modo que a un freelance se le puede asignar un idioma y no ver nada más. El inicio de sesión con SAML 2.0 con aprovisionamiento just-in-time y el aprovisionamiento SCIM 2.0 están disponibles en Enterprise, y el inicio de sesión con contraseña se puede desactivar para todo el espacio de trabajo.
Aislamiento de inquilinos
Cada consulta se delimita a tu organización y proyecto. Un ID perteneciente a otra persona responde con 404 en lugar de 403, por lo que la existencia de otro espacio de trabajo nunca se filtra. El grupo de memoria compartida de coincidencia exacta es la única excepción deliberada, y cualquier proyecto puede abandonarlo con un interruptor.
El registro de auditoría
Los cambios de rol, la creación de tokens, los cambios de facturación, la configuración de SSO y los inicios de sesión mediante SSO se registran, y las filas no pueden editarse ni eliminarse: el modelo lanza un error en ambos casos. Los inicios de sesión con contraseña no aparecen actualmente en el registro. Los propietarios y administradores en Enterprise pueden exportar todo el registro como CSV. No hay cadena de hash ni firma criptográfica, por lo que nada aquí indica que sea a prueba de manipulaciones.
Tiempo de actividad y créditos
No publicamos ningún porcentaje aquí, porque cualquier cifra que indicáramos sería solo nuestra palabra sobre nuestra propia disponibilidad. Los planes Business y Enterprise incluyen un objetivo contractual mensual de tiempo de actividad con un programa de créditos de servicio, y ese programa constituye el SLA.
Dónde se encuentra realmente el cumplimiento
Las mismas cuatro filas que leen la página de confianza y el centro de confianza, desde la misma configuración. Un sello solo puede decir "obtenido" cuando un booleano lo indica, y hoy ninguno lo hace.
- SOC 2 Type II: auditoría en curso
- ISO/IEC 42001 (AI management): en proceso de obtención
- GDPR: alineado, no certificado
- CCPA / CPRA: alineado, no certificado
Lo que pregunta un revisor, respondido primero.
Las preguntas con las que comienza una revisión de seguridad, y las respuestas, en el orden en que suelen llegar. Cada línea es un control en la base de código, no una afirmación sobre uno. La última línea es una brecha, y permanece aquí hasta que deje de ser cierta.
- no se citan hallazgos, porque aún no hay un informe de terceros
- no se implica certificación: la tabla de cumplimiento en /trust se lee desde la configuración
- la investigación de buena fe nunca se encuentra con abogados
Preguntas frecuentes
La lista con la que suele llegar una revisión de seguridad.
