Docs

Consola

Políticas

Crea, versiona y prueba las políticas que el proxy de RenLayer aplica, el constructor visual de políticas, gestión de prioridad y el playground de pruebas.

La página Políticas es donde los ingenieros de seguridad convierten requisitos organizativos en reglas que el proxy aplica en línea. Cada cambio aquí aterriza en PostgreSQL y la recoge cada instancia del proxy en su siguiente petición.

La lista de políticas

La lista muestra cada política del tenant con su nombre, acción (ALLOW/FLAG/DENY), prioridad, alcance (a qué agentes se aplica) y conteo de activaciones para la ventana seleccionada. Ordenar por conteo de activaciones es la forma más rápida de encontrar políticas que realmente trabajan frente a reglas muertas.

Creación

Haz clic en Nueva política para abrir el constructor. El formulario tiene cuatro partes que reflejan el modelo de políticas:

  1. Condiciones de coincidencia: elige entre agente, tipo de acción, upstream, contenido del prompt, headers, nombre de herramienta. Las condiciones se acumulan con AND.
  2. Acción: ALLOW, FLAG o DENY.
  3. Prioridad: entero; las prioridades más bajas se activan antes.
  4. Alcance: todo el tenant por defecto, o restringido a un conjunto elegido de agentes.

Una vista previa JSON en vivo a la derecha muestra qué se va a guardar.

Versionado

Cada guardado crea una nueva versión. La pestaña Historial de cada política muestra todas las versiones con el operador, la marca de tiempo y un diff. Hacer rollback es un clic y crea una nueva versión apuntando a la definición anterior, la cadena de auditoría permanece intacta.

Deshabilitar vs eliminar

Las políticas pueden deshabilitarse sin eliminarse. Las políticas deshabilitadas dejan de activarse de inmediato, pero permanecen visibles para contexto (y para que los rastros de auditoría sean interpretables). Elimina solo cuando estés seguro de que la política nunca volverá a ser relevante.

El playground de pruebas

La pestaña Probar te permite pegar un cuerpo de petición de muestra y ver:

  • Qué políticas coinciden, en orden de prioridad.
  • La primera política coincidente y su acción.
  • Qué detectores DLP se activarían sobre el cuerpo.

Es la forma recomendada de validar una política antes de pasarla de deshabilitada a habilitada en producción.

Patrones comunes

Algunos patrones que vemos a menudo:

  • Reglas de denegación de alta prioridad para fugas de credenciales (un DENY con prioridad 10 que coincide con contenido de prompt como aws_secret_access_key).
  • Reglas de marca de prioridad media para intenciones sensibles (un FLAG con prioridad 50 que coincide con palabras clave como salario, lista de clientes, base de datos de producción).
  • Una regla por defecto de allow con prioridad 1000 para que el resultado de la política sea siempre explícito, nunca el implícito del tenant.

A dónde ir después

Última actualización: