L’Internet des objets (IoT) continue de susciter l’intérêt. Et si les gadgets destinés au grand public ont tendance à faire la une, je trouve bien plus fascinant le travail de préparation mené en coulisses dans les centres de données par les premiers utilisateurs.
Sans doute parce qu’il reste beaucoup de travail à accomplir pour soutenir une initiative IoT à grande échelle. Et lorsqu’un « objet » cible le grand public, un déploiement IoT à petite échelle, ça n’existe pas vraiment. Car, au cas où vous ne l’auriez pas remarqué, il y a énormément de consommateurs. Et ils adorent tout ce qui brille.
Dans cette optique, le secteur technologique multiplie actuellement les initiatives pour accompagner aussi bien ceux qui intègrent l’IoT à des produits existants (voitures, appareils électroménagers, jouets) que ceux qui espèrent révolutionner le marché avec de tout nouveaux objets dont vous ignoriez avoir besoin avant de les essayer.
Vraiment. Si le secteur public arrive en tête des secteurs qui investissent dans l’IoT (selon notre rapport « État des lieux de la fourniture d’applications » 2016), les télécommunications, les technologies et les fournisseurs de services cloud ne sont pas loin derrière. En réalité, tous les secteurs ont affiché un taux d’achat plutôt élevé au cours des douze mois précédents, ce qui indique que les activités liées à l’IoT sont bien plus importantes qu’il n’y paraît lorsqu’on observe uniquement le marché grand public.
Une grande partie de cette activité se déroule au niveau de l’infrastructure, dans le réseau qui assure la connectivité et permet aux applications back-end de réagir immédiatement pour gérer, mesurer, surveiller et sécuriser ces adorables petites puces intégrées à l’ours en peluche préféré de votre enfant, mais aussi interagir avec elles.
Comme toute application ou tout client (car c’est bien ce que sont ces objets distants : des clients), ils ont besoin d’un ensemble de services de base pour fonctionner de manière cohérente, prévisible et fiable. Plus précisément, ils ont besoin de services assurant la sécurité, la distribution et la visibilité.
Sécurité
La sécurité est généralement le dernier aspect auquel nous nous intéressons lorsqu’une nouvelle technologie apparaît. Je vais donc commencer par là, car de nos jours, ce sont les failles de sécurité qui attirent le plus l’attention, même pour une technologie encore émergente comme l’IoT.
Les objets doivent communiquer avec les applications back-end. Qu’il s’agisse d’enregistrer des données, de récupérer des mises à jour ou des correctifs, ou encore de modifier des configurations, les objets doivent communiquer de manière sécurisée avec les applications back-end. Cela implique la prise en charge de tunnels sécurisés via SSL ou TLS. Il faut utiliser le protocole HTTP sécurisé, et non du texte en clair, et surtout ne pas coder les clés en dur dans vos objets. Je suis très sérieux sur ce point. Ne le faites pas.
La sécurité passe aussi par la vérification de l’identité. Oui, je sais que cet objet est une voiture, mais c’est la voiture de *qui* ? Nous avons besoin de services capables d’identifier rapidement et précisément les objets et de les associer à leurs utilisateurs et propriétaires autorisés, afin de réduire le risque que mon voisin décide de régler mon autoradio sur autre chose qu’une station de heavy metal. Quelle horreur !
Enfin, la sécurité passe également par l’analyse des protocoles. C’est particulièrement important compte tenu des nouveaux protocoles dont la normalisation est envisagée dans l’ensemble de l’univers de l’IoT. Les failles de sécurité des protocoles peuvent présenter un risque important (vous vous souvenez peut-être de Heartbleed) et sont généralement difficiles à corriger rapidement. La capacité à détecter les utilisations abusives potentielles des protocoles permet de réduire les risques en amont.
Livraison
Les données, transactionnelles ou autres, doivent être transmises aux objets et aux applications back-end. Il ne suffit pas toujours d’envoyer un ensemble de données encodées en JSON vers une API REST quelconque. De nombreux objets parlent les nouveaux langages de l’IoT : MQTT, CoAP et AQMP. Mais leurs applications back-end respectives ? Elles utilisent REST, car elles permettent également aux applications web et mobiles d’accéder aux mêmes fonctionnalités et informations. Cela signifie qu’en définitive, le chemin de transmission comporte quelque part une passerelle, un traducteur, un intermédiaire assurant l’interopérabilité des protocoles.
Cela permet à l’objet installé dans votre voiture d’envoyer des données ou des messages via MQTT que l’application back-end utilisant REST peut comprendre. L’intermédiaire intercepte et traduit ces échanges (de manière sécurisée) afin d’assurer une communication fluide entre votre objet et ses applications. Imaginez l’intermédiaire comme C-3PO, et votre voiture (ou tout autre objet) comme R2-D2. Cela implique une prise en charge native des protocoles, ainsi qu’une approche définie par logiciel offrant une plateforme de script qui permet de développer rapidement la prise en charge d’autres protocoles. La création de scripts pour le chemin de données est l’un des trois composants clés de la programmabilité du réseau, mais c’est aussi celui dont on parle le moins. Dans le domaine de l’IoT, où il faudra probablement prendre en charge une grande variété de protocoles et de langages, la flexibilité offerte par cette fonctionnalité souvent méconnue sera inestimable.
J’ai évoqué précédemment la mise à l’échelle comme un élément à prendre en compte, et c’est ici, au niveau de la livraison, que cette exigence est satisfaite. Pour prendre en charge un million d’objets à grande échelle, par exemple, vous utiliserez probablement une architecture applicative fondée sur la décomposition. Il ne s’agira peut-être pas de microservices à part entière, mais vous séparerez vraisemblablement au moins les domaines fonctionnels afin de pouvoir faire évoluer les différentes fonctions selon une méthode plus efficace (et plus rentable).
C’est là qu’intervient une solution telle que l’équilibrage de charge basé sur les messages. Vous vous souvenez peut-être que ce concept a été évoqué dans le domaine des fournisseurs de services en lien avec des protocoles tels que Diameter et SIP, où il est impératif de garantir une mise à l’échelle efficace et rentable.
L’équilibrage de charge basé sur les messages est important, car des protocoles comme MQTT reposent sur des messages. Ils utilisent un modèle de publication-abonnement (publish-subscribe), semblable aux intergiciels orientés messages dont on a peut-être entendu parler et qui sont profondément intégrés aux systèmes de l’entreprise. Quoi qu’il en soit, ces protocoles reposent sur des messages, lesquels doivent être analysés et envoyés au service ou à l’appareil approprié. Pour y parvenir tout en assurant la montée en charge, le service d’équilibrage de charge doit être capable d’analyser le message et de déterminer où l’envoyer, puis de sélectionner une ressource appropriée pour le traiter.
C’est loin d’être aussi simple qu’il n’y paraît, car les répartiteurs de charge de base disposent de capacités limitées d’analyse des applications. Pourtant, cette fonctionnalité sera indispensable pour permettre la mise à l’échelle des protocoles privilégiés par les appareils IoT.
Visibilité
Enfin, l’infrastructure doit permettre une visibilité suffisante. Cela signifie qu’elle doit permettre de voir ce qui se passe. C’est la visibilité sur les transactions sécurisées (inspection SSL) qui permet aux équipes de sécurité d’intervenir et d’identifier les acteurs malveillants. C’est également la visibilité sur les habitudes d’utilisation qui peut déclencher la mise à l’échelle automatique des services appropriés.
La visibilité ne se limite pas au « big data » fournissant de puissantes analyses opérationnelles : elle englobe également la création de rapports et la journalisation. Le dépannage va devenir particulièrement ardu dans ces architectures complexes, et la journalisation sera essentielle, tant pour les outils que pour les personnes, afin de remonter à la source du problème.
La mise à l’échelle et la prise en charge de l’IoT ne concernent pas uniquement les objets connectés. Il reste beaucoup à faire au niveau du réseau, de l’infrastructure et des cadres opérationnels nécessaires à son fonctionnement. La bonne nouvelle, c’est que si vous faites partie de ceux qui travaillent sur les architectures back-end — ô combien importantes — destinées à prendre en charge un objet connecté particulièrement intéressant, vous pourrez toujours faire valoir qu’il vous en faut un (ou trois) pour effectuer des tests.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.