Una plataforma construida para uso personal tiene un único límite de confianza implícito: todo lo que hay en ella es mío, así que todo puede razonablemente confiar en todo lo demás. Esa suposición se rompe en el momento en que la plataforma aloja una carga de trabajo de alguien que no soy yo: un inquilino externo, un cliente hipotético, cualquiera cuyo acceso necesite estar acotado por algo más deliberado que un «total, todo esto es mío». La pregunta de diseño interesante no es si aislar la carga de trabajo de un cliente (esa parte es obvia), sino cuánto aislamiento aplicar, porque una infraestructura totalmente dedicada para cada inquilino es un derroche y la ausencia total de aislamiento es un riesgo, y la respuesta honesta está en algún punto intermedio, según lo que ese inquilino realmente necesite.
Aislamiento por niveles, no como un interruptor
El modelo útil son niveles, no una elección binaria entre «compartido» o «dedicado», porque distintos recursos justifican distintos grados de dedicación. Un inquilino podría compartir un host físico con cargas de trabajo internas y aun así tener un espacio de nombres de red dedicado, o compartir la infraestructura subyacente de la pila de monitorización mientras sus datos se etiquetan de forma lo bastante distintiva como para que nunca acaben mezclados en un panel interno. El aislamiento no es una única palanca: son varias palancas independientes (compute, red, datos, credenciales, observability), y cada una se ajusta según lo que realmente exige el perfil de riesgo de ese inquilino en concreto, no según una política global única que lo aísla todo o no aísla nada.
Dicho esto, algunas de esas palancas no son negociables sin importar el nivel. El acceso de un cliente nunca debe compartir túnel VPN con el acceso del equipo interno (el mismo principio de túneles separados por nivel de privilegio que esta plataforma ya aplica en otros sitios), y punto: no es una decisión de nivel. Eso es absoluto por la misma razón por la que, en cualquier plataforma bien gestionada, un plano de gestión no comparte ruta de red con el tráfico de producción: en el momento en que el acceso de cliente y el acceso interno circulan por el mismo túnel, un compromiso en el lado del cliente tiene una ruta directa al lado interno, y ningún control de acceso a nivel de aplicación cierra del todo ese camino una vez que la capa de red ya está compartida. El coste de un segundo túnel es pequeño (otra interfaz WireGuard, otro conjunto de rutas) y el coste de no tenerlo es una red interna que solo es tan segura como el tercero externo menos fiable que la utiliza.
El etiquetado de observability como problema de aislamiento en sí mismo
Es tentador pensar en el aislamiento únicamente en términos de acceso (si este inquilino puede llegar a tal sistema) y olvidar que los datos de observability son, en sí mismos, una superficie de fuga. Las métricas y los logs de la carga de trabajo de un cliente, si acaban en los mismos paneles y el mismo espacio de consultas que la telemetría interna, generan dos problemas a la vez. Los datos operativos del cliente quedan visibles para cualquiera con acceso a la pila de observability interna, lo cual es una expansión de alcance que el cliente nunca aceptó. Y la telemetría interna se vuelve más difícil de interpretar porque ahora está entremezclada con el ruido de un inquilino: un ingeniero interno de guardia depurando un panel no debería tener que averiguar primero qué series temporales pertenecen a la plataforma y cuáles a la aplicación de un cliente.
La solución es disciplina de etiquetado aplicada en el momento de la ingesta, no una limpieza posterior: las métricas y los logs de un cliente se etiquetan de forma lo bastante distintiva (por inquilino, por workload, por la dimensión que importe en esa plataforma) como para poder excluirlos de las vistas de uso interno por construcción, no porque alguien se acuerde de filtrarlos cada vez. Es el mismo tipo de problema que el del túnel VPN: es barato hacerlo bien en el punto donde el dato se genera por primera vez, y caro (a veces imposible) corregirlo después, una vez que la señal del cliente y la interna llevan meses mezcladas en una misma ventana de retención.
El offboarding como reflejo del onboarding
El onboarding de un cliente recibe atención de diseño porque es la parte que tiene que funcionar para que la relación siquiera empiece: alguien escribe la política de acceso, aprovisiona la ruta de red, configura las vistas de observability etiquetadas y probablemente lo revisa todo antes de que la primera carga de trabajo del cliente entre en producción. El offboarding suele recibir mucha menos atención, y esa asimetría está al revés, porque el offboarding es la parte donde un error tiene una vida media más larga. Un error de onboarding suele ser visible de inmediato: el cliente no puede llegar a algo que necesita, y alguien abre un ticket. Un error de offboarding es invisible por defecto: un peer de VPN que nunca se eliminó, unas credenciales que siguen funcionando, una etiqueta de observability que sigue ingiriendo datos de un workload del que ya nadie se ocupa. Nada de eso produce un error visible. Simplemente queda ahí como acceso persistente en el que nadie está pensando, que es exactamente la forma que suele tener el hallazgo de una auditoría de seguridad mucho más tardía.
Tratar el offboarding como el reflejo deliberado del onboarding significa anotar, en el momento del onboarding, todo lo que se concedió (la ruta de red, las credenciales, el acceso a los paneles, las entradas DNS, lo que sea) precisamente para que después haya una checklist que revertir, en lugar de un ejercicio de memoria hecho lo mejor posible. Si el onboarding aprovisionó cinco cosas distintas, el offboarding debería eliminar de forma verificable esas mismas cinco cosas, no «revocar la cuenta y esperar que eso fuera todo». Esa simetría es lo que realmente importa: un modelo de aislamiento que solo se aplica a la entrada no es realmente un modelo de aislamiento, es una puerta de un solo uso que deja de importar en cuanto termina la relación y nadie vuelve a cerrar lo que se abrió.
El trade-off que esto realmente gestiona
Nada de esto es gratis, y merece la pena nombrar el coste con claridad en lugar de fingir que los niveles de aislamiento son una ganancia pura. Cada palanca de aislamiento adicional (un túnel dedicado, un etiquetado distintivo, una checklist de offboarding por escrito) es sobrecarga operativa que un entorno totalmente compartido y de confianza plena no necesitaría. Para una plataforma mayoritariamente personal, es fácil posponer esa sobrecarga indefinidamente, porque no hay ningún tercero externo cuyo radio de impacto haya que acotar. En el momento en que eso deja de ser cierto, cuando hay en la plataforma una carga de trabajo que pertenece a otra persona, la sobrecarga deja de ser opcional. Lo que cambia no es la arquitectura de la plataforma en un sentido general; son el puñado de límites que antes eran implícitos (porque todo era mío) y que ahora tienen que ser explícitos, quedar por escrito y, esto es lo crítico, ser reversibles, porque la relación que los justificaba no tiene por qué durar para siempre, y la plataforma necesita poder cerrar ese límite con la misma limpieza con la que lo abrió.
Elegir un nivel sin caer en la sobreingeniería
El riesgo en el otro extremo es tratar a todos los inquilinos como si necesitaran por defecto el nivel máximo de aislamiento, lo que suena prudente pero en realidad es solo evitar tomar la decisión de verdad. Un cliente que ejecuta un sitio estático de bajo riesgo no necesita el mismo trato de «todo dedicado» que un cliente cuya carga de trabajo toca datos sensibles o necesita un margen de recursos garantizado: aprovisionar el nivel más pesado para ambos no es seguridad extra, es coste indiferenciado que hace la plataforma más difícil de operar sin hacer a nadie sustancialmente más seguro. La decisión de nivel tiene que seguir de verdad el perfil de riesgo del inquilino: qué datos toca su carga de trabajo, cuál es el radio de impacto si su carga de trabajo se ve comprometida, si algo en su patrón de tráfico convierte los efectos de vecino ruidoso sobre el compute compartido en una preocupación real. Responder eso con honestidad, inquilino por inquilino, es lo que evita que los «niveles de aislamiento» colapsen en cualquiera de los dos extremos: ni «todo compartido, ya resolveremos los problemas cuando aparezcan» ni «todo aislado al máximo, sin importar si la situación de este inquilino realmente lo exige».
El único punto en el que me resisto a ajustar el nivel según el inquilino es el límite de red: esa es la palanca que se mantiene fija sin importar en qué nivel acabe un cliente dado en todo lo demás. El compute puede compartirse razonablemente para un inquilino de bajo riesgo. Las credenciales pueden seguir razonablemente un proceso de aprovisionamiento más ligero para un inquilino de bajo riesgo. Un túnel compartido entre el acceso de ese inquilino y el acceso del equipo interno es el único atajo que convierte un problema contenido en uno sin contener, porque es la capa en la que un compromiso del lado del cliente deja de ser un problema del cliente y pasa a ser un problema de todos. Tratar ese límite como independiente del nivel (siempre dedicado, sin excepciones) es una superficie de diseño mucho más pequeña de razonar que evaluar caso por caso cada decisión de red junto con cada decisión de compute y de credenciales, y elimina toda una categoría de dudas posteriores del tipo «¿acertamos con esto para este cliente en concreto?».
Qué debería dejar el onboarding tras de sí
El resultado práctico de dar de alta a un inquilino, más allá del propio acceso funcionando, debería ser un registro breve y concreto de exactamente qué se le aprovisionó: no un documento de política general, sino la lista literal: este peer de VPN, estas credenciales, esta etiqueta de observability, estas entradas DNS, esta asignación de compute. Son las mismas cinco categorías por las que pasa cualquier nuevo servicio, solo que con el nombre de un inquilino externo pegado a cada una en lugar de una suposición interna de confianza. Esa lista es lo que convierte el offboarding en una checklist en vez de en una investigación. Sin ella, el offboarding se convierte en alguien intentando reconstruir, meses o años después, todo lo que se le llegó a conceder a un inquilino que ya no está, que es exactamente el tipo de tarea que acaba haciéndose de forma incompleta bajo presión de tiempo, porque no hay ninguna referencia fiable con la que contrastar el trabajo. La lista no necesita ser elaborada. Necesita existir, y necesita actualizarse cada vez que se concede algo nuevo a ese inquilino después del onboarding inicial, para que siga siendo un reflejo fiel de lo que realmente está activo, en lugar de una fotografía desactualizada de lo que era cierto el primer día.