Seguridad de GeoServer: permisos de capa, autenticación y proxy

GeoServer en producción necesita responder cuatro preguntas: quién llega al servicio, quién es el usuario, qué puede consultar o modificar y cuánto trabajo puede consumir cada solicitud. TLS protege el transporte. Un formulario de ingreso no resuelve por sí solo los permisos de capas ni el aislamiento de caché.

Esta guía plantea un servicio público de mapas con administración privada y acceso de lectura a la base. Es un procedimiento operativo: adapte identidad, red y límites al entorno. Use el laboratorio sintético para ensayar y consulte documentación de la versión instalada, especialmente si extensiones modifican la autenticación.

1. Dibuje las rutas reales

Identifique dominio público, proxy, puerto GeoServer, fuentes y entrada administrativa. Incluya GeoWebCache, REST de configuración, monitoreo y URLs internas. Proteger un dominio no sirve si el mismo servidor continúa abierto por otro puerto.

Lectores -> borde HTTPS -> servicios de lectura -> GeoServer -> rol de base lector
Administradores -> acceso privado -> administración / REST -> configuración controlada
Editores -> flujo autorizado separado -> validación y rol de escritura explícitos

Los servicios públicos y administrativos pueden compartir instalación, pero su exposición debe decidirse por separado. La base debe aceptar conexiones solo desde los equipos requeridos. No la publique para facilitar una prueba de diagnóstico.

2. Publique un producto de datos seguro

Seleccione filas y campos realmente públicos. Una capa predial puede necesitar geometría, identificador y categoría de revisión, sin nombres de propietarios. Una vista o tabla exclusiva con los campos aprobados crea una segunda frontera si cambia una consulta de aplicación.

Revise WMS, GetFeatureInfo, WFS, metadatos, vista previa y teselas. Ocultar un campo en el visor no impide descargarlo directamente. Del mismo modo, una capa no anunciada es una decisión de descubrimiento, no un permiso; la documentación de capas distingue ambos comportamientos.

El usuario de base debe tener privilegios mínimos. Un endpoint público de lectura no necesita ser propietario de todas las tablas catastrales. Si mantiene WFS-T para otro proceso, use una cuenta separada y pruebe autorización y validación de escritura.

3. Separe autenticación y autorización

Autenticar establece identidad; autorizar determina operaciones y recursos permitidos. La cadena de autenticación GeoServer selecciona filtros según la solicitud y su orden. Una sesión de navegador que funciona en administración no demuestra que REST, WMS y un cliente de API sigan la cadena esperada.

Prepare identidades de prueba: lector anónimo, lector restringido, editor y administrador. Incluya una capa pública y otra deliberadamente inaccesible. Pruebe operaciones permitidas y prohibidas para cada identidad. Si integra un proveedor corporativo, verifique credenciales vencidas, retiro de grupos y renovación de sesión por el proxy real.

La seguridad por capas documenta restricciones al combinar reglas de capas y servicios. No suponga que cualquier matriz se logra superponiendo mecanismos. Para políticas complejas puede necesitar una extensión revisada o una frontera de aplicación; registre esa dependencia para las actualizaciones.

4. Proteja configuración y datos por separado

REST permite configurar almacenes, capas y estilos; no es simplemente una descarga de objetos. Limítelo a administradores y automatización autorizada. Restrinja también la interfaz web y retire datos de demostración no destinados al público. Cambie credenciales iniciales antes de exponer la instalación.

Revise la referencia de seguridad REST correspondiente al despliegue. En red y proxy permita solo rutas y métodos públicos requeridos. Una lista de operaciones permitidas resulta más fácil de revisar que excepciones agregadas sin inventario. Conserve una entrada privada de recuperación si una configuración de identidad bloquea al operador.

Asigne cuentas distintas a cada automatización con responsable y propósito. No reutilice la contraseña personal del administrador en CI. Guarde secretos en el sistema de despliegue y suprima cabeceras de autenticación y conexiones privadas de diagnósticos.

5. Incluya el proxy en el contrato

Capacidades y redirecciones deben anunciar URLs HTTPS accesibles. Compruébelas desde fuera de la red: una solicitud local exitosa puede devolver localhost o un host privado. Configure URL base y cabeceras reenviadas según la topología real.

Confíe en cabeceras de identidad y host solo si vienen de su proxy. El borde debe retirar valores aportados por el cliente antes de añadir los propios. No resuelva un problema de redirección confiando indiscriminadamente en cabeceras externas. Revise tamaño de cuerpo, tiempos máximos, conexiones y métodos permitidos por operación.

CORS regula lectura desde código de navegador; no protege contra clientes HTTP directos. Configure los orígenes que necesita la aplicación y pruebe solicitudes previas cuando correspondan. Los datos abiertos pueden admitir lectura entre muchos orígenes, pero esa decisión debe coincidir con licencia y alcance.

6. Limite operaciones costosas

Seleccione límites según cargas medidas: número de objetos, tamaño de imagen, presupuesto de renderizado, concurrencia y duración de consultas SQL. Deben proteger disponibilidad sin truncar silenciosamente el trabajo. Si un límite corta resultados, el cliente debe poder detectarlo; ofrezca una descarga masiva separada cuando sea necesaria.

No exponga extensiones de procesos o estilos dinámicos solo porque estén instaladas. Cada capacidad pública aumenta la superficie de mantenimiento y pruebas.

7. Pruebe denegaciones desde el borde público

Use el dominio y la ruta que utilizarán los consumidores. Probar únicamente localhost omite errores del proxy y caché. Mantenga datos ficticios y no copie tokens en capturas o incidencias.

Lea de nuevo la configuración tras una escritura denegada: un error HTTP no garantiza ausencia de cambios parciales. Revise GET y POST en operaciones OGC que los admitan. Si la política exige ocultar nombres restringidos, compruebe también capacidades.

8. Mantenga la protección después del lanzamiento

Conserve inventario de versiones y extensiones, siga avisos de seguridad y ensaye actualizaciones en un entorno restaurado. Incluya Java, autenticación, extensiones y consumidores. Los logs deben contener datos operativos útiles; no tokens, atributos privados ni consultas sensibles completas.

Conecte alertas con acciones: aumento de errores inicia diagnóstico, consultas lentas activan revisión y respaldo fallido exige investigar recuperación. Un tablero sin responsable no resuelve incidentes.

Continúe con restauración y actualización GeoServer. Lleve identidad, alcance por filas y edición a la evaluación de migración antes de decidir una arquitectura de reemplazo.