Como restringir o registro de usuários em um servidor Matrix auto-hospedado

Em um servidor Matrix autohospedado, "restringir o cadastro" pode significar desde impedir todos os cadastros públicos até permitir apenas pessoas com um código de convite. Para o Synapse, a opção mais simples é desativar o cadastro público. Se você ainda quiser que novas pessoas participem, exija tokens de cadastro e forneça a cada pessoa um token limitado e com prazo de validade. Esses controles afetam a criação de novas contas locais; eles não removem usuários existentes nem desativam a federação do Matrix.

Escolha o controle que melhor se adapta ao seu servidor.

Os exemplos abaixo são para o Synapse. Dendrite, Conduit e outras implementações de servidores domésticos usam interfaces de configuração e administração diferentes. Consulte a documentação do seu servidor antes de aplicar as configurações do Synapse.

Opção 1: Desativar o cadastro público

Para um servidor doméstico privado, uma pequena organização ou um servidor onde um administrador provisiona cada conta, desative o registro de clientes na configuração ativa do Synapse:

enable_registration: false

O Synapse documenta essa configuração como desativada por padrão. Edite o arquivo de configuração que seu serviço ou contêiner carrega, valide o YAML e reinicie o Synapse usando seu processo normal de gerenciamento de serviços. Uma implantação do Docker pode montar a configuração a partir de um caminho do host, portanto, editar um arquivo com nome semelhante dentro do contêiner pode não alterar o arquivo usado na inicialização.

Com o registro desativado, os usuários não podem criar novas contas pelo fluxo de registro de cliente padrão. Os administradores ainda podem criar contas por meio de métodos administrativos compatíveis. O Synapse alerta especificamente que essa configuração registration_shared_secretpermite a criação de contas usando esse segredo, mesmo que ele enable_registrationseja falso. Trate-o como uma credencial de alto impacto: mantenha-o fora de repositórios, chats e arquivos de despejo de ambiente público; limite o acesso; e retenha-o somente se o seu fluxo de trabalho administrativo exigir. Qualquer pessoa com o segredo pode criar contas, incluindo contas de administrador.

Se você usa OIDC, CAS ou outra integração de SSO, verifique também a configuração de registro automático do provedor. O Synapse documenta as alterações de registro no nível do provedor, pois, caso contrário, um usuário pode ser criado automaticamente no primeiro login bem-sucedido via SSO. Para OIDC, revise oidc_providers[].enable_registrationtambém a configuração de registro geral.

Opção 2: Permitir o cadastro somente com tokens

Use tokens de registro quando os membros puderem criar suas próprias contas, mas os cadastros precisarem ser aprovados ou distribuídos por um administrador. Na configuração do Synapse, defina ambos os valores:

enable_registration: true
registration_requires_token: true

Ambas as opções são necessárias: a configuração do token exige um token durante o cadastro, e o próprio cadastro também precisa estar habilitado. Aplique a alteração e reinicie o Synapse. Contas existentes e tokens criados anteriormente não serão removidos ao alterar essa configuração.

Criar um token de uso limitado

O Synapse fornece uma API de administração para tokens de registro. As solicitações exigem um token de acesso de administrador. Por exemplo, esta solicitação cria um token que pode concluir um registro:

curl -sS -X POST "$SYNAPSE_URL/_synapse/admin/v1/registration_tokens/new" \
  -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"uses_allowed": 1}'

Substitua as variáveis ​​de ambiente pela URL base do seu servidor doméstico e um token de acesso de administrador. Mantenha o token de administrador em sigilo e evite colar comandos que contenham credenciais reais em logs compartilhados ou posts de suporte. A API também aceita um tempo de expiração em milissegundos desde a época Unix. Use um token de uso único para um convite individual e defina uma data de expiração para quando seu fluxo de trabalho puder calculá-la e mantê-la de forma confiável. Um token com limites omitidos pode ter usos ilimitados e nenhuma data de expiração, portanto, revise os campos retornados antes de distribuí-lo.

Para inspecionar tokens, um administrador pode chamar o método `inspect_token` GET /_synapse/admin/v1/registration_tokens. A resposta inclui usos permitidos, registros pendentes, registros concluídos e a data de expiração. Se um token for vazado, atualize seus usos permitidos para zero ou exclua-o através da API de administração documentada. Um token é uma credencial de inscrição, não um convite para uma sala do Matrix; ele não adiciona automaticamente a nova conta a uma sala.

Nota importante sobre compatibilidade: a API de administração de tokens de registro do Synapse é desativada quando a integração com o Matrix Authentication Service (MAS) está habilitada. Nessa configuração, use a API de administração do MAS ou a CLI do MAS documentada para sua implementação. Não presuma que um comando de token do Synapse funcionará sem alterações com o MAS.

Opção 3: Adicionar verificações ao cadastro público

Se o seu objetivo é permitir que qualquer pessoa solicite uma conta, exigir tokens pode ser muito restritivo. A configuração do Synapse também documenta os requisitos de CAPTCHA e identificadores de terceiros como possíveis verificações. O CAPTCHA depende de um provedor configurado corretamente e pode adicionar custos de acessibilidade e privacidade. Exigir um endereço de e-mail ou número de telefone pode adicionar dependências de configuração e verificação; não é o mesmo que aprovar cada conta. Confirme quais serviços de verificação sua versão e fluxo de cliente realmente suportam antes de tornar a exigência de um identificador de terceiros um critério de segurança.

A limitação de taxa é útil em conjunto com esses controles porque reduz solicitações repetidas, mas não define quem tem permissão para se registrar. Monitore as tentativas de registro e os logs do servidor e ajuste os limites de acordo com seu tráfego e implantação. Evite copiar trechos de configuração antigos sem verificar a versão do Synapse instalada: as opções de registro e serviço de identidade foram alteradas ao longo do tempo.

O que muda — e o que não muda — no encerramento das inscrições.

• Ele controla novas contas locais. Desativar o registro bloqueia o fluxo normal de criação de contas no seu servidor doméstico.
• Não exclui contas. Os usuários existentes mantêm suas contas, a menos que você as suspenda ou desative separadamente.
• Isso não desativa a federação. Usuários em outros servidores domésticos ainda podem se comunicar com usuários e salas locais, sujeitos às configurações de associação à sala e de federação.
• Isso não torna uma sala somente para convidados. As regras de entrada na sala são uma configuração separada; os tokens de registro não substituem os convites para a sala.
• Isso não bloqueia necessariamente todos os caminhos de provisionamento. APIs administrativas, um segredo compartilhado configurado, serviços de aplicativos e configurações de criação de contas SSO precisam de análise separada.

Uma regra de proxy reverso que oculta um URL de registro pode ser um controle adicional na camada de rede, mas é fácil interromper o fluxo de clientes e não substitui a configuração do próprio servidor. Use a configuração em nível de aplicação como controle principal e teste a implementação real após qualquer alteração de proxy.

Verifique o resultado

1. Verifique a fonte de configuração efetiva, incluindo qualquer montagem de contêiner ou configuração gerada, para os valores de registro pretendidos.
2. Reinicie o Synapse e verifique os registros de inicialização em busca de erros de YAML ou configurações não suportadas.
3. A partir de um cliente Matrix desconectado, tente iniciar um novo cadastro. Com o cadastro desativado, o fluxo não deve oferecer uma opção de inscrição pública utilizável. Com o cadastro que exige token ativado, uma solicitação sem um token válido não deve ser concluída.
4. Para o registro do token, teste com um token temporário de uso único e confirme se ele conclui apenas a criação de uma conta. Inspecione a resposta da API de administração para obter informações sobre o completedtoken, pendingo endereço IP e a data de expiração.
5. Teste um caminho SSO configurado separadamente e quaisquer scripts de provisionamento de contas. Confirme se eles se comportam de acordo com sua política de acesso.

Não utilize um token de convite real para uma conta de teste, a menos que pretenda utilizá-lo. Se a configuração parecer ineficaz, verifique primeiro se alterou o ficheiro que o Synapse carrega e se o serviço foi reiniciado. Depois, verifique se existe um segredo de registo partilhado, registo automático SSO ou outro mecanismo de provisionamento fiável.

Referências oficiais

• Manual de configuração do Synapse 1.160: configurações de registro
• API de administração do token de registro do Synapse
• Guia de instalação do Synapse: registrando um usuário
• API de registro com segredo compartilhado do Synapse
• Especificação da API Cliente-Servidor do Matrix

A documentação da API de administração e configuração versionada do Synapse é a fonte oficial para nomes de opções e campos de requisição. As instruções acima não pressupõem um sistema operacional, imagem de contêiner, proxy reverso ou cliente Matrix específico; confirme esses detalhes específicos da sua implementação antes de aplicar as alterações.