Segmentación: justificar cada conexión

La llave de un hotel debe abrir tu habitación, no todas las habitaciones y el cuarto de mantenimiento. La red también necesita límites intencionados.

Segmentación: Restringir comunicaciones entre partes de un sistema según propósito y sensibilidad.

Dibuja los flujos antes que las reglas

Parte de un servicio: la capa web contacta con la aplicación y esta realiza operaciones concretas en la base. Anota origen, destino, protocolo, propósito y responsable. Incluye administración, supervisión, copias y resolución de nombres para que el diseño funcione.

Permitir que todos los equipos internos contacten con todos concede demasiada confianza a una etiqueta de red. Separa por función y sensibilidad y documenta las excepciones justificadas.

Llegar es solo una condición

Una política de red limita conexiones posibles. No sabe necesariamente si un cliente puede leer una factura concreta. La aplicación sigue necesitando identidad, autorización y tratamiento de entradas.

La confianza cero evita conceder confianza implícita solo por estar dentro de una red. Es un enfoque arquitectónico, no un producto ni la ausencia literal de confianza. Las decisiones consideran identidad, dispositivo, recurso y contexto.

Observa el límite real

Un límite útil reduce los sistemas afectados cuando uno falla o queda comprometido. Importa la aplicación efectiva, no los colores del diagrama. La administración compartida y las excepciones amplias pueden unir zonas supuestamente separadas.

Valida flujos permitidos y denegados mediante comprobaciones sintéticas aprobadas en tu entorno. Observa bloqueos inesperados y comunicaciones entre zonas. Revisa excepciones tras cambios y retira reglas de servicios desaparecidos.

Revisión resuelta: la ruta de copias olvidada

Un servicio ficticio de reservas tiene Web, Aplicación, Base de datos, Copias y Administración. Los nombres indican funciones, no confianza. Los registros describen conexiones lógicas de servicio; resolución de nombres y tráfico de retorno ya están contemplados. No se aporta una prueba de autorización sobre datos de clientes.

• S1, flujos necesarios: Web llama a Aplicación; Aplicación lee y escribe reservas en Base; Copias obtiene el conjunto de recuperación aprobado. El responsable exige los tres recorridos.
• S2, resultados: Funcionan Web-Aplicación y Aplicación-Base. Se deniega Web-Base como estaba previsto. También se deniega Copias-Base y falla el recorrido de copia requerido.
• S3, administración: Un administrador compartido puede cambiar políticas en todas las zonas. No se documentan revisión independiente ni funciones administrativas más limitadas.
• S4, propuesta de excepción: “Permitir mantenimiento interno” indica propósito, pero carece de responsable, extremos limitados y condición de vencimiento. No está aprobada.

PrediceEl diagrama muestra tres capas separadas. ¿Está preparado el diseño porque se deniega la conexión directa Web-Base?

No. Esa denegación aporta evidencia útil, pero S2 también bloquea una dependencia de recuperación. S3 describe autoridad sobre todas las zonas y S4 es una propuesta incompleta. El límite debe permitir trabajo justificado además de restringir alcance injustificado.

Corregir y verificar dos tipos de límite

Para S2, propone el flujo concreto Copias-Base exigido en S1 y registra identidad del servicio, propósito y responsable. Implementación debe elegir protocolo y mecanismo reales; el paquete no los especifica. El nombre “Copias” no basta para confiar en cualquier solicitante.

La verificación debe acreditar que funciona el recorrido de copias y se mantiene la denegación Web-Base. Comprueba permisos de aplicación por separado: conectar no concede acceso a toda reserva. Incluye comportamiento ante fallos y el registro de supervisión que permitiría detectar un cambio inesperado de política.

Para S3, revisa quién modifica reglas, aprueba excepciones y recupera administración. Compartir administración puede ser una decisión operativa explícita, pero no equivale a límites independientes. Para S4, solicita ámbito limitado, responsable y condición de final antes de aprobar.

Entregable modelo: matriz con columnas “requerido”, “observado” y “pendiente”, más una fila administrativa separada. Limita la analogía de la llave: el acceso de red abre una ruta de comunicación; la aplicación decide qué trabajo puede realizar el solicitante.

EXPLORA EL CONCEPTO

¿Qué límite falta?

Explora un servicio ficticio con tres capas.

La web solo llega a la aplicación

Reduce conectividad. La aplicación todavía debe verificar identidad y acción.

Todas las capas comparten administrador

Una ruta de gestión compartida puede cruzar los límites. Revisa los privilegios junto a las reglas.

Una excepción amplia nunca caduca

La excepción puede convertirse en la política real. Asigna responsable y revisión.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Llévalo a una decisión

Incluye conexiones y personas capaces de modificar las reglas. La administración también forma parte de la arquitectura.