Brevet FR3156218A1 — publié le 20250606

L’invention concerne un procédé de sécurisation d’un ensemble d’opérations de traitements de données destiné à être appliqué à au moins un flux de données, ledit procédé comprenant une organisation d’un ensemble d’opérations de traitement des données du flux de données dans une pluralité d’enclaves ( , , , ) chaque enclave étant apte à réaliser une ou plusieurs opérations de traitement sur le flux de données, chaque enclave étant définie par, un niveau de confidentialité ( , , ) de l’enclave, un type de protection (fixe, maximal) d’enclave, une capacité de chiffrement et de déchiffrement de l’enclave, une ou plusieurs fonctions selon le flux de données, telle qu’une fonction de création, de transit, d’écriture ou de lecture. Figure pour l’abrégé : Fig. 2 Procédé d'analyse de vulnérabilités de systèmes centré sur les traitements des données La présente invention concerne un procédé et un système de gestion intelligente de capacités de protection de données afin de garantir la protection de ces données, considérées comme actifs à protéger dans leur exploitation. Elle s’applique particulièrement dans le cadre de systèmes dont il est possible de lister de façon exhaustive les actifs limités aux données à protéger, ainsi que des séquences de traitements réalisés sur ces données par le système. Ces traitements sont déployés sur des supports matériels permettant soit la création de données, soit leur transit sans besoin d’accès aux données transitées, soit leur modification en écriture, soit leur accès en lecture sans modification de la donnée, soit leur mémorisation. Un niveau de confidentialité est associé à chaque donnée créée par le système. Un niveau de protection en confidentialité est associé à chacun des supports physiques sur lequel des traitements issus de ces données créées peuvent être réalisés. Ces supports physiques ont la capacité de fournir des traitements de calcul de signature sur des données ainsi que des capacités de chiffrement et de déchiffrement. Ces capacités de chiffrement et de déchiffrement sont relatives à un niveau de confidentialité de données. Arrière-plan technique La définition des informations dans l’activité d’ingénierie système d’une part dans la description des traitements du système et d’autre part dans la définition d’actifs à protéger issus d’une analyse de risque, est bien connue de l’homme du métier. Il en est de même de la détermination d’un niveau de protection aux supports physiques dans lesquels des traitements sur des données à protéger sont réalisés. Le document “Flaws in Flows: Unveiling Design Flaws via Information Flow Analysis” de Tuma, Katja and Scandariato, Riccardo and Balliu, Musard publié en 2019, présente aux pages 191-200 une description de systèmes sous la forme de diagrammes de flots de données sécurisées dites « secDFD » (pour « it security Data Flow Diagram » en anglais) avec un niveau de confidentialité attaché à chacun des secDSD. Les nœuds de ces secDFD font référence à des contextes d’utilisation appelés « asset » avec une définition de contrats dans les parcours des nœuds dans les secDFD. Les règles d’inférences appliquées à ces secDFD permettent de définir un niveau de confidentialité d’une fonction commune à plusieurs secDFD. Ce travail permet d’identifier le niveau de confidentialité que doit acquérir un attaquant pour cet asset afin de capturer l’information des secDSD y transitant. Il existe un besoin d’améliorer encore davantage la protection des données considérés comme des actifs à protéger dans leur exploitation par un système. Un objet de l’invention concerne un procédé de sécurisation d’un ensemble d’opérations de traitements de données destiné à être appliqué à au moins un flux de données, ledit procédé comprenant une organisation d’un ensemble d’opérations de traitement des données du flux de données dans une pluralité d’enclaves ( , , , ) chaque enclave étant apte à réaliser une ou plusieurs opérations de traitement sur le flux de données, chaque enclave étant définie par : - un niveau de confidentialité ( , , ) de l’enclave ; - un type de protection (fixe, maximal) d’enclave, ledit type de protection comprenant au moins deux catégories, une première catégorie dite protection fixe pour laquelle toute donnée du flux de données en sortie de l’enclave est associée au niveau de confidentialité de l’enclave et une seconde catégorie dite protection maximale pour laquelle toute donnée de flux de données en sortie de l’enclave est associée à un niveau de confidentialité inférieure ou égale au niveau de confidentialité de l’enclave ; - une capacité de chiffrement et de déchiffrement de l’enclave ; - une ou plusieurs fonctions selon le flux de données, telle qu’une fonction de création, de transit, d’écriture ou de lecture. L’invention se distingue ainsi de l’art antérieur cité par une vérification du niveau de confidentialité de traitements de chaînes fonctionnelles sécurisées. D’une part, le procédé de sécurisation proposé comporte des niveaux de protections d’enclaves gérant la confidentialité des actifs y transitant selon deux types de politiques (maximale ou fixe). D’autre part, le procédé de sécurisation exploite des ressources en signature et chiffrement permettant la production de directives de sécurité associées. Il produit en outre des codes de sécurité. L’invention prend en compte les caractéristiques d’ingénierie système et s’appuie sur les recommandations de sécurisation des applications industrielles. Elle permet donc une génération de codes de protection en confidentialité et intégrité particulièrement adaptées à ces applications. Dans une variante de réalisation, le procédé comprend : - une étape de calcul de directives de contrôle d’intégrité, ladite étape permettant d’associer à chaque enclave une première variable booléenne IC et une seconde variable booléenne AIC, ladite première variable booléenne IC étant associée à un contrôle d’intégrité de la donnée du flux de données entrant dans l’enclave, la seconde variable booléenne AIC étant associée à un contrôle de signature de la donnée du flux de données entrant dans l’enclave. Dans une variante de réalisation, le procédé de sécurisation comprend : - une étape de calcul d’un niveau de confidentialité global pour chaque enclave.` Dans une variante de réalisation, le procédé de sécurisation comprend : - une étape de calcul de directives de chiffrement et de déchiffrement pour la détermination d’une capacité de chiffrement et de déchiffrement pour chaque enclave. Dans une variante de réalisation, le procédé de sécurisation comprend : une étape (E4) de production de directives de validation de règles de sécurité et de génération de code de contrôle. Dans une variante de réalisation, l’organisation de l’ensemble d’opérations de traitement des données du flux de données dans une pluralité d’enclaves est réalisée à partir de données de conception obtenues via un outil de modélisation. Un autre objet de l’invention concerne un système de gestion d’évènements et d’informations de sécurité pour la mise en œuvre du procédé de sécurisation de l’invention. Un autre objet de l’invention concerne un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes d’un procédé de sécurisation d’un ensemble d’opérations de traitements de données destiné à être appliqué à au moins un flux de données lorsque ledit programme est exécuté par un processeur. Description des figures La FIG. 1 représente un système de gestion d’évènements et d’informations de sécurité selon l’invention ; La FIG. 2 schématise les différentes étapes d’un procédé de sécurisation mise en œuvre par le système de la FIG. 1 ; La FIG. 3 représente une première étape de calcul de directives de contrôle d’intégrité du procédé de la FIG. 2 ; La FIG. 4 représente une deuxième étape de calcul d’un niveau de confidentialité global du procédé de la FIG. 2 ; La FIG. 5 représente une troisième étape de calcul de directives de chiffrement et de déchiffrement du procédé de la FIG. 2 ; La FIG. 6 représente une quatrième étape de production de directives de validation de règles de sécurité du procédé de la FIG. 2 ; La FIG. 7 représente une capture des besoins système annotée d'informations issues d'une analyse de vulnérabilité en utilisant un outil de conception par modélisation ; La FIG. 8 représente une traduction des besoins systèmes de la FIG. 7 par le procédé de sécurisation de la FIG. 2 ; La FIG. 9 schématique un équipement matériel adapté pour implémenter un logiciel apte à exécuter les étapes du procédé de sécurisation de la FIG. 2 . Toute production d’applications industrielles impose une phase d’ingénierie système. Pour les applications manipulant des actifs de données sensibles devant être protégés à l’accès, une analyse de risque (par exemple en utilisant la méthode EBIOS-RM de l’ANSSI (pour « Autorité Nationale en matière de Sécurité et de défense des Systèmes d’Informations ») impose de catégoriser le niveau de gravité de la divulgation des données sous la forme d’un niveau de confidentialité. Cette analyse impose que le système réalisant les traitements se protège d’une divulgation des données dans les unités de traitement, de transit et de stockage de l’architecture physique du système. Pour cela à chaque composant physique réalisant soit le traitement, soit le transit, soit le stockage est associé un niveau de protection garantissant la capacité de traiter, faire transiter et mémoriser des données selon le niveau de confidentialité associé à la donnée. Différentes politiques de modifications de niveau de confidentialité au sortir d’une unité de traitement de données sensibles ont été proposées. Celle qui associe le niveau de protection du composant à la donnée traitée sortante est celle utilisée dans les applications de défense. L’invention exploite cette politique de protection ainsi qu’une politique du niveau sortant le plus faible en tenant compte d’interactions inter-chaînes fonctionnelles sécurisées. La FIG. 1 illustre un système gestion d’évènements et d’informations de sécurité 1 pour un ensemble d’opérations de traitements de données s’appliquant sur un flux de données. Ce système de gestion 1 est divisé en une pluralité d’enclaves , , , . Par le terme « enclave », on entend un support matériel. Chaque enclave est apte à réaliser une ou plusieurs opérations de traitement sur le flux de données. Chaque enclave , , , est définie par : - un niveau de confidentialité de l’enclave ; - un type de protection d’enclave ; - une capacité de chiffrement/déchiffrement de l’enclave ; - une ou plusieurs fonctions selon le flux de données. Le niveau de confidentialité de l’enclave est compris dans un ensemble comprenant n éléments ou niveaux de confidentialité à qui peut être défini comme suit : L’ensemble peut être partiellement ordonné, notamment constituer un treillis. Les éléments de confidentialité de l'ensemble peuvent être agencés par ordre croissant. En particulier, les éléments de confidentialité de l'ensemble peuvent être agencés selon la condition suivante : Le type de protection d’enclave est compris dans un ensemble des types de protection d'enclave. Cet ensemble est défini comme suit : signifie qu'à toute donnée en sortie d'enclave d'un niveau de protection de confidentialité est affecté ce niveau de confidentialité. signifie qu'à une donnée sortant de l'enclave est affecté du niveau de confidentialité maximal des informations de cette enclave qui pourraient affecter cette donnée. La ou les fonctions appartiennent à un ensemble de types de fonctions . Cet ensemble est défini comme : Une fonction est définie par son type de fonction, par l’enclave dans laquelle elle est traitée et par un identifiant. L'ensemble des fonctions est un ensemble de 3-uplets . Pour , fournit l’identifiant de l’enclave sur laquelle est traitée . L'ensemble est défini comme une liste de 3-uplets ( éléments de , étant des identifiants d'enclaves. Une enclave offre une capacité de calcul de signature si . Une enclave offre une capacité de chiffrement / chiffrement pour un niveau de confidentialité si . Pour une enclave , son niveau de protection en confidentialité est noté . Il est considéré par la suite que pour le niveau de protection en confidentialité des enclaves pour lesquelles . Dans l’exemple de la figure 1, le système de gestion 1 comprend une première enclave , une deuxième enclave , une troisième enclave et une quatrième enclave . La première enclave est définie par : - un niveau de confidentialité C1 ; - un niveau de protection de confidentialité maximal ; - une capacité de chiffrement/déchiffrement compatible avec les niveaux C1, C2 et C3 de confidentialité. - une fonction de création creat de données de niveau de confidentialité C1 ; - une fonction de lecture read. La deuxième enclave est définie par : - aucun niveau de confidentialité ; - un niveau de protection de confidentialité maximal ; - aucune capacité de chiffrement/déchiffrement. - une fonction de transit; - une fonction de transit. La troisième enclave est définie par : - aucun niveau de confidentialité ; - un niveau de protection de confidentialité maximal ; - une capacité de chiffrement/déchiffrement compatible avec les niveaux C1, C2 de confidentialité. - une fonction d’écriture write ; - une fonction de lecture read. La quatrième enclave est définie par : - un niveau de confidentialité C2 ; - un niveau de protection de confidentialité fixé ; - une capacité de chiffrement/déchiffrement compatible avec les niveaux C1, C2 et C3 de confidentialité. - une fonction de lecture read; - une fonction de création creat de données de niveau de confidentialité C1. Un flux de données est traité par les différentes enclaves , , , . Dans la suite de la description, on entend par l’expression « chaîne fonctionnelle annotée d'information de sécurité » ou plus simplement par l’expression « chaîne fonctionnelle », une séquence de traitements réalisée par les différentes enclaves. Un système à sécuriser est un ensemble de chaînes fonctionnelles, notamment défini de la façon suivante : Dans l’exemple de la figure 1, le système à sécuriser comporte deux chaînes fonctionnelles . Une première chaine fonctionnelle comprend la succession des fonctions , , , . Une deuxième chaine fonctionnelle comprend la succession des fonctions , , , . La FIG. 2 illustre l’ensemble des étapes E0 à E4 d’un procédé de sécurisation d’un ensemble d’opérations de traitements de données. L’étape E0 correspond à une récupération d’informations du système comme liste de . Cette étape E0 permet l’organisation d’un ensemble d’opérations de traitement des données du flux de données dans la pluralité d’enclaves. La FIG. 3 décrit plus particulièrement les résultats d’une première étape E1 de calcul des directives de contrôle d’intégrité dans les différentes enclaves. Un calcul des directives de contrôle d’intégrité comprend une identification des portions de chemins des du système, lesquels, pour les premiers et derniers nœuds de la portion de chemin, ont des enclaves qui permettent le calcul de signatures de données, avec tous les nœuds intermédiaires sont de type ou en transit , et avec un changement d'enclave entre les deux premiers et deux derniers nœuds. Un tel calcul peut être formalisé de la façon suivante. L'application de capacités de signatures entre et d’une chaîne fonctionnelle est effective si avec défini comme suit : A chaque nœud du peuvent être associées deux variables booléennes ic et aic initialisées à l’état . Pour chaque couple , satisfaisant la condition , pour les nœuds des chemins de à permettant de satisfaire la relation. indique qu'il y a un chemin pour lequel le contrôle d'intégrité est possible. n'indique pas que tous les chemins du passant dans ce nœud ont pu être préalablement signés. C'est la variable booléenne qui est destinée à porter ultérieurement une telle information. Un calcul d’une variable booléenne peut être formalisé de la façon suivante. La variable booléenne aic est initialisée à pour les nœuds pour lesquels . Pour chaque nœud pour lequel , les pas du peuvent être parcourus dans le sens du graphe orienté jusqu'au nœud pour lequel . Si aucun des nœuds ne satisfait le long de ce parcours, alors la variable booléenne prend l’état . Selon une variante, pour chaque nœud pour lequel , les pas du peuvent être parcourus à rebours du sens du graphe orienté jusqu'au noeud pour lequel . Si aucun des nœuds ne satisfait le long de ce parcours, alors la variable booléenne prend l’état . Algorithmiquement, un tel calcul d’une variable booléenne peut être réalisé via des parcours du graphe orienté pour chaque . Des exemples d’algorithmes pouvant être mis en œuvre, notamment par un ordinateur, pour réaliser un tel calcul d’une variable booléenne sont décrits ci-après. Un exemple d’un premier algorithme Algorithm 1 pour réaliser un calcul d’une variable est décrit ci-après. Un tel calcul d’une variable peut être réalisé sur les nœuds d’un . [Algorithm 1] Un exemple d’un deuxième algorithme Algorithm 2 pour réaliser un calcul est décrit ci-après. [Algorithm 2] Un exemple d’un troisième algorithme Algorithm 3 pour réaliser un calcul est décrit ci-après. [Algorithm 3] Un exemple d’un quatrième algorithme Algorithm 4 pour réaliser un calcul d’une variable a est décrit ci-après. Un tel calcul d’une variable peut être réalisé sur les nœuds d’un . [Algorithm 4] Un exemple d’un cinquième algorithme Algorithm 5 pour réaliser un calcul est décrit ci-après. Dans l’exemple qui suit, le calcul est réalisé sur un nœud . [Algorithm 5] La FIG. 4 illustre le résultat d’une deuxième étape E2 de calcul d’un niveau de confidentialité global du procédé mis en œuvre par le système de gestion de la FIG. 1 . Ce calcul consiste à identifier l’impact de contamination en confidentialité des entre elles lorsqu’elles partagent les mêmes unités de traitement, à savoir les enclaves. Il faut donc prévoir une possibilité de divulgation d’information d’une donnée d’une accessible dans une enclave par une donnée d’une autre et résultant d’un traitement en écriture par une fonction dans cette enclave. D’autre part, il faut aussi vérifier que le niveau de protection offert par une enclave soit supérieur au besoin de protection relative au niveau de confidentialité des données des réalisant des traitements sur ces enclaves. Il est décrit les calculs à réaliser dans ce procédé comme des règles d’inférence à appliquer sur les nœuds des du système afin de calculer, d’une part le niveau de besoin de protection effectif pour une enclave donnée, au regard des traitements de fonctions sur des données sur l’enclave d’autre part le niveau de confidentialité des données de en sortie de fonctions. Les règles d’inférence s’expriment comme suit : représentant les caractéristiques attachées à une enclave et étant invariants ; représentant la fonction à traiter en réception de la donnée reçue en entrée ; calculant le niveau de protection effectif de l'enclave à respecter pour assurer la protection des données transitant par cette enclave, la valeur de étant la valeur du niveau de confidentialité en entrée de la donnée à traiter ; calculant le niveau de confidentialité de la donnée après traitement par dans l'enclave. Le niveau de confidentialité de la donnée après traitement par dans l'enclave peut être le niveau de confidentialité en entrée de la donnée pour le nœud suivant du . indique une transmission de la donnée avec un niveau de confidentialité identique à celui de la donnée reçue. Lorsqu'il s'agit d’une fonction recevant et transmettant un flux, équivaut à . Le procédé peut comprendre une étape d’initialisation des nœuds des du système, notamment via une règle d’initialisation. Règle d’initialisation : Initialisation sur les enclaves. Cette règle est indépendante des et initialise les enclaves. (R init) Règle 1 : Règle appliquée à tous par des chaînes fonctionnelles dans le cas où . L’opérateur est appliqué sur les niveaux de confidentialité. Any Type signifie que la règle s’applique quel que soit le type de la fonction. (R1) Règle 2 : Règle appliquée à tout pas de pour lequel , c’est-à-dire au moins un chemin pour lequel il n’est pas possible de faire un contrôle d’intégrité sur la donnée entrante. (R2) Règle 3 : Règle pour laquelle quel que soit les pas d’exécution depuis la création de la donnée relative au , la donnée reçue en entrée du nœud est toujours signée et sans modification depuis la signature d’une part, et avec cette donnée non modifiée dont le contrôle d’intégrité est réalisé dans la suite de traitement sur le . (R3) Les modifications relatives aux fonctions de transit sont réalisées selon la capacité de chiffrement ou non des données en transit. Règle 4 : Règle sur le traitement pour les fonctions en transit, avant calcul des capacités de chiffrement. (R4) Algorithmiquement, ces règles s’appliquent sur les nœuds de tous les du système tant que la valeur des données d’entrée d’un nœud a son niveau de confidentialité qui change. Un exemple d’un tel algorithme est illustré ci-dessous : La FIG. 5 illustre le résultat d’une troisième étape E3 de calcul de directives de chiffrement et de déchiffrement pour la détermination d’une capacité de chiffrement et de déchiffrement de l'enclave. Il est exploité l’information issue des annotées d’informations de contrôle d’intégrité sous la forme d’une structure de Kripke afin d’exprimer les capacités de chiffrement comme résultat de satisfaction sur un état de cette structure exprimé par une propriété de logique temporelle. Dans un premier temps, il est complété le calcul des informations attachées aux nœuds des par le calcul, pour chaque niveau de confidentialité de pour capacité de mémorisation de chiffrement. Ce calcul se réalise par un parcours à rebours du graphe orienté des états tagués jusqu’aux états pour lesquels . Tous ces états sont initialisés . Si dans aucun de ces chemins aucun nœud n’a alors . Dans un second temps, il est regroupé l’ensemble des états attachés à une enclave du , puis partagé en autant d’états de la structure de Kripke que de parties d’arborescence distinctes. S’il y a plusieurs fonctions pour un état de la structure de kripke, nous retenons comme type attaché celui de create s’il y a un état de ce type, puis write s’il y a une fonction read, puis transit s’il n’y a que des fonctions de transit. Ce type est mémorisé pour un état de la structure de Kripke par une variable type. Le niveau de confidentialité en sortie de l’état de la structure de Kripke est mémorisé par une variable . Un état de la structure de Kripke mémorise aussi l’information i de l’enclave initiale du dont il est déduit. Les capacités de signature et de chiffrement appliquées aux données de la chaîne fonctionnelle sécurisée sont décrites en utilisant une représentation sous la forme de la structure Kripke suivante : pour laquelle : - est l’ensemble des états d’enclaves traversées par le . Ces enclaves portent l’identifiant de l’enclave, l’ensemble des fonctions du hôtes de l’enclave sous la forme d’un DAG. Ces fonctions hôtes partagent le même niveau de confidentialité appelé ; - est la fonction de transition entre les états d’enclaves ; - est l’état d’enclave portant la fonction de création de la chaîne fonctionnelle sécurisée ; - porte les attributs de l’état nécessaire pour la détermination d’application de directives de chiffrement et déchiffrement, à savoir les capacités de chiffrement/déchiffrement pour un niveau de confidentialité donné, la directive de contrôle d’intégrité , le niveau de confidentialité porté par les données de la chaîne fonctionnelle dans l’état d’enclave, ainsi que le type des fonctions de l’état d’enclave type ; - , un ensemble de fonctions booléennes appliquées aux attributs de l’état d’enclave, à savoir . Dans un premier temps, il est défini les fonctions booléennes qui vont s’appliquer sur les états d’enclaves. Une fonction retourne une valeur énumérée dans l’ensemble : . Le calcul de initialisé à est explicitée par la suite. La logique temporelle arborescente permet d’exprimer les propriétés suivantes : Une propriété est écrite sous la forme d’une propriété CTL appliquée aux états de . Cette propriété est vraie pour les états pour lesquels, pour un niveau de confidentialité , et que tous les chemins mènent à un état permettant un déchiffrement de données de confidentialité . Les états qui peuvent chiffrer leurs données et ensuite accèdent à des états validant peuvent appliquer le chiffrement. Une donnée produite par une fonction dans une enclave peut être chiffrée si elle peut accéder par un chemin à un état sans être modifiée, toutes les séquences de chemins à partir de cet état seront en transit jusqu’à un état où la donnée pourra être chiffrée. Cela correspond aux états satisfaisant la propriété CTL suivante : , pour les états de ces chemins, il est instancié, pour les états validant , pour les états validant , pour l’état validant Il est utile, pour une donnée reçue, de savoir si celle-ci peut être reçue en étant chiffrée, car cela permet de relâcher la contrainte de confidentialité de l’enclave qui la reçoit. Cela correspond aux états satisfaisant . Pour ces états, . Les règles d’inférence pour les états en transit sont ensuite complétées : Règle 5 : Nœud en transit pour les données reçues toujours chiffrées pour le niveau de confidentialité . (R5) L’information indique que la donnée a été reçue chiffrée en entrée d’enclave et que cette donnée chiffrée avec un niveau de protection en confidentialité de confère à cette donnée chiffrée un niveau de confidentialité de . Règle 5bis : Nœud en transit pour les données reçues toujours chiffrées mais pour un niveau de confidentialité inférieur à . (R5 bis) Dans le cas 5 bis, la donnée est chiffrée mais pas suffisamment pour considérer que le niveau de protection de la donnée à chiffrer puisse être de . Le niveau de confidentialité de est celui de la donnée avant chiffrement. Règle 6 : Nœud en transit pour les données reçues pouvant ne pas être chiffrées (R6) L’application de ces règles n’a d’impact que sur le niveau effectif de besoin de protection en confidentialité de l’enclave des fonctions en transit validant les conditions d’entrée. La FIG. 6 illustre le résultat d’une quatrième étape E4 de production de directives et de code de vérification de sécurité. Pour une chaîne fonctionnelle, dans le cadre de production de code, la donnée de la chaîne est tracée avec un identifiant de ladite chaine fonctionnelle. Cet identifiant est gardé à chaque étape de traitement de la chaîne fonctionnelle. Directive de satisfaction de contraintes de confidentialités des enclaves : Si pour une enclave , nous n’avons pas ou , alors une alerte est remontée indiquant une vulnérabilité du système. Directive de satisfaction des contraintes de chiffrement de données : Si la règle 5bis s’applique, il faut indiquer que le niveau de chiffrement de la donnée du dans l’enclave ne correspond pas au niveau de protection des données attendu. Directives de calcul d’intégrité. Production de code : Pour tous les nœuds du menant à des nœuds pour lesquels ou a , le calcul d’intégrité de la donnée doit être réalisé et ajouté à la donnée à transmettre. Un code de type est ajouté avant transmission à l’enclave suivante : si (donnée.cfs == identifiant_cfs) Signe(donnée.cfs) Pour un nœud pour lequel la donnée reçue vient d’une enclave pour lequel ou a et pour l’enclave courante, un calcul d’intégrité doit être réalisé avec vérification de non modification de la donnée. Un code de type est ajouté à la réception de l’enclave précédente : si (donnée.cfs ==identifiant_cfs), Check(donnée.cfs.signature, donnée.cfs) Directives de chiffrement. Production de code : Si pour une enclave donnée pour les données de Cas n° 1 : Si nous avons , alors il est réalisé le chiffrement de la donnée ainsi que sa signature. Si pour l’enclave suivante le code de est both : Si (donnée.cfs = = identifiant_cfs) chiffre (c, donnée.cfs) ; Transmet(donnée_chiffrée et donnée_en_clair) As received ou ciphered : si (donnée.cfs == identifiant_cfs) chiffre (c, donné.cfs) ; transmet(donnée_chiffrée) Cas n° 2 : Si nous avons : Si (données.cfs == identifiant_cfs) Transmet(donnée_chiffrée et donnée_en_clair) asReceived si (donnée.cfs == identifiant_cfs) transmet(donnée_chiffrée) none si (donnée.cfs == identifiant_cfs) transmet(donnée_en_clair) Cas n°3, nous avons pour l’enclave suivante le code de est soit , soit a . Cas n°4, nous avons pour l’enclave suivante le code de est soit , soit a . Cas n°5, nous avons pour l’enclave suivante le code de est soit soit a . Analyse d’incohérence et production de code : Dans les cas non répertoriés dans les directives de chiffrement précédentes, il s’agit de cas d’erreur à reporter. Dans le cas de réception de données sans identifiant de , il s’agit d’une erreur à reporter. Dans le cas de non mise à disposition de ressource de sécurité (signature, chiffrement) correspondant à ce qui est spécifié, il s’agit à reporter. Dans le cas de données dont l’identifiant où le statut de signature et chiffrement ne correspond pas à ce qui est attendu, une erreur doit être reportée. Les étapes du procédé de sécurisation peuvent être exécutées par un produit programme d’ordinateur ou logiciel comprenant des instructions de code de programme. Un tel logiciel réalise ainsi la transformation en liste de cfs et traitements décrits à partir de conceptions systèmes réalisés selon un l'outil de modélisation Capella. De telles conceptions systèmes sont notamment illustrés dans l’exemple de la FIG. 7 . Ce logiciel parse les éléments du modèle d'entrée de la vue physique en exploitant la description de séquences de traitements. Le logiciel est apte également à capturer les informations ajoutées et non définies dans Capella de niveau de confidentialité de ces chaînes et de niveau de protection et politique de gestion de la confidentialité des composants et canaux physiques de la vue physique du modèle. Le logiciel traduit alors ces éléments sous la forme de chaînes fonctionnelles. De telles chaîne fonctionnelles sont notamment illustrées dans l’exemple de la FIG. 8 . Ce logiciel capture aussi les informations ajoutées et non définies dans Capella de type de fonctions par-courues dans la description des séquences de fonctions. Les informations ajoutées sont des informations ajoutées du champ "summary" des éléments du modèle et interprétées par le logiciel qui réalise l'invention. Le logiciel transforme les informations du modèle d'origine en une représentation logicielle sous la forme de liste de chaînes fonctionnelles annotées d'informations issues d'une analyse de vulnérabilités telles que formalisées dans la description de l'invention. Il réalise les traitements de calcul de directives de contrôle d'intégrité, de calcul de niveau de protection en confidentialité des enclaves nécessaires à la sécurisation du système, du calcul des directives de chiffrement et de déchiffrement, de production d'une évaluation de respect de besoins de sécurité au regard des informations initales de description du système, ainsi que de codes de sécurisation du système à intégrer en ajout de l'implantation de la partie opérationnelle des fonctions afin de protéger en intégrité et confidentialité les échanges des données à protéger du système. Un tel logiciel peut être implanté dans un équipement matériel tel qu’illustré à la FIG. 9 . L’invention propose ainsi un procédé de sécurisation sur un système composé de traitements identifiés sur des actifs de données à sécuriser. Ces traitements sont réalisés sur une architecture de composants de traitements des données et de canaux de communication pour le transit de données entre composants. Ces élements d'architecture offrent pour chacun des niveaux de protection à la divulgation et des capacités de chiffrement et de calcul de signatures. Ce procédé identifie les violations de sécurité sur le système. Le procédé identifie également les traitements de chiffrement et de signature à réaliser pour sécuriser le système pour le traitement des données du système. Le procédé comprend ainsi une étape d'identification d'application de directives de signatures et de test d'intégrité, une étape de définition des besoins de protection des éléments d'architecture pour le traitement des données du système, une étape d'identification d'application de directives de chiffrement et de déchiffrement, une étape de production de directives de respect de contraintes de sécurité et de production de code de signature, test d'intégrité, chiffrement et déchiffrement sur le système et une étape de production de code de contrôle garantissant un comportement de l'implantation du système en cohérence avec la conception système annotée d'informations issues d'une analyse de vulnérabilité. L'étape d’identification d'application de directives de signatures et de tests d'intégrité comprend une étape d'identification des chemins de traitements sur les composants pour lesquels une donnée à sécuriser n'est pas modifiée. Au cours des chemins de traitements, les données à sécuriser peuvent être signées en amont ou en aval du traitement par ces composants. Une étape d'identification pour chaque pas de ces chemins est appliquée si la donnée peut être toujours signée avec une étape postérieure de calcul d'intégrité. L’étape de définition des besoins de protection des éléments d'architecture pour le traitement des données du système dudit procédé de sécurisation comprend une étape de traitement des composants pour lesquels les données sortantes prennent le niveau de confidentialité de protection du composant et une étape de définition du besoin de protection sur un composant dans lequel transitent différentes données à protéger. Cette dernière étape définit aussi l'impact du niveau de confidentialité de données sortantes d'un composant par le niveau de confidentialité d'autres données transitant dans le composant. Cette étape exploite les traitements de données dans des composants ne nécessitant jamais de modification de la donnée et donc non impactées par les autres données transitant dans le système. L'étape d'identification d'application de directives de chiffrement et de déchiffrement du procédé de sécurisation comprend : une étape d'identification de situations où une donnée peut transiter à partir d'un composant dans tous ses comportements possibles jusqu'à un composant dans lequel il peut être déchiffré sans qu'il ait été nécessaire que cette donnée soit lue ou modifiée, une étape d'identification des situations où il est possible de chiffrer une donnée et accéder à un état défini, une étape d'identification des situations où la donnée peut être chiffrée et ne sera pas modifiée avant d’accéder à l’étape d’identification de situations, une étape d'identification des situations où la donnée pourra toujours être chiffrée et ne sera pas modifiée avant d’accéder à l’étape d’identification de situations. L'étape de production de directives de respect de contraintes de sécurité et de production de code de signature, test d'intégrité, chiffrement et déchiffrement sur le système comprend une étape d'identification des violations de sécurité, ces violations étant des niveaux de protection des composants insuffisants, ces violations étant aussi des chiffrement de données garantissant un niveau de protection inférieur au niveau de protection attendu du fait de la criticité de la donnée à protéger, une étape de production de code de calcul de signature pour l'intégrer aux données à transmettre, puis aux données reçues pour le calcul d'intégrité, une étape de production de code de chiffrement et de déchifrement, de transmission de la donnée chiffrée, non chiffrée, ainsi que de déchiffrement. L'étape de production de codes de contrôles garantissant un comportement de l'implantation du système en cohérence avec la conception système annotée d'informations issues d'une analyse de vulnérabilité comprend une alerte émise dans les cas non répertoriés dans les directives de chiffrement, une alerte émise dans le cas de réception de données sans identifiant liées à un traitement de données, une alerte émise dans le cas de non mise à disposition de ressources de sécurité (signature, chiffrement) correspondant à ce qui est spécifié, une alerte émise dans le cas de données dont l'identifiant où le statut de signature et de chiffrement ne correspondent pas à ce qui est attendu. Procédé de sécurisation d’un ensemble d’opérations de traitements de données destiné à être appliqué à au moins un flux de données, ledit procédé comprenant une organisation d’un ensemble d’opérations de traitement des données du flux de données dans une pluralité d’enclaves ( , , , ) chaque enclave étant apte à réaliser une ou plusieurs opérations de traitement sur le flux de données, chaque enclave étant définie par : - un niveau de confidentialité ( , , ) de l’enclave ; - un type de protection (fixe, maximal) d’enclave, ledit type de protection comprenant au moins deux catégories, une première catégorie dite protection fixe pour laquelle toute donnée du flux de données en sortie de l’enclave est associée au niveau de confidentialité de l’enclave et une seconde catégorie dite protection maximale pour laquelle toute donnée de flux de données en sortie de l’enclave est associée à un niveau de confidentialité inférieure ou égale au niveau de confidentialité de l’enclave ; - une capacité de chiffrement et de déchiffrement de l’enclave ; - une ou plusieurs fonctions selon le flux de données, telle qu’une fonction de création, de transit, d’écriture ou de lecture. Procédé de sécurisation selon la revendication 1, dans lequel ledit procédé comprend : - une étape (E1) de calcul de directives de contrôle d’intégrité, ladite étape permettant d’associer à chaque enclave une première variable booléenne IC et une seconde variable booléenne AIC, ladite première variable booléenne IC étant associée à un contrôle d’intégrité de la donnée du flux de données entrant dans l’enclave, la seconde variable booléenne AIC étant associée à un contrôle de signature de la donnée du flux de données entrant dans l’enclave. Procédé de sécurisation selon la revendication 2, dans lequel ledit procédé comprend : - une étape (E2) de calcul d’un niveau de confidentialité global pour chaque enclave. Procédé de sécurisation selon l’une quelconque des revendications 1 à 3 dans lequel ledit procédé comprend : - une étape (E3) de calcul de directives de chiffrement et de déchiffrement pour la détermination d’une capacité de chiffrement et de déchiffrement pour chaque enclave. 5. Procédé de sécurisation selon l’une quelconque des revendications 1 à 4, dans lequel ledit procédé comprend : - une étape (E4) de production de directives de validation de règles de sécurité et de génération de code de contrôle. 6. Procédé de sécurisation selon l’une quelconque des revendications 1 à 5, dans lequel l’organisation de l’ensemble d’opérations de traitement des données du flux de données dans une pluralité d’enclaves ( , , , ) est réalisée à partir de données de conception (E0) obtenues via un outil de modélisation. Système de gestion d’évènements et d’informations de sécurité pour la mise en œuvre d’un procédé de sécurisation selon l’une quelconque des revendications 1 à 6. 8. Produit programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes d’un procédé de sécurisation d’un ensemble d’opérations de traitements de données destiné à être appliqué à au moins un flux de données selon l’une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté par un processeur.