# Publique um serviço onion sem ignorar a aplicação | SwissOctet Insights https://swissoctet.com/pt-br/insights/publish-onion-service-safely/ SwissOctet / Insights / Web e onion Web e onion Aplicado · 4 min de leitura Publicar um serviço onion sem ignorar a aplicação Planeje uma publicação onion legítima com exposição controlada do backend, revisão cuidadosa do conteúdo, recuperação da chave de serviço e um modelo explícito de acesso do público. Por SwissOctet Editorial Salvar guia Copiar link NESTA PÁGINA 01 Defina a publicação e seu público 02 Mantenha o listener de backend deliberado 03 Revise o que a aplicação publica 04 Trate a identidade do serviço como material protegido 05 Escolha explicitamente o acesso público ou restrito 06 Teste pela conexão do leitor 07 Leia as opções de hospedagem como partes do projeto Sua lista prática Fontes e leitura adicional Voltar para a biblioteca A RESPOSTA DIRETA Proteja a aplicação e seu acesso administrativo, limite o listener de backend, proteja as chaves do serviço onion e teste a publicação por meio de um cliente compatível. O roteamento onion é uma camada do projeto. Ele não remove vulnerabilidades da aplicação, erros no conteúdo publicado nem a necessidade de definir quem deve ter acesso. 01 Defina a publicação e seu público Comece com um propósito de publicação legítimo e uma descrição do público. Uma publicação de pesquisa pública e um portal de projeto restrito têm requisitos de acesso diferentes. Decida qual conteúdo deve ser público, qual exige autenticação de aplicação e qual nunca deve chegar à raiz da web. Mantenha essas decisões separadas do transporte usado para chegar ao site. Escreva um pequeno inventário de dados antes da implantação: páginas, uploads, conteúdo do banco de dados, contas de administrador e configuração de serviços. Atribua um responsável pelas atualizações e pelo tratamento de incidentes. O fato de um site usar um endereço onion não resolve retenção, direitos de conteúdo ou responsabilidades de segurança. Essas continuam sendo decisões práticas de aplicação que exigem um plano operacional explícito. 02 Mantenha o listener de backend deliberado Um serviço onion mapeia uma conexão para um endpoint de aplicação local. Revise onde esse endpoint escuta e quais outras redes podem alcançá-lo. O guia de configuração do Tor Project descreve os sockets Unix como uma forma útil de evitar expor o backend a uma rede local. Escolha uma abordagem compatível com seu servidor e verifique sua acessibilidade real. Uma conexão que funciona através do Tor pode coexistir com um listener público não intencional. Teste tanto o caminho de acesso pretendido quanto os limites em torno do backend. Evite suposições genéricas de configuração; leia as configurações de escuta da aplicação e o roteamento de virtual-host do servidor web. Mantenha as interfaces de gerenciamento distintas do serviço destinado ao público e restrinja quem pode alterar essas configurações. 03 Revise o que a aplicação publica Inspecione páginas, arquivos enviados, saída de erros e recursos incorporados como um leitor os encontraria. Uma aplicação pode revelar detalhes operacionais por meio de mensagens de depuração ou vincular a recursos externos sem que isso seja óbvio em seu design principal. Revise URLs geradas e metadados de conteúdo. Sirva apenas os recursos que a publicação exige e entenda qualquer solicitação de terceiros que ela inicie. Para um site de pesquisa ilustrativo, revise um artigo de exemplo, um anexo e uma página de contato antes do lançamento. Verifique se um documento editorial privado e um arquivo de ambiente estão fora do diretório público. Use material de teste não sensível ao verificar uploads. Uma conexão onion bem-sucedida prova a acessibilidade; esta revisão de conteúdo verifica o que o serviço realmente divulga ao seu público. 04 Trate a identidade do serviço como material protegido A configuração do serviço onion inclui material de chave que deve permanecer privado. Mantenha-o fora dos arquivos públicos do site e limite o acesso aos operadores que precisam dele. Planeje como uma recuperação legítima preserva a identidade pretendida do serviço e como um comprometimento seria tratado. Não coloque chaves de serviço em um arquivo público, mensagem de suporte ou repositório de projeto compartilhado. Inclua a aplicação, os dados e a configuração de serviço necessária no design de recuperação, com proteção adequada para cada um. Um backup apenas do conteúdo do site pode não restaurar o endereço pretendido, enquanto uma cópia contendo chaves privadas cria um backup sensível. Documente quem pode descriptografá-lo e restaurá-lo e teste esse acesso sem expor as chaves em relatórios de exercícios. 05 Escolha explicitamente o acesso público ou restrito O login da aplicação e a autorização do cliente Tor são camadas diferentes. O Tor Project documenta a autorização de cliente para tornar o acesso a um serviço onion v3 dependente de uma credencial de cliente. Decida se esse modelo se adequa ao público e ao processo operacional. Ele não é automaticamente necessário para uma publicação pública e não substitui as permissões da aplicação depois que um cliente se conecta. Considere um portal de projeto com um pequeno grupo aprovado. Você precisa de uma forma de distribuir, substituir e revogar material de acesso de forma privada, bem como gerenciar contas de aplicação. Teste a remoção de um cliente autorizado e de um usuário da aplicação separadamente. A tabela a seguir mantém esses controles distintos em vez de prometer que uma única configuração resolve todos os problemas de acesso. Controle Pergunta que responde Responsabilidade separada Listener do backend Quem pode alcançar o endpoint da aplicação local? Configuração do servidor web e da rede Autorização de cliente Quais clientes podem se conectar ao serviço onion? Distribuição e revogação de credenciais privadas Permissões da aplicação O que um usuário conectado pode fazer? Funções de conta e acesso a dados Revisão de publicação O que o site divulga? Conteúdo, uploads e tratamento de erros 06 Teste pela conexão do leitor Use um cliente compatível para testar páginas, navegação, formulários e downloads pelo caminho de acesso onion pretendido. Observe erros e uso de recursos da aplicação com tráfego de teste inofensivo. Evite medir apenas uma solicitação local ao backend, porque isso não exercita a conexão completa do leitor. Mantenha contas de teste e quaisquer credenciais de acesso restrito em sigilo. Verifique também os procedimentos de recuperação e manutenção. Uma atualização da aplicação deve ter um ponto de reversão e uma forma de validar a rota onion depois. Defina logs operacionais úteis e retenção sem presumir que um rótulo de distribuição ou transporte cria uma política de zero logs. Preserve evidências suficientes para diagnosticar falhas, evitando coleta desnecessária. 07 Leia as opções de hospedagem como partes do projeto SwissOctet Veil lista opções de stack de aplicação, endereço onion e backup. Selecione a stack que seu software espera e CPU, memória e armazenamento suficientes para a carga de trabalho. Confirme como o serviço real lida com implantação, identidade de serviço e restauração antes de depender dele. A localização suíça do catálogo é separada do comportamento de privacidade da sua aplicação. Mantenha o serviço destinado a publicação legítima e usuários autorizados. Planeje atualizações de administrador, revisões de acesso e uma resposta a credenciais de aplicação comprometidas. Uma publicação onion funciona melhor quando conteúdo, exposição do backend e recuperação são compreensíveis; o transporte deve apoiar esse plano em vez de se tornar uma desculpa para pular a segurança comum de software. TRANSFORME ISSO EM AÇÃO Sua lista prática. ✓ Defina conteúdo público e restrito antes da implantação. ✓ Verifique a exposição real do listener do backend. ✓ Revise páginas, uploads e solicitações de recursos externos. ✓ Proteja e teste a recuperação do material de chave do serviço. ✓ Separe a autorização de cliente das funções da aplicação. ✓ Teste manutenção e jornadas do leitor pelo caminho onion. Baixar lista PERGUNTAS COMUNS Os detalhes que importam. A hospedagem onion torna uma aplicação anônima por si só? + Não. Conteúdo publicado, configuração, contas e práticas operacionais podem revelar informações. Revise todo o serviço em vez de confiar no método de conexão. Todo site onion deve usar autorização de cliente? + Não. Decida a partir do público pretendido. A autorização de cliente restringe o acesso à conexão e adiciona um ciclo de vida de credencial; as permissões da aplicação permanecem separadas. O que devo proteger em uma cópia de recuperação? + Dados do site e configuração precisam de controles de acesso adequados. Qualquer material de chave de serviço incluído é especialmente sensível e deve permanecer privado durante o armazenamento e a restauração. REFERÊNCIAS PRINCIPAIS Vá à fonte. Estas referências apoiam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema em produção. Tor Project: Configure seu serviço onion community.torproject.org Tor Project: Configurações avançadas do serviço onion community.torproject.org Tor Project: Autorização de cliente community.torproject.org Orientação editorial da SwissOctet. Os exemplos são ilustrativos. Especificações de serviço, opções disponíveis e condições contratuais devem ser verificadas separadamente. CONECTE O CONHECIMENTO Infraestrutura relacionada. Veil Onion Suíça Vector VPS Suíça Vault Storage Suíça MANTENHA O FIO Suas próximas notas de campo. Explore todos os guias NOTA DE CAMPO / 01 + Nuvem e VPS Fundação Como escolher um VPS sem adivinhar Transforme uma ideia de aplicação em um orçamento útil de recursos e depois compare CPU, memória, armazenamento e transferência em conjunto. 4 min de leitura Leia o guia NOTA DE CAMPO / 02 + Web e onion Fundação Hospedagem web ou uma VPS: escolha o trabalho que você quer assumir Compare requisitos da aplicação, controle e responsabilidades de manutenção, em vez de tratar uma VPS como o próximo passo automático para todo site. 6 min de leitura Leia o guia NOTA DE CAMPO / 03 + Web e onion Aplicado Um runbook de cutover de domínio, DNS e TLS para um novo servidor Prepare o roteamento de hostname, os certificados e o rollback em conjunto, para que uma migração mude o servidor sem quebrar a identidade do site ou as conexões seguras. 4 min de leitura Leia o guia