Con el Proxy SG podemos implementar toda clase de filtrado de contenidos, prácticamente hasta donde alcance la imaginación y aunque no recomiendo ser demasiado creativo y exigente con las políticas, es importante conocer cómo funcionan para mantener una administración limpia y políticas eficientes.
Lo primero es comprender el flujo de una solicitud a través de las políticas. Las políticas están separadas en capas y cada una debe tener un propósito específico. Por ejemplo una solicitud podría pasar por las cuatro (04) que se muestran en la imagen, cada capa tiene un objetivo y debo atravesar todas ellas para obtener un resultado final. Dentro de cada capa se deben leer las sentencias como una lista de acceso hasta coincidir con una regla. En el ejemplo, según las condiciones de la solicitud –como el segmento IP del usuario, grupo al que pertenece, destino de la solicitud, entre otros- , se toma la decisión de no autenticar, requiere una conexión SSL, y al determinar que el destino es una página de redes sociales –por ejemplo- es denegado en la primera capa de acceso web, más en la segunda capa de acceso web se programan excepciones y el solicitante que es el administrador de redes sociales de la compañía es finalmente permitido el acceso.
En cada capa se debe tomar una decisión, y también es importante conocer las diferentes acciones a tomar en cada una de ellas. En una capa de autenticación, por supuesto está la decisión de “No Authenticate” y “Authenticate”, más también podemos encontramos el “Force Authenticate”. La diferencia entre los últimos dos (2) es que el Authenticate no solicita la autenticación al usuario si la solicitud será denegada en otra capa, por lo tanto no guardamos registro de la solicitud; mientras que un Force Authenticate siempre solicita la autenticación y por supuesto tendremos registro de quién está haciendo solicitudes incluso si están prohibidas.
Otra acción relevante es la decisión tomada en las capas de acceso. Allí se presentan las opciones de “Allow”, “Deny” y “Force Deny”. Una solicitud puede ser denegada en una capa y finalmente permitida en otra como en el ejemplo; la diferencia entre el Deny, y el Force Deny es que el último no puede ser sobre escrito en otra capa, incluso si se encuentra coincidencia con un Allow en otra capa luego del Force Deny la acción no va a cambiar.
Entendiendo como funciona el flujo de lectura de políticas para una solicitud, se llega a la conclusión de que esto puede llegar a ser muy complejo por lo que mi primer y más importante consejo es tratar de mantenerlo simple y eficiente, aunque la herramienta es muy flexible, pocas reglas aplicadas de manera inteligente te pueden llevar muy lejos. Esto es un mal ejemplo –nótese el número de regla 160-, incluso en una empresa grande no veo explicación lógica para tener tantas reglas.
Ahora dejo una rápida lista de mejores prácticas para la implementación y administración de políticas de un Proxy SG:
Layer type |
Logical Implementation |
<admin> |
Admin Authentication Layer |
<admin> |
Admin Access Layer |
<dns-proxy> |
DNS Access Layer |
<proxy> |
SOCKS Authentication Layer |
<ssl-intercept> |
SSL Intercept Layer |
<ssl> |
SSL Access Layer |
<proxy> |
Web Authentication Layer |
<proxy> |
Web Access Layer |
<cache> |
Web Content Layer |
<forward> |
Forwarding Layer |
Seguir estos lineamientos facilita la administración del equipo y nos permite una lectura rápido de las reglas. El problema es mantener el orden con el paso del tiempo, y el mejor consejo que puedo dar para ello es brindar adiestramiento a los administradores; esto puede evitar muchos problemas a largo plazo.