La sécurité comme fondation, la souveraineté comme principe, la maintenabilité comme règle.
Vous gardez le code, les données, les décisions et la capacité de changer d'hébergeur.
Ownship tourne sur n'importe quel VPS, chez n'importe quel hébergeur — aucun lock-in cloud. L'infrastructure est entièrement décrite en code, développée à parité locale, et le socle vous revient : vous pouvez l'auditer, le modifier et le déplacer.
Une défense en profondeur autour d'un code qui peut être imparfait ou généré par IA.
Six couches indépendantes, du durcissement système à l'observabilité, reliées à un modèle de menaces STRIDE. Le détail complet est présenté ci-dessous.
L'infrastructure ne se contente pas d'être configurée : elle vérifie et documente ce qu'elle applique.
Verify-as-code : après chaque déploiement, une batterie de contrôles atteste ce qui est réellement appliqué. Et surtout, une documentation institutionnelle dédiée — parcours de montée en compétences, runbooks de troubleshooting et décisions d'architecture tracées — pour que vos équipes gagnent en autonomie.
Vous gardez le contrôle du code, des données, de l'hébergement et — surtout — de la compétence. Quatre engagements concrets, vérifiables, plutôt qu'une promesse.
Ownship n'assemble que des composants open source à licences permissives. Aucune brique propriétaire, aucun runtime opaque : chaque élément de la chaîne est inspectable et remplaçable.
Le socle se déploie sur vos VPS, vos serveurs on-premise ou votre propre datacenter, chez l'hébergeur de votre choix. Aucune dépendance à un fournisseur cloud particulier, aucun service managé imposé — vous changez d'hébergeur sans réécrire l'infrastructure.
Vous ne louez pas une boîte noire : le code d'infrastructure — Ansible, compose, contrats de service, playbooks de vérification — vous est livré. Vous l'auditez, le modifiez et le versionnez chez vous.
L'accompagnement à la mise en place inclut une formation sur le code lui-même. L'objectif n'est pas de vous rendre dépendant, mais de transférer la maîtrise : vos équipes savent opérer, faire évoluer et dépanner le socle.
Le code hébergé peut être imparfait, vulnérable ou généré par IA. L'infrastructure applique donc une défense en profondeur : six couches indépendantes où la défaillance de l'une ne compromet pas l'ensemble. Le principe est celui de l'« assume breach » — on suppose l'attaquant déjà entré, et on borne son rayon d'action.
Noyau durci (ASLR complet, kptr_restrict, restriction de ptrace et du BPF non privilégié), permissions strictes sur les fichiers sensibles (R36), suppression des services inutiles, partitionnement CIS et journal d'audit auditd sur les points critiques.
Pare-feu par défaut fermé, accès administrateur uniquement via VPN chiffré à échange de clés post-quantique, isolation réseau par service (bridges --internal), filtrage DNS de sortie (Unbound RPZ), IPS collaboratif CrowdSec et blocklists de renseignement (~13 000 IP).
Reverse proxy Traefik (TLS 1.3, HSTS, en-têtes de sécurité), pare-feu applicatif Coraza contre les injections SQL, XSS et traversées de chemin, identité centralisée Keycloak (OIDC), rate limiting et fail2ban contre la force brute.
Conteneurs sans root, toutes les capabilities supprimées, système de fichiers en lecture seule, profils seccomp par service. Chaîne d'approvisionnement vérifiée : images épinglées par empreinte (digest), signature cosign en fail-closed, scans de CVE Trivy/Grype à l'admission et SBOM CycloneDX.
Intégrité des fichiers (AIDE), audits CIS hebdomadaires (Lynis), scan de vulnérabilités web (Nuclei), honeypots (endlessh, cowrie) et honeytokens — tout contact avec un leurre est, par construction, un signal d'attaque.
Métriques (Prometheus), agrégation de logs (Loki), tableaux de bord et règles d'alerte (Grafana), supervision de disponibilité (Gatus). Chaque événement de sécurité est centralisé et déclenche une alerte.
Ces couches ne sont pas un catalogue : chaque contrôle est cartographié dans un modèle de menaces STRIDE qui associe chaque scénario d'attaque aux couches qui le traitent. Une menace couverte par plusieurs couches, c'est la défense en profondeur qui fonctionne ; une case vide, c'est un risque résiduel assumé et suivi dans la feuille de route.
Au cœur d'Ownship, chaque service est décrit par un contrat de service : un fichier déclaratif où il énonce ce dont il a besoin — et rien de plus. De ce contrat, la plateforme dérive puis applique les contraintes d'exécution.
C'est le pivot de l'architecture : aucun droit par défaut. Un service n'obtient un accès réseau, une capability ou un secret que s'il le déclare — et chaque déclaration est bornée, vérifiée et rejouée à chaque déploiement.
Résultat : un runtime maîtrisé, où le rayon d'action d'un code compromis reste borné à ce que son contrat autorise.
Envie de voir le socle appliqué à votre contexte ? Planifions un échange.
Voir aussi…