Esta página puede estar parcialmente traducida. Algunos contenidos se muestran en inglés.

Nota de arquitectura de seguridad

Propiedades estructurales, supuestos y comportamiento ante fallos de OmegaOS™ Kernel.

Alcance y supuestos

Esta página describe las propiedades estructurales de seguridad del runtime de OmegaOS™ Kernel tal como fue diseñado. Abarca el motor de decisiones, el registro de auditoría y el modelo de despliegue del operador.

Supuestos

  • El operador controla el entorno de despliegue.
  • El operador es responsable del perímetro de red, el hardening del sistema operativo del host y el control de acceso al despliegue.
  • El runtime no realiza ninguna llamada de red saliente durante la evaluación de políticas.
  • OmegaOS™ Kernel es exclusivamente consultivo por defecto. En los modos observar y sombra, produce decisiones sin ejecutar acciones descendentes.

Lo que esta página no cubre

  • Federación de identidad a nivel de aplicación (responsabilidad del operador).
  • Vulnerabilidades del sistema operativo del host o del runtime de contenedores (específicas del despliegue).
  • Denegación de servicio a nivel de red (incumbencia de la infraestructura).
  • Resultados de pruebas de penetración (no se publican públicamente).

Propiedades estructurales

Fail-closed por defecto

Cuando el motor de políticas es inalcanzable o la evaluación falla, la pasarela adopta DENY en modo de aplicación. La configuración fail-open no está disponible.

Registro append-only

Los servicios runtime solo pueden crear nuevos registros. No existe modificación ni eliminación de entradas del registro. Las revocaciones generan nuevos registros, no eliminaciones.

Aislamiento de datos multi-tenant

Cada consulta se filtra mediante políticas de aislamiento a nivel de infraestructura. Los servicios runtime acceden únicamente a los registros pertenecientes al contexto del tenant actual.

Diseño exclusivamente consultivo

OmegaOS™ Kernel produce decisiones estructuradas que informan a los operadores humanos. No ejecuta de forma autónoma acciones descendentes.

Comportamiento ante fallos

Cada ruta de fallo adopta por defecto el estado más restrictivo. Sin concesión silenciosa, sin permiso sintético.

EscenarioComportamiento
Motor de políticas inalcanzable DENY (modo de aplicación)
Error interno durante la evaluación DENY (modo de aplicación)
Licencia caducada Degradación automática a OBSERVAR
Evidencia sin firma válida Marcada o rechazada en la ingesta

Modelo de aislamiento de tenants

El aislamiento de datos a nivel de infraestructura se aplica al nivel del registro. Incluso si un atacante logra una inyección a través de la capa de aplicación, el acceso a datos entre tenants está estructuralmente impedido.

Nivel de accesoAislamientoUtilizado por
Administrativo Acceso completo Herramientas del operador, migraciones
Runtime Limitado al tenant Servicios de aplicación
Límite: El acceso administrativo nunca es utilizado por los servicios runtime. Está restringido a las herramientas del operador que se ejecutan de forma independiente.

Integridad criptográfica

Autenticación de evidencias

Cada elemento de evidencia se autentica criptográficamente en la ingesta. Las evidencias que lleguen sin una firma válida pueden ser marcadas o rechazadas, lo que demuestra la integridad de los datos en la capa de aplicación, con independencia del cifrado del transporte.

PropiedadValor
AutenticaciónCódigo de autenticación de mensajes
Separación de dominioPor contexto de seguridad
AlcancePor elemento de evidencia
VerificaciónEn la ingesta — antes de la decisión

Cadena de prueba

Cada decisión se encadena en una estructura criptográfica append-only. La modificación retroactiva rompe la verificación de integridad. Las pruebas de inclusión son verificables sin revelar otras decisiones.

Firmas digitales

Los manifiestos de exportación, las licencias y las atestaciones de compilación están firmados con firmas digitales criptográficas. La verificación es completamente offline.

Sellado de tiempo de confianza

Las raíces criptográficas se anclan periódicamente a una Autoridad de Sellado de Tiempo externa. Cuando se configura con una TSA cualificada, los sellados de tiempo pueden respaldar los requisitos de temporalidad probatoria bajo ZertES y eIDAS. El efecto jurídico depende de la jurisdicción y el contexto.

Límite del operador

Aislamiento de red

Solo la pasarela acepta conexiones externas. Los servicios internos no son accesibles desde el exterior. Las herramientas administrativas se ejecutan como procesos aislados, no como servicios persistentes.

Aislamiento del runtime

Ejecución sin privilegios de root, sistema de archivos de solo lectura, capacidades innecesarias eliminadas. Sin ruta de escalada de privilegios.

Controles de solicitudes

Límites configurables sobre el tamaño de solicitudes, tiempos de espera de conexión y tiempos de espera de evaluación. Parámetros ajustables por despliegue.

Verificación formal

Cinco invariantes del sistema se verifican formalmente mediante comprobación matemática de modelos sobre espacios de estados finitos. Se trata de una exploración exhaustiva de un espacio de estados acotado, no de demostración de teoremas.

  • INDETERMINADO es el primitivo — PERMITIR/DENEGAR requieren resolución explícita
  • Registro append-only — sin modificación, sin eliminación
  • Determinismo — las mismas entradas producen las mismas salidas
  • Aislamiento de tenants — sin acceso de datos entre tenants
  • Sin acción irreversible automática — se requiere intervención humana
AlcanceInvariantes cubiertos
Resolución de decisionesDeterminismo, lógica tri-estado, aislamiento de tenants
Registro de auditoríaAppend-only, cadena de integridad, sin mutación
Modelo combinadoLos 5 invariantes combinados
Nota de alcance: La comprobación de modelos verifica invariantes sobre un modelo finito. Esto demuestra la ausencia de violaciones en el espacio de estados explorado. Una prueba matemática completa requeriría demostración formal de teoremas, lo cual no se afirma aquí.

Autenticación de API

  • Credenciales: Claves API criptográficamente robustas
  • Almacenamiento: Con hash seguro
  • Rotación: Rotación de claves sin tiempo de inactividad
  • Asignación: La clave API se asigna al contexto del tenant para el aislamiento de datos

Verificación de licencias

  • Método: Verificación criptográfica
  • Gestión de claves: Verificación mediante clave integrada
  • Red: Completamente offline
  • Fallback: Degradación controlada al caducar

Infraestructura y jurisdicción

La infraestructura que soporta este sitio web está alojada en Suiza y opera bajo jurisdicción suiza.

  • Datos alojados en Suiza
  • Sujeto al marco jurídico suizo
  • Sin transferencia intencionada de datos fuera de Suiza
  • Sin análisis de comportamiento de terceros

Documentación relacionada

El Artefacto Técnico describe la semántica del runtime. Ediciones cubre el alcance del despliegue.