Skip to main content
Ayakaleaf Pro draait in uw infrastructuur. U beheert de gegevens, de toegang en de netwerkgrenzen. Deze pagina legt het standaardbeveiligingsmodel uit en geeft aan welke operationele verantwoordelijkheden bij u liggen.

Is Ayakaleaf Pro betrouwbaar en veilig?

Ayakaleaf Pro is een zelfgehoste uitbreiding van Overleaf Pro, en onze broncode is beschikbaar op ayaka-notes/ayakaleaf-pro. Uw implementatie bepaalt waar services draaien en waar gegevens zich bevinden. Beveiliging hangt af van uw configuratie en beheer. Bescherm de beheerderstoegang, schakel HTTPS in en onderhoud back-ups. Dank aan OpenAI voor hun vriendelijke ondersteuning. We gebruiken regelmatig Codex Security om onze repository op beveiligingsproblemen te scannen en delen de resultaten van kwetsbaarheidsoplossingen openbaar.

Waar gaan mijn gegevens naartoe?

Standaard blijven de applicatiegegevens binnen uw implementatie:
  • MongoDB slaat gebruikers- en projectgegevens op.
  • Redis slaat cache- en realtime-samenwerkingsgegevens op.
  • Lokale volumes of S3-compatibele opslag bevatten projectbestanden.
Standaard is alleen de webservice extern bereikbaar. Interne services communiceren via het Docker-netwerk.

Worden mijn gegevens naar derden verzonden of van derden opgehaald?

Er verlaat niets uw implementatie, tenzij u een functie inschakelt die dat vereist. Ayakaleaf Pro verstuurt geen telemetrie, geen gebruiksanalyses en geen crashrapporten. Foutrapportage en analyses zijn uitgeschakeld in de standaardconfiguratie. Verschillende functies doen helemaal geen externe verzoeken. Sjablonen worden opgeslagen en aangeboden vanuit uw eigen implementatie. De Python-scriptrunner draait in de browser van de gebruiker via WebAssembly, en de runtime ervan wordt aangeboden door uw eigen webservice in plaats van een openbaar CDN, zodat scriptcode en uitvoer het netwerk nooit bereiken. Git Bridge is alleen bereikbaar via het interne Docker-netwerk. Zoeken in het volledige project, het symboolpalet, wijzigingen bijhouden, de projectgeschiedenis en het beheerpaneel zijn volledig lokaal. Sandbox-compilatiecontainers worden aangemaakt met uitgeschakeld netwerk. De verzoeken van de overige functies gaan naar de volgende bestemmingen. Elk verzoek komt van de webservice:
AI-functies zijn standaard uitgeschakeld. Wanneer ze zijn ingeschakeld, sturen chat en suggesties voor LaTeX-fouten prompts en relevante projectcontext naar het modelendpoint dat is geconfigureerd met AI_BASE_URL. Optioneel zoeken op het web stuurt zoekopdrachten naar de geconfigureerde Tavily-compatibele service, en zoeken in de documentatie stuurt zoekopdrachten naar DOCS_MCP_URL (standaard: https://docs.overleaf.com/~gitbook/mcp). Zoekresultaten kunnen worden meegestuurd in verzoeken aan de modelaanbieder. Zie AI-integratie voor configuratie en gebruikersinstellingen.
GitHub-integratie maakt contact met github.com en api.github.com. Ze wordt per gebruiker ingeschakeld door een GitHub-account te koppelen, en de autorisatie vraagt de scopes read:org, repo en workflow aan. Bij een push wordt de volledige inhoud van de projectbestanden geüpload als Git-blobs, die vervolgens worden samengesteld tot trees en commits. Er worden ook branch-, reference-, compare- en merge-bewerkingen uitgevoerd, en het profiel, de organisatielidmaatschappen en de repositorylijst van het gekoppelde account worden gelezen. Projectinhoud verlaat uw implementatie in beide richtingen — beschouw een gekoppeld GitHub-account als een exportpad voor elk project dat eraan is gekoppeld.
Zotero-integratie maakt contact met www.zotero.org voor autorisatie en met api.zotero.org voor bibliotheekgegevens. Ze wordt per gebruiker ingeschakeld door een Zotero-account te koppelen. De OAuth-handshake en de API-sleutel van de gebruiker worden verzonden. Het lezen gebeurt in één richting: referentiebibliotheken worden als BibTeX binnengehaald en er wordt geen projectinhoud geüpload.
Mendeley-integratie maakt contact met api.mendeley.com voor zowel autorisatie als bibliotheekgegevens. Ze wordt per gebruiker ingeschakeld door een Mendeley-account te koppelen. De OAuth-handshake vraagt de scope all van Mendeley aan — de enige scope die de API aanbiedt — maar Ayakaleaf voert uitsluitend leesbewerkingen uit: referentiebibliotheken en groepsbibliotheken worden als BibTeX binnengehaald en er wordt geen projectinhoud geüpload. Toegangstokens worden automatisch vernieuwd; wanneer Mendeley een toestemming intrekt, wordt de opgeslagen referentie verwijderd en wordt de gebruiker gevraagd het account opnieuw te koppelen.
Documentatiepagina’s worden opgehaald van https://learnwiki.overleaf.com, configureerbaar met WIKI_URL. De verzoeken worden gedaan door de webservice, niet door de browser van de gebruiker, zodat de upstream-wiki uw server ziet en nooit de adressen van uw gebruikers. Alleen de titel van de opgevraagde pagina wordt verzonden, en de antwoorden worden op schijf gecachet. Laat WIKI_URL naar uw eigen mirror verwijzen of blokkeer de bestemming als uitgaand documentatieverkeer niet acceptabel is.
E-mailbezorging maakt contact met de SMTP-server of mail-API die u configureert; er is geen standaardwaarde. Ontvangeradressen en berichtinhoud verlaten uw implementatie, inclusief links voor het opnieuw instellen van wachtwoorden en uitnodigingslinks.
Twee optionele controles zijn standaard uitgeschakeld. De controle op gelekte wachtwoorden is inactief tenzij HAVE_I_BEEN_PWNED_ENABLED is ingesteld; wanneer ingeschakeld, stuurt deze de eerste tekens van een SHA-1-hash van het wachtwoord naar api.pwnedpasswords.com, nooit het wachtwoord zelf. CAPTCHA-verificatie is inactief tenzij een reCAPTCHA-sitesleutel is geconfigureerd, en maakt contact met www.google.com wanneer ze actief is.
Single sign-on maakt alleen contact met de identiteitsprovider die u opgeeft, en wat daarheen gaat, hangt af van het protocol. Bij LDAP maakt de webservice rechtstreeks verbinding met uw directory: deze bindt met het serviceaccount dat u configureert, zoekt binnen de base, het filter en de attributenlijst die u definieert, en verifieert het op het inlogformulier ingevoerde wachtwoord tegen uw directory, zodat de gebruikersnaam en het wachtwoord de directoryserver bereiken. Het inschakelen van contacten op basis van de directory leidt tot een extra zoekopdracht om de contactlijst te vullen. Bij OIDC wisselt de webservice de autorisatiecode in bij uw tokenendpoint en roept vervolgens uw user-info-endpoint aan, waarbij standaard de scopes openid profile email worden aangevraagd; dit is configureerbaar met OVERLEAF_OIDC_SCOPE. Bij SAML gaat het authenticatieverzoek via de browser van de gebruiker naar de identiteitsprovider in plaats van via een directe serververbinding. In alle drie de gevallen worden de naam en het e-mailadres van de gebruiker van de provider ontvangen in plaats van ernaartoe gestuurd, en vervolgens opgeslagen in het lokale gebruikersrecord.
Referenties van derden — OAuth-tokens en API-sleutels — worden in MongoDB bewaard in het gebruikersrecord, versleuteld met AES-256-CTR met een salt en initialisatievector per record. Ze worden nooit in platte tekst opgeslagen en nooit naar logs geschreven. De versleutelingssleutel komt uit ${PROVIDER}_CIPHER_PASSWORD als die is ingesteld (zoals bij Zotero en Mendeley); anders wordt er bij het eerste gebruik een gegenereerd en in uw datavolume opgeslagen met rechten die alleen voor de eigenaar gelden. Maak een back-up van die sleutel samen met uw datavolume: als deze verloren gaat, kunnen opgeslagen referenties niet worden ontsleuteld en moet elke gebruiker zijn accounts opnieuw koppelen.
Bestanden gekoppeld via een URL worden namens de gebruiker door uw implementatie opgehaald, dus de bestemming is het adres dat de gebruiker opgeeft. Via een URL gekoppelde bestanden zijn uitgeschakeld tenzij u url toevoegt aan ENABLED_LINKED_FILE_TYPES, en de standaardconfiguratie bevat dit niet. Externe ZIP- en TeX-imports via de Open in Overleaf API gebruiken ook dezelfde component linked-url-proxy. Directe verzoeken resolven de doelhostnaam en weigeren beperkte netwerkbereiken, met inachtneming van geconfigureerde uitzonderingen voor toegestane resources. Als OVERLEAF_LINKED_URL_OUTBOUND_PROXY is geconfigureerd, resolvet de uitgaande proxy de hostnamen, dus moet die zelf de beperkingen voor het interne netwerk afdwingen; de netwerkcontroles van de applicatie gelden alleen voor URL’s die IP-adressen bevatten. Zie Externe URL — Uitgaande proxy voor details. Deze verzoeken halen de opgegeven URL op in plaats van projectbestanden te uploaden.
Als uw beleid een allowlist voor uitgaand verkeer vereist, sta dan alleen de hosts toe van de functies die u hebt ingeschakeld — github.com en api.github.com voor GitHub, www.zotero.org en api.zotero.org voor Zotero, api.mendeley.com voor Mendeley, learnwiki.overleaf.com of uw eigen WIKI_URL voor documentatie, api.pwnedpasswords.com voor de wachtwoordcontrole, www.google.com voor CAPTCHA, plus uw eigen mailserver en identiteitsprovider. Als AI-functies of zoeken zijn ingeschakeld, sta dan ook de geconfigureerde endpoints voor het model, het zoeken op het web en de documentatie-MCP toe. Weiger bestemmingen die niet nodig zijn voor uw ingeschakelde functies. Waar uitgaand verkeer centraal moet worden geïnspecteerd of gelogd, kunnen de GitHub-, Zotero- en Mendeley-integraties elk via een HTTP-proxy worden geleid door GITHUB_SYNC_PROXY_URL, MENDELEY_PROXY_URL en ZOTERO_PROXY_URL in te stellen. Het ophalen van gekoppelde URL’s en externe imports kunnen OVERLEAF_LINKED_URL_OUTBOUND_PROXY gebruiken. Bestanden die via een URL zijn gekoppeld, kunnen niet tot een lijst van hosts worden beperkt, omdat de gebruiker de bestemming kiest op het moment van het verzoek; beperk die functie via de eigen instelling voor toegestane resources van de proxycomponent, of laat haar uitgeschakeld.
Als u Ayakaleaf Pro implementeert met s3.md-opslag ingeschakeld, worden de in S3 opgeslagen gegevens dan versleuteld?Nee. De gegevens worden niet versleuteld. Alle history-chunks, sjabloonbestanden, pdf’s en andere bestanden worden in platte tekst opgeslagen. Als u een externe S3-opslagprovider van derden gebruikt, let dan goed op gegevensbeveiliging en privacy.

Zijn projectcompilaties geïsoleerd?

Ayakaleaf Pro ondersteunt gesandboxte compilaties. Elke compilatie draait in een aparte container. Sandboxcontainers hebben standaard geen netwerktoegang. Dat beperkt de blootstelling aan interne netwerkbronnen. Gesandboxte compilaties vereisen toegang tot de Docker-socket van de host. Beperk het beheer van de host tot vertrouwde beheerders.

Kan ik CI-builds en container-images vertrouwen?

GitHub Actions bouwt en publiceert de container-images van Ayakaleaf Pro. De images zijn beschikbaar via de openbare GitHub Container Registry. De images ondersteunen amd64 en arm64. Docker kiest bij het pullen van een image automatisch de passende architectuur. Gebruik de tag latest niet in productie. Pin een expliciete versie vast, bij voorkeur een image-digest. Test elke upgrade in een niet-productieomgeving. Controleer de image, de configuratie en de integraties voordat u uitrolt.

Is de code open source?

Ayakaleaf Pro en de bijbehorende functierepository’s zijn openbaar beschikbaar. Zo kunnen gebruikers wijzigingen beoordelen en upstream-bronnen traceren. Openbare broncode maakt onafhankelijke beoordeling mogelijk. Op zichzelf garandeert dat echter geen reproduceerbare release-builds. Controleer vóór het upgraden:
  • De releasetag of commit.
  • De imageversie of digest.
  • Afhankelijkheden van derden en licentievereisten.
Laatst gewijzigd op 5 oktober 2026