Pourquoi devriez-vous passer à Connext DDS Secure

« La sécurité doit être intégrée, pas boulonnée. » Vrai. Vous l'avez entendu. Je l'ai entendu aussi. En fait, avec l'IIoT devenant rapidement une réalité, cette phrase est répétée tellement de fois que je crains qu'elle ne devienne un cliché qui crée un sentiment d'urgence sans réelle puissance. Mais pourquoi la sécurité est-elle souvent verrouillée pour commencer ? Comprendre les raisons nous aidera-t-il à l'éviter ? J'espere. Il existe de nombreuses raisons, allant d'économiques à réglementaires, éducatives et techniques, que je ne peux pas aborder en détail dans cet article de blog (voir l'IISF pour plus de détails).

Dans certains cas, le paysage des menaces, les risques associés et les considérations de sécurité n'ont pas été bien pensés lors du développement de l'architecture du système. Dans d'autres cas, les systèmes existants sont réutilisés pour fonctionner dans des conditions totalement différentes avec des menaces totalement différentes. Les analystes de la sécurité dédaignent souvent de tels efforts et c'est compréhensible. Cependant, la gestion de plus haut niveau est généralement amenée à prendre des décisions par les forces du marché, en accordant une priorité plus élevée à l'efficacité et aux fonctionnalités hautes performances. Peut-être que la sécurité est une surcharge dont vous pouvez vous soucier une fois que vous avez mis en route le système de base. Ou peut-être pensez-vous que votre système sera « à vide d'air ». Mais il est probablement trop tard à ce stade pour envisager la sécurité en raison du coût de la réarchitecture du système. Ainsi, on essaierait de faire de son mieux en ajoutant la sécurité plus tard après avoir fait fonctionner le système de base. Dans de nombreux cas, le processus d'ajout ultérieur de la sécurité n'est pas bien défini ou, dans les cas où il existe des meilleures pratiques connues, n'est pas correctement suivi. Pourquoi alors s'étonner du statut décevant de la sécurité dans l'IIoT ?

Une partie du défi de l'ingénierie de la sécurité consiste à concevoir des architectures qui offrent une protection acceptable contre les menaces de sécurité résultant d'erreurs, de malchance ou de malveillance tout en minimisant les frais généraux sur les fonctions commerciales et les performances du système. Cela semble facile, mais est assez difficile à réaliser dans la pratique – d'autant plus que les systèmes deviennent plus complexes et interdépendants et que des groupes de personnes plus larges et plus diversifiés travaillent à les réaliser. Pour les systèmes IIoT en particulier, les mesures de sécurité doivent être envisagées dans le cadre des contraintes plus larges d'interopérabilité, de performances, d'évolutivité, de résilience, de sécurité et de conformité, dans des environnements où les menaces de sécurité et les risques associés changent assez rapidement. Ces considérations ont été discutées et prises en compte dans le développement de la spécification de sécurité DDS et de Connext® DDS Secure de RTI.

Si vous êtes déjà un utilisateur de DDS ou si vous évaluez DDS pour le devenir, vous devez absolument envisager RTI Connext DDS Secure. Dans ce qui suit, j'expliquerai comment Connext DDS Secure permet des configurations de sécurité qui permettent aux architectes et aux ingénieurs de trouver le bon équilibre entre sécurité et performances, en fonction des risques de sécurité et des exigences de performances. Je fournirai également un exemple de projet de recherche qui vise à intégrer en toute sécurité des environnements cliniques afin d'améliorer considérablement les résultats pour les patients.

La sécurité DDS est-elle adaptée à votre cas d'utilisation ?

Les ingénieurs RTI utilisent généralement une règle empirique pour voir si l'architecture du système d'un client basé sur DDS a vraiment du sens, ou s'il est préférable d'utiliser un autre cadre de connectivité (voir IICF pour une discussion technique détaillée sur ce sujet). En général, si la réponse à au moins trois des cinq questions suivantes est « oui », DDS serait le cadre le plus approprié pour le système parmi les autres cadres de connectivité existants :

1. Est-ce un gros problème si votre système cesse de fonctionner pendant une courte période ?
2. Avez-vous dit « milliseconde » ou « microseconde » au cours des deux dernières semaines ?
3. Avez-vous plus de 10 ingénieurs logiciels ?
4. Envoyez-vous des données à plusieurs endroits, par opposition à un seul (par exemple, vers le cloud ou une base de données) ?
5. Mettez-vous en œuvre une nouvelle architecture IIoT ?

Si votre réponse à la question 1 est oui, vous avez des exigences strictes en matière de disponibilité et de tolérance aux pannes. DDS fournit déjà des fonctionnalités qui aident grandement à répondre à ces exigences, y compris un fonctionnement entièrement peer-to-peer (donc sans aucun point de défaillance unique) et plusieurs paramètres pertinents, notamment les politiques de propriété, de durabilité, de vivacité et de délai de QoS. De plus, DDS Security permet la ségrégation des domaines DDS, l'authentification des participants DDS, les autorisant à publier ou à s'abonner à des sujets DDS et l'authentification des messages DDS avant que les données ne soient transmises du middleware aux applications de niveau supérieur. Ces fonctionnalités permettent de prévenir et/ou d'atténuer considérablement l'impact de certaines classes d'attaques par déni de service (DOS). Ces fonctionnalités, associées à des mesures de contrôle d'accès appropriées au niveau du réseau, du système d'exploitation et des applications, offriraient une meilleure protection contre les attaques DoS potentielles dans les systèmes DDS.

Si votre réponse à la question 2 est oui, il est probable que vous ayez des besoins importants en temps réel. Dans de tels cas, vous souhaiterez affiner la sécurité de votre système DDS en fonction des exigences de risque et de performance. Par exemple, vous ne vous souciez peut-être pas qu'une lecture de température d'un capteur dans un espace public soit cryptée et transmise de manière confidentielle, mais vous vous souciez probablement de l'authenticité de ces lectures. DDS Security vous permet de définir et d'appliquer de telles configurations, sans apporter de modifications au code de votre application.

Une réponse positive à la question 3 signifie probablement que vous souhaitez minimiser le coût de l'interopérabilité entre les équipes de développement de logiciels travaillant chacune sur différents aspects d'un projet logiciel assez important. La conception centrée sur les données de DDS permet aux équipes logicielles de se mettre d'accord sur les données (c'est-à-dire les types et les sujets) qui doivent être distribuées et comment (c'est-à-dire avec quels paramètres de QoS), sans avoir nécessairement besoin d'exposer des API de traitement de données. De même, les configurations de sécurité DDS pour les plug-ins intégrés (par exemple, la gouvernance du domaine et les fichiers d'autorisation des participants) permettent de définir des politiques de sécurité pour la distribution des données. Ces politiques explicites sont créées en fonction de vos modèles de données et de la manière dont vous souhaitez protéger les domaines DDS. Ces politiques peuvent être examinées de manière indépendante par des ingénieurs de sécurité et des architectes système, et être réajustées en fonction de l'analyse des risques et des exigences de performances sans introduire de modifications dans le code de l'application.

Une réponse positive à la question 4 signifie probablement que vous souhaitez tirer le meilleur parti de la multidiffusion pour une livraison de données beaucoup plus efficace. Contrairement aux solutions de niveau de transport populaires telles que TLS/DTLS qui ne peuvent pas utiliser les avantages de la multidiffusion, la sécurité DDS est intégrée avec la prise en charge de la multidiffusion permettant une performance de livraison de données plus optimisée.

Si votre réponse à la question 5 est positive, vous avez la possibilité d'intégrer la sécurité sans trop vous soucier d'avoir à gérer du code hérité. Dans le même temps, vous avez probablement l'évolutivité, l'interopérabilité et évitez le verrouillage du fournisseur sur votre liste d'exigences. Le DDS est l'une des technologies de connectivité de base pour l'IIoT (voir IICF pour plus de détails) et est basé sur un ensemble de spécifications accessibles au public. De plus, DDS Security utilise une architecture enfichable avec des API standardisées pour l'authentification, l'autorisation, la cryptographie, le marquage des données et la journalisation. Ces fonctionnalités, associées à la prise en charge de politiques de sécurité explicites et granulaires pour la distribution des données, font de DDS un candidat solide pour les systèmes IIoT de nouvelle génération, permettant de concevoir la sécurité dans l'architecture de votre système, et non sur celle-ci.

Tout cela semble intéressant, mais est-ce que quelqu'un utilise DDS Security ? La réponse est un oui fort. RTI Connext DDS Secure a déjà été évalué et utilisé par un certain nombre de nos clients commerciaux et gouvernementaux. Nous avons reflété les commentaires que nous avons reçus de ces premiers utilisateurs dans notre gamme de produits. Dans les cas où des éclaircissements ou des mises à jour supplémentaires ont été nécessaires pour la spécification de sécurité DDS, nous avons signalé les problèmes à la communauté DDS afin d'améliorer encore la norme.

Exemple :Sécurité DDS pour une interopérabilité sécurisée des dispositifs médicaux

Un exemple intéressant qui montre les avantages de DDS et de DDS Secur

[1] [2] 下一页