> ## 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. # Zaufanie i bezpieczeństwo > Poznaj sposób przetwarzania danych, dostarczania buildów oraz podział odpowiedzialności za bezpieczeństwo. Ayakaleaf Pro działa w Twojej infrastrukturze. To Ty kontrolujesz jego dane, dostęp i granice sieci. Ta strona wyjaśnia domyślny model bezpieczeństwa, a także wskazuje Twoje obowiązki operacyjne. ### Czy Ayakaleaf Pro jest niezawodny i bezpieczny? Ayakaleaf Pro to samodzielnie hostowane rozszerzenie Overleaf Pro, a nasz kod źródłowy jest dostępny pod adresem [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro). To Twoje wdrożenie decyduje o tym, gdzie działają usługi i gdzie znajdują się dane. Bezpieczeństwo zależy od Twojej konfiguracji i sposobu eksploatacji. Chroń dostęp administracyjny, włącz HTTPS i regularnie twórz kopie zapasowe. Dziękujemy OpenAI za życzliwe wsparcie. Będziemy regularnie używać [Codex Security](https://chatgpt.com/codex/cloud/security/findings) do skanowania naszego repozytorium pod kątem problemów z bezpieczeństwem i publicznie udostępniać wyniki naprawy podatności. ### Gdzie trafiają moje dane? Domyślnie dane aplikacji pozostają w obrębie Twojego wdrożenia: * MongoDB przechowuje dane użytkowników i projektów. * Redis przechowuje pamięć podręczną i dane współpracy w czasie rzeczywistym. * Lokalne wolumeny lub magazyn zgodny z S3 przechowują pliki projektów. Domyślnie udostępniona na zewnątrz jest tylko usługa webowa. Usługi wewnętrzne komunikują się przez sieć Dockera. ### Czy moje dane będą wysyłane do stron trzecich lub z nich pobierane? Nic nie opuszcza Twojego wdrożenia, chyba że włączysz funkcję, która tego wymaga. Ayakaleaf Pro *nie wysyła telemetrii, analityki użytkowania ani raportów o awariach*. Raportowanie błędów i analityka są wyłączone w konfiguracji domyślnej. Kilka funkcji w ogóle nie wykonuje żadnych żądań zewnętrznych. Szablony są przechowywane i serwowane z Twojego własnego wdrożenia. Moduł uruchamiania skryptów Python działa w przeglądarce użytkownika za pośrednictwem WebAssembly, a jego środowisko uruchomieniowe jest serwowane z Twojej własnej usługi webowej, a nie z publicznego CDN, więc kod skryptów i ich wyniki nigdy nie trafiają do sieci. Git Bridge jest dostępny tylko w wewnętrznej sieci Dockera. Pełne wyszukiwanie w projekcie, paleta symboli, śledzenie zmian, historia projektu i panel administracyjny działają w całości lokalnie. Kontenery kompilacji w trybie sandbox są tworzone z wyłączoną siecią. Żądania pozostałych funkcji trafiają do poniższych miejsc docelowych. Każde żądanie pochodzi z usługi webowej: Funkcje AI są domyślnie wyłączone. Po ich włączeniu czat i sugestie dotyczące błędów LaTeX wysyłają prompty i odpowiedni kontekst projektu do punktu końcowego modelu skonfigurowanego za pomocą `AI_BASE_URL`. Opcjonalne wyszukiwanie w sieci wysyła zapytania do skonfigurowanej usługi zgodnej z Tavily, a wyszukiwanie w dokumentacji wysyła zapytania do `DOCS_MCP_URL` (domyślnie: `https://docs.overleaf.com/~gitbook/mcp`). Wyniki wyszukiwania mogą być dołączane do żądań wysyłanych do dostawcy modelu. Informacje o konfiguracji i ustawieniach dostępnych dla użytkowników znajdziesz w [AI Integration](/pl/on-premises/configuration/overleaf-toolkit/ai-integration "mention"). **Integracja z GitHub** łączy się z `github.com` i `api.github.com`. Jest włączana indywidualnie przez każdego użytkownika poprzez połączenie konta GitHub, a autoryzacja żąda zakresów `read:org`, `repo` i `workflow`. Wypychanie (push) przesyła pełną zawartość plików projektu jako bloby Git, które są następnie składane w drzewa i commity. Integracja wykonuje również operacje na gałęziach, referencjach, porównaniach i scaleniach oraz odczytuje profil połączonego konta, przynależność do organizacji i listę repozytoriów. Treść projektu opuszcza Twoje wdrożenie w obu kierunkach — traktuj połączone konto GitHub jako ścieżkę eksportu dla każdego dołączonego do niego projektu. **Integracja z Zotero** łączy się z `www.zotero.org` w celu autoryzacji i z `api.zotero.org` w celu pobrania danych biblioteki. Jest włączana indywidualnie przez każdego użytkownika poprzez połączenie konta Zotero. Wysyłane są dane uzgadniania OAuth oraz klucz API użytkownika. Odczyt odbywa się jednokierunkowo: biblioteki bibliograficzne są pobierane w formacie BibTeX i żadna treść projektu nie jest przesyłana. **Integracja z Mendeley** łączy się z `api.mendeley.com` zarówno w celu autoryzacji, jak i pobrania danych biblioteki. Jest włączana indywidualnie przez każdego użytkownika poprzez połączenie konta Mendeley. Uzgadnianie OAuth żąda zakresu `all` Mendeley — jedynego zakresu oferowanego przez jego API — ale Ayakaleaf wykonuje wyłącznie odczyty: biblioteki bibliograficzne i biblioteki grupowe są pobierane w formacie BibTeX i żadna treść projektu nie jest przesyłana. Tokeny dostępu są odświeżane automatycznie; gdy Mendeley cofnie uprawnienie, zapisane dane uwierzytelniające są usuwane, a użytkownik jest proszony o ponowne połączenie konta. **Strony dokumentacji** są pobierane z `https://learnwiki.overleaf.com`, co można skonfigurować za pomocą `WIKI_URL`. Żądania wykonuje usługa webowa, a nie przeglądarka użytkownika, więc nadrzędne wiki widzi Twój serwer, a nigdy adresy Twoich użytkowników. Wysyłany jest tylko tytuł żądanej strony, a odpowiedzi są buforowane na dysku. Jeśli wychodzący ruch związany z dokumentacją jest niedopuszczalny, wskaż w `WIKI_URL` własny serwer lustrzany lub zablokuj to miejsce docelowe. **Wysyłka e-maili** łączy się z dowolnym skonfigurowanym przez Ciebie serwerem SMTP lub API pocztowym; nie ma ustawienia domyślnego. Adresy odbiorców i treść wiadomości opuszczają Twoje wdrożenie, w tym linki do resetowania hasła i zaproszenia. Dwie opcjonalne weryfikacje są domyślnie wyłączone. Sprawdzanie, czy hasło nie wyciekło, jest nieaktywne, dopóki nie zostanie ustawione `HAVE_I_BEEN_PWNED_ENABLED`; po włączeniu wysyła pierwsze znaki skrótu SHA-1 hasła do `api.pwnedpasswords.com`, nigdy samo hasło. Weryfikacja CAPTCHA jest nieaktywna, dopóki nie zostanie skonfigurowany klucz witryny reCAPTCHA; gdy jest aktywna, łączy się z `www.google.com`. **Logowanie jednokrotne (SSO)** łączy się wyłącznie z dostarczonym przez Ciebie dostawcą tożsamości, a to, jakie dane są przesyłane, zależy od protokołu. W przypadku LDAP usługa webowa łączy się bezpośrednio z Twoim katalogiem: wykonuje bind przy użyciu skonfigurowanego konta usługi, wyszukuje w ramach zdefiniowanej bazy, filtra i listy atrybutów oraz weryfikuje hasło wprowadzone w formularzu logowania względem katalogu, więc nazwa użytkownika i hasło trafiają do serwera katalogowego. Włączenie kontaktów opartych na katalogu powoduje dodatkowe wyszukiwanie w celu wypełnienia listy kontaktów. W przypadku OIDC usługa webowa wymienia kod autoryzacyjny w Twoim punkcie końcowym tokenów, a następnie wywołuje punkt końcowy informacji o użytkowniku, domyślnie żądając zakresów `openid profile email`; można to skonfigurować za pomocą `OVERLEAF_OIDC_SCOPE`. W przypadku SAML żądanie uwierzytelnienia trafia do dostawcy tożsamości przez przeglądarkę użytkownika, a nie przez bezpośrednie połączenie z serwera. We wszystkich trzech przypadkach imię i nazwisko oraz adres e-mail użytkownika są otrzymywane od dostawcy, a nie do niego wysyłane, a następnie zapisywane w lokalnym rekordzie użytkownika. **Dane uwierzytelniające usług zewnętrznych** — tokeny OAuth i klucze API — są przechowywane w MongoDB w rekordzie użytkownika, zaszyfrowane algorytmem AES-256-CTR z solą i wektorem inicjalizacyjnym unikalnymi dla każdego rekordu. Nigdy nie są przechowywane jako tekst jawny ani zapisywane w logach. Klucz szyfrujący pochodzi z `${PROVIDER}_CIPHER_PASSWORD`, jeśli jest ustawiony (np. dla Zotero i Mendeley); w przeciwnym razie jest generowany przy pierwszym użyciu i zapisywany w wolumenie danych z uprawnieniami tylko dla właściciela. Twórz kopię zapasową tego klucza razem z wolumenem danych: jeśli zostanie utracony, zapisanych danych uwierzytelniających nie będzie można odszyfrować i każdy użytkownik będzie musiał ponownie połączyć swoje konta. **Pliki połączone z adresu URL** są pobierane przez Twoje wdrożenie w imieniu użytkownika, więc miejscem docelowym jest dowolny adres podany przez użytkownika. Pliki połączone z URL są wyłączone, dopóki nie dodasz `url` do `ENABLED_LINKED_FILE_TYPES`, a konfiguracja domyślna tego nie zawiera. Zewnętrzne importy ZIP i TeX przez API Open in Overleaf również korzystają z tego samego komponentu `linked-url-proxy`. Żądania bezpośrednie rozwiązują nazwę hosta docelowego i odrzucają zastrzeżone zakresy sieci, z uwzględnieniem skonfigurowanych wyjątków dozwolonych zasobów. Przy skonfigurowanym `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` to serwer proxy ruchu wychodzącego rozwiązuje nazwy hostów, więc musi on samodzielnie egzekwować ograniczenia dotyczące sieci wewnętrznej; kontrole sieciowe aplikacji dotyczą wtedy tylko adresów URL zawierających adresy IP. Szczegóły znajdziesz w [External URL — Outbound Proxy](/pl/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention"). Żądania te pobierają podany adres URL, a nie przesyłają plików projektu. Jeśli Twoja polityka wymaga listy dozwolonych połączeń wychodzących, zezwól tylko na hosty powiązane z włączonymi funkcjami — `github.com` i `api.github.com` dla GitHub, `www.zotero.org` i `api.zotero.org` dla Zotero, `api.mendeley.com` dla Mendeley, `learnwiki.overleaf.com` lub własny `WIKI_URL` dla dokumentacji, `api.pwnedpasswords.com` dla sprawdzania haseł, `www.google.com` dla CAPTCHA, a także własny serwer pocztowy i dostawcę tożsamości. Jeśli włączone są funkcje AI lub wyszukiwanie, zezwól również na skonfigurowane punkty końcowe modelu, wyszukiwania w sieci i MCP dokumentacji. Blokuj miejsca docelowe, które nie są wymagane przez włączone funkcje. Jeśli ruch wychodzący musi być centralnie kontrolowany lub logowany, integracje z GitHub, Zotero i Mendeley można przekierować przez serwer proxy HTTP, ustawiając odpowiednio `GITHUB_SYNC_PROXY_URL`, `MENDELEY_PROXY_URL` i `ZOTERO_PROXY_URL`. Pobieranie plików połączonych z URL i importy zdalne mogą korzystać z `OVERLEAF_LINKED_URL_OUTBOUND_PROXY`. Plików połączonych z adresu URL nie można ograniczyć do listy hostów, ponieważ miejsce docelowe wybiera użytkownik w momencie żądania; ogranicz tę funkcję za pomocą ustawienia dozwolonych zasobów w samym komponencie proxy lub pozostaw ją wyłączoną. Czy w przypadku wdrożenia Ayakaleaf Pro z włączonym magazynem [s3.md](/pl/on-premises/configuration/overleaf-toolkit/s3 "mention") dane przechowywane w S3 są szyfrowane? *Nie.* Dane nie są szyfrowane. Wszystkie fragmenty historii, pliki szablonów, pliki PDF i inne pliki są przechowywane jako tekst jawny. Jeśli korzystasz z zewnętrznego magazynu S3 innej firmy, zwróć szczególną uwagę na bezpieczeństwo i prywatność danych. ### Czy kompilacje projektów są izolowane? Ayakaleaf Pro obsługuje kompilacje w trybie sandbox. Każda kompilacja odbywa się w osobnym kontenerze. Kontenery sandbox domyślnie nie mają dostępu do sieci. Ogranicza to narażenie zasobów sieci wewnętrznej. Kompilacje w trybie sandbox wymagają dostępu do gniazda Dockera hosta. Ogranicz administrację hostem do zaufanych operatorów. ### Czy mogę ufać buildom CI i obrazom kontenerów? GitHub Actions buduje i publikuje obrazy kontenerów Ayakaleaf Pro. Obrazy są dostępne w publicznym GitHub Container Registry. Obrazy obsługują architektury `amd64` i `arm64`. Docker podczas pobierania obrazu wybiera odpowiednią architekturę. Nie używaj tagu `latest` w środowisku produkcyjnym. Przypnij konkretną wersję, najlepiej skrót (digest) obrazu. Testuj każdą aktualizację w środowisku nieprodukcyjnym. Przed wdrożeniem zweryfikuj obraz, konfigurację i integracje. ### Czy kod jest open source? Ayakaleaf Pro i powiązane repozytoria funkcji są publicznie dostępne. Dzięki temu użytkownicy mogą przeglądać zmiany i śledzić źródła nadrzędne. Publiczny kod źródłowy umożliwia niezależny przegląd. Sam w sobie nie gwarantuje jednak odtwarzalności buildów wydań. Przed aktualizacją sprawdź: * Tag wydania lub commit. * Wersję lub skrót (digest) obrazu. * Zależności zewnętrzne i wymagania licencyjne. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.