El consejo más común en el debate de single tenant vs multi tenant es también el menos útil: single tenant es seguro, multi tenant es barato, y la decisión termina con una tarjeta de evaluación de adquisiciones. Ese enfoque falla en los edificios donde el diseño de red tiene el mayor impacto comercial.
En un hotel, residencia de estudiantes, edificio de departamentos para renta, campus hospitalario o espacio de trabajo flexible, la pregunta decisiva es quién controla el límite de la red. Una plataforma dedicada aún puede filtrar tráfico debido a una mala política. Una infraestructura física compartida puede proteger a cada inquilino cuando la identidad, la autenticación, el enrutamiento y la revocación se diseñan correctamente. El número de inquilinos es solo la etiqueta. El control de límites es la arquitectura.
La evidencia de vivienda en el Reino Unido hace que esta distinción sea difícil de ignorar. El análisis del gobierno identificó 459,262 desarrollos que son o podrían ser de tenencia mixta, los cuales contienen 3.33 millones de viviendas sociales, lo que equivale al 79% de las 4.21 millones de viviendas sociales identificadas en las estadísticas oficiales de vivienda. Sin embargo, la proporción promedio de inquilinos sociales fue del 80%, mientras que la mediana fue del 97%, lo que demuestra que los desarrollos pueden contener varios tipos de tenencia y al mismo tiempo seguir estando fuertemente concentrados en un solo tipo de ocupación. Los departamentos construidos para tal fin representaron el 54% de los desarrollos de viviendas múltiples identificados, con una mediana de proporción de inquilinos sociales del 91%, en comparación con el 50% de los departamentos convertidos. La forma de la propiedad cambia el problema del límite operativo, no solo el contrato de arrendamiento. (Análisis del gobierno del Reino Unido sobre la tenencia mixta en la vivienda social inglesa)
Por qué la cuestión entre Single Tenant y Multi Tenant va más allá del SaaS
Los equipos empresariales a menudo heredan esta discusión de la adquisición de SaaS. Comparan instancias dedicadas con infraestructura de aplicaciones compartida y luego asumen que la misma conclusión se aplica a un edificio físico. No es así. En propiedades compartidas, la pregunta más importante es si el operador puede mantener a un residente, invitado, departamento o contratista dentro del límite correcto de acceso y políticas.
Un despliegue de inquilino único generalmente brinda a los ingenieros una separación física más limpia. Eso ayuda con el alcance de la auditoría, el control de cambios y la contención de fallas. No elimina el riesgo operativo. Un controlador mal parcheado, credenciales de administrador débiles, una regla de firewall mal configurada o un servicio de autenticación con un alcance incorrecto pueden comprometer un entorno dedicado de manera tan efectiva como uno compartido.
La red multiinquilino crea una responsabilidad diferente. El operador comparte puntos de acceso, switches, controladores, enlaces ascendentes y, a menudo, el plano de gestión, y luego utiliza controles lógicos para separar a los usuarios. Esos controles deben funcionar en las capas de conexión inalámbrica, autenticación, enrutamiento, DNS, monitoreo y soporte. Un inquilino no está aislado simplemente porque tiene un SSID o una página de inicio de sesión diferente.
El límite práctico no es el SSID. Es la cadena completa desde la identidad hasta la autorización, el reenvío de tráfico, la telemetría y la revocación.
Tres límites a evaluar
Aborde la arquitectura como tres preguntas independientes:
- Límite físico: ¿Qué radios, switches, controladores, circuitos y dispositivos se comparten?
- Límite de identidad: ¿Cómo sabe la red qué persona, dispositivo, habitación, departamento o empresa se está conectando?
- Límite de gestión: ¿Quién puede crear credenciales, cambiar políticas, inspeccionar telemetría, aprobar el acceso y revocarlo?
Este enfoque es importante en las redes residenciales y de hospitalidad porque a los usuarios no les importa si el proveedor llama al diseño nativo de la nube, compartido o dedicado. Esperan que sus dispositivos se conecten fácilmente y que los de sus vecinos permanezcan separados. El personal espera que el acceso desaparezca cuando se deshabilite su cuenta de directorio. Los operadores esperan un único flujo de trabajo de soporte en lugar de una infraestructura independiente para cada habitación u ocupante.
La política de seguridad contra incendios del Reino Unido ofrece un paralelo útil. La ley Fire Safety Act 2021 aclaró que la Orden de Seguridad contra Incendios se aplica a la estructura, paredes externas, balcones y puertas de entrada de los departamentos en edificios residenciales multiocupados con dos o más conjuntos de instalaciones domésticas. Las regulaciones relacionadas entraron en vigor el 23 de enero de 2023, mientras que los controles históricos de HMO se desarrollaron después de incendios graves y formalizaron una categoría de riesgo distinta para los edificios multiocupados. (Investigación sobre tenencia mixta del gobierno del Reino Unido y contexto de seguridad contra incendios)
La lección para los arquitectos de red es directa. La ocupación compartida merece controles explícitos, pero la respuesta no es automáticamente el hardware dedicado. Es un límite demostrable que coincide con el riesgo, el modelo comercial y la capacidad operativa del edificio.
Explicación de las arquitecturas de inquilino único y multi-inquilino
En redes, single tenant significa que una organización o inquilino recibe una pila de infraestructura dedicada o una instancia operativa dedicada. Eso puede incluir puntos de acceso independientes, controladores, VLANs, dominios de autenticación, monitoreo y permisos de administración. El diseño limita las dependencias compartidas, lo que facilita la comprensión del entorno cuando la organización es propietaria de cada punto final y decisión de política.
Un fideicomiso hospitalario, un sitio de defensa o un campus corporativo pueden elegir este modelo para el tráfico principal porque sus procesos internos de identidad, cumplimiento y respuesta a incidentes necesitan un entorno estrechamente controlado. La infraestructura dedicada también puede admitir una planificación de radio a la medida, requisitos de dispositivos inusuales y ventanas de cambio que serían difíciles de coordinar entre inquilinos no relacionados.
Las redes de tipo multi tenant utilizan una infraestructura física común al tiempo que aplican controles lógicos por organización, hogar, habitación, departamento o servicio. Las VLAN, las VRF, los atributos RADIUS, las claves precompartidas privadas basadas en la identidad (iPSK), las políticas de firewall y los motores de políticas pueden crear contextos de acceso independientes sin duplicar cada dispositivo físico.
La red física se comparte. El contexto de seguridad y la experiencia del usuario no deberían compartirse. Una cadena hotelera podría operar una plataforma administrada de forma centralizada en todas sus propiedades, mientras que un proveedor de alojamiento estudiantil podría mapear a cada residente o unidad a un contexto de política y credenciales independiente.
Comparativa rápida de redes de inquilino único frente a multi-inquilino
| Dimensión | Single Tenant | Multi Tenant |
|---|---|---|
| Aislamiento físico | Infraestructura dedicada o instancia operativa | Switches, puntos de acceso, controladores o circuitos compartidos |
| Aislamiento lógico | Normalmente más simple porque menos tenants comparten el entorno | Esencial, aplicado a través de identidad, VLANs, VRFs, reglas de firewall y políticas |
| Plano de gestión | Dedicado o estrictamente limitado a una sola organización | Centralizado, con administración consciente de los tenants y permisos delegados |
| Escalamiento de costos | Repite la infraestructura y el trabajo operativo por tenant | Comparte la infraestructura y concentra la gestión |
| Contexto típico | Empresas reguladas, defensa, sector salud principal, propiedades corporativas dedicadas | Hospitalidad, viviendas estudiantiles, propiedades para alquiler (BTR), servicios gestionados, espacios de trabajo compartidos |
| Principal modo de falla | Los entornos duplicados se desvían de su configuración original o reciben poco mantenimiento | Un error de política o de identidad puede afectar a múltiples tenants |
Los equipos que comparan patrones de implementación pueden usar esta guía de arquitectura de WiFi multi-tenant como una referencia práctica, pero el diseño aún debe probarse frente al edificio real y el modelo operativo.
La elección no es entre seguro e inseguro. Es entre la separación física con mayor duplicación y la separación lógica con mayores exigencias de diseño y gobernanza.
Comparación detallada de los criterios más importantes
La decisión de la arquitectura pertenece al edificio y al modelo operativo, no a la etiqueta de SaaS. Una red de atención médica, una residencia estudiantil, una propiedad de BTR y un hotel pueden ofrecer WiFi como un servicio básico, pero sus límites de falla aceptables, responsabilidades de soporte y patrones de tráfico difieren.
Elija single tenant cuando una falla deba permanecer dentro de los bienes físicos de una sola organización. Los ingenieros pueden cambiar un controlador, firewall o servicio de autenticación sin coordinar una ventana de mantenimiento compartida. Ese beneficio dura solo cuando cada entorno dedicado recibe la aplicación adecuada de parches, monitoreo, documentación y pruebas de recuperación. La infraestructura dedicada brinda control, no resiliencia automática.
Elija multitenant cuando un solo operador deba ofrecer un servicio repetible a través de muchos ocupantes o propiedades. Una estructura compartida admite una política estándar, monitoreo centralizado y una incorporación consistente. Con esto, el operador asume una mayor carga de gobernanza: las credenciales, el tráfico, la telemetría y el acceso administrativo deben mantener un alcance correctamente definido para cada tenant.
Cinco criterios que definen el diseño
| Criterio | Single Tenant | Multi Tenant | Punto de anclaje |
|---|---|---|---|
| Aislamiento | La separación física limita el radio de impacto compartido | La separación lógica debe mantenerse en cada capa de control | La fuerza del aislamiento aumenta con el grado de separación, desde el esquema compartido hasta una base de datos por tenant |
| Seguridad | Menos dependencias compartidas crean un límite de auditoría más claro | Los controles centrales mejoran la consistencia, pero un error de política puede afectar a múltiples tenants | La seguridad depende de la garantía de identidad, la configuración, el parcheo y el monitoreo, no de la etiqueta de la arquitectura |
| Costo | El hardware, las licencias, las rutas de soporte y el mantenimiento se repiten para cada tenant | La infraestructura compartida mejora la utilización y reduce el trabajo repetitivo | El costo por tenant aumenta a medida que se incrementa el aislamiento. La comparación detallada de costos aparece en la siguiente sección (comparación de arquitectura SaaS del Reino Unido) |
| Rendimiento | La capacidad dedicada evita la fricción entre tenants | La capacidad compartida requiere control de admisión, QoS y monitoreo activo | El operador necesita controles explícitos para los vecinos ruidosos y los dispositivos de alta demanda |
| Operaciones | Cada entorno puede ser más simple, pero el ecosistema se vuelve repetitivo | Una sola plataforma puede funcionar de manera eficiente, siempre que la automatización de la identidad y de las políticas esté madura | El esquema de single tenant concentra el trabajo operativo por entorno. El de multi tenant lo concentra en la gobernanza y el plano de control |
El aislamiento es una propiedad de diseño
Pruebe el aislamiento a través de los flujos de tráfico, no de los diagramas. ¿Puede un residente descubrir el dispositivo de otro residente? ¿Puede un huésped acceder a los servicios del personal? ¿Puede un administrador de soporte ver los datos de la sesión de otro tenant? ¿Pierde el acceso de inmediato una identidad dada de baja, incluso desde dispositivos que fueron autorizados previamente?
Las mismas pruebas se aplican a ambos modelos. Un controlador dedicado no las responde de forma automática, y un controlador compartido no las hace imposibles. El problema decisivo es dónde se aplica la seguridad, cómo se delimita a los administradores y cuánta infraestructura común se encuentra debajo de cada inquilino.
En viviendas estudiantiles y BTR, los residentes esperan un acceso privado aunque el edificio comparta la conmutación, la red inalámbrica y la conectividad ascendente. Los hoteles se enfrentan al mismo límite entre los servicios para huéspedes, el personal y los servicios operativos. El sector salud añade equipos clínicos gestionados y sistemas heredados, por lo que el modelo de políticas debe proteger esas dependencias sin hacer que el soporte de rutina sea inviable.
El rendimiento sigue el patrón de la demanda
Los hoteles experimentan una demanda concentrada en las horas de check-in, eventos y uso nocturno. El alojamiento para estudiantes combina una alta densidad de dispositivos con una rotación frecuente. El sector salud mezcla equipos administrados, dispositivos personales y sistemas especializados. Single tenant puede reservar capacidad, mientras que multi tenant puede satisfacer la misma demanda cuando el operador mide el tiempo de transmisión de datos, aplica QoS y separa el tráfico crítico del uso recreativo.
El WiFi es ahora un servicio básico en estas propiedades. Una interrupción del servicio afecta la experiencia de los residentes, las operaciones de los invitados y los resultados comerciales, no meramente un panel técnico.
La prueba práctica es simple: ¿puede el operador observar la saturación antes de que los usuarios la reporten, identificar al tenant o servicio responsable y cambiar la política sin reconstruir la red? Si no es así, el modelo de aislamiento seleccionado está incompleto.
Costo, escala y la complejidad oculta del aislamiento
La infraestructura dedicada parece sencilla en un plan de proyecto. Cada tenant recibe sus propios controladores, switches, puntos de acceso, licencias, integraciones de monitoreo, almacenes de identidad, programa de firmware y proceso de soporte. La factura final incluye el tiempo de ingeniería necesario para implementar, documentar, probar, parchar y recuperar cada copia.
El diseño de un solo inquilino también duplica el trabajo operativo. Los ingenieros mantienen plantillas independientes, revisan alertas similares en diferentes consolas, repiten la validación de firmware y preservan procedimientos de recuperación independientes. Esa separación justifica su costo cuando un inquilino necesita un límite de cumplimiento normativo distinto o controles técnicos inusuales. Se convierte en una erosión del margen cuando cada inquilino recibe el mismo servicio y ninguna política requiere una separación física.
La comparación de costos anterior aún se aplica, pero los operadores de red deben tener en cuenta los gastos que las tablas de SaaS no muestran. Una licencia de controlador independiente puede tener su propio alcance de contrato. Cada plataforma adicional puede requerir un acuerdo de soporte, una ventana de mantenimiento y una validación de firmware antes de la implementación. Los ingenieros también dedican tiempo a probar la autenticación, el monitoreo, la conmutación por error y el traspaso de inquilinos en múltiples entornos. En un portafolio concurrido de vivienda estudiantil, BTR o de hospitalidad en el Reino Unido, esas horas afectan el margen de servicio tan directamente como el hardware.
Desglose de costos por inquilino
| Partida de costo | Tenant único, por tenant | Multitenant, por tenant | Notas |
|---|---|---|---|
| Infraestructura física | Stack dedicado o reservado | Asignación de estructura compartida | El tenant único repite el equipo y el trabajo del sitio |
| Licencias de controlador y plataforma | Instancia separada o alcance de licencia | Plataforma compartida, licencias conscientes del tenant | Los términos del contrato pueden cambiar el resultado |
| Identidad y autenticación | Dominio separado o integración dedicada | Servicio compartido con políticas de alcance definido | El modelo multitenant requiere un sólido mapeo de tenants |
| Monitoreo | Tableros y rutas de alerta separados | Tablero central con filtros de tenant | Un filtrado deficiente puede crear un riesgo de control de acceso |
| Soporte y gestión de cambios | Ventanas y manuales de procedimientos específicos del tenant | Flujos de trabajo estandarizados con excepciones | La estandarización mejora la escala solo cuando la política está madura |
| Recuperación y pruebas | Planes de recuperación separados | Recuperación de plataforma compartida más validación del tenant | El operador debe demostrar la restauración a nivel de tenant |
Una plataforma compartida reduce la duplicación únicamente cuando el operador puede aplicar los límites de los tenants de manera consistente. Requiere plantillas de políticas, implementación por etapas, validación de configuración, registros con alcance de tenant y reversión probada. Sin esos controles, una sola consola compartida puede convertir un problema de aislamiento en un problema de control de acceso.
El diseño de la red debe probarse antes de los cambios en producción. Los equipos pueden usar un diseñador de subredes iPSK para modelar la segmentación basada en la identidad, verificar la asignación de subredes y exponer conflictos de direcciones o políticas de manera temprana.
Pague por el aislamiento físico cuando el negocio requiera un límite físico. No pague por él simplemente porque el equipo de diseño no ha construido uno lógico confiable.
La respuesta correcta suele ser híbrida. Mantenga el tráfico clínico, de pagos, de administración de edificios o corporativo en una ruta dedicada y estrictamente controlada. Utilice una red compartida y con reconocimiento de inquilinos para invitados, residentes, contratistas y otras poblaciones variables. Esa asignación ubica el aislamiento donde una falla conlleva consecuencias comerciales, regulatorias o de seguridad, mientras que la infraestructura compartida maneja la demanda que se beneficia de la escala.
Escenarios del mundo real para TI empresarial y operadores de red
La decisión de arquitectura se vuelve más clara cuando se nombran el propietario, el usuario y el impacto de las fallas. Una red para una organización no es automáticamente un problema de un solo tenant, y una red que atiende a muchas personas no es automáticamente un problema multi-tenant.
Escenario uno, un campus empresarial de 5,000 asientos
Un campus empresarial grande con requisitos estrictos de residencia de datos debería optar de forma predeterminada por un single tenant para los servicios principales. El factor decisivo no es el número de personas. Es la necesidad de alinear los límites físicos, administrativos y de auditoría.
Los controladores dedicados, los servicios de autenticación, el acceso de administración y las rutas de tráfico facilitan la demostración de la propiedad del sistema. Los equipos de seguridad pueden restringir el acceso de administrador al personal de la organización, definir un solo proceso de cambio e investigar incidentes sin filtrar la actividad de inquilinos no relacionados.
El acceso de invitados aún puede utilizar un servicio lógico independiente. La red principal de empleados no debe depender de la misma ruta de políticas que los visitantes temporales, contratistas o asistentes a eventos.
Escenario dos, un grupo hotelero con múltiples sitios
Un grupo hotelero que opera propiedades bajo una sola marca generalmente debería elegir multi tenant. Un centro de operaciones de red central necesita consistencia en la incorporación, políticas de Captive Portal, informes y respuesta a incidentes en hoteles, restaurantes y sedes. Duplicar todo el entorno de gestión en cada propiedad haría que la estandarización fuera más difícil, no más segura.
La frontera aún debe existir a nivel de propiedad, de invitados, de personal y de servicio. Los dispositivos de los invitados no deben alcanzar los sistemas de punto de venta. Las identidades del personal no deben heredar los permisos de los invitados. El equipo de una propiedad debe ver la información requerida para su trabajo sin recibir acceso sin restricciones a cada sitio.
El equilibrio es claro. El control centralizado gana, siempre que el operador pueda aplicar una administración y una política de tráfico que reconozcan a cada tenant.
Escenario tres, viviendas para estudiantes y de alquiler en el Reino Unido
En el sector de build-to-rent y el alojamiento para estudiantes diseñado a la medida, un modelo híbrido multi-tenant suele ser el ganador. Los residentes esperan privacidad a nivel de departamento o habitación, pero el operador se beneficia de una sola red física en toda la propiedad, un solo modelo de soporte y una gestión de servicios centralizada.
La evidencia de la vivienda estudiantil en el Reino Unido muestra que el 93% de los arrendadores encuestados en Escocia utiliza un solo contrato de arrendamiento, mientras que el 7% utiliza contratos de arrendamiento múltiples. Esto sugiere que la simplicidad administrativa sigue influyendo en los modelos operativos. (Evidencia de vivienda estudiantil en el Reino Unido)
La conectividad en estos edificios es cada vez más un servicio básico proporcionado por el operador en lugar de un contrato que firma cada residente. En la Encuesta Nacional de Alojamiento Estudiantil 2026 de Save the Student, el 80% de los estudiantes afirmó que su renta cubría al menos un servicio adicional, y el 48% dijo que la banda ancha estaba incluida, solo por detrás del agua (63%), la electricidad (61%) y el gas (54%). Ofrecerlo de manera confiable es la parte más difícil: la encuesta de Jisc de 2024/25 a 15,398 estudiantes de educación superior del Reino Unido reveló que el 60% reportó problemas de conectividad WiFi dentro o fuera del campus. (Save the Student, Encuesta Nacional de Alojamiento Estudiantil 2026; Hallazgos de la encuesta de Jisc sobre la experiencia digital de los estudiantes de educación superior del Reino Unido 2024/25)
Por lo tanto, la red debe ofrecer una experiencia privada sin convertir a cada residente en un proyecto de infraestructura independiente. El acceso basado en la identidad, la política por unidad, la facturación sencilla y la revocación inmediata importan más que la etiqueta de la arquitectura.
Cómo ofrecer aislamiento de inquilinos sin duplicar la red
Las redes modernas impulsadas por la identidad ofrecen una tercera opción entre una pila física por inquilino y una red compartida sin control. El operador comparte la infraestructura común y luego vincula el acceso a la identidad de un individuo, unidad, habitación, departamento o dispositivo.
iPSK es un punto de partida práctico para entornos residenciales y de dispositivos mixtos. En lugar de emitir una contraseña compartida para todo un edificio, el operador asigna claves privadas distintas y las asocia a un contexto de política. Una clave puede identificar un departamento, habitación, residente, grupo de dispositivos o clase de servicio, según el requisito operativo.
Construya el plano de control en capas
- Asociar la identidad con el acceso. Utilice atributos RADIUS, grupos de directorio o un servicio de identidad gestionado para asociar a un usuario o dispositivo con la política de inquilino correcta.
- Aplicar controles basados en roles. El personal, los residentes, los invitados, los contratistas y los sistemas del edificio deben recibir diferentes permisos. Los equipos que evalúen esta capa pueden revisar el software de control de acceso basado en roles para obtener una explicación más amplia de las políticas por rol.
- Separar el tráfico. Utilice VLANs, VRFs, reglas de firewall y políticas de servicio para detener el movimiento lateral entre inquilinos y proteger los sistemas operativos.
- Automatizar los eventos del ciclo de vida. Facilite el acceso cuando se apruebe a un residente o empleado, y revóquelo cuando cambie el registro del directorio o de la administración de la propiedad.
- Definir el alcance de la telemetría. El monitoreo central debe proporcionar a los operadores datos de estado útiles sin exponer la información de identidad o de sesión de un inquilino a otro.
El SSO a través de Microsoft Entra ID u Okta puede vincular el acceso corporativo a la gobernanza de identidad establecida. Esto funciona bien para el personal y los usuarios gestionados. El iPSK sigue siendo útil para residentes, visitantes, dispositivos heredados y equipos que no pueden completar un flujo de autenticación empresarial moderno.
La plataforma de redes basada en identidad de Purple es un ejemplo de un enfoque de plano de control que admite el acceso específico del inquilino a través de una infraestructura compartida, incluyendo iPSK e integraciones con proveedores de identidad corporativos. Su valor en esta arquitectura no es la existencia de otro SSID. Es la capacidad de conectar la identidad, las políticas, la incorporación y la revocación sin requerir una red física independiente para cada ocupante.
El diseño aún requiere pruebas. Valide que una credencial no pueda cruzar su política prevista, que la incorporación de dispositivos no eluda la segmentación, que los administradores tengan permisos con alcance de inquilino y que la revocación llegue a las sesiones activas. Una red física compartida puede ofrecer una experiencia de inquilino privado, pero solo cuando el operador trata la identidad y la política como infraestructura de producción.
Qué arquitectura elegir y cuándo hacerlo
Utilice single tenant cuando la organización necesite un límite físico dedicado, no simplemente un inicio de sesión independiente. El sector salud regulado, los entornos de pago, la defensa y las cargas de trabajo empresariales de alta sensibilidad deberían comenzar ahí para los servicios principales. La arquitectura simplifica la recopilación de pruebas y reduce las dependencias compartidas, aunque sigue exigiendo una gestión disciplinada de parches, monitoreo e identidad.
Utilice multiinquilino cuando el operador atienda a muchos clientes, ocupantes, habitaciones, departamentos o propiedades y el servicio dependa de una entrega repetible. El sector hotelero, las residencias de estudiantes, el sector BTR (construcción para alquiler), los servicios gestionados y los espacios de trabajo compartidos suelen beneficiarse más de las operaciones centralizadas que de la duplicación de hardware. La condición es una política estricta que reconozca al inquilino, no un estándar de seguridad relajado.
Use el modelo híbrido cuando un sitio contenga servicios internos de alta sensibilidad y grandes volúmenes de usuarios transitorios o residenciales.
Matriz de recomendación de arquitectura
| Escenario | Modelo recomendado | Por qué |
|---|---|---|
| Núcleo de empresa regulada, sistemas clínicos de salud o tráfico de pagos | Tenant único | El límite físico y de auditoría debe coincidir con el límite de control de la organización |
| Proveedor de SaaS o proveedor de servicios gestionados que atiende a muchos clientes | Multitenant | La infraestructura compartida admite políticas repetibles, operaciones centrales y una expansión eficiente |
| Grupo hotelero con servicios centrales para huéspedes | Multitenant | Un modelo operativo admite identidad, soporte y prestación de servicios consistentes en todas las propiedades |
| BTR, viviendas para estudiantes o espacios de trabajo flexibles | Multitenant híbrido | La infraestructura compartida funciona con identidad, políticas, facturación y revocación por ocupante |
| Sitio corporativo con redes para empleados y huéspedes | Híbrido | Mantenga el tráfico corporativo sensible bajo estricto control mientras aplica un acceso de invitados consciente de los tenants |
| Entorno con incidentes repetidos de vecinos ruidosos o hallazgos de auditoría | Reevaluar y luego aislar los servicios afectados | El límite actual está fallando, independientemente de la etiqueta de la arquitectura |
Las decisiones de migración deben seguir la misma lógica. Realice un inventario de las clases de tráfico, identidades, tipos de dispositivos, roles de gestión y dominios de falla antes de seleccionar una plataforma. Las señales de alerta incluyen visibilidad inexplicable entre inquilinos, políticas inconsistentes entre sitios, revocación lenta de accesos, equipos de soporte con un alcance administrativo excesivo y rotación de inquilinos causada por la falta de controles o retrasos en las funciones.
Hágase una pregunta antes de firmar el diseño: ¿quién es el propietario del límite de la red y necesita hardware dedicado o una política dedicada?
El resumen del documento de orientación es simple:
- Elija single tenant cuando el aislamiento físico sea un requisito comercial o de cumplimiento normativo.
- Elija multi tenant cuando la escala dependa de una infraestructura compartida y controles de identidad maduros.
- Elija un modelo híbrido cuando coexistan el tráfico central sensible y el acceso compartido de gran volumen.
Purple proporciona redes basadas en la identidad para edificios compartidos, lo que incluye controles de acceso a nivel de inquilino y separación basada en iPSK en infraestructura común. Visite Purple para evaluar si su enfoque se adapta al diseño de su red de alojamiento para estudiantes, propiedades de departamentos para renta, hotelería, sector salud o red de invitados empresariales, y luego pruebe el límite con sus propias políticas de identidad, revocación y tráfico.
