Swirl.SWIRL CLOUD
Une sécurité que vous pouvez prouver. Les preuves viennent de la plateforme en fonctionnement.
Swirl Cloud rattache ses contrôles à NIS2, ISO/IEC 27001, DORA, au RGPD et aux benchmarks CIS, évalue les contrôles techniques en continu à partir de la plateforme elle-même et rassemble les preuves pour vos auditeurs. Ces preuves soutiennent un audit ; elles ne valent pas certification.
Comment les preuves sont produites
Cataloguer
Chaque contrôle indique son objectif, les exigences qu’il couvre, ses vérifications automatiques et les documents qu’un auditeur demandera.
Évaluer
Prometheus évalue les vérifications toutes les 15 secondes : un contrôle passe quand sa preuve existe et qu’aucune vérification n’échoue.
Surveiller
Un tableau de bord suit chaque référentiel, et une alerte se déclenche quand un contrôle se dégrade pendant 30 minutes.
Prouver
Un rapport par référentiel et un dossier de preuves haché et signé avec votre clé, que vos auditeurs vérifient hors ligne.
Les contrôles, par thème
27 contrôles : 18 sont vérifiés en continu sur la plateforme en fonctionnement, 9 se prouvent par vos documents. Chaque fiche indique ce que vérifie le contrôle et les exigences qu’il couvre.
Identité et accès
- Automatique
Identité centrale et authentification unique
Les personnes se connectent aux services par un seul fournisseur d’identité, qui applique les règles de mot de passe et de protection contre la force brute ; les comptes locaux ne servent qu’en secours.
NIS2 21(2)(i)ISO 27001 A.5.15, A.5.16, A.5.17, A.8.5DORA Art. 9RGPD Art. 32(1)(b)
- Documents
Double authentification des administrateurs
L’accès d’administration à la plateforme exige un second facteur.
NIS2 21(2)(j)ISO 27001 A.8.2, A.8.5DORA Art. 9RGPD Art. 32(1)(b)
- Documents
Revue périodique des accès
Les responsables confirment ou retirent régulièrement les rôles de chaque personne, comptes locaux compris.
NIS2 21(2)(i)ISO 27001 A.5.18, A.8.2DORA Art. 9
- Automatique
Gestion des secrets
Les identifiants sont conservés dans Vault, transmis aux applications par External Secrets, jamais stockés dans Git, et renouvelés avant leur limite d’âge.
NIS2 21(2)(h)ISO 27001 A.5.17, A.8.24DORA Art. 9RGPD Art. 32(1)(a)CIS Kubernetes 5.4.2
Détection et réponse
- Automatique
Journalisation de sécurité
Les événements de l’API Kubernetes, du coffre de secrets et de l’identité sont enregistrés de façon centrale, avec une durée de conservation définie.
NIS2 21(2)(b)ISO 27001 A.8.15, A.5.28DORA Art. 10RGPD Art. 32(1)(b)CIS Kubernetes 3.2.1, Kubernetes 3.2.2
- Automatique
Supervision et alertes de sécurité
La collecte des métriques et l’acheminement des alertes fonctionnent en continu, pour qu’un problème détecté parvienne à un opérateur.
NIS2 21(2)(b)ISO 27001 A.8.16DORA Art. 10RGPD Art. 32(1)(b)
- Automatique
Prévention des intrusions
Fail2ban et CrowdSec bloquent la force brute et les sources malveillantes connues sur chaque serveur.
NIS2 21(2)(e)ISO 27001 A.8.16, A.8.20DORA Art. 10RGPD Art. 32(1)(b)
- Automatique
Intégrité des fichiers et logiciels malveillants
AIDE et rkhunter vérifient au moins chaque semaine que les fichiers des serveurs n’ont pas changé de façon inattendue et qu’aucun rootkit n’est présent.
NIS2 21(2)(e)ISO 27001 A.8.7, A.8.16DORA Art. 10CIS Ubuntu : intégrité des fichiers
- Documents
Gestion et notification des incidents
Les incidents de sécurité sont détectés, traités, enregistrés et notifiés dans les délais réglementaires.
NIS2 21(2)(b), 23ISO 27001 A.5.24, A.5.25, A.5.26, A.5.27DORA Art. 17, Art. 19RGPD Art. 33
Durcissement et vulnérabilités
- Automatique
Pare-feu des serveurs, refus par défaut
Chaque serveur rejette le trafic entrant non sollicité, sauf les ports d’administration, d’entrée et de cluster documentés.
NIS2 21(2)(e)ISO 27001 A.8.20, A.8.22DORA Art. 9RGPD Art. 32(1)(b)CIS Ubuntu : pare-feu du serveur
- Automatique
Segmentation réseau entre applications
Chaque espace de noms applicatif restreint son trafic par des NetworkPolicies.
NIS2 21(2)(e)ISO 27001 A.8.22DORA Art. 9CIS Kubernetes 5.3.2
- Automatique
Isolation des charges (Pod Security Standards)
Les charges respectent le profil Baseline des Pod Security Standards de Kubernetes.
NIS2 21(2)(e)ISO 27001 A.8.9DORA Art. 9CIS Kubernetes 5.2
- Automatique
Benchmark de configuration Kubernetes
La configuration du cluster est évaluée en continu face au CIS Kubernetes Benchmark.
NIS2 21(2)(f)ISO 27001 A.8.9DORA Art. 9CIS benchmark Kubernetes
- Automatique
Audit de durcissement des serveurs
Les serveurs sont audités chaque mois avec Lynis et restent au niveau de durcissement accepté ou au-dessus.
NIS2 21(2)(f)ISO 27001 A.8.9RGPD Art. 32(1)(d)CIS Ubuntu : audit du benchmark
- Automatique
Mises à jour de sécurité
Les serveurs installent automatiquement les mises à jour de sécurité et redémarrent sous une semaine quand une mise à jour l’exige.
NIS2 21(2)(e)ISO 27001 A.8.8, A.8.19DORA Art. 9CIS Ubuntu : mises à jour logicielles
- Automatique
Gestion des vulnérabilités
Les images en fonctionnement sont analysées en continu et chaque nouvelle vulnérabilité critique est triée.
NIS2 21(2)(e)ISO 27001 A.8.8DORA Art. 9RGPD Art. 32(1)(d)
- Automatique
Chiffrement en transit
Les adresses publiques utilisent des certificats TLS valides, renouvelés avant leur expiration.
NIS2 21(2)(h)ISO 27001 A.8.24DORA Art. 9RGPD Art. 32(1)(a)
Continuité et exploitation
- Automatique
Sauvegardes
Les archives de restauration et les volumes persistants sont sauvegardés chaque jour hors du domaine de panne.
NIS2 21(2)(c)ISO 27001 A.8.13DORA Art. 12RGPD Art. 32(1)(c)
- Documents
Reprise et continuité d’activité
L’organisation peut restaurer la plateforme et ses données dans les objectifs de reprise convenus.
NIS2 21(2)(c)ISO 27001 A.5.29, A.5.30DORA Art. 11, Art. 12RGPD Art. 32(1)(c)
- Automatique
Objectifs de disponibilité
Chaque adresse publique est sondée en continu face à un objectif de 99,5 %, et une consommation rapide ou durable du budget d’erreur alerte un opérateur.
NIS2 21(2)(c)ISO 27001 A.8.14, A.8.16DORA Art. 9, Art. 11RGPD Art. 32(1)(b)
- Automatique
Gestion des changements
Les changements de la plateforme et des applications sont appliqués depuis des révisions Git revues, sans dérive de l’état réel.
NIS2 21(2)(e)ISO 27001 A.8.9, A.8.32DORA Art. 9
- Automatique
Gestion de la capacité
La marge de stockage et de calcul est surveillée pour qu’aucun service ne tombe faute de ressources.
ISO 27001 A.8.6DORA Art. 9RGPD Art. 32(1)(b)
Gouvernance
- Documents
Gestion des risques et politique de sécurité
Les risques de sécurité de l’information sont évalués et traités dans le cadre d’une politique approuvée.
NIS2 21(2)(a)ISO 27001 A.5.1DORA Art. 6RGPD Art. 32(2)
- Documents
Registre des traitements
Chaque traitement de données personnelles est inscrit avec ses finalités, ses données, ses destinataires, son stockage et sa durée de conservation.
NIS2 21(2)(i)ISO 27001 A.5.34RGPD Art. 30
- Documents
Sécurité des fournisseurs et de la chaîne d’approvisionnement
Les services externes et les fournisseurs de logiciels sont inventoriés, évalués et couverts par des accords.
NIS2 21(2)(d)ISO 27001 A.5.19, A.5.20, A.5.21, A.5.22DORA Art. 28RGPD Art. 28
- Documents
Sensibilisation et sécurité du personnel
Le personnel est formé, et les arrivées, mobilités et départs reçoivent et perdent leurs accès à temps.
NIS2 21(2)(g), 21(2)(i)ISO 27001 A.6.1, A.6.3, A.6.5
- Documents
Évaluation de l’efficacité
Les mesures de sécurité sont testées et revues régulièrement, et leurs constats sont suivis jusqu’à leur clôture.
NIS2 21(2)(f)ISO 27001 A.5.35, A.5.36DORA Art. 24, Art. 25RGPD Art. 32(1)(d)
Des rapports pour vos audits et questionnaires
Revue des accès
Les utilisateurs de Keycloak et de GitLab avec leurs rôles et leur dernière connexion, les administrateurs de Kubernetes et d’Argo CD, les comptes de secours et une feuille de validation à signer.
Registre des traitements RGPD
Un projet de registre (article 30) établi à partir des applications, de leurs données, de leurs sous-traitants et de leurs sauvegardes.
Incidents et échéances NIS2
Une chronologie des alertes, changements et connexions, avec les échéances NIS2 (24 heures, 72 heures, un mois) et RGPD (72 heures) et les projets de rapports.
Délais de correction
Chaque vulnérabilité d’une image en fonctionnement est suivie depuis sa découverte : 15 jours pour une critique, 30 pour une haute.
Âge des identifiants
Chaque secret de Vault avec sa version, sa dernière écriture et son âge face à la limite, sans jamais révéler sa valeur.
Rapport mensuel
La part du temps où chaque contrôle a passé, la disponibilité et les coûts du mois, conservés 13 mois.
Tests et divulgation des vulnérabilités
Tests d’intrusion
Aucun test d’intrusion externe n’a encore été mené. Il est prévu sur une installation de référence avant la première installation client, puis à chaque version majeure.
Signaler une vulnérabilité
Vous pensez avoir trouvé une vulnérabilité dans Swirl Cloud ou dans ce site ? Écrivez à contact@swirlit.dev en indiquant l’adresse ou le composant concerné, les étapes pour la reproduire et l’impact constaté. N’accédez pas à des données et ne les modifiez pas au-delà de ce qui démontre le problème, évitez de perturber le service, et laissez-nous le temps de corriger avant toute publication.
contact@swirlit.devQuestions fréquentes
Swirl Cloud est-il certifié ?
Non. Une certification ISO/IEC 27001 porte sur une organisation et son périmètre, pas sur un logiciel. Swirl Cloud fournit les preuves techniques de vos propres audits.
Swirl Cloud nous rend-il conformes à NIS2 ou à DORA ?
Il couvre et prouve les mesures techniques de la plateforme. La gouvernance, l’analyse de risques, la formation et les accords avec vos fournisseurs restent de votre ressort ; la plateforme liste les documents qu’un auditeur vous demandera.
Les preuves quittent-elles nos serveurs ?
Non. Les vérifications, les rapports et le dossier de preuves sont produits sur votre installation ; vous choisissez ce que vous remettez à vos auditeurs.