Antes de empezar
- Un inventario de servicios con los datos que contiene cada componente.
- Una lista de roles de miembro, editor y administrador.
- Una cuenta de prueba autorizada y una ruta de recuperación documentada antes de cambiar la red o la configuración de inicio de sesión.
1. Describe a la persona y la tarea.
Para cada servicio, completa esta frase: «Una persona con este rol necesita realizar esta acción desde este tipo de dispositivo». Leer un horario público, editar un procedimiento interno y mantener una base de datos son tareas diferentes. Evita hacer público un servicio solo porque un voluntario necesita acceso remoto ocasional.
Separa el acceso a la red de la autorización en la aplicación. Llegar a una página de inicio de sesión no es permiso para leer archivos de miembros. A la inversa, ocultar un servicio detrás de una red privada no decide qué miembros pueden editar o exportar su contenido. Registra ambas capas y el proceso para retirar el acceso cuando alguien se marcha.
Mantén la recuperación de cuentas en la misma discusión. Un servicio privado que solo una persona puede desbloquear crea un fallo diferente, aunque sus reglas de acceso iniciales parezcan restrictivas.
2. Rellena una pequeña matriz de acceso.
Aquí tienes una configuración hipotética de taller comunitario. Las opciones son ejemplos para el debate, no un diseño de red listo para usar.
| Componente | Público previsto | Acción permitida | Comprobación |
|---|---|---|---|
| Horario público | Cualquiera | Leer fechas aprobadas | El visitante sin sesión no ve notas de miembros |
| Wiki de trabajo | Miembros y editores | Leer; editar solo para editores | El miembro no puede cambiar un procedimiento |
| Biblioteca de archivos | Cuentas de grupo con nombre | Leer o subir dentro de las áreas asignadas | Una cuenta dada de baja no puede descargar un archivo |
| Administración de la aplicación | Mantenedores autorizados | Gestionar la configuración y las cuentas | Un miembro ordinario no puede abrir la configuración |
| Base de datos | Ruta de aplicación y mantenimiento | Operaciones requeridas de la aplicación | Sin listener público no previsto |
Escribe el mecanismo real junto a cada fila: cuentas de aplicación, un método de acceso privado aprobado u otro control documentado. «Privado» sin un mecanismo y una prueba es solo una etiqueta.
3. Revisa las rutas alrededor de la página de inicio de sesión.
Enumera el proxy inverso, los listeners de la aplicación, los puertos de la base de datos y las herramientas de administración. Una aplicación puede tener una pantalla de inicio de sesión cuidadosamente configurada mientras otra interfaz sigue siendo accesible. Inspecciona la configuración desplegada antes de cambiarla y mantén una ruta de recuperación para todo lo que controle el acceso remoto.
Docker merece una comprobación aparte cuando forma parte de tu configuración. Un mapeo de puertos sin una dirección de host explícita normalmente se publica en todas las direcciones del host. Una vinculación de loopback limita el acceso en el caso NAT predeterminado documentado, pero el modo de red, el enrutamiento directo y el comportamiento de versiones anteriores de Docker importan. Lee la documentación para la topología real y luego verifica la accesibilidad por las rutas IPv4 y IPv6 que uses. Publicación y mapeo de puertos de Docker.
4. Comprueba los controles efectivos, no las etiquetas tranquilizadoras.
Inspecciona el firewall junto con el software que crea las reglas de red. Docker documenta que el tráfico publicado de los contenedores puede desviarse antes de que se apliquen las reglas de entrada habituales de UFW. Por lo tanto, un estado de UFW que parece limpio no demuestra que un puerto de contenedor sea inaccesible. No desactives la gestión del firewall de Docker como solución rápida; la documentación describe las consecuencias de red. Filtrado de paquetes de Docker y firewalls.
Comprueba los roles de la aplicación por separado. Por ejemplo, BookStack combina las capacidades de los roles y permite anulaciones a nivel de contenido, por lo que los permisos efectivos de un usuario pueden diferir del nombre de un rol asignado. Revisa la asignación completa y prueba páginas y adjuntos representativos. Reglas de permisos de BookStack.
5. Mantén el transporte y la confianza en el plan.
Un servicio restringido a miembros sigue conteniendo credenciales y contenido privado. Planifica HTTPS y la confianza en los certificados para los clientes reales en lugar de enseñar a los miembros a ignorar las advertencias del navegador. Mantén la responsabilidad de la renovación de certificados y las comprobaciones de fallos en el cuaderno junto con el acceso al dominio.
La documentación de Caddy distingue la validación de certificados públicos de su autoridad de certificación local. Un cliente debe confiar en la autoridad local para usar sus certificados sin advertencias. Para los certificados públicos, la validación HTTP y TLS-ALPN necesitan sus respectivas rutas de entrada; la validación DNS es una alternativa configurada por separado. Elige un método que se ajuste al límite de acceso previsto. HTTPS automático de Caddy y confianza local.
Este es un paso de planificación de acceso, no una afirmación de que un certificado por sí solo haga que una aplicación sea privada o esté debidamente autorizada.
6. Prueba tanto las rutas permitidas como las denegadas.
Usa sesiones de navegador separadas para un visitante sin sesión, un miembro normal y un editor. Comprueba una página normal, una URL directa de adjunto local, una acción de exportación y una ruta de administración. Vuelve a probar después de eliminar una cuenta o cambiar su rol. Registra el resultado esperado antes de intentar la acción para que un éxito inesperado no se confunda con comodidad.
Desde redes que estés autorizado a usar para pruebas, verifica que el servicio público sea accesible y que las interfaces privadas previstas no lo sean. Prueba las familias de direcciones relevantes y el endpoint real, no solo un nombre de host que puede resolverse de forma diferente. Registra la fecha, la red de origen y el resultado. Estas comprobaciones deben realizarse en tu configuración; ninguna se afirma como completada aquí.
Prueba una imagen confidencial incrustada por su URL directa sin sesión y con un miembro no autorizado. Las imágenes de BookStack son públicas por defecto, a diferencia de los adjuntos locales; una página restringida por sí sola es insuficiente. Revisa seguridad de imágenes y los almacenamiento y distinciones de permisos en la guía de acceso antes de aceptar el límite.
7. Trata un límite fallido como una decisión que revisar.
Si una cuenta no autorizada puede leer datos, detén la expansión del acceso e inspecciona la herencia de roles, los recursos compartidos y las rutas directas de archivos. Si un puerto privado es accesible, revisa su vinculación y las reglas de red antes de añadir otra capa por conjeturas. Si el mantenedor previsto no puede conectarse, usa la ruta de recuperación documentada en lugar de conceder a todos un acceso más amplio.
Coloca la regla corregida y una comprobación repetible en el cuaderno de acceso. Vincúlalo con el inventario de servicios y ejercicio de recuperación. Estos límites reducen el acceso no deseado cuando se implementan correctamente; no prometen anonimato ni eliminan la necesidad de actualizaciones y de un manejo cuidadoso de los datos.
Documentación detrás de esta nota
Usa la documentación de la versión que realmente ejecutas. Estos ejemplos son material de planificación, no un registro de una prueba en un VPS Hoszen.