Domaine technique de l'invention

La présente invention se rapporte à un système de sécurité pour un système de contrôle industriel.

Etat de la technique

Un système de contrôle industriel (ICS pour « Industrial Control System ») désigne de manière générale un système de contrôle employé dans le domaine industriel et incluant des solutions de supervision de type SCADA, des solutions de contrôle distribués (DCS pour « Distributed control Systems ») ou toute autre solution incluant notamment un ou plusieurs contrôleurs logiques programmables (PLC pour « Programmable Logic Controller »). Un système de contrôle industriel est notamment destiné à configurer, superviser et gérer des infrastructures critiques telles que par exemple celles liées à une centrale de production électrique, une centrale nucléaire, une usine de traitement d'eau, des solutions d'extraction minière ou de gaz, un process de fabrication pharmaceutique ou chimique. Le système comporte ainsi une ou plusieurs entités matérielles et/ou entités logicielles installées et accessibles à travers un ou plusieurs portails de sécurité. Une entité matérielle peut être un contrôleur logique programmable (PLC), un capteur, un actionneur... Une entité logicielle est par exemple un logiciel mis en œuvre pour configurer, gérer, commander ou superviser le système et une ou plusieurs de ses entités matérielles définies ci-dessus.

Compte tenu de l'aspect critique des infrastructures décrites ci-dessus, la sécurité informatique est devenue un enjeu majeur pour protéger le système de toute intrusion malveillante.

Aujourd'hui, la sécurité de chaque entité matérielle ou entité logicielle du système est gérée de manière indépendante de sorte qu'un utilisateur doit se connecter à chaque fois, en fournissant des données d'identité (par exemple Login et mot de passe) et en justifiant de droits d'accès spécifiques, qu'il souhaite accéder à une entité matérielle ou une entité logicielle distincte du système de contrôle industriel.

Le document WO2006/059195A1 décrit une architecture de gestion d'énergie sécurisée comportant plusieurs dispositifs électroniques intelligents connectés entre eux. Le but de l'invention est de proposer un système de sécurité pour système de contrôle industriel permettant d'éviter à un utilisateur de se connecter à chaque fois qu'il souhaite accéder à une entité matérielle et/ou une entité logicielle du système de contrôle industriel. La solution de l'invention permet de gérer les données d'identité de chaque utilisateur ou entité matérielle du système, originaire d'action dans le système, ainsi que le contrôle d'accès aux ressources des différentes entités du système.

Ce but est atteint par un système de sécurité pour un système de contrôle industriel qui comporte une ou plusieurs entités matérielles et/ou une ou plusieurs entités logicielles accessibles par au moins un utilisateur à travers au moins un portail de sécurité, le système de sécurité comportant :

- une base de données de sécurité agencée pour mémoriser :

- des données d'identité associés à chaque utilisateur et entité matérielle,

- des données de droits d'accès à chaque entité matérielle ou entité logicielle du système,

- des jetons de sécurité générés pour chaque utilisateur et chaque entité matérielle, chaque jeton de sécurité comprenant les données signées par un serveur de sécurité et relatives à l'identité de l'utilisateur ou de l'entité matérielle et les données de droits d'accès attribués à l'utilisateur ou à l'entité matérielle,

- un serveur de sécurité comprenant :

- un module de vérification dans la base de données de sécurité des données d'identité d'un utilisateur ou d'une entité matérielle,

- un module de génération de jetons de sécurité pour chaque utilisateur ou entité matérielle identifié dans la base de données de sécurité,

- un module de gestion des données d'identité de chaque utilisateur, entité matérielle stockée dans la base de données de sécurité,

- un module de gestion des données de droits d'accès stockées dans la base de données de sécurité,

- Chaque entité matérielle ou entité logicielle comporte un agent logiciel comprenant :

- un module de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité, d'une entité logicielle ou d'une autre entité matérielle, - un module d'analyse des droits d'accès de l'utilisateur, d'une autre entité logicielle ou d'une autre entité matérielle,

- un module de réception de jeton de sécurité agencé pour recevoir et mémoriser chaque jeton reçu et pour signer le jeton de sécurité reçu d'un portail de sécurité ou d'une première entité matérielle et pour transférer ce jeton signé vers une deuxième entité matérielle ou logicielle à laquelle le portail de sécurité ou la première entité matérielle souhaite accéder.

Selon une particularité, chaque agent logiciel comporte un module de gestion de clés cryptographiques agencé pour la génération, l'échange, le stockage, l'utilisation et le remplacement de clés cryptographiques nécessaires pour signer un jeton de sécurité ou pour le décrypter.

Selon une autre particularité, chaque agent logiciel comporte une ou plusieurs librairies cryptographiques.

Selon une autre particularité, l'agent logiciel d'une entité matérielle comporte un module d'authentification agencé pour envoyer l'identité de l'entité matérielle vers le serveur de sécurité pour recevoir de sa part un jeton de sécurité.

Brève description des figures

D'autres caractéristiques et avantages vont apparaître dans la description détaillée qui suit faite en regard des dessins annexés dans lesquels :

la figure 1 représente de manière schématique, l'architecture du système de sécurité de l'invention employé pour sécuriser un système de contrôle industriel,

la figure 2 illustre la procédure d'enregistrement d'un utilisateur et d'ajout d'une entité matérielle dans le système de sécurité de l'invention, la figure 3 illustre la procédure d'enrôlement d'une entité matérielle et d'authentification de cette entité,

la figure 4 illustre la procédure d'authentification d'un utilisateur et d'accès à une entité logicielle par un utilisateur,

la figure 5 illustre la procédure d'accès d'un utilisateur à une entité matérielle via une entité logicielle,

la figure 6 illustre la procédure d'accès d'une entité matérielle à une autre entité matérielle, la figure 7 illustre la procédure de mise à jour d'un jeton de sécurité, les figures 8A et 8B représentent deux architectures distinctes d'un jeton de sécurité.

Description détaillée d'au moins un mode de réalisation

Comme décrit ci-dessus, un système de contrôle industriel est par exemple destiné à gérer une infrastructure critique et comporte une ou plusieurs entités matérielles et/ou une ou plusieurs entités logicielles. Une entité matérielle est par exemple un contrôleur logique programmable, un capteur, un actionneur... Une entité logicielle est par exemple destinée à gérer la configuration et/ou le fonctionnement d'une ou plusieurs entités matérielles du système.

Selon la configuration du système, plusieurs cas d'interaction entre utilisateur, entité matérielle 5 et entité logicielle 6 peuvent se présenter :

- l'utilisateur 1 peut être amené à se connecter à une entité matérielle 5 ou une entité logicielle 5 du système via un portail de sécurité 10,

- une entité matérielle 5a ou une entité logicielle 6a peut être amenée à se connecter à une autre entité matérielle 5b ou à une autre entité logicielle 6b.

Chacun de ces cas de fonctionnement sera décrit ci-dessous, en liaison avec le système de sécurité de l'invention.

Le système de sécurité de l'invention comporte principalement les éléments suivants :

- une base de données de sécurité 4,

- un serveur de sécurité 3,

- des agents logiciels 50, 60 associés chacun à une entité matérielle 5 ou à une entité logicielle 6 distincte.

La base de données de sécurité 4 est destinée à stocker différents types de données de sécurité :

- des données d'authentification 40, - des données d'autorisation 41 ,

- des données 42 liées à la politique de sécurité mise en œuvre pour le système.

Dans les données d'authentification 40, on retrouve :

- pour chaque utilisateur, un identifiant, un mot de passe et un jeton de sécurité,

- pour chaque entité matérielle, un identifiant, un certificat et un jeton de sécurité.

Dans les données d'autorisation 41 , on retrouve :

- pour chaque entité matérielle et entité logicielle du système, des données liées à leurs droits d'accès vers chaque entité matérielle et vers chaque entité logicielle du système,

Dans les données 42 liées à la politique de sécurité, on retrouve :

- pour chaque utilisateur 1 et entité matérielle 5 du système, un fichier sous un format adapté, par exemple XACML (pour extensible Access Control Markup Language), pour résumer les autorisations associées à chaque utilisateur 1 ou entité matérielle 5 du système ainsi qu'une copie du jeton de sécurité associé.

Pour chaque utilisateur 1 et entité matérielle 5 du système, le jeton de sécurité correspond au fichier XACML décrit ci-dessus, horodaté et signé par le serveur de sécurité 3.

Le serveur de sécurité 3 est destiné notamment à gérer l'authentification de chaque utilisateur 1 et chaque entité matérielle 5 du système. Il comporte ainsi :

- un module 30 de gestion des données d'authentification de chaque utilisateur 1 , stockées dans la base de données de sécurité 4, destiné à vérifier les données d'authentification de chaque utilisateur, un module 31 de gestion des données d'authentification de chaque entité matérielle 5 du système, stockées dans la base de données de sécurité 4, destiné à vérifier le certificat de chaque entité matérielle,

un module 32 de gestion des données liées aux droits d'accès de chaque utilisateur 1 et chaque entité matérielle 5 du système, stockées dans la base de données de sécurité 4,

un module 33 de gestion des jetons de sécurité attribués à chaque utilisateur et chaque entité matérielle du système, notamment pour réaliser la signature et l'horodatage à la génération de chaque jeton de sécurité, une interface administrateur 34 permettant notamment à un administrateur, à l'aide d'un outil logiciel d'administration, d'enregistrer des nouveaux utilisateurs et de nouvelles entités matérielles, de saisir les droits d'accès aux différentes entités matérielles et entités logicielles du système ainsi que la configuration et l'attribution des droits d'accès à chaque utilisateur et chaque entité matérielle.

Chaque entité matérielle 5 comporte un agent logiciel 50 dont la responsabilité est de gérer toutes les opérations de sécurité liées à l'entité matérielle à laquelle il est associé. Pour une entité matérielle 5, un tel agent logiciel 50 comporte :

- un module 500 de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité 10, d'une entité logicielle 6 ou d'une autre entité matérielle 5,

- un module 501 d'analyse des droits d'accès de l'utilisateur 1 , d'une entité logicielle 6 ou d'une autre entité matérielle 5 après décryptage et lecture d'un jeton de sécurité reçu,

- un module 502 de réception de jeton de sécurité agencé pour recevoir et mémoriser chaque jeton reçu et pour signer le jeton de sécurité reçu d'un portail de sécurité 10 ou d'une première entité et pour transférer ce jeton signé vers une deuxième entité à laquelle le portail de sécurité 10 ou la première entité souhaite accéder,

- un module 503 de gestion de clés cryptographiques agencé pour la génération, l'échange, le stockage, l'utilisation et le remplacement de clés cryptographiques, - une ou plusieurs librairies cryptographiques 504 telles que par exemple OpenSSL,

- un module 505 d'authentification agencé pour envoyer l'identité (certificat) de l'entité matérielle vers le serveur de sécurité 3 pour recevoir de sa part un jeton de sécurité.

Chaque entité logicielle 6 comporte également un agent logiciel 60 dont la responsabilité est de gérer toutes les opérations de sécurité liées à l'entité logicielle 6 à laquelle il est associé. Cet agent comporte :

- un module 600 de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité, d'une entité matérielle ou d'une autre entité logicielle,

- un module 601 d'analyse des droits d'accès de l'utilisateur, d'une entité matérielle ou d'une autre entité logicielle après décryptage et lecture d'un jeton de sécurité reçu,

- un module 602 de réception de jeton de sécurité agencé pour recevoir, mémoriser chaque jeton reçu et pour signer le jeton de sécurité reçu d'un portail de sécurtié ou d'une première entité et pour transférer ce jeton signé vers une deuxième entité à laquelle le portail de sécurité ou la première entité souhaite accéder,

- une ou plusieurs librairies cryptographiques 603 telles que par exemple OpenSSL.

Dans chaque entité matérielle 5 ou logicielle 6 du système, le module 501 , 601 d'analyse des droits d'accès analyse l'architecture du fichier XACML qui comporte un point d'application de la décision (PEP pour « Policy Enforcement Point ») et un point de décision de la politique (PDP pour « Policy Décision Point »).

Les figures 8A et 8B montrent l'architecture d'un jeton de sécurité, respectivement lorsque celui-ci est issu du serveur de sécurité et lorsque celui-ci est transmis par un agent logiciel. Sur la figure 8A, le jeton de sécurité transmis par le serveur de sécurité est un fichier qui comporte les données suivantes :

- des données 80 d'horodatage spécifiant la date de création du fichier,

- la duré de validité 81 du jeton de sécurité,

- des données 82 d'identité de l'utilisateur 1 ou de l'entité matérielle 5 associé au jeton de sécurité,

- des données 83 d'identification de l'organisme ayant généré le fichier,

- les données 84 liées aux droits d'accès de l'utilisateur 1 ou de l'entité matérielle 5 concerné,

Ce fichier est signé (signature 85) par le serveur de sécurité 3 à l'aide d'une clé privée afin de générer le jeton de sécurité.

Sur la figure 8B, le jeton de sécurité transmis par un agent logiciel 50, 60 d'une entité matérielle 5 ou d'une entité logicielle 6, consiste dans le jeton de sécurité décrit ci-dessus qui est en plus signé (signature 86) par l'agent logiciel 50, 60 afin de pouvoir être authentifié par le récepteur.

Le système de sécurité peut comporter une autorité de certification 7 destinée notamment à fournir les certificats pour chaque entité matérielle et logicielle du système. L'autorité de certification est en interaction avec le serveur de sécurité pour fournir, sur demande du serveur de sécurité, chaque certificat associé à une entité matérielle et logicielle du système. Les certificats sont stockés dans une base de données gérée par l'autorité de certification. L'autorité de certification 7 dispose également de moyens pour générer de nouveaux certificats et pour vérifier si les certificats de chaque entité matérielle et logicielle sont à jour.

Pour crypter les données échangées, le système de sécurité de l'invention utilise un système classique de cryptage basé sur un mécanisme de clé publique et de clé privée, par exemple TLS/SSL.

La figure 2 illustre le principe d'enregistrement d'un utilisateur 1 et d'une entité matérielle 5 d'un système par un administrateur 2 connecté au serveur de sécurité à travers l'outil logiciel d'administration 20 exécuté sur un poste informatique. Pour toute tâche d'administration, l'administrateur 2 doit d'abord s'identifier (A1 ) auprès du serveur de sécurité 3 via l'outil logiciel d'administration 20. Pour l'ajout d'un utilisateur 1 , la procédure suit les étapes suivantes :

- A2 : l'administrateur 2 envoie au serveur de sécurité 3 une requête d'ajout d'un utilisateur 1 , accompagnée des données d'identification de l'utilisateur 1 ,

A3 : le serveur de sécurité 3 émet une commande d'écriture des données d'identification relatives à l'utilisateur 1 dans la base de données de sécurité 4,

- A4 : La base de données de sécurité 4 confirme au serveur de sécurité 3 l'ajout de l'utilisateur 1 ,

- A5 : Le serveur de sécurité 3 confirme l'ajout de l'utilisateur dans la base de données de sécurité 4.

Pour l'ajout d'une entité matérielle 5, la procédure comporte les étapes suivantes :

B1 : via, l'outil logiciel d'administration 20, l'administrateur 2 envoie au serveur de sécurité 3 une requête d'ajout d'une entité matérielle 5,

B2 : le serveur de sécurité 3 envoie une requête à l'autorité de certification 7 en vue d'obtenir le certificat de l'entité matérielle 5 à enregistrer,

B3 : l'autorité de certification 7 renvoie le certificat requis,

B4 : le serveur de sécurité 3 envoie une commande d'écriture des données d'identification, notamment le certificat obtenu, liées à l'entité matérielle 5 dans la base de données de sécurité 4,

B5 : la base de données de sécurité 4 confirme l'enregistrement de l'entité matérielle,

B6 : le serveur de sécurité confirme l'ajout de l'entité matérielle à l'administrateur.

La figure 3 illustre la procédure d'enrôlement d'une entité matérielle 5 et son authentification : C1 : via l'interface administrateur du serveur de sécurité 3, l'administrateur 1 lance une commande de type « Discover » du serveur de sécurité en vue de déterminer les entités matérielles du système,

C2 : le serveur de sécurité 3 envoie une requête de demande de certificat à l'agent logiciel 50 d'une entité matérielle 5 du système,

C3 : le module d'authentification 505 de l'agent logiciel 50 de l'entité matérielle 5 répond à la requête par l'envoi de son certificat,

C4 : le serveur de sécurité 3 vérifie le certificat de l'entité matérielle 5, si le certificat est valide :

- C5 : l'entité matérielle 5 est authentifiée,

si le certificat n'est pas valide :

- C6 : l'administrateur 2 émet une requête d'ajout de l'entité matérielle 5 à destination du serveur de sécurité 3,

- C7 : le serveur de sécurité 3 envoie une requête d'enrôlement au module d'authentification de l'agent logiciel 50 de l'entité matérielle avec l'adresse de l'autorité de certification 7 en vue d'obtenir un certificat auprès de l'autorité de certification 7,

- C8 : l'agent logiciel 50 de l'entité matérielle 5 émet une requête à destination de l'autorité de certification 7, par exemple sous la forme d'une requête basée sur le protocole SCEP (« Simple Certificate Enrollment Protocol »), en vue d'obtenir un certificat valide,

- C9 : l'autorité de certification 7 génère un certificat pour l'entité matérielle 5 et répond à la requête par envoi du certificat à destination de l'agent logiciel 50 de l'entité matérielle 5,

- C10 : le module d'authentification de l'agent logiciel 50 de l'entité matérielle 5 renvoie le certificat obtenu au serveur de sécurité 3,

- C1 1 : le serveur de sécurité 3 valide l'authentification de l'entité matérielle 5 auprès de l'administrateur 2.

C12 : l'administrateur 2, à partir de l'outil logiciel d'administration 20, saisit les données de configuration de l'entité matérielle 5, notamment les données liées aux droits d'accès de cette entité matérielle, C13 : l'administrateur 2 émet une requête d'enregistrement des données de configuration de l'entité matérielle à destination du serveur de sécurité 3 en vue de la création du fichier XACML pour l'entité matérielle 5,

C14 : l'administrateur émet ensuite une requête à destination du serveur de sécurité pour la génération du jeton de sécurité,

C15 : le serveur de sécurité 3 génère le jeton de sécurité grâce à son module de gestion,

C16 : le serveur de sécurité 3 distribue le jeton de sécurité à destination de l'entité matérielle,

C17 : le module de réception de l'entité matérielle mémorise le jeton reçu.

La figure 4 illustre la procédure d'accès d'un utilisateur à une entité logicielle. Cette procédure comporte les étapes suivantes :

D1 : l'utilisateur 1 lance une entité logicielle 6 du système,

D2 : l'entité logicielle 6 demande à son agent logiciel 60 d'authentifier cet utilisateur 1 et de vérifier ses droits d'accès,

D3 : l'agent logiciel 60, par l'intermédiaire de son module de vérification, vérifie le jeton de sécurité de l'utilisateur 1 ,

- si le jeton de sécurité est valide :

D4 : l'entité logicielle s'exécute.

- si le jeton de sécurité n'est pas valide :

D5 : l'agent logiciel envoie une requête à destination du portail de sécurité en vue d'obtenir le jeton de sécurité actuel associé à l'utilisateur,

D6 : si le portail de sécurité détient un jeton de sécurité pour cet utilisateur :

D7 : le portail de sécurité envoie le jeton de sécurité à destination de l'agent logiciel de l'entité logicielle,

D8 : le module de vérification de l'agent de l'entité logicielle vérifie le jeton de sécurité reçu pour authentification, D8 : le module d'analyse de l'agent logiciel de l'entité logicielle vérifie les droits d'accès de l'utilisateur,

D9 : si l'utilisateur est authentifié et ses droits d'accès validés, l'entité logicielle s'exécute,

le portail de sécurité ne détient pas de jeton :

D10 : le portail de sécurité demande à l'utilisateur de renseigner ses données d'identité (identifiant, mot de passe),

D1 1 : L'utilisateur renseigne ses données d'identité,

D12 : le portail de sécurité émet une requête à destination du serveur de sécurité en vue d'obtenir un jeton de sécurité en émettant les données d'identité de l'utilisateur,

D13 : le serveur de sécurité vérifie les données d'identité reçues auprès de la base de données de sécurité :

D14 : si les données d'identité ne sont pas inscrites dans la base de données de sécurité :

D15 : le serveur de sécurité émet une réponse négative à destination du portail de sécurité,

D16 : la procédure d'authentification a échoué.

D17 : si les données d'identité sont inscrites dans la base de données de sécurité :

D18 : le serveur de sécurité envoie une requête à la base de données de sécurité en vue d'obtenir les données liées aux droits d'accès de l'utilisateur, c'est- à-dire le fichier XACML associé à cet utilisateur,

D19 : La base de données de sécurité 4 renvoie les données liées aux droits d'accès de l'utilisateur sous la forme du fichier XACML,

D20 : sur la base du fichier XACML reçu, le serveur de sécurité génère le jeton de sécurité,

D21 : le serveur de sécurité envoie le jeton de sécurité généré à destination du portail de sécurité, D22 : le portail de sécurité transfère le jeton de sécurité à l'agent logiciel de l'entité logicielle,

D23 : le module de vérification de l'agent de l'entité logicielle vérifie le jeton de sécurité reçu pour authentification de l'utilisateur et vérification de ses droits d'accès,

D24 : si l'utilisateur 1 est authentifié et ses droits d'accès validés, l'entité logicielle 6 s'exécute.

La figure 5 illustre la procédure mise en œuvre pour l'accès d'un utilisateur à une entité matérielle 5 à travers une entité logicielle 6. La procédure comporte les étapes suivantes :

E1 : l'utilisateur 1 émet une requête à destination de l'entité logicielle 6 en vue de réaliser une opération sur une entité matérielle 5,

E2 : l'entité logicielle 6 demande à l'entité matérielle 5 l'établissement d'un canal de communication sécurisé (Par exemple sous le protocole TLS pour Transport Layer Security),

E3 : l'entité matérielle 5 établit un canal de communication sécurisé avec l'entité logicielle 6,

E4 : l'agent logiciel 60 de l'entité logicielle 6 signe le jeton de sécurité de l'utilisateur 1 et l'envoie à destination de l'agent logiciel 50 de l'entité matérielle 5,

E5 : Le module de vérification de l'agent logiciel 50 de l'entité matérielle 5 vérifie le jeton de sécurité reçu.

E6 : si le jeton de sécurité est valide, l'opération peut être réalisée sur l'entité matérielle 5.

- si le jeton de sécurité est invalide :

E7 : l'agent logiciel de l'entité matérielle émet une réponse à l'agent logiciel de l'entité matérielle pour lui signaler la non- validité,

E8 : l'agent logiciel de l'entité logicielle demande une mise à jour du jeton de sécurité au portail de sécurité de l'utilisateur, E9 : le portail de sécurité demande à l'utilisateur de renseigner ses données d'identité (identifiant, mot de passe),

E10 : l'utilisateur renseigne ses données d'identité,

E1 1 : le portail de sécurité émet une requête à destination du serveur de sécurité en vue d'obtenir un jeton de sécurité, accompagnée des données d'identité de l'utilisateur,

E12 : après lecture de la base de données de sécurité 4, le serveur de sécurité 3 envoie le jeton de sécurité généré à destination du portail de sécurité,

E13 : le portail de sécurité transfère le jeton de sécurité à l'agent logiciel de l'entité logicielle qui le transfère à l'agent logiciel de l'entité matérielle,

E14 : le module de vérification de l'agent logiciel de l'entité matérielle vérifie le jeton de sécurité reçu pour authentification, le module d'analyse de l'agent logiciel de l'entité matérielle vérifie les droits d'accès de l'utilisateur,

E6 : si le nouveau jeton de sécurité est valide, l'opération peut être réalisée sur l'entité matérielle.

La figure 6 illustre la procédure mise en place pour permettre à une première entité matérielle 5a d'accéder à une deuxième entité matérielle 5b. Elle comporte les étapes suivantes :

F1 : la première entité matérielle 5a demande à la deuxième entité matérielle 5b l'établissement d'un canal de communication sécurisé (Par exemple sous le protocole TLS pour Transport Layer Security),

F2 : la deuxième entité matérielle 5b établit un canal de communication sécurisé avec la première entité matérielle 5a,

F3 : l'agent logiciel de la deuxième entité matérielle 5b émet une requête à destination de l'agent logiciel de la première entité matérielle 5a en vue d'obtenir son jeton de sécurité, F4 : l'agent logiciel de la première entité matérielle 5a envoie son jeton de sécurité à destination de l'agent logiciel de la deuxième entité matérielle 5b,

F5 : le module de vérification de l'agent logiciel de la deuxième entité matérielle 5b vérifie le jeton de sécurité reçu,

- si le jeton de sécurité est valide :

F6 : l'agent logiciel de la deuxième entité matérielle analyse les droits d'accès de la première entité matérielle,

F7 : si ses droits d'accès sont validés, la première entité matérielle 5a peut émettre des commandes à destination de la deuxième entité matérielle 5b,

F8 : la deuxième entité matérielle 5a autorise l'accès de la première entité matérielle 5a selon ses droits d'accès,

F9 : si le jeton de sécurité est invalide :

F10 : l'agent logiciel de la deuxième entité matérielle demande un nouveau jeton de sécurité à la première entité matérielle,

F1 1 : l'agent logiciel de la première entité matérielle envoie une requête à destination du serveur de sécurité en vue d'obtenir une mise à jour de son jeton de sécurité,

F12 : le serveur de sécurité génère un nouveau jeton de sécurité à partir du fichier XACML, le serveur de sécurité horodatant et signant ledit fichier,

F13 : le serveur de sécurité envoie le nouveau jeton de sécurité à destination de l'agent logiciel de la première entité matérielle 5a,

F14 : l'agent logiciel de la première entité matérielle transfère le jeton de sécurité à destination de l'agent logiciel de la deuxième entité matérielle,

F15 : le module de vérification de l'agent logiciel de la deuxième entité matérielle vérifie le nouveau jeton de sécurité, F6 : si le nouveau jeton de sécurité est valide, l'agent logiciel de la deuxième entité matérielle analyse les droits d'accès de la première entité matérielle,

F7 : si ses droits d'accès sont validés, la première entité matérielle 5a peut émettre des commandes à destination de la deuxième entité matérielle 5b,

F8 : la deuxième entité matérielle 5a autorise l'accès de la première entité matérielle 5a selon ses droits d'accès,

La figure 7 illustre la procédure de mise à jour d'un jeton de sécurité appartenant à une entité matérielle. Un agent logiciel d'une entité matérielle ou logicielle qui a reçu un jeton de sécurité valide peut demander si le jeton de sécurité en sa possession est bien à jour. La procédure de vérification qu'un jeton de sécurité est à jour est réalisée sur des données représentatives d'une signature compressée du jeton de sécurité. Ainsi, seules ces données sont envoyées par une entité vers une autre. Cette procédure comporte les étapes suivantes :

- G1 : l'agent d'une première entité (matérielle sur la figure 7) demande une vérification du jeton de sécurité reçu à l'agent logiciel d'une deuxième entité (logicielle) présente dans la chaîne,

- G2 : si l'agent logiciel de la deuxième entité conclut à une différence, il renvoie une réponse à l'agent de la première entité,

- G3 : l'agent logiciel de la première entité demande à l'agent de la deuxième entité le jeton de sécurité à jour,

- G4 : l'agent logiciel de la deuxième entité envoie une demande au portail de sécurité pour savoir si le jeton de sécurité est à jour,

- G5 : après vérification, si le jeton de sécurité n'est pas à jour, le portail de sécurité envoie une réponse à l'agent logiciel de la deuxième entité indiquant que le jeton de sécurité n'est pas à jour,

- G6 : l'agent logiciel de la deuxième entité demande au portail de sécurité le jeton de sécurité à jour,

- G7 : le portail de sécurité envoie une demande au serveur de sécurité pour savoir si le jeton de sécurité est à jour, G8 : après vérification, si le jeton de sécurité n'est pas à jour, le serveur de sécurité envoie une réponse au portail de sécurité indiquant que le jeton de sécurité n'est pas à jour,

G9 : le portail de sécurité demande à l'utilisateur de saisir ses données d'identité,

G10 : l'utilisateur saisit ses données d'identité,

G1 1 : le portail de sécurité envoie une requête à destination du serveur de sécurité en vue d'obtenir un nouveau jeton de sécurité,

G12 : le serveur de sécurité répond au portail de sécurité par l'envoi d'un nouveau jeton de sécurité à destination du portail de sécurité.

La solution de l'invention présente ainsi de nombreux avantages, parmi lesquels :

Permettre la gestion des données d'identité de chaque utilisateur ou entité matérielle dans le système de contrôle industriel, d'une manière centralisée avec un impact limité sur les architectures des produits existants,

Permettre la gestion des autorisations et des droits d'accès de chaque utilisateur ou entité matérielle vers chaque entité matérielle ou logicielle du système,

- Sécuriser la communication entre les différentes entités du système, par l'échange direct des jetons de sécurité entre ces entités, sans passer par un serveur central, en utilisant notamment des techniques de cryptographie asymétrique,

- Couvrir tous les niveaux d'un système de contrôle industriel,

- Accéder à des ressources multiples à partir d'une authentification unique (« Single Sign On »).

Ainsi, grâce au système de sécurité de l'invention, un utilisateur s'authentifie une seule fois auprès du serveur de sécurité, puis toute authentification de l'utilisateur par les différentes entités revient à authentifier le jeton de sécurité qui lui a été associé. De même, un utilisateur ou une entité matérielle, muni d'un jeton de sécurité, a la capacité de faire des accès sécurisés à une ou plusieurs entités matérielles logicielles du système de manière directe ou indirecte sur plusieurs niveaux.