> ## 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. # Fiducia e sicurezza > Comprendi la gestione dei dati, la distribuzione delle build e le responsabilità in materia di sicurezza. 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](https://github.com/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](https://chatgpt.com/codex/cloud/security/findings) 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](/it/on-premises/configuration/overleaf-toolkit/ai-integration "mention") 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](/it/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention"). 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](/it/on-premises/configuration/overleaf-toolkit/s3 "mention") 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.