Skip to main content
Ayakaleaf Pro viene eseguito nella tua infrastruttura. Sei tu a controllarne i dati, gli accessi e i confini di rete. Questa pagina illustra il modello di sicurezza predefinito e indica le tue responsabilità operative.

​
Ayakaleaf Pro è affidabile e sicuro?

Ayakaleaf Pro è un’estensione self-hosted di Overleaf Pro e il nostro codice sorgente è disponibile su ayaka-notes/ayakaleaf-pro. È la tua distribuzione a determinare dove vengono eseguiti i servizi e dove risiedono i dati. La sicurezza dipende dalla tua configurazione e dalla tua gestione operativa. Proteggi l’accesso amministrativo, abilita HTTPS e mantieni dei backup. Ringraziamo OpenAI per il suo gentile supporto. Useremo regolarmente Codex Security per analizzare il nostro repository alla ricerca di problemi di sicurezza e condivideremo pubblicamente i risultati delle correzioni delle vulnerabilità.

​
Dove finiscono i miei dati?

Per impostazione predefinita, i dati dell’applicazione rimangono all’interno della tua distribuzione:
  • MongoDB memorizza i dati degli utenti e dei progetti.
  • Redis memorizza la cache e i dati della collaborazione in tempo reale.
  • I volumi locali o uno storage compatibile con S3 contengono i file dei progetti.
Per impostazione predefinita è esposto solo il servizio web. I servizi interni comunicano tramite la rete Docker.

​
I miei dati verranno inviati a terze parti o recuperati da esse?

Nulla esce dalla tua distribuzione a meno che tu non abiliti una funzionalità che lo richieda. Ayakaleaf Pro non invia alcuna telemetria, alcuna analisi d’uso e alcun crash report. La segnalazione degli errori e le analisi sono disabilitate nella configurazione predefinita. Diverse funzionalità non effettuano mai richieste esterne. I template sono memorizzati e serviti dalla tua distribuzione. Il Python script runner viene eseguito nel browser dell’utente tramite WebAssembly e il suo runtime è servito dal tuo servizio web anziché da una CDN pubblica, quindi il codice degli script e il relativo output non raggiungono mai la rete. Git Bridge è raggiungibile solo sulla rete Docker interna. La ricerca completa nei progetti, la tavolozza dei simboli, il track changes, la cronologia dei progetti e il pannello di amministrazione sono interamente locali. I container di compilazione in sandbox vengono creati con la rete disabilitata. Le restanti funzionalità effettuano richieste verso le seguenti destinazioni. Ogni richiesta ha origine dal servizio web:
Le funzionalità di AI sono disabilitate per impostazione predefinita. Quando sono abilitate, la chat e i suggerimenti per gli errori LaTeX inviano i prompt e il contesto rilevante del progetto all’endpoint del modello configurato con AI_BASE_URL. La ricerca web opzionale invia le query al servizio compatibile con Tavily configurato, mentre la ricerca nella documentazione invia le query a DOCS_MCP_URL (predefinito: https://docs.overleaf.com/~gitbook/mcp). I risultati della ricerca possono essere inclusi nelle richieste al fornitore del modello. Consulta Integrazione AI per la configurazione e i controlli a disposizione degli utenti.
L’integrazione GitHub contatta github.com e api.github.com. Viene abilitata per singolo utente collegando un account GitHub e l’autorizzazione richiede gli scope read:org, repo e workflow. Il push carica il contenuto completo dei file del progetto come blob Git, che vengono poi assemblati in tree e commit. Esegue inoltre operazioni su branch, riferimenti, confronti e merge, e legge il profilo dell’account collegato, le appartenenze alle organizzazioni e l’elenco dei repository. Il contenuto dei progetti esce dalla tua distribuzione in entrambe le direzioni: considera un account GitHub collegato come un canale di esportazione per ogni progetto a esso associato.
L’integrazione Zotero contatta www.zotero.org per l’autorizzazione e api.zotero.org per i dati della libreria. Viene abilitata per singolo utente collegando un account Zotero. Vengono inviati l’handshake OAuth e la chiave API dell’utente. Le letture sono unidirezionali: le librerie di riferimenti vengono importate come BibTeX e nessun contenuto dei progetti viene caricato.
L’integrazione Mendeley contatta api.mendeley.com sia per l’autorizzazione sia per i dati della libreria. Viene abilitata per singolo utente collegando un account Mendeley. L’handshake OAuth richiede lo scope all di Mendeley, l’unico offerto dalla sua API, ma Ayakaleaf esegue sempre e solo letture: le librerie di riferimenti e le librerie di gruppo vengono importate come BibTeX e nessun contenuto dei progetti viene caricato. I token di accesso vengono aggiornati automaticamente; quando Mendeley revoca un’autorizzazione, la credenziale memorizzata viene eliminata e all’utente viene chiesto di collegare nuovamente l’account.
Le pagine di documentazione vengono recuperate da https://learnwiki.overleaf.com, configurabile con WIKI_URL. Le richieste vengono effettuate dal servizio web, non dal browser dell’utente, quindi la wiki upstream vede il tuo server e mai gli indirizzi dei tuoi utenti. Viene inviato solo il titolo della pagina richiesta e le risposte vengono memorizzate nella cache su disco. Se il traffico in uscita verso la documentazione non è accettabile, imposta WIKI_URL su un tuo mirror oppure blocca la destinazione.
L’invio delle email contatta il server SMTP o l’API di posta che configuri; non esiste un valore predefinito. Gli indirizzi dei destinatari e il contenuto dei messaggi escono dalla tua distribuzione, compresi i link di reimpostazione della password e di invito.
Due controlli opzionali sono disabilitati per impostazione predefinita. Il controllo delle password compromesse è inattivo a meno che non sia impostata HAVE_I_BEEN_PWNED_ENABLED; quando è abilitato, invia a api.pwnedpasswords.com i primi caratteri di un hash SHA-1 della password, mai la password stessa. La verifica CAPTCHA è inattiva a meno che non sia configurata una site key reCAPTCHA e, quando è attiva, contatta www.google.com.
Il single sign-on raggiunge solo l’identity provider che fornisci e ciò che vi transita dipende dal protocollo. Con LDAP il servizio web si connette direttamente alla tua directory: esegue il bind con l’account di servizio che configuri, effettua ricerche in base alla base, al filtro e all’elenco di attributi che definisci e verifica la password inserita nel modulo di accesso rispetto alla tua directory, per cui nome utente e password raggiungono il server della directory. L’abilitazione dei contatti basati sulla directory comporta una ricerca aggiuntiva per popolare l’elenco dei contatti. Con OIDC il servizio web scambia il codice di autorizzazione presso il tuo token endpoint e quindi chiama il tuo endpoint user-info, richiedendo per impostazione predefinita gli scope openid profile email; questo è configurabile con OVERLEAF_OIDC_SCOPE. Con SAML la richiesta di autenticazione transita attraverso il browser dell’utente verso l’identity provider, anziché tramite una connessione diretta dal server. In tutti e tre i casi, il nome e l’indirizzo email dell’utente arrivano dal provider anziché essere inviati a esso, e vengono poi memorizzati nel record utente locale.
Le credenziali di terze parti (token OAuth e chiavi API) sono conservate in MongoDB nel record dell’utente, cifrate con AES-256-CTR con un salt e un vettore di inizializzazione specifici per ogni record. Non vengono mai memorizzate in chiaro né scritte nei log. La chiave di cifratura proviene da ${PROVIDER}_CIPHER_PASSWORD, se impostata (come per Zotero e Mendeley); altrimenti ne viene generata una al primo utilizzo e salvata nel tuo volume dei dati con permessi riservati al solo proprietario. Esegui il backup di quella chiave insieme al volume dei dati: se va persa, le credenziali memorizzate non possono essere decifrate e ogni utente dovrà collegare nuovamente i propri account.
I file collegati da un URL vengono recuperati dalla tua distribuzione per conto dell’utente, quindi la destinazione è l’indirizzo fornito dall’utente. I file collegati tramite URL sono disabilitati a meno che tu non aggiunga url a ENABLED_LINKED_FILE_TYPES, e la configurazione predefinita non lo include. Anche le importazioni esterne di ZIP e TeX tramite l’API Open in Overleaf usano lo stesso componente linked-url-proxy. Le richieste dirette risolvono il nome host di destinazione e rifiutano gli intervalli di rete riservati, fatte salve le eccezioni per le risorse consentite configurate. Con OVERLEAF_LINKED_URL_OUTBOUND_PROXY configurato, è il proxy in uscita a risolvere i nomi host, quindi deve applicare autonomamente le restrizioni sulla rete interna; i controlli di rete dell’applicazione si applicano solo agli URL contenenti indirizzi IP. Per i dettagli, consulta URL esterni — Proxy in uscita. Queste richieste recuperano l’URL fornito anziché caricare i file del progetto.
Se i tuoi criteri richiedono una allow-list in uscita, consenti solo gli host delle funzionalità che hai abilitato: github.com e api.github.com per GitHub, www.zotero.org e api.zotero.org per Zotero, api.mendeley.com per Mendeley, learnwiki.overleaf.com o il tuo WIKI_URL per la documentazione, api.pwnedpasswords.com per il controllo delle password, www.google.com per il CAPTCHA, oltre al tuo server di posta e al tuo identity provider. Se le funzionalità di AI o la ricerca sono abilitate, consenti anche gli endpoint configurati del modello, della ricerca web e del MCP della documentazione. Nega le destinazioni non richieste dalle funzionalità abilitate. Se il traffico in uscita deve essere ispezionato o registrato centralmente, le integrazioni GitHub, Zotero e Mendeley possono essere instradate ciascuna attraverso un proxy HTTP impostando GITHUB_SYNC_PROXY_URL, MENDELEY_PROXY_URL e ZOTERO_PROXY_URL. Il recupero dei file collegati tramite URL e le importazioni remote possono usare OVERLEAF_LINKED_URL_OUTBOUND_PROXY. I file collegati da un URL non possono essere limitati a un elenco di host, poiché la destinazione viene scelta dall’utente al momento della richiesta; limita questa funzionalità tramite l’impostazione delle risorse consentite del componente proxy, oppure lasciala disabilitata.
Se distribuisci Ayakaleaf Pro con lo storage s3.md abilitato, i dati memorizzati in S3 sono cifrati?No. I dati non sono cifrati. Tutti i chunk della cronologia, i file dei template, i PDF e gli altri file sono memorizzati in chiaro. Se usi un fornitore esterno di storage S3 di terze parti, presta molta attenzione alla sicurezza e alla privacy dei dati.

​
Le compilazioni dei progetti sono isolate?

Ayakaleaf Pro supporta le compilazioni in sandbox. Ogni compilazione viene eseguita in un container separato. Per impostazione predefinita, i container sandbox non hanno accesso alla rete. Ciò riduce l’esposizione alle risorse della rete interna. Le compilazioni in sandbox richiedono l’accesso al socket Docker dell’host. Limita l’amministrazione dell’host a operatori fidati.

​
Posso fidarmi delle build CI e delle immagini dei container?

GitHub Actions costruisce e pubblica le immagini dei container di Ayakaleaf Pro. Le immagini sono disponibili sul GitHub Container Registry pubblico. Le immagini supportano amd64 e arm64. Docker seleziona l’architettura corrispondente durante il pull di un’immagine. Non usare il tag latest in produzione. Fissa una versione esplicita, preferibilmente un digest dell’immagine. Testa ogni aggiornamento in un ambiente non di produzione. Verifica l’immagine, la configurazione e le integrazioni prima del rilascio.

​
Il codice è open source?

Ayakaleaf Pro e i relativi repository delle funzionalità sono pubblicamente disponibili. Ciò consente agli utenti di esaminare le modifiche e risalire alle fonti upstream. Il codice sorgente pubblico consente una revisione indipendente. Di per sé, tuttavia, non garantisce build di rilascio riproducibili. Prima di eseguire un aggiornamento, verifica:
  • Il tag o il commit della release.
  • La versione o il digest dell’immagine.
  • Le dipendenze di terze parti e i requisiti di licenza.
Ultima modifica il 5 ottobre 2026