Proxy SG, políticas y sus mejores prácticas

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:

1. Agrupa capa tipo de decisión en la misma capa. Por ejemplo las decisiones de autenticación en una capa, las de acceso web en otra. El fabricante recomienda un esquema de capas similar al siguiente:

2. Trata de ser consistente con el modelo. Toma siempre en cuenta el tipo de acción que se toma por defecto sea Permitiendo o Denegando. Si se toma la acción de Denegar como regla por defecto –recomendado para usar el proxy como Gateway- entonces las reglas específicas de cada capa deben ser por lo general un Permitir.

4. Agrupa los orígenes lo mejor que puedas según su función, esto puede ser agrupando usuarios, o segmentos IP según las políticas de uso de la red para cada tipo de usuario. Podrías por ejemplo agrupar a los usuarios en el directorios LDAP según su cargo y función o agrupar los orígenes sabiendo que los usuarios de Recursos Humanos tienen un direccionamiento IP y los Vicepresidentes otro.
5. Agrupa los destinos en categorías. Bluecoat categoriza las páginas web por su contenido y lo actualiza constantemente (https://sitereview.bluecoat.com/categories.jsp); podemos crear reglas que permitan a cada grupo de usuarios el acceso a diferentes categorías. Por ejemplo:

• • Grupo A (Vicepresidentes) – Acceso a todas las categorías
  • Grupo B (Empleados) – Acceso a todas las categorías excluyendo el contenido para adultos, violencia y tabaco.
  • Grupo C (Personal externo) – Acceso sólo a categorías de Reuniones en línea, y entidades financieras.

5. Coloca las reglas más utilizadas al inicio de la capa. En el ejemplo anterior al haber más empleados que Vicepresidentes, colocaría las reglas para cada uno en el orden: Grupo B > Grupo C > Grupo A.
6. Evita el uso de expresiones regulares. Expresar URL específicos en las reglas es ineficiente para el uso de recursos.
7. Utiliza definiciones u objetos para minimizar la cantidad de reglas. Si se aplica una misma acción para varios segmentos IP de Origen, podríamos agruparlos en un objeto.
8. Utiliza “LayerGuards” para evitar la lectura innecesaria de capas. El uso de esta herramienta nos permite evaluar una condición antes de leer las sentencias de una capa. Ejemplo: Un usuario corporativo, se evalúa sobre la capa “Corp Web Access”, de lo contrario debe continuar su flujo en el resto de las capas.

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.