Como Usar Authorized Fetch em uma Instância de Usuário Único

Instâncias Mastodon de usuário único são servidores privados onde você gerencia sua própria conta sem compartilhar a instância com outros usuários. Essas instâncias ainda podem receber requisições maliciosas de servidores remotos não verificados que se passam por outros. O Authorized Fetch é um recurso de segurança que força todas as requisições de federação a carregarem uma assinatura válida do servidor solicitante. Quando ativado, ele impede que servidores não autorizados baixem suas postagens públicas sem que sua instância aprove a conexão. Este artigo explica como ativar o Authorized Fetch em uma instância de usuário único e quais mudanças esperar após ativá-lo.

O Que o Authorized Fetch Faz e Por Que Instâncias de Usuário Único Precisam Dele

Authorized fetch é um modo de segurança do Mastodon que rejeita requisições de federação recebidas, a menos que o servidor solicitante prove sua identidade com uma assinatura criptográfica. No modo normal, o Mastodon aceita requisições sem assinatura de qualquer servidor remoto que peça as postagens públicas de um usuário. Esse comportamento aberto permite que terceiros façam scraping de timelines públicas sem que o dono da instância saiba. Em uma instância de usuário único, o risco é menor porque há apenas uma conta, mas a instância ainda expõe postagens públicas para qualquer um que envie uma requisição GET ao endpoint correto da API.

Quando você ativa o authorized fetch, o Mastodon verifica cada requisição recebida em busca de uma assinatura HTTP válida, assinada pela chave privada do servidor remoto. Se a assinatura estiver ausente ou for inválida, a requisição é negada com uma resposta 401 Não Autorizado. Isso impede que servidores não verificados baixem suas postagens, impulsionamentos ou listas de seguidores. O recurso é às vezes chamado de “modo seguro” na documentação do Mastodon.

Instâncias de usuário único se beneficiam do authorized fetch porque não têm uma equipe de moderação para revisar tráfego suspeito. O dono da instância é o único usuário, então qualquer puxada de dados não autorizada passa despercebida até que o dano seja feito. Ativar o authorized fetch adiciona uma camada de proteção sem exigir ferramentas de moderação adicionais. A contrapartida é que alguns servidores legítimos que não assinam suas requisições não conseguirão buscar suas postagens. Na prática, a maioria das instâncias modernas do Mastodon e do Pleroma assinam suas requisições, então o impacto é mínimo.

Passos para Ativar o Authorized Fetch em uma Instância de Usuário Único

O processo difere dependendo de como você executa o Mastodon. As duas configurações mais comuns são Docker Compose e uma instalação baseada em systemd. Ambos os métodos exigem que você defina uma variável de ambiente e reinicie os serviços.

Para Instalações com Docker Compose

1. Abra seu arquivo Docker Compose
   Navegue até o diretório que contém seu arquivo docker-compose.yml. Esse arquivo geralmente está localizado em /opt/mastodon ou /srv/mastodon. Edite o arquivo com um editor de texto como nano ou vim.
2. Adicione a variável de ambiente AUTHORIZED_FETCH
   Encontre o bloco environment sob o serviço web. Adicione uma nova linha: AUTHORIZED_FETCH=true. Se o bloco não existir, crie-o sob o serviço web. Repita este passo para os serviços streaming e sidekiq se eles estiverem definidos separadamente.
3. Salve o arquivo e reinicie os contêineres
   Execute docker-compose down seguido por docker-compose up -d. Isso para todos os contêineres e os inicia novamente com a nova variável de ambiente. Verifique se os contêineres estão rodando com docker-compose ps.

Para Instalações com systemd

1. Edite o arquivo de ambiente do Mastodon
   Abra o arquivo .env.production localizado no diretório raiz do Mastodon, tipicamente /home/mastodon/live. Use um editor de texto para adicionar a linha AUTHORIZED_FETCH=true ao final do arquivo.
2. Reinicie os serviços do Mastodon
   Execute sudo systemctl restart mastodon-web, sudo systemctl restart mastodon-streaming e sudo systemctl restart mastodon-sidekiq. Você pode combinar esses comandos em um só: sudo systemctl restart mastodon-{web,streaming,sidekiq}.
3. Confirme que os serviços estão ativos
   Use sudo systemctl status mastodon-web para verificar se o serviço web iniciou sem erros. Procure pela linha “Authorized fetch enabled” nos logs.

O Que Muda Após Ativar o Authorized Fetch

Uma vez que o authorized fetch está ativo, sua instância rejeitará todas as requisições de federação sem assinatura. Isso significa que servidores remotos que não assinam suas requisições não conseguirão puxar suas postagens. Na prática, isso afeta um pequeno número de servidores desatualizados ou mal configurados. Suas próprias postagens ainda aparecerão na timeline federada de outras instâncias, porque sua instância assina as requisições de saída que envia.

Você pode verificar se o authorized fetch está funcionando consultando os logs do Mastodon. Procure por entradas que digam “Unauthenticated request rejected” ou “Authorized fetch enabled.” Se você vir essas mensagens, o recurso está ativo. Você também pode testar enviando uma requisição HTTP direta ao endpoint da API da sua instância para postagens públicas sem assinatura. A resposta deve ser um erro 401.

Problemas Comuns Após Ativar o Authorized Fetch

Servidores Remotos Não Conseguem Buscar Minhas Postagens

Se um servidor remoto específico não conseguir buscar suas postagens após você ativar o authorized fetch, o problema provavelmente é que o servidor remoto não assina suas requisições. Isso é comum com versões muito antigas do Mastodon ou software não-Mastodon que não implementa HTTP Signatures. Não há solução alternativa da sua parte. O administrador do servidor remoto deve atualizar o software para suportar requisições assinadas.

Minhas Próprias Postagens Desaparecem de Outras Instâncias

Se suas postagens pararem de aparecer em outras instâncias, o problema geralmente é que a instância remota está rejeitando suas requisições de saída. Isso não é causado pelo authorized fetch do seu lado. Verifique os logs de federação de saída da sua instância. A instância remota pode ter bloqueado sua instância ou pode estar enfrentando um problema de rede temporário.

Aumento no Uso de CPU ou Memória

O authorized fetch adiciona sobrecarga de verificação de assinatura a cada requisição recebida. Em uma instância de usuário único com baixo tráfego, o impacto é insignificante. Se você administra uma instância muito movimentada, pode notar um leve aumento no uso de CPU. Monitore o uso de recursos do seu servidor com top ou htop após ativar o recurso.

Authorized Fetch vs Modo de Federação Padrão

Item	Authorized Fetch Ativado	Padrão (Sem Authorized Fetch)
Autenticação de requisição	Exige assinatura HTTP válida	Aceita requisições sem assinatura
Proteção contra scraping	Bloqueia scrapers não verificados	Permite que qualquer servidor puxe dados públicos
Compatibilidade com servidores antigos	Pode bloquear servidores desatualizados	Compatível com todos os servidores
Esforço de configuração	Uma alteração de variável de ambiente	Nenhuma configuração necessária

Ativar o authorized fetch em uma instância de usuário único é uma etapa direta de endurecimento de segurança. O recurso não requer manutenção contínua após configurado. Se você decidir desativá-lo depois, basta remover a linha AUTHORIZED_FETCH=true da sua configuração e reiniciar os serviços. Após desativar, sua instância voltará a aceitar requisições sem assinatura. Para a maioria dos donos de instâncias de usuário único, a proteção adicional contra scraping de dados supera o risco menor de compatibilidade com servidores desatualizados.