> ## 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.
# Confiança e segurança
> Entenda o tratamento de dados, a entrega de builds e as responsabilidades de segurança.
O Ayakaleaf Pro é executado na sua infraestrutura. Você controla seus dados, o acesso e os limites de rede. Esta página explica o modelo de segurança padrão. Ela também identifica suas responsabilidades operacionais.
### O Ayakaleaf Pro é confiável e seguro?
O Ayakaleaf Pro é um aprimoramento auto-hospedado do Overleaf Pro, e nosso código-fonte está disponível em [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro). Sua implantação controla onde os serviços são executados e onde os dados residem.
A segurança depende da sua configuração e da sua operação. Proteja o acesso de administrador, habilite o HTTPS e mantenha backups.
Agradecemos à OpenAI pelo gentil apoio. Usaremos regularmente o [Codex Security](https://chatgpt.com/codex/cloud/security/findings) para analisar nosso repositório em busca de problemas de segurança e compartilharemos publicamente os resultados das correções de vulnerabilidades.
### Para onde vão os meus dados?
Por padrão, os dados da aplicação permanecem dentro da sua implantação:
* O MongoDB armazena os dados de usuários e projetos.
* O Redis armazena cache e dados de colaboração em tempo real.
* Volumes locais ou armazenamento compatível com S3 guardam os arquivos dos projetos.
Apenas o serviço web é exposto por padrão. Os serviços internos se comunicam pela rede Docker.
### Meus dados serão enviados ou obtidos de terceiros?
Nada sai da sua implantação, a menos que você habilite um recurso que exija isso. O Ayakaleaf Pro envia *nenhuma telemetria, nenhuma análise de uso e nenhum relatório de falhas*. O relatório de erros e a análise de uso estão desativados na configuração padrão.
Vários recursos nunca fazem requisições externas. Os templates são armazenados e servidos a partir da sua própria implantação. O executor de scripts Python roda no navegador do usuário por meio de WebAssembly, e seu runtime é servido pelo seu próprio serviço web, e não por uma CDN pública, de modo que o código e a saída dos scripts nunca chegam à rede. O Git Bridge só é acessível na rede Docker interna. A busca completa em projetos, a paleta de símbolos, o controle de alterações, o histórico de projetos e o painel de administração são totalmente locais. Os contêineres de compilação em sandbox são criados com a rede desativada.
As requisições dos demais recursos chegam aos destinos a seguir. Cada requisição se origina no serviço web:
Os recursos de IA estão desativados por padrão. Quando habilitados, o chat e as sugestões para erros de LaTeX enviam prompts e o contexto relevante do projeto para o endpoint do modelo configurado com `AI_BASE_URL`. A busca na web opcional envia consultas ao serviço compatível com Tavily configurado, e a busca na documentação envia consultas para `DOCS_MCP_URL` (padrão: `https://docs.overleaf.com/~gitbook/mcp`). Os resultados da busca podem ser incluídos nas requisições ao provedor do modelo. Consulte [Integração com IA](/pt/on-premises/configuration/overleaf-toolkit/ai-integration "mention") para a configuração e os controles do usuário.
A **integração com o GitHub** acessa `github.com` e `api.github.com`. Ela é habilitada por usuário, ao vincular uma conta do GitHub, e a autorização solicita os escopos `read:org`, `repo` e `workflow`. O push envia o conteúdo completo dos arquivos do projeto como blobs Git, que são então montados em trees e commits. Ela também realiza operações de branch, referência, comparação e merge, e lê o perfil da conta vinculada, as organizações das quais ela é membro e a lista de repositórios. O conteúdo do projeto sai da sua implantação em ambas as direções — trate uma conta do GitHub vinculada como um caminho de exportação para todos os projetos associados a ela.
A **integração com o Zotero** acessa `www.zotero.org` para autorização e `api.zotero.org` para os dados da biblioteca. Ela é habilitada por usuário, ao vincular uma conta do Zotero. O handshake OAuth e a chave de API do usuário são enviados. As leituras são unidirecionais: as bibliotecas de referências são importadas como BibTeX, e nenhum conteúdo de projeto é enviado.
A **integração com o Mendeley** acessa `api.mendeley.com` tanto para autorização quanto para os dados da biblioteca. Ela é habilitada por usuário, ao vincular uma conta do Mendeley. O handshake OAuth solicita o escopo `all` do Mendeley — o único escopo oferecido por sua API —, mas o Ayakaleaf apenas realiza leituras: as bibliotecas de referências e as bibliotecas de grupo são importadas como BibTeX, e nenhum conteúdo de projeto é enviado. Os tokens de acesso são renovados automaticamente; quando o Mendeley revoga uma autorização, a credencial armazenada é descartada e o usuário é solicitado a vincular a conta novamente.
As **páginas de documentação** são obtidas de `https://learnwiki.overleaf.com`, configurável com `WIKI_URL`. As requisições são feitas pelo serviço web, e não pelo navegador do usuário, de modo que a wiki de origem vê o seu servidor e nunca os endereços dos seus usuários. Apenas o título da página solicitada é enviado, e as respostas são armazenadas em cache no disco. Aponte `WIKI_URL` para o seu próprio espelho, ou bloqueie o destino, se o tráfego de saída para a documentação não for aceitável.
O **envio de e-mails** acessa qualquer servidor SMTP ou API de e-mail que você configurar; não há um padrão. Os endereços dos destinatários e o conteúdo das mensagens saem da sua implantação, incluindo links de redefinição de senha e de convite.
Duas verificações opcionais estão desativadas por padrão. A verificação de senhas comprometidas fica inativa, a menos que `HAVE_I_BEEN_PWNED_ENABLED` esteja definida; quando habilitada, ela envia os primeiros caracteres de um hash SHA-1 da senha para `api.pwnedpasswords.com`, nunca a própria senha. A verificação de CAPTCHA fica inativa, a menos que uma chave de site do reCAPTCHA esteja configurada, e acessa `www.google.com` quando ativa.
O **single sign-on** acessa apenas o provedor de identidade que você fornecer, e o que trafega até ele depende do protocolo. Com LDAP, o serviço web se conecta diretamente ao seu diretório: ele faz o bind com a conta de serviço que você configurar, pesquisa sob a base, o filtro e a lista de atributos que você definir, e verifica a senha digitada no formulário de login no seu diretório, de modo que o nome de usuário e a senha chegam ao servidor de diretório. Habilitar contatos baseados no diretório gera uma pesquisa adicional para preencher a lista de contatos. Com OIDC, o serviço web troca o código de autorização no seu endpoint de token e, em seguida, chama o seu endpoint de user-info, solicitando por padrão os escopos `openid profile email`; isso é configurável com `OVERLEAF_OIDC_SCOPE`. Com SAML, a requisição de autenticação trafega pelo navegador do usuário até o provedor de identidade, em vez de por uma conexão direta entre servidores. Nos três casos, o nome e o endereço de e-mail do usuário vêm do provedor, em vez de serem enviados a ele, e são então armazenados no registro local do usuário.
As **credenciais de terceiros** — tokens OAuth e chaves de API — são mantidas no MongoDB, no registro do usuário, criptografadas com AES-256-CTR com um salt e um vetor de inicialização por registro. Elas nunca são armazenadas em texto puro e nunca são gravadas em logs. A chave de criptografia vem de `${PROVIDER}_CIPHER_PASSWORD`, se definida (como no Zotero e no Mendeley); caso contrário, uma chave é gerada no primeiro uso e persistida dentro do seu volume de dados com permissões apenas para o proprietário. Faça backup dessa chave junto com o seu volume de dados: se ela for perdida, as credenciais armazenadas não poderão ser descriptografadas e todos os usuários precisarão vincular suas contas novamente.
Os **arquivos vinculados a partir de uma URL** são obtidos pela sua implantação em nome do usuário, então o destino é qualquer endereço que o usuário fornecer. Os arquivos de URL vinculada ficam desativados, a menos que você adicione `url` a `ENABLED_LINKED_FILE_TYPES`, e a configuração padrão não o inclui. Importações externas de ZIP e TeX por meio da API Open in Overleaf também usam o mesmo componente `linked-url-proxy`. Requisições diretas resolvem o hostname de destino e rejeitam faixas de rede restritas, sujeitas às exceções de recursos permitidos configuradas. Com `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` configurada, é o proxy de saída que resolve os hostnames, portanto ele mesmo deve aplicar as restrições de rede interna; as verificações de rede da aplicação só se aplicam a URLs que contêm endereços IP. Consulte [URL externa — Proxy de saída](/pt/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention") para mais detalhes. Essas requisições obtêm a URL fornecida, em vez de enviar arquivos do projeto.
Se a sua política exigir uma lista de permissões de saída, permita apenas os hosts dos recursos que você habilitou — `github.com` e `api.github.com` para o GitHub, `www.zotero.org` e `api.zotero.org` para o Zotero, `api.mendeley.com` para o Mendeley, `learnwiki.overleaf.com` ou o seu próprio `WIKI_URL` para a documentação, `api.pwnedpasswords.com` para a verificação de senhas, `www.google.com` para o CAPTCHA, além do seu próprio servidor de e-mail e provedor de identidade. Se os recursos de IA ou de busca estiverem habilitados, permita também os endpoints configurados do modelo, da busca na web e do MCP de documentação. Bloqueie os destinos que não sejam exigidos pelos recursos habilitados. Quando o tráfego de saída precisar ser inspecionado ou registrado centralmente, as integrações com GitHub, Zotero e Mendeley podem ser roteadas por um proxy HTTP, definindo `GITHUB_SYNC_PROXY_URL`, `MENDELEY_PROXY_URL` e `ZOTERO_PROXY_URL`. A obtenção de URLs vinculadas e as importações remotas podem usar `OVERLEAF_LINKED_URL_OUTBOUND_PROXY`. Arquivos vinculados a partir de uma URL não podem ser restritos a uma lista de hosts, pois o destino é escolhido pelo usuário no momento da requisição; restrinja esse recurso pela configuração de recursos permitidos do próprio componente de proxy, ou mantenha-o desativado.
Se você implantar o Ayakaleaf Pro com o armazenamento [s3.md](/pt/on-premises/configuration/overleaf-toolkit/s3 "mention") habilitado, os dados armazenados no S3 são criptografados?
*Não.* Os dados não são criptografados. Todos os chunks de histórico, arquivos de templates, PDFs e outros arquivos são armazenados em texto puro. Se você usar um provedor externo de armazenamento S3 de terceiros, preste muita atenção à segurança e à privacidade dos dados.
### As compilações de projetos são isoladas?
O Ayakaleaf Pro suporta compilações em sandbox. Cada compilação é executada em um contêiner separado. Os contêineres de sandbox não têm acesso à rede por padrão. Isso reduz a exposição a recursos da rede interna.
As compilações em sandbox exigem acesso ao socket do Docker do host. Restrinja a administração do host a operadores confiáveis.
### Posso confiar nos builds de CI e nas imagens de contêiner?
O GitHub Actions constrói e publica as imagens de contêiner do Ayakaleaf Pro. As imagens estão disponíveis no GitHub Container Registry público.
As imagens suportam `amd64` e `arm64`. O Docker seleciona a arquitetura correspondente ao baixar uma imagem.
Não use a tag `latest` em produção. Fixe uma versão explícita, de preferência um digest de imagem.
Teste cada atualização em um ambiente que não seja de produção. Verifique a imagem, a configuração e as integrações antes da implantação.
### O código é open source?
O Ayakaleaf Pro e os repositórios de recursos relacionados estão disponíveis publicamente. Isso permite que os usuários revisem as alterações e rastreiem as fontes upstream.
O código-fonte público permite uma revisão independente. Por si só, ele não garante builds de versão reproduzíveis.
Antes de atualizar, revise:
* A tag ou o commit da versão.
* A versão ou o digest da imagem.
* As dependências de terceiros e os requisitos de licença.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.