> ## 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. # Vertrauen und Sicherheit > Verstehen Sie den Umgang mit Daten, die Bereitstellung von Builds und die Verantwortlichkeiten im Bereich Sicherheit. Ayakaleaf Pro läuft in Ihrer Infrastruktur. Sie kontrollieren die Daten, den Zugriff und die Netzwerkgrenzen. Diese Seite erläutert das Standard-Sicherheitsmodell und zeigt außerdem Ihre betrieblichen Verantwortlichkeiten auf. ### Ist Ayakaleaf Pro zuverlässig und sicher? Ayakaleaf Pro ist eine selbst gehostete Erweiterung von Overleaf Pro; unser Quellcode ist unter [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro) verfügbar. Ihre Bereitstellung bestimmt, wo Dienste laufen und wo Daten gespeichert werden. Die Sicherheit hängt von Ihrer Konfiguration und Ihrem Betrieb ab. Schützen Sie den Administratorzugang, aktivieren Sie HTTPS und erstellen Sie regelmäßig Backups. Wir danken OpenAI für die freundliche Unterstützung. Wir verwenden regelmäßig [Codex Security](https://chatgpt.com/codex/cloud/security/findings), um unser Repository auf Sicherheitsprobleme zu überprüfen, und veröffentlichen die Ergebnisse der Schwachstellenbehebungen. ### Wohin gehen meine Daten? Standardmäßig verbleiben Anwendungsdaten innerhalb Ihrer Bereitstellung: * MongoDB speichert Benutzer- und Projektdaten. * Redis speichert Cache- und Echtzeit-Kollaborationsdaten. * Lokale Volumes oder S3-kompatibler Speicher enthalten die Projektdateien. Standardmäßig ist nur der Webdienst nach außen erreichbar. Interne Dienste kommunizieren über das Docker-Netzwerk. ### Werden meine Daten an Dritte gesendet oder von Dritten abgerufen? Nichts verlässt Ihre Bereitstellung, sofern Sie nicht eine Funktion aktivieren, die dies erfordert. Ayakaleaf Pro sendet *keine Telemetrie, keine Nutzungsanalysen und keine Absturzberichte*. Fehlerberichte und Analysen sind in der Standardkonfiguration deaktiviert. Mehrere Funktionen stellen überhaupt keine externen Anfragen. Vorlagen werden in Ihrer eigenen Bereitstellung gespeichert und von dort ausgeliefert. Der Python Script Runner wird über WebAssembly im Browser des Benutzers ausgeführt, und seine Laufzeitumgebung wird von Ihrem eigenen Webdienst statt von einem öffentlichen CDN bereitgestellt, sodass Skriptcode und Ausgaben niemals ins Netzwerk gelangen. Git Bridge ist nur im internen Docker-Netzwerk erreichbar. Die vollständige Projektsuche, die Symbolpalette, die Änderungsverfolgung, der Projektverlauf und das Admin-Panel sind vollständig lokal. Container für die Sandbox-Kompilierung werden mit deaktiviertem Netzwerk erstellt. Die übrigen Funktionen senden Anfragen an die folgenden Ziele. Jede Anfrage geht vom Webdienst aus: KI-Funktionen sind standardmäßig deaktiviert. Sind sie aktiviert, senden der Chat und die Vorschläge zu LaTeX-Fehlern Prompts und relevanten Projektkontext an den mit `AI_BASE_URL` konfigurierten Modell-Endpunkt. Die optionale Websuche sendet Anfragen an den konfigurierten Tavily-kompatiblen Dienst, und die Dokumentationssuche sendet Anfragen an `DOCS_MCP_URL` (Standard: `https://docs.overleaf.com/~gitbook/mcp`). Suchergebnisse können in Anfragen an den Modellanbieter einfließen. Konfiguration und Benutzereinstellungen finden Sie unter [KI-Integration](/de/on-premises/configuration/overleaf-toolkit/ai-integration "mention"). Die **GitHub-Integration** kontaktiert `github.com` und `api.github.com`. Sie wird pro Benutzer durch Verknüpfen eines GitHub-Kontos aktiviert, und bei der Autorisierung werden die Scopes `read:org`, `repo` und `workflow` angefordert. Beim Pushen werden die vollständigen Inhalte der Projektdateien als Git-Blobs hochgeladen, die anschließend zu Trees und Commits zusammengesetzt werden. Außerdem werden Branch-, Referenz-, Vergleichs- und Merge-Operationen durchgeführt sowie das Profil, die Organisationsmitgliedschaften und die Repository-Liste des verknüpften Kontos gelesen. Projektinhalte verlassen Ihre Bereitstellung in beide Richtungen – betrachten Sie ein verknüpftes GitHub-Konto als Exportweg für jedes damit verbundene Projekt. Die **Zotero-Integration** kontaktiert `www.zotero.org` für die Autorisierung und `api.zotero.org` für Bibliotheksdaten. Sie wird pro Benutzer durch Verknüpfen eines Zotero-Kontos aktiviert. Dabei werden der OAuth-Handshake und der API-Schlüssel des Benutzers übertragen. Lesezugriffe erfolgen nur in eine Richtung: Literaturbibliotheken werden als BibTeX abgerufen, und es werden keine Projektinhalte hochgeladen. Die **Mendeley-Integration** kontaktiert `api.mendeley.com` sowohl für die Autorisierung als auch für Bibliotheksdaten. Sie wird pro Benutzer durch Verknüpfen eines Mendeley-Kontos aktiviert. Der OAuth-Handshake fordert den Scope `all` von Mendeley an – den einzigen Scope, den die API anbietet –, Ayakaleaf führt jedoch ausschließlich Lesezugriffe durch: Literatur- und Gruppenbibliotheken werden als BibTeX abgerufen, und es werden keine Projektinhalte hochgeladen. Zugriffstoken werden automatisch erneuert; widerruft Mendeley eine Berechtigung, wird die gespeicherte Anmeldeinformation verworfen und der Benutzer aufgefordert, das Konto erneut zu verknüpfen. **Dokumentationsseiten** werden von `https://learnwiki.overleaf.com` abgerufen; dies ist über `WIKI_URL` konfigurierbar. Die Anfragen stellt der Webdienst, nicht der Browser des Benutzers, sodass das Upstream-Wiki nur Ihren Server und niemals die Adressen Ihrer Benutzer sieht. Es wird nur der angeforderte Seitentitel gesendet, und die Antworten werden auf der Festplatte zwischengespeichert. Lassen Sie `WIKI_URL` auf Ihren eigenen Mirror verweisen oder blockieren Sie das Ziel, wenn ausgehender Datenverkehr für die Dokumentation nicht akzeptabel ist. Der **E-Mail-Versand** kontaktiert den SMTP-Server oder die Mail-API, die Sie konfigurieren; es gibt keinen Standardwert. Empfängeradressen und Nachrichteninhalte verlassen Ihre Bereitstellung, einschließlich Links zum Zurücksetzen des Passworts und Einladungslinks. Zwei optionale Prüfungen sind standardmäßig deaktiviert. Die Prüfung auf kompromittierte Passwörter ist inaktiv, sofern `HAVE_I_BEEN_PWNED_ENABLED` nicht gesetzt ist; ist sie aktiviert, sendet sie die ersten Zeichen eines SHA-1-Hashes des Passworts an `api.pwnedpasswords.com`, niemals das Passwort selbst. Die CAPTCHA-Verifizierung ist inaktiv, sofern kein reCAPTCHA-Site-Key konfiguriert ist, und kontaktiert im aktiven Zustand `www.google.com`. **Single Sign-On** kontaktiert ausschließlich den von Ihnen angegebenen Identitätsanbieter, und welche Daten dorthin übertragen werden, hängt vom Protokoll ab. Bei LDAP verbindet sich der Webdienst direkt mit Ihrem Verzeichnis: Er bindet sich mit dem von Ihnen konfigurierten Dienstkonto, sucht unterhalb der von Ihnen festgelegten Basis, Filter und Attributliste und prüft das im Anmeldeformular eingegebene Passwort gegen Ihr Verzeichnis, sodass Benutzername und Passwort den Verzeichnisserver erreichen. Wenn Sie verzeichnisbasierte Kontakte aktivieren, wird eine zusätzliche Suche durchgeführt, um die Kontaktliste zu füllen. Bei OIDC tauscht der Webdienst den Autorisierungscode an Ihrem Token-Endpunkt ein und ruft anschließend Ihren User-Info-Endpunkt auf, wobei standardmäßig die Scopes `openid profile email` angefordert werden; dies ist über `OVERLEAF_OIDC_SCOPE` konfigurierbar. Bei SAML wird die Authentifizierungsanfrage über den Browser des Benutzers an den Identitätsanbieter übermittelt statt über eine direkte Serververbindung. In allen drei Fällen werden Name und E-Mail-Adresse des Benutzers vom Anbieter empfangen, nicht an ihn gesendet, und anschließend im lokalen Benutzerdatensatz gespeichert. **Anmeldeinformationen von Drittanbietern** – OAuth-Token und API-Schlüssel – werden in MongoDB im Benutzerdatensatz gespeichert, verschlüsselt mit AES-256-CTR mit einem eigenen Salt und Initialisierungsvektor pro Datensatz. Sie werden niemals im Klartext gespeichert und niemals in Logs geschrieben. Der Verschlüsselungsschlüssel stammt aus `${PROVIDER}_CIPHER_PASSWORD`, falls gesetzt (etwa bei Zotero und Mendeley); andernfalls wird bei der ersten Verwendung ein Schlüssel erzeugt und mit Berechtigungen nur für den Eigentümer in Ihrem Daten-Volume gespeichert. Sichern Sie diesen Schlüssel zusammen mit Ihrem Daten-Volume: Geht er verloren, können gespeicherte Anmeldeinformationen nicht entschlüsselt werden, und alle Benutzer müssen ihre Konten erneut verknüpfen. **Über eine URL verknüpfte Dateien** werden von Ihrer Bereitstellung im Namen des Benutzers abgerufen, das Ziel ist also die Adresse, die der Benutzer angibt. Über URLs verknüpfte Dateien sind deaktiviert, solange Sie `url` nicht zu `ENABLED_LINKED_FILE_TYPES` hinzufügen, und die Standardkonfiguration enthält diesen Wert nicht. Externe ZIP- und TeX-Importe über die Open in Overleaf API verwenden ebenfalls die Komponente `linked-url-proxy`. Direkte Anfragen lösen den Hostnamen des Ziels auf und lehnen eingeschränkte Netzwerkbereiche ab, vorbehaltlich konfigurierter Ausnahmen für erlaubte Ressourcen. Ist `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` konfiguriert, löst der ausgehende Proxy die Hostnamen auf und muss daher selbst Einschränkungen für das interne Netzwerk durchsetzen; die Netzwerkprüfungen der Anwendung gelten dann nur für URLs, die IP-Adressen enthalten. Details finden Sie unter [Externe URL – Ausgehender Proxy](/de/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention"). Diese Anfragen rufen die angegebene URL ab, statt Projektdateien hochzuladen. Wenn Ihre Richtlinien eine Allow-List für ausgehenden Datenverkehr verlangen, erlauben Sie nur die Hosts der von Ihnen aktivierten Funktionen – `github.com` und `api.github.com` für GitHub, `www.zotero.org` und `api.zotero.org` für Zotero, `api.mendeley.com` für Mendeley, `learnwiki.overleaf.com` oder Ihre eigene `WIKI_URL` für die Dokumentation, `api.pwnedpasswords.com` für die Passwortprüfung, `www.google.com` für CAPTCHA sowie Ihren eigenen Mailserver und Identitätsanbieter. Wenn KI-Funktionen oder die Suche aktiviert sind, erlauben Sie zusätzlich die konfigurierten Endpunkte für Modell, Websuche und Dokumentations-MCP. Verweigern Sie Ziele, die für Ihre aktivierten Funktionen nicht benötigt werden. Wenn ausgehender Datenverkehr zentral geprüft oder protokolliert werden muss, können die Integrationen für GitHub, Zotero und Mendeley jeweils über einen HTTP-Proxy geleitet werden, indem Sie `GITHUB_SYNC_PROXY_URL`, `MENDELEY_PROXY_URL` und `ZOTERO_PROXY_URL` setzen. Das Abrufen verknüpfter URLs und Remote-Importe können `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` verwenden. Über eine URL verknüpfte Dateien lassen sich nicht auf eine Host-Liste beschränken, da das Ziel vom Benutzer zum Zeitpunkt der Anfrage gewählt wird; schränken Sie diese Funktion über die Einstellung für erlaubte Ressourcen der Proxy-Komponente ein oder lassen Sie sie deaktiviert. Wenn Sie Ayakaleaf Pro mit aktiviertem [s3.md](/de/on-premises/configuration/overleaf-toolkit/s3 "mention")-Speicher bereitstellen: Sind die in S3 gespeicherten Daten verschlüsselt? *Nein.* Die Daten sind nicht verschlüsselt. Alle History-Chunks, Vorlagendateien, PDFs und anderen Dateien werden im Klartext gespeichert. Wenn Sie einen externen S3-Speicheranbieter eines Drittanbieters verwenden, achten Sie bitte besonders auf Datensicherheit und Datenschutz. ### Sind Projektkompilierungen isoliert? Ayakaleaf Pro unterstützt die Sandbox-Kompilierung. Jede Kompilierung läuft in einem separaten Container. Sandbox-Container haben standardmäßig keinen Netzwerkzugriff. Das verringert die Angriffsfläche gegenüber internen Netzwerkressourcen. Die Sandbox-Kompilierung erfordert Zugriff auf den Docker-Socket des Hosts. Beschränken Sie die Host-Administration auf vertrauenswürdige Betreiber. ### Kann ich CI-Builds und Container-Images vertrauen? GitHub Actions baut und veröffentlicht die Container-Images von Ayakaleaf Pro. Die Images sind über die öffentliche GitHub Container Registry verfügbar. Die Images unterstützen `amd64` und `arm64`. Docker wählt beim Herunterladen eines Images die passende Architektur aus. Verwenden Sie in der Produktion nicht den Tag `latest`. Legen Sie eine explizite Version fest, vorzugsweise einen Image-Digest. Testen Sie jedes Upgrade in einer Nicht-Produktionsumgebung. Überprüfen Sie Image, Konfiguration und Integrationen vor dem Rollout. ### Ist der Code Open Source? Ayakaleaf Pro und die zugehörigen Feature-Repositories sind öffentlich verfügbar. So können Benutzer Änderungen überprüfen und Upstream-Quellen nachverfolgen. Öffentlicher Quellcode ermöglicht eine unabhängige Überprüfung. Er garantiert für sich genommen jedoch keine reproduzierbaren Release-Builds. Überprüfen Sie vor einem Upgrade: * Den Release-Tag oder Commit. * Die Image-Version oder den Digest. * Abhängigkeiten von Drittanbietern und Lizenzanforderungen. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.