Skip to main content
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. 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 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 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 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 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.
Última modificação em 5 de outubro de 2026