Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Azure Sphere expliqué simplement : la sécurité IoT du silicium au cloud avec Pluton, Linux durci et Security Service (Doublage IA)

Transcript

Azure Sphere expliqué simplement : la sécurité IoT du silicium au cloud avec Pluton, Linux durci et Security Service (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Prêt pour 10 jours de Microsoft 365 Copilot, l'IA, Azure
0:04
Speaker 2: et les personnes qui façonnent l'avenir du travail, du sac.
0:08
Speaker 2: En janvier, la M365Con est de retour et nous allons
0:11
Speaker 2: plus loin. Rejoignez-nous pour des sessions en direct, des démonstrations
0:15
Speaker 2: concrètes et des connaissances pratiques de MVP et d'experts du
0:17
Speaker 2: secteur du monde entier. Pas de diapositives génériques, pas de
0:20
Speaker 2: mots à la mode sans fin. Nous nous attaquons aux
0:22
Speaker 2: vrais défis. Copilot Studio, Agendia, Fabrique, Sécurité, Gouvernance et Automatisation, Hack.
0:30
Speaker 2: Que vous soyez un professionnel de l'informatique, un développeur ou
0:32
Speaker 2: un chef d'entreprise, des sessions sont conçues pour vous. Pendant
0:35
Speaker 2: dix jours complets, vous pouvez explorer de multiples technologies et
0:38
Speaker 2: vous connecter à une communauté mondiale. Regardez en direct et
0:42
Speaker 2: rapportez des informations pratiques à votre organisation
0:45
Speaker 2: Janvier 2027, dix jours, une communauté Microsoft. Les inscriptions sont
0:50
Speaker 2: ouvertes dès maintenant. Rendez-vous chez vous dès aujourd'hui. C'est m365con. net. One. net. com.
1:00
Speaker 2: Rejoignez-nous dès maintenant sur m365one. net et nous vous retrouverons en
1:03
Speaker 2: direct en janvier. Vous achetez un thermostat intelligent pour votre maison.
1:08
Speaker 2: Vous l'installez, vous le connectez au Wi-Fi et il fonctionne parfaitement.
1:11
Speaker 2: Vous pouvez régler la température depuis votre téléphone, il apprend
1:13
Speaker 2: votre emploi du temps, tout va bien. Jusqu'au jour où
1:16
Speaker 2: ce thermostat devient un élément d'un botnet qui attaque le
1:18
Speaker 2: réseau d'un hôpital à l'autre bout du monde. Cela vous
1:21
Speaker 2: semble dramatique? Ce n'est pas. C'est arrivé. Le botnet Mireille,
1:25
Speaker 2: en 2016, a mis hors service des pans entiers d'Internet
1:26
Speaker 2: en utilisant uniquement des caméras et des routeurs piratés. Et
1:29
Speaker 2: la raison pour laquelle ces appareils étaient vulnérables et simples,
1:31
Speaker 2: ils n'ont jamais été conçus pour être sécurisés en premier lieu.
1:33
Speaker 2: Voici le problème avec la plupart des appareils IoT qui
1:35
Speaker 2: contiennent de minuscules ordinateurs, de petits microcontrôleurs qui gèrent une
1:38
Speaker 2: ou deux tâches. Mais historiquement, ces puces étaient conçus pour
1:41
Speaker 2: des choses comme les fours à micro-ondes et les machines
1:43
Speaker 2: à laver, des choses qui ne se connectent pas à Internet,
1:45
Speaker 2: des choses qui ne se connectent pas à Internet. Les
1:46
Speaker 2: fabricants ont donc optimisé le système en fonction du coût
1:48
Speaker 2: et de la consommation d'énergie, pas de la sécurité. Puis
1:50
Speaker 2: l'Internet des objets est arrivé. Soudain, toutes ces puces simples
1:53
Speaker 2: et bon marché devaient se connecter à Internet
1:55
Speaker 2: Et les fabricants ont fait ce qu'ils font. Ils ont
1:58
Speaker 2: ajouté un module Wi-Fi et c'est parti. Pas de démarrage sécurisé,
2:01
Speaker 2: pas de racine de confiance matérielle, pas de mécanisme de
2:03
Speaker 2: mise à jour. Une fois qu'un appareil était expédié, c'était terminé.
2:05
Speaker 2: Si une vulnérabilité était découverte 6 mois plus tard, il
2:07
Speaker 2: n'y avait aucun moyen de la corriger. L'appareil était bloqué
2:09
Speaker 2: avec les bugs avec lesquels il était livré. Et ces
2:11
Speaker 2: appareils restaient sur le terrain pendant des années. Un capteur
2:13
Speaker 2: d'usine pouvait fonctionner pendant une décennie. Un compteur intelligent pouvait
2:16
Speaker 2: rester sur le côté d'un bâtiment pendant 15 ans. C'est
2:18
Speaker 2: beaucoup de temps pour qu'un appareil vulnérable soit connecté à Internet.
2:21
Speaker 2: Les conséquences sont réelles. Des botnets qui lancent des attaques massives,
2:25
Speaker 2: des violations de données qui exposent des informations personnelles, des
2:27
Speaker 2: réseaux compromis qui donnent aux attaquants un pied dans les entreprises.
2:30
Speaker 2: Tout cela parce que personne n'a pensé à la sécurité
2:31
Speaker 2: lorsque la puce a été conçue. Microsoft s'est donc penché
2:34
Speaker 2: sur ce problème et a décidé de créer quelque chose
2:35
Speaker 2: à partir de zéro. Pas un correctif logiciel, pas un
2:37
Speaker 2: service de sécurité que l'on ajoute plus tard. Quelque chose
2:39
Speaker 2: qui commence par le silicium lui-même
2:41
Speaker 2: Ce qui est réellement Azure Sphere? La vue d'ensemble. Azure
2:45
Speaker 2: Sphere est la plateforme de sécurité IoT de bout en
2:47
Speaker 2: bout de Microsoft. Cela ressemble à du jargon marketing, alors
2:50
Speaker 2: laissez-moi vous le traduire en anglais simple. Ce sont trois
2:52
Speaker 2: choses qui fonctionnent ensemble. Une puce de microcontrôleur certifiée, un
2:55
Speaker 2: système d'exploitation sécurisé et un service de sécurité cloud. Vous
2:58
Speaker 2: avez besoin des trois. Enlevez-en un et tout s'effondre. L'expression
3:01
Speaker 2: clé que vous entendrez souvent est la sécurité du silicium
3:03
Speaker 2: au clou. Ce n'est pas qu'un slogan. Cela signifie que
3:07
Speaker 2: la sécurité commence au niveau de la puce physique et
3:09
Speaker 2: s'étend jusqu'au service cloud qui gère les appareils. Chaque couche
3:12
Speaker 2: est conçue pour fonctionner ensemble. Maintenant, comparons cela à l'ancienne approche.
3:16
Speaker 2: La plupart des mesures de sécurité de l'idée au son.
3:18
Speaker 2: Prenez une puce classique, exécutez un système d'exploitation classique puis
3:20
Speaker 2: essayez d'ajouter des fonctionnalités de sécurité plus tard. Vous pouvez
3:22
Speaker 2: peut-être chiffrer certaines données ou ajouter un mot de passe.
3:25
Speaker 2: C'est comme construire une maison avec des murs en papier
3:26
Speaker 2: puis installer un pendormant sophistiqué. Le pendormant fonctionne et quelqu'un
3:30
Speaker 2: peut toujours traverser le mur. Azure Sphere adopte une approche différente.
3:34
Speaker 2: La sécurité est intégrée dès le départ, elle n'est pas
3:35
Speaker 2: ajoutée à l'intérieur. La puce elle-même possède des fonctionnalités de
3:38
Speaker 2: sécurité intégrées au silicium. Le système d'exploitation est conçu spécifiquement
3:41
Speaker 2: pour fonctionner en toute sécurité. Le service cloud gère l'ensemble
3:44
Speaker 2: du parc. Voici une analogie qui peut vous aider. Imaginez
3:46
Speaker 2: un bâtiment sécurisé. La puce est la porte blindée. Elle
3:49
Speaker 2: est solide au point d'entrée. Le système d'exploitation est le
3:51
Speaker 2: gardien de sécurité à l'intérieur. Il s'assure que les personnes
3:54
Speaker 2: ne vont que là où elles sont autorisées et le
3:55
Speaker 2: service de sécurité cloud est la station de surveillance centrale
3:58
Speaker 2: Il surveille tout, envoie des mises à jour et répond
4:00
Speaker 2: aux problèmes. Maintenant, une question courante est, Azure Sphere n'est-elle
4:03
Speaker 2: qu'une autre plateforme IoT? Pas vraiment. La plupart des plateformes
4:07
Speaker 2: IoT comme AWS IoT Core ou Azure IoT Hub concernent
4:10
Speaker 2: la connexion d'appareils au cloud et la gestion des données.
4:13
Speaker 2: Azure Sphere concerne spécifiquement la sécurité au niveau des appareils.
4:16
Speaker 2: C'est la base sur laquelle les appareils IoT sécurisés peuvent
4:18
Speaker 2: être construits. Voyez les choses de cette façon. AWS IoT
4:21
Speaker 2: comme un service postal, il déplace vos données d'un point
4:23
Speaker 2: A à un point B en toute sécurité. Azure Sphere,
4:26
Speaker 2: c'est comme construire un coffre-fort pour vos données avant même
4:28
Speaker 2: de les remettre au service postal. Il résolve différents problèmes
4:31
Speaker 2: et vous pourriez en fait utiliser les deux ensemble. Alors
4:33
Speaker 2: qu'est-ce qui rend la puce spéciale? Décomposons chaque couche en
4:36
Speaker 2: commençant par le silicium lui-même. Couche 1. Le silicium, le
4:41
Speaker 2: microcontrôleur Azure Sphere. Commençons par la puce elle-même, car c'est
4:44
Speaker 2: là que tout commence. La base matérielle d'Azure Sphere est
4:47
Speaker 2: un microcontrôleur conçu sur mesure. Actuellement, la principale puce que
4:51
Speaker 2: vous trouverez en production est le Mediatek MT360. En apparence,
4:54
Speaker 2: il ressemble à n'importe quel autre microcontrôleur. Il est petit,
4:57
Speaker 2: consomme relativement peu d'énergie et gère les tâches de traitement
4:59
Speaker 2: de base. Ce qui le rend différent, c'est ce qui
5:02
Speaker 2: est intégré au silicium. A l'intérieur de cette puce, il
5:04
Speaker 2: y a quelque chose appelé le sous-système de sécurité Pluton.
5:07
Speaker 2: Pluton n'est pas un logiciel. C'est un processeur de sécurité
5:09
Speaker 2: dédié distinct, intégré directement au matériel. Considérez-le comme un minuscule
5:13
Speaker 2: ordinateur inviolable, à l'intérieur de l'ordinateur principal. Sa seule fonction
5:16
Speaker 2: est de gérer les opérations de sécurité. Pourquoi est-ce important?
5:19
Speaker 2: Parce qu'il crée ce qu'on appelle une racine de confiance matérielle.
5:21
Speaker 2: Voici ce que cela signifie en termes simples. Lorsque l'appareil s'allume,
5:24
Speaker 2: le sous-système Pluton est la première chose qui commence à fonctionner.
5:27
Speaker 2: Elle vérifie sa propre identité, au niveau le plus bas possible,
5:29
Speaker 2: le silicium lui-même. Avant le chargement de tout logiciel, avant
5:32
Speaker 2: le démarrage du système d'exploitation, avant que quoi que ce
5:34
Speaker 2: soit d'autre ne se produise, la puce peut vérifier qu'elle
5:36
Speaker 2: est bien celle qu'elle prétend être. C'est fondamentalement différent de
5:38
Speaker 2: la sécurité logicielle. Avec un logiciel, vous êtes toujours sûr
5:41
Speaker 2: que rien n'a été altéré avant le chargement du logiciel
5:43
Speaker 2: de sécurité. Si quelqu'un a modifié le chargeur de démarrage
5:46
Speaker 2: ou le micro-logiciel, votre logiciel de sécurité pourrait vérifier la
5:49
Speaker 2: mauvaise chose. La confiance basée sur le matériel ne pose
5:50
Speaker 2: pas ce point. Vous ne pouvez pas modifier Pluton sans
5:53
Speaker 2: accéder physiquement à la puce, et même dans ce cas,
5:55
Speaker 2: elle est conçue pour résister à la falsification. A partir
5:57
Speaker 2: de là, la puce applique un démarrage sécurisé. L'appareil n'exécutera
5:59
Speaker 2: que les logiciels qui ont été signés et approuvés par cryptographie.
6:02
Speaker 2: Si quelqu'un tente de charger un micro-logiciel non autorisé, la
6:04
Speaker 2: puce refuse tout simplement. Elle ne démarrera pas. Elle ne
6:06
Speaker 2: fonctionnera pas. L'appareil restera verrouillé. Le MT362 a également une
6:10
Speaker 2: conception croisée. Il combine le traitement en temps réel, celui
6:12
Speaker 2: dont vous avez besoin pour contrôler des moteurs ou lire
6:14
Speaker 2: des capteurs, avec le traitement d'application pour des tâches plus complexes.
6:18
Speaker 2: Cela signifie qu'une seule puce peut gérer à la fois
6:20
Speaker 2: le contrôle de bas niveau et la connectivité et la
6:21
Speaker 2: sécurité de plus haut niveau. Pas besoin de deux processeurs distincts.
6:25
Speaker 2: Pourquoi la sécurité matérielle est-elle si importante? Parce que la
6:27
Speaker 2: sécurité logicielle peut être contournée. Un attaquant astucieux peut trouver
6:30
Speaker 2: des bugs dans le système d'exploitation, exploiter les vulnérabilités des
6:33
Speaker 2: applications ou tromper le logiciel pour qu'il fasse des choses
6:35
Speaker 2: qu'il ne devrait pas. La sécurité matérielle est beaucoup plus
6:38
Speaker 2: difficile à perdre. Il faut un accès physique à la puce,
6:40
Speaker 2: un équipement spécialisé et beaucoup de temps et de compétences.
6:43
Speaker 2: Voici l'analogie Kikos. Le sous-système de sécurité Pluton est comme
6:46
Speaker 2: un coffre-fort inviolable intégré dans les fondations d'un bâtiment. Vous
6:49
Speaker 2: ne pouvez pas le déplacer. Vous ne pouvez pas l'ouvrir
6:51
Speaker 2: sans les bons outils. Et même si quelqu'un entre par
6:53
Speaker 2: effraction par une fenêtre, le coffre-fort reste sécurisé. C'est le
6:55
Speaker 2: niveau de protection dont nous parlons. Mais le matériel seul
6:58
Speaker 2: ne suffit pas. Le système d'exploitation qui s'exécute par-dessus est
7:00
Speaker 2: tout aussi important. La couche 2, le système d'exploitation. Un
7:03
Speaker 2: Linux verrouillé. Vous avez donc cette puce sécurisée. Qu'est-ce qui
7:07
Speaker 2: fonctionne dessus? Système d'exploitation personnalisé verrouillé basé sur Linux conçu
7:10
Speaker 2: spécifiquement pour Azure Sphere. Maintenant, quand je dis Linux... Vous
7:13
Speaker 2: pensez peut-être à Ubuntu ou Debian, un système d'exploitation à
7:15
Speaker 2: usage général que vous pouvez installer sur un ordinateur portable
7:17
Speaker 2: ou un serveur. Le système d'exploitation d'Azure Sphere n'a rien
7:20
Speaker 2: à voir avec ça. Il a été réduit au strict minimum.
7:22
Speaker 2: Toutes les fonctionnalités qui ne sont pas absolument nécessaires ont
7:24
Speaker 2: été supprimées. Pas de serveur web, pas d'environnement de bureau,
7:27
Speaker 2: pas de pilote inutile, juste les composants de base nécessaires
7:29
Speaker 2: pour exécuter des applications sécurisées et communiquer avec le cloud.
7:33
Speaker 2: Pourquoi est-ce important? Parce que chaque ligne de code est
7:34
Speaker 2: une vulnérabilité potentielle. Plus vous avez de code, plus vous
7:37
Speaker 2: pouvez avoir de bugs. En gardant le système d'exploitation petit,
7:40
Speaker 2: Microsoft réduit ce que les chercheurs en sécurité appellent la
7:43
Speaker 2: base informatique de confiance, la quantité de code qui doit
7:45
Speaker 2: être fiable pour que le système soit sécurisé. Moins de
7:48
Speaker 2: lignes de code signifie moins d'endroits où les attaquants peuvent
7:50
Speaker 2: se cacher. Il ne s'agit pas seulement de supprimer des fonctionnalités.
7:53
Speaker 2: Le système d'exploitation applique également ce qu'on appelle la compartimentation dynamique.
7:57
Speaker 2: C'est un terme sophistiqué pour Unidesyn. Les applications sont isolées
8:00
Speaker 2: les unes des autres. Si une application est compromise, cela
8:03
Speaker 2: ne peut pas affecter les autres applications exécutées sur le
8:04
Speaker 2: même appareil. Chaque application s'exécute dans son propre bac à sable,
8:08
Speaker 2: avec son propre espace mémoire et ses propres autorisations. Le
8:10
Speaker 2: système d'exploitation contrôle également l'accès au matériel via l'utilisation de périphériques.
8:14
Speaker 2: Une application ne peut utiliser que les composants matériels auxquels
8:16
Speaker 2: elle est explicitement autorisée à accéder à accéder. Si une
8:18
Speaker 2: application tente de lire à partir d'un capteur pour lequel
8:20
Speaker 2: elle n'a pas l'autorisation, le système d'exploitation la bloque. Point final.
8:23
Speaker 2: Aucune exception. Cela empêche une application compromise d'accéder à des
8:26
Speaker 2: éléments auxquels elle ne devrait pas. Voici maintenant la partie
8:29
Speaker 2: qui diffère de la plupart des systèmes d'exploitation ailleurs. Microsoft
8:31
Speaker 2: gère et met à jour le système d'exploitation, pas le
8:33
Speaker 2: fabricant de l'appareil. Lorsque Microsoft détecte une faille de sécurité
8:37
Speaker 2: et publie un correctif, Ce correctif est directement envoyé aux
8:39
Speaker 2: appareils via le service de sécurité Azure Sphere. Le fabricant
8:43
Speaker 2: n'a rien à faire. Il n'a pas à le tester
8:45
Speaker 2: ni à l'approuver. Microsoft gère l'intégralité du pipeline de mise
8:48
Speaker 2: à jour. C'est un énorme problème. Dans le monde traditionnel
8:51
Speaker 2: de l'IDO, lorsqu'une vulnérabilité est détectée, le fabricant doit développer
8:54
Speaker 2: un correctif, le tester, le faire approuver, puis l'intégrer d'une
8:56
Speaker 2: manière ou d'une autre à des appareils qui peuvent être
8:58
Speaker 2: dispersés dans le monde entier. Ce processus peut prendre des mois,
9:02
Speaker 2: voire jamais. Avec Azure Sphere, la mise à jour s'effectue automatiquement,
9:05
Speaker 2: souvent dans les jours qui suivent la découverte d'une vulnérabilité.
9:08
Speaker 2: Pourquoi l'approche du système d'exploitation est-elle si importante? Parce que
9:10
Speaker 2: la plupart des violations de l'IDO se produisent au niveau
9:11
Speaker 2: de la couche logicielle. Les attaquants n'essaient généralement pas de
9:13
Speaker 2: pirater le matériel. C'est trop difficile. Ils recherchent des bugs logiciels,
9:17
Speaker 2: ils trouvent des vulnérabilités non corrigées, ils exploitent des contrôles
9:19
Speaker 2: d'accès faibles. En verrouillant le système d'exploitation, en réduisant la
9:22
Speaker 2: surface d'attaque et en automatisant les mises à jour, Azure
9:24
Speaker 2: Sphere supprime les chemins d'attaque les plus courants. Vous disposez
9:27
Speaker 2: donc d'un matériel sécurisé exécutant un système d'exploitation verrouillé. Et
9:29
Speaker 2: comment gérer des milliers de ces appareils dans le monde réel?
9:32
Speaker 2: C'est là qu'intervient le service cloud. Couche 3, le cloud,
9:36
Speaker 2: le service de sécurité Vous disposez donc d'une puce sécurisée
9:39
Speaker 2: avec une racine de confiance matérielle. Vous disposez d'un système
9:42
Speaker 2: d'exploitation verrouillé qui isole les applications et contrôle l'accès au matériel.
9:45
Speaker 2: Mais voilà le problème. Un appareil sécurisé, dès le premier jour,
9:48
Speaker 2: ne l'est pas forcément le millième jour. La sécurité n'est
9:50
Speaker 2: pas une configuration ponctuelle, un processus continu. C'est là qu'intervient
9:53
Speaker 2: le service cloud. Le service de sécurité Azure Sphere est
9:56
Speaker 2: le centre de commande de l'ensemble du parc d'appareils. Chaque
9:59
Speaker 2: appareil Azure Sphere se connecte à ce service tout au
10:01
Speaker 2: long de sa durée de vie. Cette connexion n'est pas facultative,
10:03
Speaker 2: elle est obligatoire. Un appareil qui ne peut pas accéder
10:05
Speaker 2: au service ne fonctionnera pas correctement. Cela peut paraître sévère,
10:08
Speaker 2: mais c'est intentionnel. Cela garantit que chaque appareil est toujours géré,
10:12
Speaker 2: surveillé et à jour. Laissez-moi vous expliquer ce que fait
10:15
Speaker 2: réellement le service. Tout d'abord, l'authentification basée sur les certificats.
10:19
Speaker 2: Chaque appareil Azure Sphere est livré avec une identité unique
10:22
Speaker 2: et vérifiable intégrée au matériel. Lorsque l'appareil démarre et se
10:25
Speaker 2: connecte au cloud, il présente cette identité. Le service de
10:28
Speaker 2: sécurité vérifie que l'identité est valide, que l'appareil appartient au
10:31
Speaker 2: bon locataire et qu'il n'a pas été altéré. Quelque chose
10:34
Speaker 2: semble anormal, le service peut empêcher l'appareil de se connecter.
10:36
Speaker 2: Cela diffère fondamentalement de l'ancien modèle où les appareils utilisaient
10:39
Speaker 2: des mots de passe simples ou des clés partagées. Si
10:41
Speaker 2: un mot de passe est volé, vous devez le modifier
10:43
Speaker 2: sur chaque appareil. Avec l'authentification basée sur les certificats, chaque
10:46
Speaker 2: appareil possède ses propres informations d'identification unique. La compromission d'un
10:49
Speaker 2: appareil ne compromet pas le reste du parc
10:51
Speaker 2: Deuxièmement, les mises à jour automatiques en direct. C'est la
10:54
Speaker 2: fonctionnalité phare. Lorsque Microsoft détecte une faille de sécurité dans
10:57
Speaker 2: le système d'exploitation Azure Sphere, il développe un correctif et
11:00
Speaker 2: le transmet directement à chaque appareil via le service de sécurité.
11:03
Speaker 2: L'appareil télécharge la mise à jour, vérifie qu'elle est signée
11:05
Speaker 2: par Microsoft à l'aide de la racine de confiance matérielle,
11:07
Speaker 2: puis l'installe. Plus besoin d'attendre que le fabricant développe un correctif.
11:10
Speaker 2: Plus besoin d'attendre que les équipes informatiques planifient des fenêtres
11:13
Speaker 2: de maintenance. Plus d'appareils qui ne sont jamais mis à
11:15
Speaker 2: jour parce que personne ne pense à vérifier. La mise
11:17
Speaker 2: à jour se fait automatiquement, souvent dans les jours qui
11:19
Speaker 2: suivent la découverte d'une vulnérabilité. Voici maintenant un point important,
11:22
Speaker 2: l'appareil ne peut pas refuser une mise à jour. Si
11:24
Speaker 2: le service de sécurité indique qu'une mise à jour est disponible,
11:26
Speaker 2: l'appareil doit l'installer. Encore une fois, cela semble être un contrôle.
11:29
Speaker 2: Mais dans le monde de la sécurité Lido, c'est nécessaire.
11:31
Speaker 2: Le botnet Mirai est apparu parce que les appareils ont
11:33
Speaker 2: été livrés avec des vulnérabilités connues et que personne ne
11:35
Speaker 2: les a jamais corrigées. Les mises à jour obligatoires empêchent
11:37
Speaker 2: ce scénario. Troisièmement, le signalement des défaillances. Lorsqu'un problème survient
11:41
Speaker 2: sur un appareil Azure Sphere, qu'il s'agisse d'un plantage, d'un
11:43
Speaker 2: événement de sécurité ou d'une défaillance matérielle, l'appareil le signale
11:46
Speaker 2: au service de sécurité. Cela offre aux fabricants et aux
11:49
Speaker 2: opérateurs une visibilité en temps réel sur l'état de santé
11:51
Speaker 2: de l'ensemble de leur parc. Si un appareil commence à
11:53
Speaker 2: se comporter de manière étrange, vous le savez immédiatement. Si
11:56
Speaker 2: un modèle apparaît sur plusieurs appareils, vous pouvez enquêter et réagir. Quatrièmement,
12:01
Speaker 2: la surveillance et l'attestation à distance. Le service de sécurité
12:03
Speaker 2: peut vérifier que chaque appareil de votre parc exécute toujours
12:05
Speaker 2: un logiciel approuvé. Il peut vérifier que le processus de
12:08
Speaker 2: démarrage était propre, que le système d'exploitation n'a pas été
12:10
Speaker 2: modifié et que les applications sont celles que vous avez approuvées.
12:13
Speaker 2: Si un appareil échoue à cette vérification, le service peut
12:15
Speaker 2: le signaler pour enquête ou l'empêcher d'accéder à vos ressources.
12:18
Speaker 2: Et enfin, l'engagement de support de 10 ans. Microsoft s'est
12:21
Speaker 2: engagé à prendre en charge les appareils Azure Sphere pendant
12:23
Speaker 2: une décennie. Cela signifie des mises à jour de sécurité,
12:25
Speaker 2: des correctifs de systèmes d'exploitation et la disponibilité du service
12:28
Speaker 2: cloud pendant au moins 10 ans à compter de la
12:29
Speaker 2: date de mise en service d'appareil. Pour les équipements et
12:31
Speaker 2: infrastructures industrielles qui restent sur le terrain pendant des années,
12:33
Speaker 2: c'est un énorme problème. Voici l'analogie. Le service de sécurité
12:37
Speaker 2: est comme une station de surveillance centrale qui surveille chaque
12:39
Speaker 2: porte d'un bâtiment en temps réel. Il sait qui est entré,
12:42
Speaker 2: quand il est entré, s'il est censé être là. Si
12:44
Speaker 2: une porte est endommagée, la station envoie quelqu'un pour la
12:46
Speaker 2: réparer immédiatement. Et tous les quelques mois, elle met à
12:48
Speaker 2: niveau les serrures de chaque porte sans que personne n'ait
12:50
Speaker 2: à le demander. Maintenant, rassemblons les trois couches et voyons
12:53
Speaker 2: comment elles fonctionnent réellement comme un seul système. Comment tout
12:57
Speaker 2: cela fonctionne ensemble, la véritable puissance. Laissez-moi vous présenter un
13:00
Speaker 2: scénario réaliste. Imaginez qu'une entreprise construise un nouveau capteur industriel,
13:03
Speaker 2: quelque chose qui surveille la température et les vibrations sur
13:05
Speaker 2: une chaîne de production en usine. Ce capteur utilise Azure Sphere.
13:08
Speaker 2: Suivons ce qui se passe à partir du moment où
13:10
Speaker 2: il est mis sous tension pour la première fois. Première étape,
13:12
Speaker 2: la puce démarre. Vous vous souvenez du sous-système de sécurité Pluton?
13:15
Speaker 2: C'est la première chose qui commence à fonctionner. Il vérifie
13:17
Speaker 2: sa propre identité au niveau du matériel, puis il vérifie
13:19
Speaker 2: que le chargeur de démarrage est signé et approuvé par Microsoft.
13:22
Speaker 2: Ce n'est qu'à ce moment-là qu'il autorise l'exécution du chargeur
13:24
Speaker 2: de démarrage. Si quelqu'un avait essayé de flasher un micro-logiciel
13:26
Speaker 2: non autorisé sur la puce, le processus de démarrage s'arrêterait là.
13:30
Speaker 2: Deuxième étape, le chargeur de démarrage charge le système d'exploitation,
13:32
Speaker 2: mais il ne se contente pas de charger ce qui
13:34
Speaker 2: est stocké en mémoire. Il vérifie l'image du système d'exploitation
13:36
Speaker 2: par rapport à une signature cryptographique. Le système d'exploitation doit
13:39
Speaker 2: être dans un état connu, signé par Microsoft et non altéré.
13:42
Speaker 2: Si le système d'exploitation a été modifié, la puce refuse
13:44
Speaker 2: de le charger. L'appareil reste verrouillé. Troisième étape, le système
13:47
Speaker 2: d'exploitation démarre et l'appareil contacte le service de sécurité Azure Sphere.
13:52
Speaker 2: Il présente son identité unique basée sur un certificat. Le
13:55
Speaker 2: service vérifie que cet appareil appartient au bon locataire et
13:57
Speaker 2: que son identité est valide Si tout est correct, l'appareil
14:01
Speaker 2: est authentifié. Quatrième étape, le service de sécurité vérifie la
14:04
Speaker 2: version du logiciel de l'appareil. Exécute-t-il le dernier système d'exploitation?
14:07
Speaker 2: Y a-t-il des correctifs de sécurité à appliquer? Si des
14:10
Speaker 2: mises à jour sont disponibles, le service les envoie immédiatement.
14:13
Speaker 2: L'appareil télécharge les mises à jour, vérifie qu'elles sont signées
14:15
Speaker 2: et les installe. Ce n'est qu'une fois que l'appareil est
14:17
Speaker 2: entièrement à jour qu'il passe à l'étape suivante. Cinquième étape,
14:20
Speaker 2: l'appareil commence à fonctionner. Il commence à envoyer des données
14:23
Speaker 2: de télémétrie, des relevés de température, des niveaux de vibration
14:25
Speaker 2: et un état de fonctionnement au cloud. Toutes ces communications
14:28
Speaker 2: se font via des canaux authentifiés, écriptés et cryptés. L'appareil
14:32
Speaker 2: commence également à recevoir des commandes si nécessaire. Peut-être une
14:34
Speaker 2: modification de configuration ou une demande d'exécution d'un diagnostic. Chaque
14:37
Speaker 2: commande est vérifiée et autorisée. Voici maintenant ce qui se
14:40
Speaker 2: passe tout au long de la durée de vie de l'appareil.
14:42
Speaker 2: Toutes les quelques semaines ou tous les quelques mois, Microsoft
14:44
Speaker 2: publie des mises à jour de sécurité. Le service de
14:45
Speaker 2: sécurité Azure Sphere envoie automatiquement ces mises à jour à l'appareil.
14:49
Speaker 2: L'appareil les installe, souvent sans aucun temps d'arrêt. L'opérateur de
14:52
Speaker 2: l'usine n'a rien à faire. Le capteur continue de fonctionner,
14:54
Speaker 2: mais il exécute toujours le logiciel le plus récent et
14:56
Speaker 2: le plus sécurisé. Si quelque chose ne va pas, par
14:58
Speaker 2: exemple si l'appareil plante ou détecte une anomalie, il signale
15:01
Speaker 2: la défaillance au service de sécurité. L'opérateur reçoit une alerte,
15:05
Speaker 2: il peut enquêter à distance. Si nécessaire, il peut appliquer
15:07
Speaker 2: un correctif ou reconfigurer l'appareil. Tout cela sans envoyer de
15:10
Speaker 2: technicien à l'usine. L'idée clé ici mérite d'être répétée. La
15:14
Speaker 2: sécurité n'est pas une fonctionnalité que l'on ajoute à un appareil.
15:16
Speaker 2: C'est la base sur laquelle tout fonctionne. Azure Sphere n'ajoute
15:19
Speaker 2: pas de sécurité à après-coup. Il construit l'ensemble de l'appareil,
15:22
Speaker 2: du matériel, du système d'exploitation et de la gestion du
15:23
Speaker 2: cloud autour de la sécurité dès le départ. C'est là
15:25
Speaker 2: que réside la véritable puissance de la plateforme, pas une
15:27
Speaker 2: fonctionnalité isolée, mais la manière dont les trois couches fonctionnent ensemble.
15:30
Speaker 2: La puce fournit la racine de confiance matérielle, le système
15:32
Speaker 2: d'exploitation fournit l'environnement verrouillé, le service cloud assure la gestion
15:35
Speaker 2: et les mises à jour continuent. Ensemble, il crée quelque
15:38
Speaker 2: chose de plus grand que la somme de ses parties. Cependant,
15:40
Speaker 2: la qualité d'une plateforme de sécurité dépend de ses antécédents.
15:43
Speaker 2: Parlons donc honnêtement des vulnérabilités qui ont été découvertes. Le
15:46
Speaker 2: tableau honnête, les vulnérabilités et la réalité. Soyons honnêtes. Une
15:50
Speaker 2: plateforme qui promet d'être à toute épreuve va attirer l'attention.
15:53
Speaker 2: Et Azure Sphere en a eu sa part. En 2020,
15:55
Speaker 2: Microsoft a lancé le défi de recherche sur la sécurité
15:58
Speaker 2: Azure Sphere. Ils ont invité des chercheurs en sécurité à
16:00
Speaker 2: examiner la plateforme, à trouver des faiblesses et à les signaler.
16:04
Speaker 2: Cisco Talos a accepté leur ordre. Au fil du temps,
16:06
Speaker 2: ils ont trouvé 31 vulnérabilités sur l'ensemble de la pile.
16:09
Speaker 2: De quel type de bug s'agissait-il? Des problèmes de noyaux
16:11
Speaker 2: qui pourraient permettre à un attaquant de faire planter le système.
16:13
Speaker 2: Des chemins d'élévation de privilèges qui permettraient à une application
16:15
Speaker 2: malveillante d'obtenir un accès de plus haut niveau. L'exécution de
16:17
Speaker 2: codes non signés, le genre de bug qui compromet la
16:19
Speaker 2: promesse d'exécution de logiciels uniquement signés. Logiciels uniquement signés. Certains
16:23
Speaker 2: d'entre eux étaient graves, quelques-uns ont été jugés critiques. Voici
16:25
Speaker 2: maintenant le contexte important. Microsoft a invité cette recherche. Ils
16:28
Speaker 2: ont mis en place un programme formel, payé des chercheurs
16:30
Speaker 2: et corrigé chaque vulnérabilité signalée. Chacun de ces 31 bugs
16:33
Speaker 2: a été corrigé via le système de mise à jour
16:35
Speaker 2: automatique dont nous avons parlé plus tôt. Quelques semaines après
16:37
Speaker 2: leur découverte, les correctifs ont été appliqués aux appareils sur
16:39
Speaker 2: le terrain. Autre point, il n'existe aucun cas documenté d'exploitation
16:43
Speaker 2: de ces vulnérabilités dans le monde réel. Aucune attaque à
16:46
Speaker 2: grande échelle. Aucun botnet créé à partir d'appareils Azure Sphere.
16:49
Speaker 2: Les recherches ont été approfondies, mais elles ont également été.
16:51
Speaker 2: Cela ne signifie pas qu'Azure Sphere est parfaite. Aucune plateforme
16:54
Speaker 2: ne l'est. Ce qui compte, c'est la rapidité avec laquelle
16:56
Speaker 2: les problèmes sont détectés. Sur ce plan, Azure Sphere a
16:59
Speaker 2: fait ses preuves. Le pipeline de mise à jour obligatoire
17:01
Speaker 2: signifie que lorsqu'une vulnérabilité est découverte, chaque appareil est corrigé.
17:04
Speaker 2: Pas certains appareils, pas les appareils dont le fabricant a
17:07
Speaker 2: pris la peine de publier une mise à jour, chaque appareil,
17:09
Speaker 2: chaque appareil. Comparer cela au reste du monde de l'IDO.
17:12
Speaker 2: D'autres plateformes présentent également des vulnérabilités, mais beaucoup d'entre elles
17:14
Speaker 2: ne disposent pas d'un mécanisme de mise à jour obligatoire.
17:16
Speaker 2: Une vulnérabilité est découverte, le fabricant publie un correctif, puis
17:19
Speaker 2: plus rien. Les appareils restent sans correctif pendant des années
17:22
Speaker 2: parce que personne ne pousse la mise à jour. Azure
17:24
Speaker 2: Sphere résout ce problème. Le compromis est cependant réel. Une
17:27
Speaker 2: plateforme étroitement intégrée signifie de solides garanties de sécurité, mais
17:29
Speaker 2: elle implique également une dépendance vis-à-vis de Microsoft. Vous ne
17:32
Speaker 2: pouvez pas changer de système d'exploitation ni utiliser une autre.
17:34
Speaker 2: Vous êtes tous dans l'écosystème Azure Sphere. Pour certaines organisations,
17:37
Speaker 2: c'est un obstacle. Pour d'autres, c'est un prix à payer
17:40
Speaker 2: pour ne pas avoir à gérer la sécurité vous-même. Ce
17:42
Speaker 2: qu'il faut retenir, c'est qu'Azure Sphere n'est pas invulnérable. Il
17:45
Speaker 2: y a eu des bugs, il y en aura d'autres,
17:46
Speaker 2: mais la plateforme est conçue pour gérer cette réalité. Le
17:49
Speaker 2: pipeline de mise à jour, la racine de confiance matérielle,
17:51
Speaker 2: le verrouillage du système d'exploitation, tout cela existe parce que
17:53
Speaker 2: Microsoft savait que des vulnérabilités seraient découvertes. L'objectif n'est pas
17:56
Speaker 2: d'être parfait, mais d'être résilient. Alors à qui cela s'adresse-t-il réellement?
17:59
Speaker 2: Et quand devriez-vous vous en soucier? À qui cela s'adresse-t-il?
18:02
Speaker 2: Cas d'utilisation réelle. Zorsphere n'est pas destiné à tous les appareils.
18:06
Speaker 2: Il est destiné aux appareils pour lesquels une faille de
18:08
Speaker 2: sécurité coûterait plus cher que l'appareil lui-même. Pensez aux capteurs
18:11
Speaker 2: industriels qui surveillent les équipements d'usines. Un capteur compromis pourrait
18:14
Speaker 2: envoyer de fausses lectures, ce qui amènerait les opérateurs à
18:16
Speaker 2: prendre de mauvaises décisions. Pire, un attaquant pourrait utiliser ce
18:19
Speaker 2: capteur comme point d'ancrage pour pénétrer plus profondément dans le
18:21
Speaker 2: réseau de l'usine. Le coût de cette violation pourrait se
18:23
Speaker 2: chiffrer en millions de dollars en perte de production. Pensez
18:26
Speaker 2: aux appareils commerciaux, aux distributeurs automatiques, aux systèmes CVC, aux
18:28
Speaker 2: contrôleurs d'automatisation des bâtiments. Ces appareils se trouvent dans des
18:31
Speaker 2: espaces publics connectés au réseau souvent pendant des années. Personne
18:34
Speaker 2: ne les met à jour. Personne n'y pense. Ce sont
18:36
Speaker 2: des cibles parfaites pour les attaquants à la recherche d'un
18:38
Speaker 2: point d'entrée. Pensez aux infrastructures des villes intelligentes, aux feux
18:41
Speaker 2: de circulation, aux capteurs environnementaux, aux contrôleurs des systèmes d'eau.
18:43
Speaker 2: Si ces éléments sont compromis, ce ne sont pas seulement
18:45
Speaker 2: les données qui sont en danger, mais aussi les données physiques.