Qué es un sistema y dónde termina

La palabra que parece explicarlo todo

«Sistema» puede significar un teléfono, una aplicación, una empresa o la red eléctrica de un país. Esa elasticidad es útil para hablar, pero peligrosa para razonar. Si una explicación cambia de significado a mitad del argumento —primero el sistema es una aplicación y después incluye al proveedor, las cuentas y los operadores—, también cambian las propiedades que podrían evaluarse. Una frase como «el sistema conserva el mensaje» no puede juzgarse hasta saber qué entidades incluye, durante cuánto tiempo y bajo qué condiciones.

En ingeniería, un sistema no se reconoce por su tamaño ni porque tenga una carcasa. Se reconoce como un conjunto de elementos organizados que, mediante sus relaciones, produce un comportamiento o significado que interesa a alguien. NIST SP 800-160 trata el sistema junto con sus elementos, su entorno y las relaciones entre ambos (NIST SP 800-160 Vol. 1 Rev. 1, §2.1). Para esta ruta inicial usaremos una regla operativa: un sistema es el conjunto de entidades y relaciones que decidimos considerar para responder una pregunta declarada. Es una síntesis pedagógica, no una definición universal que sustituya al estándar.

La frontera es la línea del modelo que separa lo que analizamos como parte del sistema de aquello que tratamos como entorno. No es una pared física, una garantía ni un perímetro defensivo. Puede atravesar una máquina, una organización o un proveedor. Elegirla permite trabajar; también crea omisiones que deben permanecer visibles.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Empezar por la pregunta y el propósito

El caso conductor sigue siendo el mensaje que Ana envía a Bruno. Supongamos que la aplicación muestra «enviado», pero Bruno no ve nada. Antes de dibujar componentes debemos elegir la pregunta. «¿Funciona la mensajería?» es demasiado amplia: podría referirse a la composición local, la conexión, el servicio, la entrega, la notificación o la lectura humana. Dos preguntas más útiles son:

1. ¿La aplicación de Ana consiguió entregar una petición al servicio remoto?
2. ¿El conjunto de componentes consiguió presentar el mensaje a Bruno?

La primera admite una frontera pequeña: aplicación cliente, proceso, sistema operativo y punto de interacción con la red. El servicio remoto queda en el entorno y se modela por lo observable en su interfaz. La segunda necesita una frontera mayor: cliente, transporte, servicio, almacenamiento, notificación y dispositivo receptor. Ninguna frontera es «la verdadera» en abstracto. Cada una es adecuada o inadecuada respecto de la pregunta.

El propósito describe el resultado que interesa dentro de esa pregunta. No es una intención mágica del artefacto. Una misma aplicación puede participar en propósitos distintos: redactar un mensaje, sincronizar conversaciones, autenticar una cuenta o mostrar notificaciones. El propósito orienta qué comportamientos importan y qué entidades debemos distinguir.

Conviene escribir al comienzo una frase de trabajo: «Para esta pregunta, modelaremos como sistema…». Después se enumeran las exclusiones: «No modelaremos todavía…». Este pequeño contrato evita que una conclusión local crezca silenciosamente. Si la frontera termina en la interfaz del servicio, una respuesta aceptada puede sostener un claim sobre esa interacción; no sostiene por sí sola almacenamiento duradero, entrega al receptor ni lectura humana.

Componentes, elementos y relaciones

Un elemento del sistema es una parte discreta que podemos tratar como unidad para el análisis presente. «Componente» se usa con frecuencia para una parte implementada, pero aquí no asumiremos que todo elemento sea una pieza de software. Pueden ser elementos un dispositivo, un proceso, una base de datos, una persona que opera una consola, una regla organizativa o un servicio externo, siempre que el modelo explique su papel.

Enumerar cajas no basta. Un sistema aparece en las relaciones: una aplicación invoca una función del sistema operativo; un proceso envía una petición; un servicio valida una sesión; una base de datos conserva un registro; un operador cambia una configuración. Cada flecha necesita un verbo. «Aplicación — servidor» sólo indica cercanía gráfica. «La aplicación envía una petición HTTP al endpoint del servicio» declara dirección, acción y punto de interacción.

Las relaciones también pueden transportar autoridad, datos, tiempo o dependencia. No deben fusionarse. Que un servicio reciba datos de una cuenta no significa que esa cuenta administre el servicio. Que un proveedor opere infraestructura no significa que decida el propósito de negocio. Que dos componentes estén dentro de la misma frontera no demuestra que confíen entre sí.

Desliza horizontalmente para leer el diagrama a tamaño completo.

El estado es la información relevante que puede hacer que el sistema responda de forma distinta ante la misma entrada. Una cola local vacía o pendiente, una sesión vigente o terminada y una configuración activada o desactivada son estados distintos. En este capítulo sólo necesitamos reconocerlos; el capítulo 0.3 explicará representación y cambio. Incluir estado impide dibujar sistemas como tuberías atemporales: la respuesta puede depender de lo ocurrido antes.

Interfaz no significa interior

Una interfaz es el lugar o convención mediante la cual dos elementos interactúan. Puede ser una pantalla, una llamada entre programas, un protocolo, un archivo compartido o un procedimiento humano. La interfaz hace posible observar o solicitar algo sin conocer toda la implementación. Precisamente por eso limita lo que podemos afirmar.

Cuando la aplicación recibe una respuesta 202 Accepted, por ejemplo, la semántica del protocolo describe una respuesta a una petición; no convierte automáticamente la interfaz en prueba de todas las acciones posteriores. La implementación remota puede usar colas, bases de datos, réplicas y procesos que el cliente no observa. En la Parte 0 no estudiaremos HTTP en detalle: interesa la diferencia entre contrato observable e interior inferido.

Una interfaz tampoco tiene que ser estable, completa o honesta por naturaleza. Su comportamiento depende de versión, configuración, errores y entorno. Modelarla como interfaz significa declarar qué entradas, salidas y condiciones estamos usando, no otorgarle confianza automática.

En el caso de Ana, el botón «enviar» es una interfaz entre persona y aplicación. Una API es otra interfaz entre cliente y servicio. La notificación es una interfaz entre sistema y Bruno. Tres interfaces pueden representar estados diferentes. Si el diagrama las reúne en una caja llamada «mensajería», desaparecen precisamente las transiciones que necesitamos investigar.

Entorno, dependencias y condiciones

El entorno contiene entidades y condiciones que no incluimos como elementos internos, pero que pueden afectar al sistema o recibir sus consecuencias. Externo no significa irrelevante. La red, el reloj, la energía, el proveedor de identidad y la política de retención pueden quedar fuera de una frontera pequeña y aun así determinar su comportamiento.

Una dependencia es una relación en la que el sistema necesita una capacidad, condición o recurso que no produce por sí solo en el alcance elegido. Debe expresarse como una oración comprobable. «Depende de Internet» es impreciso. «La aplicación necesita resolución de nombre y conectividad hasta el endpoint durante el intento» permite preguntar qué parte estuvo disponible.

Las dependencias pueden ser técnicas, humanas, organizativas o temporales. Un operador debe renovar un certificado; un contrato debe permitir conservar una copia; un reloj debe mantenerse dentro de cierta precisión; un proveedor debe responder dentro de una ventana. NIST SP 800-160 señala que los sistemas interactúan con su entorno y que los elementos pueden depender de otras entidades. Nuestra clasificación es editorial, pero obliga a no convertir «externo» en «mágico».

Para cada dependencia conviene registrar:

• qué capacidad se espera;
• quién o qué la proporciona;
• qué interfaz la expone;
• qué condición o versión se presupone;
• cómo se observaría su ausencia o degradación;
• qué consecuencias quedan fuera del sistema pero dentro del problema.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Esta lista no es todavía un análisis de amenazas. Tampoco calcula riesgo. Su función es impedir que una explicación trate las dependencias como hechos permanentes. Los capítulos posteriores añadirán autoridad, fallos, amenaza y evidencia.

Quién usa, opera, posee o resulta afectado

Una persona puede relacionarse con el sistema de varias formas. Usuario describe un papel de interacción; operador, un papel que ejecuta o mantiene actividades; propietario puede referirse a responsabilidad o derechos sobre activos; stakeholder es cualquier parte con intereses o necesidades relevantes. No son sinónimos y una misma persona puede ocupar varios roles.

Ana usa la aplicación, pero quizá no opera el servicio. Una empresa puede decidir la política de retención sin administrar el centro de datos. Un proveedor puede operar infraestructura sin ser propietario de los mensajes. Bruno puede resultar afectado aunque no haya elegido la configuración. Si el modelo dibuja una sola figura humana llamada «usuario», oculta autoridad y responsabilidad.

La frontera organizativa tampoco coincide necesariamente con la técnica. Un servicio gestionado puede estar fuera de la organización y dentro del sistema de interés porque participa en el resultado evaluado. A la inversa, una herramienta corporativa puede quedar fuera de una pregunta estrecha. NIST SP 800-37 utiliza la autorización boundary para delimitar componentes autorizados y documentar conexiones, pero ese concepto tiene un propósito específico de gestión de riesgo; no debe confundirse con toda frontera conceptual (NIST SP 800-37 Rev. 2, tareas P-11 y P-12).

El mismo objeto puede ser sistema o componente

La escala depende de la pregunta. Un teléfono puede ser sistema cuando analizamos su capacidad de presentar una notificación. Puede ser componente cuando estudiamos el servicio completo de mensajería. Su procesador puede ser sistema desde la ingeniería del hardware y componente desde la aplicación. No hay contradicción: cambió el sistema de interés.

Este principio evita dos errores opuestos. El primero es reducir siempre el sistema al artefacto visible: «la aplicación es segura» aunque dependa de cuentas, servicios y operadores. El segundo es expandirlo hasta incluir todo el mundo, haciendo imposible una conclusión útil. Una frontera profesional es lo bastante amplia para no ocultar el mecanismo decisivo y lo bastante concreta para que claims y evidencia sean evaluables.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Un sistema de sistemas reúne sistemas constituyentes que conservan cierto grado de independencia y participan en capacidades mayores. En este nivel inicial basta reconocer que «varios sistemas conectados» no es automáticamente un único sistema bien gobernado. Cada constituyente puede tener operador, ciclo de vida, objetivos y fallos propios. No aplicaremos todavía ingeniería formal de sistemas de sistemas.

Propiedades locales y resultados globales

Una propiedad de un componente no se transfiere automáticamente al sistema. Si el almacenamiento cifra una copia, aún quedan tránsito, claves, metadatos, pantallas, operadores y otras copias. Si una API autentica al cliente, eso no prueba autorización para cada operación. Si un proceso está disponible, el servicio puede fallar por una dependencia.

La composición tampoco es siempre negativa: varios elementos pueden producir una capacidad que ninguno posee por separado. Pero el resultado surge de relaciones y condiciones, no de sumar etiquetas. Por eso el modelo debe indicar dónde se espera una propiedad y qué relación la conserva o la rompe.

Consideremos la propiedad «sólo Bruno puede leer el mensaje». En una frontera que contiene únicamente la pantalla de Bruno, podemos observar presentación local bajo una sesión; no podemos concluir exclusividad global. Al ampliar la frontera aparecen dispositivo de Ana, servicio, almacenamiento, claves, copias, operadores y recuperación de cuenta. La frase original se vuelve una familia de claims sobre distintos estados y actores.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Comparar fronteras sin buscar una única correcta

Volvamos a las dos preguntas iniciales. Para saber si el cliente entregó una petición al servicio, una frontera local con el endpoint como interfaz externa puede ser suficiente. Necesitaremos observar la petición, la respuesta, el tiempo y la versión del cliente. La conclusión debe terminar allí.

Para saber si Bruno pudo ver el mensaje, necesitamos incluir más transiciones: aceptación, almacenamiento o procesamiento, selección del destinatario, entrega, sincronización, presentación y sesión del receptor. La evidencia de la primera frontera se reutiliza, pero no resuelve la segunda. Cambiar de frontera no invalida el primer resultado; cambia el claim que puede sostenerse.

Podemos comparar fronteras con cinco preguntas:

1. ¿Qué decisión pretende informar el análisis?
2. ¿Qué comportamiento o propiedad se quiere explicar?
3. ¿Qué elementos pueden cambiar ese resultado?
4. ¿Qué interfaces permiten observarlos sin inventar su interior?
5. ¿Qué queda fuera y qué supuesto introduce esa exclusión?

Una frontera se revisa cuando omite una entidad necesaria, mezcla roles incompatibles o produce un claim que la evidencia interna no puede sostener. También puede reducirse si incorpora detalles que no cambian la respuesta y sólo añaden ruido.

Cinco señales de que la frontera está mal elegida

La primera señal es un sujeto que cambia sin aviso. El texto comienza diciendo que «la aplicación» respondió y termina atribuyendo a «el sistema» almacenamiento, entrega y lectura. Para corregirlo, subraya el sujeto de cada oración y pregunta si sigue dentro de la misma frontera. Si no, amplía el modelo o reduce la conclusión.

La segunda es una caja externa sin contrato observable. Dibujar «nube», «Internet» o «proveedor» fuera del sistema no explica qué capacidad se espera. Sustituye la caja por relaciones: resuelve un nombre, transporta una petición, valida una identidad, conserva una copia o entrega una notificación. No necesitas conocer toda la implementación para exigir una interfaz y una condición.

La tercera es un actor humano fusionado con su cuenta o dispositivo. «Ana envió el mensaje» puede resumir una acción cotidiana, pero el modelo técnico debe separar persona, cuenta, sesión, aplicación y teléfono cuando la pregunta depende de ellos. Separar no significa negar que estén relacionados; significa evitar que una observación de dispositivo se convierta en intención humana.

La cuarta es una propiedad sin lugar. «Está cifrado», «está autenticado» o «está disponible» necesita objeto, momento y frontera. Pregunta qué dato o interacción posee la propiedad, qué elemento la aplica y qué otras rutas permanecen. Una propiedad sin lugar suele esconder un salto de componente a sistema.

La quinta es un modelo que no puede fallar de forma observable. Si cualquier resultado encaja porque siempre podemos culpar al entorno, la frontera no ayuda a discriminar. Declara al menos un resultado que contradiga una relación esperada y una observación segura que permita detectarlo. El entorno puede explicar un fallo, pero esa explicación debe convertirse en dependencia y condición, no en salida universal.

Estas señales no obligan a dibujar más cajas. A veces la reparación correcta es una frontera menor y un claim más estrecho. El objetivo no es capturar cada detalle, sino hacer explícitos los detalles capaces de cambiar la respuesta.

Caso trabajado: tres modelos para el mismo mensaje

Modelo A, cliente local: teléfono de Ana, aplicación, proceso, cola local e interfaz de red. Propósito: determinar si el cliente intentó enviar. El servicio queda externo. Podemos observar acción de usuario, creación del mensaje, estado local y petición emitida. No podemos afirmar aceptación remota.

Modelo B, interacción cliente–servicio: añade endpoint, autenticación de sesión, respuesta y estado de aceptación. Propósito: determinar si el servicio recibió y aceptó la petición bajo una sesión. No incluye procesamiento posterior, dispositivo de Bruno ni lectura.

Modelo C, presentación extremo a extremo: añade almacenamiento o cola remota, resolución del destinatario, sincronización, dispositivo y aplicación de Bruno. Propósito: explicar por qué el contenido fue o no presentado. La lectura humana permanece como estado externo que requiere otra observación.

Cada modelo usa algunos elementos del anterior, pero no hereda sus conclusiones sin revisar interfaces, versiones y tiempo. Una marca «enviado» puede corresponder a un estado del Modelo A o B; el texto de la interfaz por sí solo no identifica cuál. Dibujar los tres modelos permite preguntar qué transición falta en vez de decir «el sistema falló».

Desliza horizontalmente para leer el diagrama a tamaño completo.

Transferencia: una cerradura conectada

Una cerradura doméstica puede abrirse desde una aplicación. Si la pregunta es «¿el motor movió el pestillo?», el sistema de interés puede incluir mecanismo, sensor, controlador y energía local. Si la pregunta es «¿quién podía solicitar apertura?», necesitamos cuenta, credencial, autorización, aplicación, servicio remoto y quizá plataforma de recuperación. Si la pregunta es «¿la vivienda quedó protegida?», aparecen puerta, instalación, uso humano y condiciones físicas que exceden al dispositivo.

No copies las cajas de la mensajería. Conserva el método: propósito, elementos, relaciones, estado, interfaces, dependencias, entorno y omisiones. En el modelo local, una respuesta de aplicación no demuestra movimiento físico. En el modelo de autoridad, que el motor se moviera no identifica quién fue autorizado. En el modelo de vivienda, que la cerradura funcione no garantiza que todas las entradas estén protegidas.

La transferencia revela por qué la frontera no es decoración. Cada ampliación cambia lo que significa «funcionó», quién puede observarlo y qué evidencia necesitaríamos. El capítulo 0.4 añadirá capas de ejecución; 0.6 separará identidad y autoridad; la Parte I enseñará a convertir estas distinciones en claims de seguridad y evidencia.

Lo que ya puedes explicar

Ya puedes comenzar un modelo por una pregunta y justificar qué queda dentro. Puedes distinguir elementos de relaciones, interfaz de implementación, sistema de entorno y usuario de operador o stakeholder. También puedes explicar por qué un servicio externo sigue siendo dependencia relevante y por qué una propiedad local no se convierte automáticamente en resultado global.

Puedes comparar dos fronteras sin preguntar cuál es «la real»: preguntas qué decisión informan, qué mecanismos incluyen y qué claims permite su evidencia. Puedes declarar una omisión sin tratarla como irrelevante.

Lo que todavía no estamos afirmando

Todavía no estamos describiendo procesos, memoria, protocolos de red, autenticación, autorización ni amenazas en profundidad. Tampoco estamos diciendo que una frontera técnica sea perímetro de seguridad, que una dependencia sea vulnerabilidad o que un stakeholder sea necesariamente propietario. Esos conceptos tendrán mecanismos y fuentes propios.

El modelo tampoco prueba por sí solo que el sistema funcione como fue dibujado. Una figura organiza preguntas. La evidencia y las pruebas decidirán qué relaciones ocurrieron en una versión y un intervalo concretos.

Síntesis

Un sistema no es una caja universal encontrada en el mundo: es un conjunto organizado de elementos y relaciones considerado para una pregunta. La frontera permite razonar, pero debe declarar entorno, dependencias y omisiones. El mismo objeto puede ser sistema o componente, y una interfaz puede revelar comportamiento sin exponer toda la implementación.

La disciplina central consiste en no cambiar de frontera en silencio. Propósito, estado, relaciones y roles determinan qué claims son posibles. Una propiedad de componente no se hereda sin examinar composición. Un servicio externo no desaparece porque quede fuera del dibujo. Cuando la pregunta cambia, el modelo debe cambiar de forma explícita.

Comprobación de comprensión

1. ¿Por qué «la aplicación» no determina por sí sola la frontera del sistema?
2. ¿Qué diferencia existe entre un elemento y una relación?
3. ¿Qué puede revelar una interfaz y qué no autoriza a concluir?
4. Construye una dependencia técnica y otra humana como oraciones comprobables.
5. ¿Cómo puede un teléfono ser sistema en una pregunta y componente en otra?
6. Compara los Modelos A y C del caso de mensajería.
7. ¿Por qué cifrado local no implica confidencialidad del sistema completo?
8. Distingue usuario, operador y stakeholder en el caso de la cerradura.
9. Formula un supuesto externo y una observación que podría refutarlo.
10. ¿Qué condición justificaría ampliar o reducir una frontera?

Problema de transferencia

Una biblioteca presta libros electrónicos mediante una aplicación. Un lector ve «préstamo activo», pero el libro no abre. Construye tres fronteras: interfaz local, interacción con el servicio y disponibilidad completa del contenido. En cada una declara propósito, al menos cinco elementos, cuatro relaciones con verbo, dos estados, dos dependencias y una omisión. Escribe un claim que cada frontera puede sostener y otro que no puede sostener. Termina indicando qué observación distinguiría error local, rechazo del servicio y problema de licencia sin acceder a cuentas ajenas.

Fuentes principales

1. NIST SP 800-160 Vol. 1 Rev. 1, §2.1 y §2.1.1 — conceptos de sistema, elementos, estructura, entorno y relaciones.
2. NIST SP 800-160 Vol. 1 Rev. 1, §2.1.2 y Apéndice G — sistemas de sistemas y procesos del ciclo de vida.
3. NIST SP 800-37 Rev. 2, tareas P-11 y P-12 — authorization boundary y descripción del sistema dentro de un proceso concreto de gestión de riesgo.
4. NIST SP 800-53 Rev. 5, controles CA-3 y PL-8 — conexiones, interfaces y arquitectura como artefactos documentados; no como definición universal de frontera.