Sécurité structurelle, pas de correctifs
OmegaOS™ Kernel est fail-closed par défaut, en ajout seul par structure, et advisory-only par conception. Chaque atténuation est structurelle — intégrée dans le schéma, le runtime et le modèle de déploiement.
Modèle de menaces
Accès non autorisé aux données
Atténué par Row-Level Security (RLS) appliqué par locataire au niveau Postgres, plus authentification par clé API avec ~285 bits d'entropie.
Falsification de la piste d'audit
Atténué par le schéma en ajout seul. Les services d'exécution (hovo_app) ne peuvent que faire des INSERT — pas de UPDATE ni DELETE sur les tables du registre. Les révocations créent de nouveaux enregistrements.
Contournement de licence
Atténué par vérification Ed25519 hors ligne. Clé publique intégrée à la compilation. Pas de serveur de licence, pas de dépendance réseau. Les jetons falsifiés échouent à la vérification cryptographique.
Fuite de builds
Atténué par le filigrane de build. Chaque binaire intègre git_sha + build_timestamp + customer_tag à la compilation. L'empreinte apparaît dans les health checks et les logs de décision.
Fail-closed par défaut
Lorsque le PDP amont est injoignable ou que l'évaluation échoue, le gateway retourne DENY par défaut en mode enforce. Ce comportement est contrôlé par OPA_FAIL_MODE, qui vaut closed par défaut.
Les systèmes fail-open accordent silencieusement l'accès lorsqu'ils tombent en panne. Les systèmes fail-closed bloquent l'accès lorsqu'ils tombent en panne. Pour les environnements sensibles à la conformité, fail-closed est le défaut sûr.
| Scénario | Fail-Closed | Fail-Open |
|---|---|---|
| OPA injoignable | 403 Forbidden | Autorisation synthétique (journalisée) |
| Erreur interne | 403 Forbidden | Autorisation synthétique (journalisée) |
| Licence expirée | Rétrogradation automatique vers OBSERVE | |
Row-Level Security
Chaque requête passe par les politiques RLS de Postgres. Le rôle hovo_app ne peut accéder qu'aux lignes correspondant au contexte du locataire courant, défini au début de chaque transaction.
Même si un attaquant réalise une injection SQL à travers la couche applicative, il ne peut pas accéder aux données d'un autre locataire — la base de données applique l'isolation au niveau de la ligne.
| Rôle | RLS | Utilisé par |
|---|---|---|
| hovo_admin | BYPASSRLS | Outils CLI, migrations |
| hovo_app | Appliqué | hovo-api, hovo-gateway |
hovo_admin n'est jamais utilisé par les services d'exécution. Il est réservé aux outils opérateur qui s'exécutent séparément.
Registre en ajout seul
Six tables du registre sont en INSERT uniquement pour le rôle d'exécution. Aucune décision ne peut être modifiée rétroactivement.
Intégrité des évidences
Chaîne de responsabilité HMAC-SHA256 de la source externe au dossier de décision.
Les connecteurs externes (CRIF, Zefix, WorldCheck) signent chaque élément d’évidence avec HMAC-SHA256, créant une chaîne de responsabilité infalsifiable de la source externe au dossier de décision. Une évidence sans signature HMAC valide peut être signalée ou rejetée à l’ingestion — prouvant l’intégrité au niveau applicatif, indépendamment du chiffrement de transport.
Les tags de séparation de domaine (OMEGAOS:EVIDENCE:v1:) empêchent les collisions de hash entre contextes de sécurité.
| Propriété | Valeur |
|---|---|
| Algorithme | HMAC-SHA256 |
| Séparation de domaine | OMEGAOS:EVIDENCE:v1: |
| Portée | Par élément d’évidence, par connecteur |
| Vérification | À l’ingestion — avant la décision |
Chaîne de preuve cryptographique
Trois couches cryptographiques indépendantes — chacune vérifiable sans faire confiance aux autres.
Arbre de Merkle (RFC 9162)
Chaque décision est enchaînée dans un arbre de Merkle append-only. Toute modification rétroactive casse le hash racine. Les preuves d’inclusion sont vérifiables en O(log n) opérations sans révéler les autres décisions.
Signatures Ed25519
Les manifestes d’export, licences et attestations de build sont signés avec Ed25519. Clé publique intégrée à la compilation. La vérification est entièrement hors ligne — aucun service externe requis.
Horodatage RFC 3161
Les racines Merkle sont périodiquement ancrées auprès d’une autorité de services de confiance qualifiée (RFC 3161, conforme à ZertES et eIDAS). Fournit une preuve juridiquement contraignante admissible devant les tribunaux suisses et européens.
Vérification formelle
Les cinq invariants du système sont formellement spécifiés en TLA+ et vérifiés par le model checker TLC sur des espaces d’états finis. Il s’agit de model checking — exploration exhaustive d’un espace borné — pas de preuve de théorème.
Les invariants vérifiés sont :
- L’Indéterminé est le primitif — T/F exigent resolve()
- Registre append-only — pas de UPDATE, pas de DELETE
- Déterminisme — mêmes entrées produisent mêmes sorties
- Isolation locataire — aucun accès inter-locataire
- Aucune action irréversible automatique — supervision humaine requise
| Spécification | Portée |
|---|---|
| OmegaResolve.tla | Déterminisme, pas de T/F primitif, isolation locataire |
| OmegaLedger.tla | Append-only, chaîne de hash, pas de mutation |
| OmegaInvariants.tla | Les 5 invariants combinés |
Authentification par clé API
- Format :
delk_+ 48 caractères alphanumériques (~285 bits d'entropie) - Stockage : haché bcrypt (coût 12) — texte brut affiché une seule fois à la génération
- Rotation : Maximum 2 hachages par locataire pour une rotation sans temps d'arrêt
- Correspondance : clé API → tenant_id est la source unique de vérité pour le contexte RLS
Vérification de licence
- Algorithme : vérification de signature Ed25519
- Gestion des clés : clé publique intégrée dans le binaire à la compilation
- Réseau : entièrement hors ligne — pas de serveur de licence, pas de téléphonie maison
- Repli : les jetons expirés ou invalides rétrogradent automatiquement le gateway en mode OBSERVE
Filigrane de build
Chaque binaire intègre une empreinte forensique à la compilation pour la traçabilité.
customer_tag qui doit correspondre au tag intégré dans le build. Les tags incompatibles font échouer la licence — empêchant la réutilisation entre différents builds clients.
Durcissement réseau
Kubernetes
Les NetworkPolicy restreignent le trafic : seul le gateway accepte les connexions externes. L'API est interne au cluster uniquement. Les outils d'administration s'exécutent comme Jobs ponctuels, pas comme déploiements persistants.
Limites HTTP
Taille max du body : 1 Mio (configurable). Timeout requête : 30 secondes. Timeout connexion OPA : 3 secondes. Timeout lecture OPA : 10 secondes. Tout configurable via variables d'environnement.
Sécurité des conteneurs
Utilisateur non-root (65534), système de fichiers racine en lecture seule, toutes les capabilities supprimées, profil seccomp RuntimeDefault. Pas d'escalade de privilèges autorisée.
Infrastructure et juridiction
L'infrastructure supportant ce site est hébergée en Suisse et opère sous la juridiction suisse.
- Données hébergées en Suisse
- Soumis au cadre juridique suisse
- Aucun transfert intentionnel de données hors de Suisse
- Aucune analyse comportementale tierce
Documentation sécurité complète
Le modèle de menaces complet, les recommandations opérationnelles et le guide de durcissement sont disponibles dans la documentation de sécurité.
Voir la documentation