6. Diseño de políticas de firewall: objetivos, alcance, riesgo y criterios de aceptación

6.1 Introducción

En el tema anterior vimos distintos tipos de firewalls. Ahora nos enfocaremos en una tarea central: diseñar políticas. Una política de firewall define qué comunicaciones se permiten, se bloquean, se registran o se inspeccionan.

El problema no suele ser crear una regla aislada. El problema real es mantener un conjunto de reglas coherente a lo largo del tiempo. Si cada urgencia se resuelve agregando permisos amplios, la política termina siendo difícil de entender, riesgosa y casi imposible de auditar.

Diseñar una política exige combinar seguridad, operación y negocio. La regla debe permitir lo necesario, bloquear lo innecesario, registrar lo importante y tener una justificación clara.

6.2 Qué es una política de firewall

Una política de firewall es el conjunto de criterios y reglas que determina cómo se controla el tráfico entre zonas, redes, sistemas, usuarios o aplicaciones. Puede incluir reglas técnicas, procedimientos de aprobación, estándares de nomenclatura, criterios de logging y revisiones periódicas.

Una política bien diseñada responde preguntas como:

• Qué comunicación se necesita permitir.
• Quién solicita el acceso y quién lo aprueba.
• Cuál es el origen y cuál es el destino.
• Qué protocolo, puerto o aplicación se requiere.
• Por cuánto tiempo debe estar habilitado.
• Qué riesgo introduce.
• Qué registro o monitoreo debe aplicarse.
• Cómo se probará que funciona sin abrir de más.

6.3 Objetivo de una regla

Cada regla debe tener un objetivo concreto. Si una regla no puede explicarse en una frase simple, probablemente está mal definida o necesita dividirse.

Ejemplos de objetivos claros:

• Permitir que la aplicación web de la DMZ consulte la base de datos interna por el puerto necesario.
• Permitir que la red de administración acceda por SSH a servidores Linux específicos.
• Bloquear conexiones RDP desde internet hacia cualquier activo interno.
• Permitir consultas DNS solo hacia resolutores corporativos autorizados.

6.4 Alcance de una política

El alcance define dónde aplica la política. Puede ser un firewall perimetral, un firewall interno, una nube, una DMZ, un grupo de servidores, una red de usuarios o un conjunto de firewalls administrados centralmente.

Definir el alcance evita confusiones. No es lo mismo una política para salida a internet que una política entre aplicaciones internas. Tampoco es lo mismo una regla temporal para migración que una regla permanente para un servicio crítico.

6.5 Principio de mínimo acceso

El principio de mínimo acceso indica que una regla debe permitir solo lo estrictamente necesario. En firewalls, esto se traduce en limitar origen, destino, puerto, protocolo, aplicación, usuario y duración.

Comparación sencilla:

6.6 Denegar por defecto

Una política defensiva suele aplicar el criterio de denegar por defecto: lo que no está explícitamente permitido, se bloquea. Esto obliga a justificar cada comunicación y evita que el tráfico inesperado circule libremente.

El cierre típico de una política es una regla final de bloqueo. Esta regla debe registrar al menos eventos relevantes, porque los bloqueos pueden indicar errores de configuración, intentos de abuso o necesidades operativas no documentadas.

6.7 Análisis de riesgo antes de permitir

No todas las comunicaciones tienen el mismo riesgo. Permitir HTTPS desde usuarios hacia internet no tiene el mismo impacto que permitir administración remota desde internet hacia servidores internos.

Antes de aprobar una regla, conviene evaluar:

• Sensibilidad del destino.
• Nivel de confianza del origen.
• Tipo de protocolo o aplicación.
• Exposición a internet o a terceros.
• Posibilidad de movimiento lateral.
• Impacto si se compromete la cuenta, sistema o servicio.
• Controles compensatorios disponibles.

6.8 Matriz simple de riesgo

Una forma práctica de ordenar decisiones es usar una matriz simple que combine probabilidad e impacto. No hace falta que sea compleja para ser útil.

6.9 Criterios de aceptación

Los criterios de aceptación indican bajo qué condiciones una regla puede aprobarse. Funcionan como una lista de requisitos mínimos antes de implementar el cambio.

Ejemplos de criterios:

• La solicitud tiene dueño técnico y dueño de negocio.
• El origen, destino, puerto y protocolo están definidos con precisión.
• La regla tiene justificación operativa.
• El acceso respeta mínimo privilegio.
• Se evaluó el riesgo y se definieron controles compensatorios si hacen falta.
• La regla tiene fecha de revisión o expiración si es temporal.
• Se especificó qué debe registrarse.
• Existe una prueba para validar que la regla funciona y no abre de más.

6.10 Información mínima de una solicitud

Una solicitud de regla incompleta genera demoras, errores y permisos demasiado amplios. Por eso conviene pedir siempre una base mínima de información.

6.11 Reglas temporales

Las reglas temporales son necesarias en migraciones, pruebas, incidentes o integraciones puntuales. El problema aparece cuando se crean como temporales y quedan activas indefinidamente.

Una regla temporal debe tener:

• Fecha y hora de inicio.
• Fecha y hora de expiración.
• Responsable de aprobación.
• Motivo documentado.
• Monitoreo durante su vigencia.
• Confirmación de eliminación al finalizar.

6.12 Logging y visibilidad

No todas las reglas necesitan el mismo nivel de logging, pero las reglas importantes deben dejar evidencia suficiente para investigar. Registrar todo sin criterio puede generar demasiado ruido; registrar poco puede dejar ciegos a los equipos de seguridad.

Conviene registrar especialmente:

• Bloqueos en zonas sensibles.
• Accesos administrativos.
• Tráfico desde internet hacia servicios publicados.
• Tráfico desde DMZ hacia red interna.
• Conexiones hacia destinos de alto riesgo.
• Reglas temporales o excepcionales.
• Cambios en la propia política de firewall.

6.13 Orden de reglas

En muchos firewalls, las reglas se evalúan de arriba hacia abajo. La primera coincidencia define la acción. Por eso el orden es parte del diseño.

Una regla demasiado amplia ubicada antes de reglas específicas puede anular controles posteriores. Por ejemplo, si primero se permite todo el tráfico desde una red, una regla posterior que intenta bloquear un puerto específico quizá nunca se aplique.

Buenas prácticas de orden:

• Ubicar reglas específicas antes que reglas generales.
• Separar reglas por zona o propósito.
• Evitar reglas duplicadas o solapadas.
• Mantener una regla final de bloqueo.
• Documentar excepciones cerca de las reglas afectadas.

6.14 Nombres, comentarios y documentación

Una política mantenible necesita nombres y comentarios claros. Si una regla dice "permit any temp test", en unos meses nadie sabrá qué hace, quién la pidió ni si se puede eliminar.

Una buena descripción debería incluir:

• Propósito de la regla.
• Ticket o solicitud asociada.
• Responsable técnico.
• Fecha de creación.
• Fecha de revisión o expiración.
• Aplicación o servicio afectado.

6.15 Validación antes y después del cambio

Antes de aplicar una política, conviene validar impacto. Después de aplicarla, hay que confirmar que cumple su objetivo sin abrir tráfico adicional.

Validaciones útiles:

• Probar conectividad desde el origen autorizado.
• Confirmar que destinos no autorizados siguen bloqueados.
• Revisar logs para verificar qué regla coincide.
• Confirmar que no se afectaron servicios relacionados.
• Monitorear alertas IDS/IPS después del cambio.
• Guardar evidencia de la prueba.

6.16 Ejemplo práctico de diseño de política

Supongamos que una aplicación web en DMZ necesita consultar una base de datos interna. Una mala solución sería permitir todo el tráfico desde la DMZ hacia la red interna. Una política defensiva sería mucho más precisa.

6.17 Gestión de cambios

Una política de firewall debe cambiar con control. Los cambios urgentes existen, pero incluso en urgencias conviene dejar registro y revisar después.

Un flujo básico de cambio puede ser:

1. Solicitud con datos mínimos.
2. Revisión técnica y de seguridad.
3. Evaluación de riesgo.
4. Aprobación.
5. Implementación en ventana definida.
6. Prueba de funcionamiento.
7. Monitoreo posterior.
8. Documentación y cierre.

6.18 Errores frecuentes

• Permitir "any-any": abre más tráfico del necesario y dificulta auditoría.
• No definir responsable: nadie sabe si la regla sigue siendo necesaria.
• No registrar bloqueos: se pierde visibilidad sobre intentos fallidos o abusos.
• Acumular reglas temporales: aumentan exposición sin revisión.
• Ignorar el orden: reglas amplias pueden neutralizar reglas específicas.
• No probar: una regla puede no funcionar o abrir más de lo esperado.
• Documentar mal: una política sin contexto se vuelve difícil de mantener.

6.19 Lista de verificación inicial

• Definir objetivo de cada regla.
• Precisar origen, destino, puerto, protocolo y aplicación.
• Aplicar mínimo acceso.
• Evaluar riesgo antes de permitir.
• Definir logging necesario.
• Asignar responsable técnico y de negocio.
• Agregar fecha de revisión o expiración.
• Validar antes y después del cambio.
• Revisar reglas solapadas o duplicadas.
• Mantener una regla final de bloqueo.

6.20 Ideas clave para recordar

• Una política de firewall debe estar guiada por necesidad, riesgo y mínimo acceso.
• El alcance define dónde aplica una regla y qué impacto puede tener.
• Los criterios de aceptación evitan reglas vagas o demasiado amplias.
• Las reglas temporales necesitan expiración real.
• El logging debe aportar visibilidad sin generar ruido inútil.
• La documentación y la revisión periódica son parte de la seguridad.

6.21 Conclusión

Diseñar políticas de firewall es mucho más que abrir o cerrar puertos. Implica entender la necesidad, definir alcance, evaluar riesgo, aplicar mínimo acceso, registrar lo importante y validar que el cambio tenga el efecto esperado.

En el próximo tema estudiaremos reglas, ACL, orden de evaluación, objetos, grupos y buenas prácticas de filtrado. Allí veremos cómo llevar estas políticas a configuraciones concretas.