Las Network Policies en Snowflake permiten restringir el acceso a la cuenta según direcciones IP autorizadas. Son una capa adicional de seguridad clave en entornos empresariales.

Sin embargo, una configuración incorrecta puede provocar:

• Bloqueo accidental de usuarios
• Errores de conexión
• Interrupciones operativas
• Dificultades de acceso administrativo

En este artículo revisamos los errores más comunes al trabajar con Network Policies y cómo resolverlos correctamente.

Error 1: Bloqueo accidental de la propia IP

Uno de los errores más frecuentes es aplicar una Network Policy sin incluir la IP actual desde la que se está configurando.

Ejemplo de política mal configurada:

CREATE NETWORK POLICY corporate_policy

ALLOWED_IP_LIST = (‘192.168.1.0/24’);

Si el administrador no está dentro de ese rango, quedará bloqueado inmediatamente al aplicar la política.

Cómo evitarlo

Antes de aplicar:

1. Verificar IP pública actual.
2. Incluir temporalmente esa IP en la allowlist.
3. Probar acceso antes de aplicarla a nivel de cuenta.

Aplicación a nivel cuenta:

ALTER ACCOUNT SET NETWORK_POLICY = corporate_policy;

Siempre validar antes de ejecutar este comando.

Error 2: Confusión entre ALLOWED_IP_LIST y BLOCKED_IP_LIST

Snowflake evalúa ambas listas, y una mala combinación puede generar conflictos.

Ejemplo problemático:

CREATE NETWORK POLICY policy_example

ALLOWED_IP_LIST = (‘0.0.0.0/0’)

BLOCKED_IP_LIST = (‘203.0.113.5’);

Aunque se permite todo el tráfico, una configuración incorrecta puede generar comportamientos inesperados si no se entiende bien la precedencia.

Recomendación

• Evitar configuraciones excesivamente amplias.
• Mantener listas claras y documentadas.
• Preferir allowlist específica en lugar de bloqueos amplios.

Error 3: Aplicar la política en el nivel incorrecto

Las Network Policies pueden aplicarse a:

• Nivel de cuenta
• Nivel de usuario

Aplicarla a nivel cuenta afecta a todos los usuarios:

ALTER ACCOUNT SET NETWORK_POLICY = corporate_policy;

Aplicarla a nivel usuario:

ALTER USER analyst_user SET NETWORK_POLICY = corporate_policy;

Confundir ambos niveles puede generar bloqueos inesperados.

Error 4: No considerar entornos multi-región o VPN

En organizaciones con:

• VPN corporativa
• Oficinas internacionales
• Usuarios remotos
• Entornos multi-cloud

Las IP pueden variar.

Si no se contemplan todos los rangos posibles, algunos usuarios perderán acceso.

Recomendación

• Coordinar con el equipo de infraestructura.
• Documentar rangos IP corporativos.
• Evaluar rangos dinámicos si existen.

Error 5: Cambios sin pruebas previas

Aplicar una política directamente en producción sin validación previa puede generar:

• Interrupción de pipelines
• Fallos en integraciones externas
• Problemas en herramientas BI

Buena práctica

• Probar primero en el entorno de desarrollo.
• Aplicar a usuarios específicos antes de aplicarla globalmente.
• Validar acceso de cuentas de servicio.

Error 6: Olvidar cuentas de servicio o integraciones externas

Herramientas como:

• BI tools
• Fivetran
• APIs externas
• Scripts automatizados

pueden conectarse desde IPs específicas.

Si no se incluyen esas IPs en la allowlist, los procesos fallarán.

Cómo diagnosticar problemas

Cuando un usuario no puede conectarse:

1. Verificar mensaje de error.
2. Confirmar IP pública del cliente.
3. Revisar política activa:

SHOW NETWORK POLICIES;

1. 
   Confirmar asignación:

SHOW PARAMETERS LIKE ‘NETWORK_POLICY’ IN ACCOUNT;

o

SHOW PARAMETERS LIKE ‘NETWORK_POLICY’ IN USER analyst_user;

Esto permite identificar rápidamente el origen del problema.

Estrategia recomendada para entornos empresariales

Una implementación segura suele incluir:

• Política global restrictiva.
• Políticas específicas para administradores.
• Documentación clara de IPs.
• Revisión periódica.
• Integración con VPN corporativa.
• Control de cambios formal.

Las Network Policies deben formar parte de una estrategia más amplia de seguridad, no ser un control aislado.

Relación con arquitectura Zero Trust

Las Network Policies contribuyen a un enfoque de:

• Defense in Depth
• Zero Trust
• Seguridad multicapa

Pero no sustituyen:

• MFA
• SSO
• RBAC
• Masking policies

La seguridad debe ser integral.

Conclusión

Las Network Policies en Snowflake son una herramienta poderosa para reforzar la seguridad a nivel de red. Sin embargo, una configuración incorrecta puede provocar bloqueos operativos significativos.

La clave está en:

• Planificación previa
• Pruebas controladas
• Documentación clara
• Coordinación con infraestructura

Bien implementadas, las Network Policies aportan una capa sólida de protección sin afectar la operativa diaria.