Como desativar a telemetria e as conexões externas no Collabora CODE

Resposta curta: O Collabora Online Development Edition (CODE) não oferece uma opção geral de telemetria que os administradores precisam desativar para análises de rotina. A Collabora afirma que a versão auto-hospedada do Online não requer telemetria nem retornos de chamada para análises. A atividade de saída que vale a pena controlar é separada: verificações periódicas de atualização, integrações opcionais, endpoints de monitoramento e recursos de documentos que buscam dados remotos. Desative os recursos opcionais que você não usa e, em seguida, aplique uma lista de permissões de saída, mantendo a conexão WOPI com o seu servidor de armazenamento.

Isso se aplica ao CODE autohospedado, como uma instância integrada ao Nextcloud ou ownCloud. Bloquear completamente o tráfego de saída pode interromper o carregamento e o salvamento de documentos, pois o CODE precisa acessar seu host WOPI. Os nomes de configuração abaixo foram verificados em relação ao modelo upstream da Collabora em 6 de outubro de 2026; o empacotamento e os valores padrão podem variar de acordo com a versão.

O que é considerado telemetria ou conexão externa?

Telemetria geralmente se refere ao uso do produto ou aos dados de diagnóstico enviados a um fornecedor. A Collabora afirma que seu produto Online autohospedado não requer telemetria, retornos de chamada de análise ou conectividade com serviços externos. O coolwsd.xmlmodelo upstream não mostra um coletor de telemetria global nem um interruptor de "conexão com servidores externos".

A ferramenta exibe uma verificação periódica de versão: fetch_update_checko padrão é de 10 horas. Defina-a 0para desativar essa verificação. allow_update_popupA opção `true` controla se os avisos de atualização aparecem no editor; defini-la como ` falsefalse` oculta a notificação, mas não substitui a desativação da verificação em si. Se a sua versão suporta ambas as opções, defina ambas.

Outras conexões são orientadas a funcionalidades. Elas podem incluir um monitor externo configurado, serviços remotos de ortografia ou gramática, tradução DeepL, provedores de IA, configuração remota de fontes e dados externos solicitados por um documento. O modelo original indica que as APIs remotas do LanguageTool ou Duden estão desativadas por padrão; o DeepL também está desativado por padrão. Use as configurações fornecidas com a sua versão específica do CODE ao analisar as opções de IA ou integração.

Etapa 1: Identifique os destinos essenciais e opcionais

Mapeie o funcionamento da edição antes de alterar a rede. Por exemplo, suponha que o Nextcloud esteja em `http:// cloud.example.comlocalhost:8080` e o CODE office.example.comem `http://localhost:8080`. O navegador carrega o editor do CODE, enquanto o servidor CODE também se comunica com o Nextcloud por meio do WOPI para buscar e salvar o documento. Preserve essa rota servidor a servidor, o esquema e a porta usados ​​pela sua instalação e quaisquer serviços de DNS ou proxy que sua implementação exija.

Em seguida, faça um inventário dos serviços opcionais em sua configuração efetiva. Verifique <monitors>os endereços de monitoramento configurados explicitamente. Confira a verificação ortográfica remota, o DeepL, a IA, a configuração remota de fontes e os URLs de configuração remota. Remova os endpoints personalizados que não fazem parte de um fluxo de trabalho aprovado. Se um endpoint personalizado for necessário, documente seu nome de host e finalidade antes de criar a exceção de rede correspondente.

Examine também a configuração lok_allow. Ela controla quais hosts os documentos editados podem usar como fontes de dados externas, incluindo URLs usados ​​para gráficos inseridos ou funções de planilha, como [exemplo de URL] WEBSERVICE(). Não se trata de um firewall universal. As observações da configuração upstream indicam que os hosts WOPI e POST permitidos também podem ser tratados como fontes de dados permitidas; portanto, mantenha essa política distinta dos controles de saída de rede.

Passo 2: Desative as verificações periódicas de atualização

Para o contêiner Collabora CODE, defina as opções por meio de sua extra_paramsvariável de ambiente. Incorpore-as ao valor existente; mantenha quaisquer configurações atuais de terminação TLS, proxy reverso ou host das quais sua instalação dependa. Fixe uma tag de imagem CODE aprovada para seu ambiente em vez de depender de uma latesttag móvel.

services:
  collabora:
    image: collabora/code:<approved-tag>
    environment:
      extra_params: >-
        --o:fetch_update_check=0
        --o:allow_update_popup=false

Este é um fragmento ilustrativo do Docker Compose, não uma implantação completa. Preserve suas restrições de domínio, credenciais de administrador, configurações de TLS e configuração de proxy existentes. No Kubernetes, o gráfico Helm original expõe collabora.extra_paramse suporta coolwsd.xmlconteúdo personalizado; use o arquivo de valores e as instruções para a versão do gráfico que você instalou.

Se você estiver gerenciando o arquivo XML diretamente, insira os valores dentro do <config>elemento principal:

<fetch_update_check>0</fetch_update_check>
<allow_update_popup>false</allow_update_popup>

Não confie em uma edição manual dentro de um contêiner em execução, a menos que esse arquivo seja persistente. Uma reinicialização, atualização de imagem ou implantação de orquestração pode substituí-lo. Altere a origem de configuração persistente do Compose, Helm ou montada e recrie ou implante o CODE usando seu procedimento normal.

Etapa 3: Desative as integrações não utilizadas e restrinja as buscas de documentos.

Deixe <monitors>em branco se você não usa um serviço de monitoramento externo. O arquivo upstream contém um monitor de exemplo comentado; uma entrada comentada é um exemplo, não uma conexão ativa. Remova as entradas de monitor ativas que foram adicionadas localmente se não forem mais necessárias.

Mantenha a verificação ortográfica e gramatical remota, o DeepL e os recursos do provedor de IA desativados, a menos que os usuários dependam deles. A verificação remota de idioma pode enviar o texto selecionado do documento para o serviço configurado; portanto, habilitá-la tem consequências tanto para a conectividade quanto para o processamento de dados. Se uma integração for necessária, permita apenas o endpoint aprovado por meio da política de saída.

Para conteúdo remoto solicitado por documentos, remova os hosts públicos <lok_allow>e mantenha apenas os destinos necessários para seus usuários. Não remova a rota WOPI para isso. O WOPI é a conexão de armazenamento necessária para a edição normal. Observe também que entradas amplas em redes privadas podem permitir a busca de documentos em mais hosts internos do que o pretendido; restrinja-as conforme o layout da sua rede e a versão do CODE permitirem.

Etapa 4: Aplicar regras de saída fora do código

As configurações do aplicativo desativam comportamentos específicos; elas não garantem que o sistema operacional ou o processo não possam abrir qualquer outra conexão. Para uma proteção mais robusta, aplique regras de saída no firewall do host, na rede do contêiner, na NetworkPolicy do Kubernetes ou em um firewall externo. Use a opção "negar por padrão" para o CODE e, em seguida, permita apenas o destino WOPI e as dependências explicitamente aprovadas. Permita o DNS por meio do serviço de rede que sua plataforma utiliza.

No exemplo acima, o CODE pode ter permissão para acessar cloud.example.como esquema e a porta configurados para WOPI, enquanto destinos públicos não relacionados são bloqueados. Evite depender de um IP fixo quando o host de armazenamento estiver atrás de um balanceador de carga ou tiver endereços variáveis. Um grupo de destinos mantido ou um proxy de saída controlado é mais fácil de gerenciar. Certifique-se de que qualquer proxy esteja configurado de forma consistente para o contêiner.

Mantenha os caminhos de entrada e saída separados. O navegador precisa conseguir acessar o endpoint CODE publicado, e o servidor de armazenamento pode precisar acessar o CODE para sessões de descoberta ou documentação. Uma política de saída que permite que o CODE chame o WOPI não estabelece essas rotas de entrada. Da mesma forma, alterar essa política lok_allownão desabilita todos os tipos de conexão de saída.

Etapa 5: Reinicie e verifique a política.

Reinicie ou implemente o CODE para que a configuração efetiva seja carregada. Verifique os logs de inicialização para conferir os valores de configuração carregados e os avisos sobre configurações ignoradas. Em seguida, abra um documento de teste editável por meio da integração de armazenamento normal, faça uma alteração, salve, feche e abra novamente. O documento deverá manter a alteração.

• Analise os registros do firewall, proxy ou políticas de rede durante a inicialização e edição. O tráfego WOPI esperado deve ser permitido.
• Confirme se os destinos externos que você pretendia bloquear estão realmente bloqueados. Um registro silencioso por si só não comprova que todas as rotas possíveis estão bloqueadas.
• Após o intervalo de verificação de atualização anterior ter expirado, verifique se o contêiner CODE tentou realizar uma busca de atualização. Confirme se a janela pop-up de atualização está ausente, caso também tenha sido desativada.
• Teste todos os recursos que os usuários precisam, incluindo fontes remotas, tradução, auxílios linguísticos, links para documentos e fórmulas que recuperam dados externos. Restaure apenas o destino específico aprovado necessário para cada recurso.

Se os documentos não abrirem ou não puderem ser salvos, verifique primeiro o DNS e a rota WOPI de servidor para servidor. Se apenas uma imagem externa ou fórmula de planilha falhar, verifique lok_allowseparadamente a política do firewall. Bloquear uma fonte de dados pública enquanto o WOPI continua funcionando é o resultado esperado; bloquear o salvamento significa que a política de saída é muito abrangente.

O que desativar essas conexões pode e não pode garantir

Desativar a verificação de atualizações e integrações não utilizadas reduz a atividade de saída esperada do CODE. Uma política de rede de negação por padrão define o limite de aplicação. Nenhuma delas controla o tráfego separado do seu host, ambiente de execução de contêiner, plataforma de orquestração, proxy reverso ou agente de monitoramento. Se o requisito abranger todo o servidor, audite também esses componentes.

As configurações padrão podem mudar entre versões, e as integrações podem adicionar configurações. Compare o modelo fornecido com sua imagem fixada com o modelo upstream atual antes da implementação e teste em ambiente de homologação. As principais referências são o modelo de configuração coolwsd.xml upstream da Collabora , seus valores oficiais no gráfico Helm e sua declaração sobre implantações auto-hospedadas e serviços externos .