KryllOS est un produit auto-hébergé : vous l'installez sur votre propre serveur, et vous en êtes le seul utilisateur. Pas de cloud Kryll qui détient vos clés, pas de compte à créer, pas de mot de passe à gérer.
Cette réalité change radicalement la nature du modèle de sécurité. La question n'est plus « comment protéger un service multi-tenant », mais « comment protéger un serveur personnel qui n'a aucune raison d'être accessible depuis l'extérieur ». Le modèle de KryllOS répond avec un principe simple : robuste là où ça compte, sobre là où ça suffit.
Une frontière de sécurité solide
KryllOS n'est accessible que par vous, via un tunnel SSH dont le port reste fermé en permanence. Il ne s'ouvre qu'après une séquence de port knocking connue de vous seul. Pour un attaquant qui scanne Internet, votre serveur n'existe pas : aucun port ouvert, aucune réponse, aucune surface d'attaque visible.
Cette approche du serveur invisible avant authentification applique un modèle conçu en 2007 par la Defense Information Systems Agency (DISA) du Département de la Défense américain. Connu sous le nom de Software Defined Perimeter, ou « Black Cloud », il a été pensé à l'origine pour protéger des réseaux classifiés. C'est aujourd'hui le fondement des architectures Zero Trust qui équipent Cloudflare Access, Zscaler Private Access et la plupart des ZTNA modernes.
Pas de security theater entre vous et vous-même
La frontière étant solide, les protections qu'on empilerait habituellement à l'intérieur (authentification HTTP, sessions, rate limiting, chiffrement local des secrets) perdent leur sens. Si quelqu'un a franchi le tunnel SSH, c'est qu'il dispose de vos clés ou d'un shell sur votre machine : du point de vue du système, il est vous. Chiffrer une clé API avec une clé de déchiffrement stockée à côté ne change rien au coût d'attaque.
KryllOS choisit donc de rester honnête sur ce qu'il protège réellement, et de concentrer la cryptographie là où elle compte vraiment.
Les garanties cryptographiques où elles comptent vraiment
- Plugins signés : signature cryptographique vérifiée avant chaque exécution, avec audit pour la marketplace officielle.
- Filesystem sandboxé : toutes les opérations fichiers passent par une couche de validation qui empêche un plugin ou un appel API de sortir du dossier dédié.
- Dépendances épinglées par hash : KryllOS et ses composants sont distribués avec un manifeste cryptographique qui permet de vérifier que les bibliothèques tierces téléchargées sont bien celles qui ont été testées par l'équipe. Une compromission de PyPI ou d'un dépôt amont ne peut pas glisser en douce dans une mise à jour.
- Identifiants exchange isolés : vos clés API sont stockées dans une base SQLite locale, accessibles uniquement par le process KryllOS lui-même.
Les bonnes pratiques côté utilisateur
KryllOS prend en charge ce qu'il peut prendre en charge. Le reste relève de quelques bonnes pratiques classiques d'administration :
- Une clé SSH robuste (Ed25519, jamais de mot de passe) avec passphrase locale.
- Une séquence de port knocking que vous ne partagez pas et que vous changez si elle a fuité.
- Des clés API exchange créées avec les permissions minimales (trading uniquement, pas de retrait de fonds, restriction par IP si l'exchange le permet).
- Une vigilance particulière sur les plugins installés hors marketplace : un plugin tiers, c'est du code qui s'exécute avec les droits de votre serveur. La marketplace officielle existe précisément pour vous éviter d'avoir à faire vous-même cette analyse.
Un modèle adapté à sa cible
Ce n'est pas Binance ou Coinbase. KryllOS ne garde pas les fonds de millions d'utilisateurs, ne s'expose pas publiquement sur Internet, n'a aucune surface d'attaque à défendre face aux bots qui scannent en continu. C'est une station de trading personnelle qui, depuis Internet, n'existe simplement pas.
À cette échelle, l'enjeu n'est pas de construire une forteresse défensive. C'est de réduire la surface d'attaque jusqu'à la rendre invisible, et de concentrer la cryptographie sur les points qui restent.
