Antes de começar
- Um inventário de serviços com os dados que cada componente mantém.
- Uma lista de papéis de membro, editor e administrador.
- Uma conta de teste autorizada e uma rota de recuperação documentada antes de alterar configurações de rede ou login.
1. Descreva a pessoa e a tarefa.
Para cada serviço, complete esta frase: “Uma pessoa neste papel precisa realizar esta ação a partir deste tipo de dispositivo.” Ler um horário público, editar um procedimento interno e manter um banco de dados são tarefas diferentes. Evite tornar um serviço público simplesmente porque um voluntário precisa de acesso remoto ocasional.
Separe o acesso à rede da autorização da aplicação. Alcançar uma página de login não é permissão para ler arquivos de membros. Por outro lado, ocultar um serviço atrás de uma rede privada não decide quais membros podem editar ou exportar seu conteúdo. Registre ambas as camadas e o processo para remover acesso quando alguém sair.
Mantenha a recuperação de conta na mesma discussão. Um serviço privado que só uma pessoa consegue desbloquear cria uma falha diferente, mesmo que suas regras iniciais de acesso pareçam restritivas.
2. Preencha uma pequena matriz de acesso.
Aqui está uma configuração hipotética de oficina comunitária. As escolhas são exemplos para discussão, não um design de rede pronto.
| Componente | Público pretendido | Ação permitida | Verifique |
|---|---|---|---|
| Horário público | Qualquer pessoa | Ler datas aprovadas | Visitante desconectado não vê notas de membros |
| Wiki de trabalho | Membros e editores | Ler; editar apenas para editores | Membro não pode alterar um procedimento |
| Biblioteca de arquivos | Contas de grupo nomeadas | Ler ou enviar dentro das áreas atribuídas | Conta desligada não pode baixar um arquivo |
| Administração da aplicação | Mantenedores autorizados | Gerenciar configurações e contas | Membro comum não pode abrir configurações |
| Banco de dados | Caminho de aplicação e manutenção | Operações necessárias da aplicação | Nenhum listener público não intencional |
Escreva o mecanismo real ao lado de cada linha: contas de aplicação, um método de acesso privado aprovado ou outro controle documentado. “Privado” sem um mecanismo e um teste é apenas um rótulo.
3. Revise os caminhos ao redor da página de login.
Liste o proxy reverso, listeners de aplicação, portas de banco de dados e ferramentas de administração. Uma aplicação pode ter uma tela de login cuidadosamente configurada enquanto uma interface diferente permanece alcançável. Inspecione a configuração implantada antes de alterá-la e mantenha um caminho de recuperação para qualquer coisa que controle acesso remoto.
O Docker merece uma verificação separada quando faz parte da sua configuração. Um mapeamento de porta sem um endereço de host explícito normalmente é publicado em todos os endereços do host. Uma vinculação de loopback limita o acesso no caso NAT padrão documentado, mas o modo de rede, o roteamento direto e o comportamento de versões mais antigas do Docker importam. Leia a documentação para a topologia real e depois verifique a acessibilidade pelos caminhos IPv4 e IPv6 que você utiliza. Publicação e mapeamento de portas do Docker.
4. Verifique controles efetivos, não rótulos tranquilizadores.
Inspecione o firewall em conjunto com o software que cria as regras de rede. O Docker documenta que o tráfego publicado de contêineres pode ser desviado antes que as regras de entrada usuais do UFW sejam aplicadas. Portanto, um status do UFW aparentemente limpo não prova que uma porta de contêiner está inacessível. Não desative o gerenciamento de firewall do Docker como uma solução rápida; a documentação descreve as consequências de rede. Filtragem de pacotes e firewalls do Docker.
Verifique as funções de aplicação separadamente. Por exemplo, o BookStack combina habilidades de função e permite substituições no nível de conteúdo, portanto as permissões efetivas de um usuário podem diferir do nome de uma função atribuída. Revise a atribuição completa e teste páginas e anexos representativos. Regras de permissão do BookStack.
5. Mantenha transporte e confiança no plano.
Um serviço restrito a membros ainda carrega credenciais e conteúdo privado. Planeje HTTPS e a confiança em certificados para os clientes reais em vez de ensinar os membros a ignorar avisos do navegador. Mantenha a responsabilidade pela renovação de certificados e verificações de falha no caderno junto com o acesso ao domínio.
A documentação do Caddy distingue a validação de certificado público de sua autoridade de certificação local. Um cliente deve confiar na autoridade local para usar seus certificados sem avisos. Para certificados públicos, a validação HTTP e TLS-ALPN precisam de seus respectivos caminhos de entrada; a validação DNS é uma alternativa configurada separadamente. Escolha um método que se ajuste ao limite de acesso pretendido. HTTPS automático do Caddy e confiança local.
Esta é uma etapa de planejamento de acesso, não uma afirmação de que um certificado por si só torna uma aplicação privada ou devidamente autorizada.
6. Teste tanto os caminhos permitidos quanto os negados.
Use sessões de navegador separadas para um visitante desconectado, um membro comum e um editor. Verifique uma página normal, uma URL direta de anexo local, uma ação de exportação e uma rota de administração. Teste novamente após remover uma conta ou alterar sua função. Registre o resultado esperado antes de tentar a ação para que um sucesso inesperado não seja confundido com conveniência.
A partir de redes que você está autorizado a usar para testes, verifique se o serviço público está acessível e se as interfaces privadas pretendidas não estão. Teste as famílias de endereços relevantes e o endpoint real, não apenas um nome de host que pode resolver de forma diferente. Registre a data, a rede de origem e o resultado. Essas verificações devem ser realizadas na sua configuração; nenhuma é declarada como concluída aqui.
Teste uma imagem incorporada confidencial por sua URL direta enquanto desconectado e com um membro não autorizado. As imagens do BookStack são públicas por padrão, ao contrário dos anexos locais; uma página restrita por si só é insuficiente. Revise segurança de imagens e os distinções de armazenamento e permissão no guia de acesso antes de aceitar o limite.
7. Trate um limite falho como uma decisão a revisitar.
Se uma conta não autorizada puder ler dados, pare de expandir o acesso e inspecione a herança de funções, compartilhamentos e caminhos diretos de arquivos. Se uma porta privada estiver acessível, revise sua vinculação e regras de rede antes de adicionar outra camada por tentativa e erro. Se o mantenedor pretendido não conseguir se conectar, use a rota de recuperação documentada em vez de conceder a todos um acesso mais amplo.
Coloque a regra corrigida e uma verificação repetível no caderno de acesso. Vincule-o ao inventário de serviços e exercício de recuperação. Esses limites reduzem o acesso indesejado quando implementados corretamente; eles não prometem anonimato nem removem a necessidade de atualizações e manuseio cuidadoso de dados.
Documentação por trás desta nota
Use a documentação da versão que você realmente executa. Estes exemplos são material de planejamento, não um registro de teste em um VPS Hoszen.