> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Confianza y seguridad

> Comprende el tratamiento de los datos, la entrega de compilaciones y las responsabilidades de seguridad.

Ayakaleaf Pro se ejecuta en tu infraestructura. Tú controlas sus datos, el acceso y los límites de red. Esta página explica el modelo de seguridad predeterminado. También identifica tus responsabilidades operativas.

### ¿Es Ayakaleaf Pro fiable y seguro?

Ayakaleaf Pro es una mejora autoalojada de Overleaf Pro, y nuestro código fuente está disponible en [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro). Tu despliegue controla dónde se ejecutan los servicios y dónde residen los datos.

La seguridad depende de tu configuración y de tu operación. Protege el acceso de administrador, habilita HTTPS y mantén copias de seguridad.

Gracias a OpenAI por su amable apoyo. Usaremos periódicamente [Codex Security](https://chatgpt.com/codex/cloud/security/findings) para analizar nuestro repositorio en busca de problemas de seguridad y compartiremos públicamente los resultados de las correcciones de vulnerabilidades.

### ¿Adónde van mis datos?

De forma predeterminada, los datos de la aplicación permanecen dentro de tu despliegue:

* MongoDB almacena los datos de usuarios y proyectos.
* Redis almacena la caché y los datos de colaboración en tiempo real.
* Los volúmenes locales o el almacenamiento compatible con S3 contienen los archivos de los proyectos.

De forma predeterminada, solo se expone el servicio web. Los servicios internos se comunican a través de la red de Docker.

### ¿Se enviarán mis datos a terceros o se obtendrán de ellos?

Nada sale de tu despliegue a menos que habilites una función que lo requiera. Ayakaleaf Pro no envía *telemetría, analíticas de uso ni informes de fallos*. Los informes de errores y las analíticas están deshabilitados en la configuración predeterminada.

Varias funciones nunca realizan solicitudes externas. Las plantillas se almacenan y se sirven desde tu propio despliegue. El ejecutor de scripts de Python se ejecuta en el navegador del usuario mediante WebAssembly, y su entorno de ejecución se sirve desde tu propio servicio web en lugar de desde una CDN pública, por lo que el código y la salida de los scripts nunca llegan a la red. Git Bridge solo es accesible en la red interna de Docker. La búsqueda completa en proyectos, la paleta de símbolos, el control de cambios, el historial de proyectos y el panel de administración son totalmente locales. Los contenedores de compilación en sandbox se crean con la red deshabilitada.

Las solicitudes de las funciones restantes llegan a los siguientes destinos. Cada solicitud se origina en el servicio web:

<Accordion title="Asistentes de IA y búsqueda">
  Las funciones de IA están deshabilitadas de forma predeterminada. Cuando se habilitan, el chat y las sugerencias para errores de LaTeX envían prompts y el contexto relevante del proyecto al endpoint del modelo configurado con `AI_BASE_URL`. La búsqueda web opcional envía consultas al servicio compatible con Tavily configurado, y la búsqueda en la documentación envía consultas a `DOCS_MCP_URL` (predeterminado: `https://docs.overleaf.com/~gitbook/mcp`). Los resultados de búsqueda pueden incluirse en las solicitudes al proveedor del modelo. Consulta [Integración de IA](/es/on-premises/configuration/overleaf-toolkit/ai-integration "mention") para la configuración y los controles de usuario.
</Accordion>

<Accordion title="Integración con GitHub">
  La **integración con GitHub** se comunica con `github.com` y `api.github.com`. Se habilita por usuario vinculando una cuenta de GitHub, y la autorización solicita los scopes `read:org`, `repo` y `workflow`. Al hacer push se sube el contenido completo de los archivos del proyecto como blobs de Git, que luego se ensamblan en árboles y commits. También realiza operaciones de ramas, referencias, comparación y fusión, y lee el perfil de la cuenta vinculada, sus pertenencias a organizaciones y su lista de repositorios. El contenido del proyecto sale de tu despliegue en ambas direcciones: trata una cuenta de GitHub vinculada como una vía de exportación para todos los proyectos asociados a ella.
</Accordion>

<Accordion title="Integración con Zotero">
  La **integración con Zotero** se comunica con `www.zotero.org` para la autorización y con `api.zotero.org` para los datos de la biblioteca. Se habilita por usuario vinculando una cuenta de Zotero. Se envían el intercambio OAuth y la clave de API del usuario. Las lecturas son unidireccionales: las bibliotecas de referencias se importan como BibTeX y no se sube ningún contenido de los proyectos.
</Accordion>

<Accordion title="Integración con Mendeley">
  La **integración con Mendeley** se comunica con `api.mendeley.com` tanto para la autorización como para los datos de la biblioteca. Se habilita por usuario vinculando una cuenta de Mendeley. El intercambio OAuth solicita el scope `all` de Mendeley, el único que ofrece su API, pero Ayakaleaf solo realiza lecturas: las bibliotecas de referencias y las bibliotecas de grupo se importan como BibTeX y no se sube ningún contenido de los proyectos. Los tokens de acceso se renuevan automáticamente; cuando Mendeley revoca una autorización, la credencial almacenada se descarta y se pide al usuario que vuelva a vincular la cuenta.
</Accordion>

<Accordion title="Páginas de documentación">
  Las **páginas de documentación** se obtienen de `https://learnwiki.overleaf.com`, configurable con `WIKI_URL`. Las solicitudes las realiza el servicio web, no el navegador del usuario, por lo que la wiki de origen ve tu servidor y nunca las direcciones de tus usuarios. Solo se envía el título de la página solicitada, y las respuestas se almacenan en caché en disco. Apunta `WIKI_URL` a tu propio espejo, o bloquea el destino, si el tráfico saliente de documentación no es aceptable.
</Accordion>

<Accordion title="Envío de correo electrónico">
  El **envío de correo electrónico** se comunica con el servidor SMTP o la API de correo que configures; no hay ninguno predeterminado. Las direcciones de los destinatarios y el contenido de los mensajes salen de tu despliegue, incluidos los enlaces de restablecimiento de contraseña y de invitación.
</Accordion>

<Accordion title="Dos comprobaciones opcionales (PWD/reCAPTCHA)">
  <strong>Dos comprobaciones opcionales están deshabilitadas de forma predeterminada.</strong> La comprobación de contraseñas comprometidas está inactiva a menos que se establezca `HAVE_I_BEEN_PWNED_ENABLED`; cuando está habilitada, envía los primeros caracteres de un hash SHA-1 de la contraseña a `api.pwnedpasswords.com`, nunca la contraseña en sí. La verificación CAPTCHA está inactiva a menos que se configure una clave de sitio de reCAPTCHA, y se comunica con `www.google.com` cuando está activa.
</Accordion>

<Accordion title="Inicio de sesión único (OAuth/LDAP/SAML)">
  El **inicio de sesión único** solo llega al proveedor de identidad que proporciones, y lo que viaja hasta él depende del protocolo. Con LDAP, el servicio web se conecta directamente a tu directorio: se autentica con la cuenta de servicio que configures, busca bajo la base, el filtro y la lista de atributos que definas, y verifica la contraseña introducida en el formulario de inicio de sesión contra tu directorio, de modo que el nombre de usuario y la contraseña llegan al servidor de directorio. Habilitar los contactos respaldados por el directorio provoca una búsqueda adicional para rellenar la lista de contactos. Con OIDC, el servicio web intercambia el código de autorización en tu endpoint de token y luego llama a tu endpoint de información de usuario, solicitando de forma predeterminada los scopes `openid profile email`; esto se puede configurar con `OVERLEAF_OIDC_SCOPE`. Con SAML, la solicitud de autenticación viaja a través del navegador del usuario hasta el proveedor de identidad en lugar de mediante una conexión directa del servidor. En los tres casos, el nombre y la dirección de correo electrónico del usuario llegan desde el proveedor en lugar de enviarse a él, y luego se almacenan en el registro de usuario local.
</Accordion>

<Accordion title="Credenciales de terceros">
  Las **credenciales de terceros** (tokens OAuth y claves de API) se guardan en MongoDB en el registro del usuario, cifradas con AES-256-CTR con una sal y un vector de inicialización por registro. Nunca se almacenan en texto plano ni se escriben en los logs. La clave de cifrado proviene de `${PROVIDER}_CIPHER_PASSWORD` si está establecida (como en Zotero y Mendeley); de lo contrario, se genera una en el primer uso y se conserva dentro de tu volumen de datos con permisos solo para el propietario. Haz una copia de seguridad de esa clave junto con tu volumen de datos: si se pierde, las credenciales almacenadas no podrán descifrarse y todos los usuarios tendrán que volver a vincular sus cuentas.
</Accordion>

<Accordion title="Archivos vinculados desde una URL">
  Los **archivos vinculados desde una URL** los obtiene tu despliegue en nombre del usuario, por lo que el destino es la dirección que proporcione el usuario. Los archivos de URL vinculados están deshabilitados a menos que añadas `url` a `ENABLED_LINKED_FILE_TYPES`, y la configuración predeterminada no lo incluye. Las importaciones externas de ZIP y TeX mediante la API Open in Overleaf también usan el mismo componente `linked-url-proxy`. Las solicitudes directas resuelven el nombre de host de destino y rechazan los rangos de red restringidos, con sujeción a las excepciones de recursos permitidos configuradas. Con `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` configurado, el proxy saliente resuelve los nombres de host, por lo que debe aplicar él mismo las restricciones de la red interna; las comprobaciones de red de la aplicación solo se aplican a las URL que contienen direcciones IP. Consulta [URL externa — Proxy saliente](/es/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention") para más detalles. Estas solicitudes obtienen la URL proporcionada en lugar de subir archivos de los proyectos.
</Accordion>

Si tu política exige una lista de destinos salientes permitidos, permite solo los hosts de las funciones que hayas habilitado: `github.com` y `api.github.com` para GitHub, `www.zotero.org` y `api.zotero.org` para Zotero, `api.mendeley.com` para Mendeley, `learnwiki.overleaf.com` o tu propio `WIKI_URL` para la documentación, `api.pwnedpasswords.com` para la comprobación de contraseñas, `www.google.com` para CAPTCHA, además de tu propio servidor de correo y proveedor de identidad. Si las funciones de IA o la búsqueda están habilitadas, permite también los endpoints configurados del modelo, de la búsqueda web y del MCP de documentación. Deniega los destinos que no requieran las funciones habilitadas. Cuando el tráfico saliente deba inspeccionarse o registrarse de forma centralizada, las integraciones con GitHub, Zotero y Mendeley pueden enrutarse cada una a través de un proxy HTTP estableciendo `GITHUB_SYNC_PROXY_URL`, `MENDELEY_PROXY_URL` y `ZOTERO_PROXY_URL`. La obtención de URL vinculadas y las importaciones remotas pueden usar `OVERLEAF_LINKED_URL_OUTBOUND_PROXY`. Los archivos vinculados desde una URL no pueden limitarse a una lista de hosts, ya que el destino lo elige el usuario en el momento de la solicitud; restringe esa función mediante el ajuste de recursos permitidos del propio componente proxy, o déjala deshabilitada.

<Warning>
  Si despliegas Ayakaleaf Pro con el almacenamiento [s3.md](/es/on-premises/configuration/overleaf-toolkit/s3 "mention") habilitado, ¿se cifran los datos almacenados en S3?

  *<strong>No.</strong>* Los datos no se cifran. Todos los fragmentos del historial, los archivos de plantillas, los PDF y demás archivos se almacenan en texto plano. Si usas un proveedor externo de almacenamiento S3 de terceros, presta especial atención a la seguridad y la privacidad de los datos.
</Warning>

### ¿Están aisladas las compilaciones de los proyectos?

Ayakaleaf Pro admite compilaciones en sandbox. Cada compilación se ejecuta en un contenedor independiente. Los contenedores de sandbox no tienen acceso a la red de forma predeterminada. Esto reduce la exposición a los recursos de la red interna.

Las compilaciones en sandbox requieren acceso al socket de Docker del host. Restringe la administración del host a operadores de confianza.

### ¿Puedo confiar en las compilaciones de CI y en las imágenes de contenedor?

GitHub Actions compila y publica las imágenes de contenedor de Ayakaleaf Pro. Las imágenes están disponibles en el GitHub Container Registry público.

Las imágenes admiten `amd64` y `arm64`. Docker selecciona la arquitectura correspondiente al descargar una imagen.

No uses la etiqueta `latest` en producción. Fija una versión explícita, preferiblemente un digest de imagen.

Prueba cada actualización en un entorno que no sea de producción. Verifica la imagen, la configuración y las integraciones antes del despliegue.

### ¿El código es de código abierto?

Ayakaleaf Pro y los repositorios de funciones relacionados están disponibles públicamente. Esto permite a los usuarios revisar los cambios y rastrear las fuentes upstream.

El código fuente público permite una revisión independiente. Por sí solo, no garantiza compilaciones de versiones reproducibles.

Antes de actualizar, revisa:

* La etiqueta de la versión o el commit.
* La versión o el digest de la imagen.
* Las dependencias de terceros y los requisitos de licencia.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.