Así decide Albgott quién tiene acceso.

Todo lo demás en esta página es una variación de una sola regla: el tráfico entre redes gestionadas se deniega por defecto, y cada excepción es una regla explícita y nombrada — un origen, un destino, un puerto. Nada es alcanzable porque dos cosas compartan red; es alcanzable porque existe una regla para exactamente ese flujo en el router.

Eso se aplica al propio router, no solo a lo que pasa a través de él. El acceso directo se limita a conexiones ya establecidas, los dos túneles VPN, el acceso admin desde una allow-list explícita, e ICMP — todo lo demás se descarta antes incluso de considerarse.

El acceso remoto corre sobre dos túneles WireGuard separados en lugar de una sola VPN con niveles de permisos: wg-corp para uso normal, wg-admin para administración de la infraestructura. Ninguno se une a una VLAN directamente — un dispositivo que se conecta recibe una dirección en un overlay enrutado, y el router filtra sobre esa dirección exactamente igual que haría con cualquier otra red.

La separación tiene que ver tanto con quién está al otro lado como con a qué puede llegar. Colaboro con gente que no soy yo, y wg-corp es por donde se conectan — llega a las herramientas internas y nada más allá de eso. wg-admin es el único camino al control plane de la infraestructura, y ningún colaborador lo tiene nunca. Un dispositivo comprometido en wg-corp no puede llegar a una consola de hipervisor; ese es todo el sentido de la separación.

Existen dos proveedores de identidad y los dos funcionan hoy, por motivos distintos. Authentik es el objetivo a largo plazo — todo en esta plataforma está pensado para acabar autenticándose a través de él. Zitadel existe por un motivo más concreto y de cara al futuro: está listo para cuando una app expuesta al público necesite su propia capa de identidad, con soporte multi-tenant real (usuarios, proyectos y configuración aislados por organización) integrado desde el principio.

Infisical corre como un servicio real y accesible de gestión de secrets, solo interno — el objetivo es simple: dejar de guardar credenciales en texto plano dentro de archivos de config y compose repartidos por los hosts, y darles en su lugar un único hogar gestionado.

La migración es deliberada y está en curso, no terminada: decidir qué secrets se mueven, y luego actualizar lo que los consume para tratar Infisical como la fuente de verdad solo una vez que realmente lo es. Esto importa más justo donde más arriesgado es equivocarse — CI. Los build agents viven en su propio segmento de red aislado con reglas de salida estrictas y explícitas, y nada permite que un build comprometido llegue a nada del management plane.

Seguridad y observability no son stacks separados aquí — el mismo monitoring que se cubre en /operations es también lo que primero notaría la mayoría de problemas relacionados con acceso. Las comprobaciones activas corren tanto desde fuera de la red como desde dentro, así que una mala configuración aparece independientemente de lo que reporte el pipeline de métricas. Las alertas van a un único teléfono, con las críticas disparándose más rápido y los avisos duplicados para el mismo host suprimidos — un problema real se oye una vez, alto y claro, no disperso por varios sistemas.

La carencia honesta: nada de esto es monitoring de seguridad construido a propósito. Hoy no hay alertas dedicadas para logins fallidos repetidos, actividad inusual de un peer VPN, o drift en las reglas del firewall — la observability general probablemente detectaría mucho de eso de forma incidental, pero «probablemente lo notaría» y «lo está vigilando explícitamente» son afirmaciones distintas, y esta página pretende seguir siendo honesta sobre cuál de las dos es realmente cierta.

Consolidando en un solo sitio la honestidad de cada sección anterior, porque enterrar las carencias entre cinco subsecciones anularía el sentido de tener esta página.