On déploie une application sur un réseau contraint, on prépare le dossier de sécurité, et la question tombe : faut-il viser un Certificate of Networthiness ou passer par une Authority to Operate ? La réponse dépend moins du label que du cycle de vie réel de l’application et du niveau de contrôle exigé par l’environnement cible.
Matrice de traçabilité et contrôles continus : ce que change le passage au RMF
Le Certificate of Networthiness (CoN) a longtemps fonctionné comme un tampon d’entrée. On constituait un dossier technique, on le soumettait, et une fois validé, l’application pouvait circuler sur le réseau. Le problème, c’est que cette validation restait ponctuelle.
A découvrir également : Adepte de la technologie : comment protéger vos biens ?
L’approche a été progressivement remplacée par des cadres de gestion du risque plus continus, comme le Risk Management Framework (RMF). La différence de fond : il ne s’agit plus de « passer une certification » à un instant T, mais de maintenir une autorisation vivante sur toute la durée de vie de l’application.
Concrètement, pour les équipes qui avaient l’habitude de monter un dossier CoN, le passage au RMF implique de construire une matrice de traçabilité entre anciens livrables et contrôles actuels. Réutiliser tel quel un dossier documentaire conçu pour un CoN ne suffit plus. Chaque contrôle doit être mappé sur les exigences RMF, avec des preuves actualisées.
A voir aussi : Protéger efficacement vos appareils Apple : les équipements à privilégier
ATO : un dossier de conformité réutilisable à l’échelle du cycle de vie
L’Authority to Operate (ATO) formalise l’autorisation d’exploiter un système dans un environnement donné. Sur le papier, on pourrait croire que c’est juste un CoN plus lourd. En pratique, l’ATO structure un dossier de conformité conçu pour être réutilisé et mis à jour, pas archivé après validation.
Ce dossier couvre la sécurité technique, mais aussi des dimensions que le CoN historique n’intégrait pas :
- La gouvernance des données : qui accède à quoi, comment les flux sont documentés, quelles politiques de rétention s’appliquent.
- La traçabilité décisionnelle : quand une application intègre de l’IA, la documentation des modèles et de leurs jeux de données entre dans le périmètre d’autorisation.
- La preuve continue : les contrôles ne sont pas figés au moment de la soumission. On attend des preuves régulières que le système reste conforme après déploiement.
Pour une équipe produit, cela signifie que le travail de conformité ne s’arrête pas à l’obtention de l’ATO. Il faut prévoir des revues périodiques, des mises à jour du dossier à chaque évolution significative, et une capacité à produire des preuves à la demande.
Certificate of Networthiness ou ATO : critères de choix selon le contexte applicatif
Le choix entre ces deux approches ne se pose pas de la même manière selon qu’on déploie une application interne sur un réseau de défense ou un service cloud destiné à plusieurs organisations.
Quand le CoN reste pertinent
Dans certains environnements, le CoN conserve une utilité opérationnelle. C’est le cas lorsque l’application est un composant technique limité (un outil réseau, un firmware, un module d’infrastructure) qui doit simplement prouver qu’il ne dégrade pas la sécurité du réseau hôte. Le périmètre est restreint, la validation est technique, et le cycle de mise à jour est lent.
Quand l’ATO s’impose
Dès que l’application traite des données sensibles, évolue fréquemment ou s’intègre dans un environnement cloud, l’ATO devient la voie naturelle. Les retours varient sur ce point, mais la tendance est nette : les organisations qui industrialisent leurs contrôles de sécurité privilégient l’ATO parce qu’il s’inscrit dans une logique DevSecOps compatible avec des cycles de livraison courts.
L’enjeu principal, c’est l’alignement entre le rythme de développement et le rythme de conformité. Un CoN figé bloque les mises à jour. Un ATO bien construit, adossé à des contrôles automatisés, permet de livrer sans attendre une revalidation complète à chaque release.
Construire un dossier qui tient dans le temps : les points concrets
Quel que soit le cadre retenu, la qualité du dossier initial détermine la charge de maintien. On voit régulièrement des équipes monter un dossier volumineux pour décrocher l’autorisation, puis se retrouver incapables de le mettre à jour parce qu’il n’a pas été pensé pour évoluer.
Quelques principes qui font la différence sur le terrain :
- Séparer les preuves statiques (architecture, schéma réseau) des preuves dynamiques (logs, résultats de scans, rapports de tests). Les premières changent rarement, les secondes doivent être rafraîchies à chaque cycle.
- Documenter les écarts acceptés dès le dossier initial. Un risque identifié et assumé pèse moins qu’un risque découvert lors d’un audit.
- Automatiser la collecte de preuves : un pipeline qui génère les artefacts de conformité à chaque build réduit drastiquement le coût de maintien de l’ATO.
La tentation fréquente, c’est de traiter la conformité comme un projet ponctuel. Les équipes qui s’en sortent le mieux intègrent les exigences de l’ATO directement dans leur chaîne CI/CD, de sorte que chaque livraison produit automatiquement les preuves nécessaires.
Le Certificate of Networthiness garde un rôle pour des composants techniques ciblés sur des réseaux contraints. Pour toute application qui évolue, traite des données ou s’appuie sur du cloud, l’ATO adossé au RMF offre un cadre plus adapté aux réalités de production actuelles. Le vrai coût n’est pas dans l’obtention de l’autorisation, mais dans sa maintenance, et c’est là que le choix du cadre fait toute la différence.
