WEBVTT 00:00:00.500 --> 00:00:06.840 Bereit für 10 Tage Microsoft 365, Co-Pilot, KI, Azure und die Menschen, die die Zukunft der Arbeit gestalten? 00:00:07.780 --> 00:00:11.060 Diesen Januar ist die M365-Con zurück und wird noch größer. 00:00:11.500 --> 00:00:12.200 Und wird noch größer. 00:00:12.840 --> 00:00:18.140 Seien Sie dabei bei Live-Sessions, Demos aus der Praxis und erfahren Sie praktisches Wissen von MVPs und Branchenexperten aus aller Welt. 00:00:18.720 --> 00:00:21.180 Keine generischen Folien, keine endlosen Schlagworte. 00:00:21.920 --> 00:00:23.560 Wir stellen uns den echten Herausforderungen. 00:00:23.680 --> 00:00:28.820 Co-Pilot Studio, KI-Agents, Fabric, Sicherheit, Governance und Automatisierung, GAP. 00:00:28.820 --> 00:00:34.260 Ganz gleich, ob Sie IT-Experte, Entwickler oder Führungskraft sind, es gibt für Sie passende Sessions. 00:00:35.480 --> 00:00:39.880 An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen. 00:00:40.900 --> 00:00:44.340 Sehen Sie sich die Live-Übertragung an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen. 00:00:45.120 --> 00:00:48.860 Januar 2027, 10 Tage, eine Microsoft-Community. 00:00:49.380 --> 00:00:50.640 Die Registrierung ist ab sofort möglich. 00:00:51.380 --> 00:00:52.940 Gehen Sie noch heute zu Ihrem Standort. 00:00:54.520 --> 00:00:58.120 Das ist end3565.con.no 00:00:58.120 --> 00:01:04.800 Melden Sie sich jetzt unter m33556.con.net an und wir sehen uns im Januar live. 00:01:05.360 --> 00:01:07.580 Stellen Sie sich vor, Sie kaufen ein intelligentes Thermostat für Ihr Zuhause. 00:01:08.000 --> 00:01:10.540 Sie installieren es, verbinden es mit dem WLAN und es funktioniert einwandfrei. 00:01:11.120 --> 00:01:14.000 Sie können die Temperatur über Ihr Smartphone regeln, das Thermostat lernt Ihren Zeitplan. 00:01:14.100 --> 00:01:14.820 Alles ist in Ordnung. 00:01:15.560 --> 00:01:20.740 Bis eines Tages, dieser Thermostat Teil eines Bordnetzes wird, das das Netzwerk eines Krankenhauses auf der anderen Seite der Welt angreift. 00:01:21.240 --> 00:01:21.920 Klingt dramatisch? 00:01:22.240 --> 00:01:22.580 Ist es nicht. 00:01:22.920 --> 00:01:23.560 Das ist tatsächlich passiert. 00:01:23.560 --> 00:01:28.880 Das Mirai Bordnetz hat 2016 große Teile des Internets lahmgelegt und zwar mithilfe von gehackten Kameras und Routern. 00:01:28.880 --> 00:01:33.360 Der Grund für die Anfälligkeit dieser Geräte ist einfach, sie wurden von Anfang an nicht dafür entwickelt, sicher zu sein. 00:01:34.060 --> 00:01:39.340 Das Besondere an den meisten IoT-Geräten ist, dass sie winzige Computer enthalten, kleine Mikrocontroller, die ein oder zwei Aufgaben übernehmen. 00:01:40.220 --> 00:01:45.760 Ursprünglich wurden diese Chips jedoch für Dinge wie Mikrowellenherde und Waschmaschinen entwickelt, also für Dinge, die nicht mit dem Internet verbunden sind. 00:01:45.760 --> 00:01:49.920 Daher haben die Hersteller auf Kosten- und Energieverbrauch geachtet, nicht auf Sicherheit. 00:01:50.620 --> 00:01:51.560 Dann kam das Internet der Dinge. 00:01:52.080 --> 00:01:54.980 Plötzlich mussten all diese billigen, einfachen Chips mit dem Internet verbunden werden. 00:01:55.520 --> 00:01:57.120 Und die Hersteller taten, was Hersteller eben tun. 00:01:57.680 --> 00:01:59.340 Sie fügten ein WLAN-Modul hinzu und fertig. 00:01:59.780 --> 00:02:00.460 Kein sicheres Boden. 00:02:00.780 --> 00:02:02.240 Keine hardware-seitige Vertrauensbasis. 00:02:02.560 --> 00:02:03.540 Kein Aktualisierungsmechanismus. 00:02:03.900 --> 00:02:05.280 Sobald ein Gerät ausgeliefert wurde, war es vorbei. 00:02:05.640 --> 00:02:08.840 Wenn sechs Monate später eine Sicherheitslücke gefunden wurde, gab es keine Möglichkeit, sie zu schließen. 00:02:08.840 --> 00:02:11.100 Das Gerät behielt die Fehler bei, mit denen es ausgeliefert wurde. 00:02:11.560 --> 00:02:13.280 Und diese Geräte bleiben jahrelang im Einsatz. 00:02:13.600 --> 00:02:15.020 Ein werkseitig eingebauter Sensor kann erzielen. 00:02:15.020 --> 00:02:17.760 Ein intelligenter Zähler kann 15 Jahre lang an einem Gebäude hängen. 00:02:18.160 --> 00:02:21.060 Das ist eine lange Zeit für ein anfälliges Gerät, um mit dem Internet verbunden zu sein. 00:02:21.460 --> 00:02:22.260 Die Folgen sind real. 00:02:23.060 --> 00:02:24.620 Bootnetze, die massive Angreife starten. 00:02:25.140 --> 00:02:26.900 Datenschutzverletzungen, die persönliche Informationen offenlegen. 00:02:27.060 --> 00:02:29.600 Kompromittierte Netzwerke, die Angreifern einen Fuß in die Tür von Unternehmen verschaffen. 00:02:30.280 --> 00:02:32.760 Und das alles, weil bei der Entwicklung des Chips niemand an die Sicherheit gedacht hat. 00:02:33.040 --> 00:02:36.080 Also hat sich Microsoft dieses Problems angenommen und beschlossen, etwas von Kunden auf neu zu entwickeln. 00:02:36.320 --> 00:02:39.100 Kein Software-Patch, kein Sicherheitsdienst, den man später hinzufügt. 00:02:39.460 --> 00:02:40.920 Etwas, was beim Silizium selbst beginnt. 00:02:41.920 --> 00:02:43.180 Das ist Azure Sphere im Grunde. 00:02:43.860 --> 00:02:44.440 Das große Gans. 00:02:44.440 --> 00:02:48.260 Azure Sphere ist die durchgängige IoT-Sicherheitsplattform von Microsoft. 00:02:48.940 --> 00:02:51.700 Das klingt nach Marketing-Sprech, also lasst es mich in einfaches Englisch übersetzen. 00:02:52.280 --> 00:02:53.480 Es sind drei Dinge, die zusammenarbeiten. 00:02:54.020 --> 00:02:57.880 Ein zertifizierter Mikrocontroller-Chip, ein sicheres Betriebssystem und ein Cloud-Sicherheitsdienst. 00:02:58.360 --> 00:02:59.000 Man braucht alle drei. 00:02:59.300 --> 00:03:01.260 Nimmt man auch nur eines davon weg, bricht das ganze System zusammen. 00:03:01.520 --> 00:03:04.360 Der Schlüsselbegriff, den man oft hören wird, lautet Sicherheit vom Silizium bis zur Cloud. 00:03:04.720 --> 00:03:05.560 Das sind nicht nur ein Slogan. 00:03:06.060 --> 00:03:09.860 Er bedeutet, dass die Sicherheit auf der physischen Chip-Ebene beginnt und sich bis zum Cloud-Dienst erstreckt, 00:03:09.860 --> 00:03:10.740 der die Geräte verwaltet. 00:03:10.740 --> 00:03:14.080 Jede Ebene ist so konzipiert, dass sie zusammenarbeitet. 00:03:14.560 --> 00:03:15.980 Vergleichen wir das nun mit dem alten Ansatz. 00:03:16.420 --> 00:03:17.680 Die meiste IoT-Sicherheit ist in Add-on. 00:03:18.100 --> 00:03:22.080 Man nimmt einen normalen Chip, führt ein normales Betriebssystem aus und versucht dann später Sicherheitsfunktionen hinzuzufügen. 00:03:22.600 --> 00:03:24.700 Vielleicht verschlüsselt man ein paar Daten, vielleicht versieht man ein Kennboard damit. 00:03:25.120 --> 00:03:28.180 Das ist, als würde man ein Haus mit Wänden aus Papier bauen und dann einen schicken Riegel anbringen. 00:03:28.720 --> 00:03:31.120 Der Riegel funktioniert, aber jemand kann immer noch durch die Wand gehen. 00:03:32.120 --> 00:03:33.500 Azure Sphere verfolgt einen anderen Ansatz. 00:03:33.500 --> 00:03:36.420 Die Sicherheit ist von Anfang an integriert und wird nicht erst später hinzugefügt. 00:03:36.680 --> 00:03:39.480 Der Chip selbst verfügt über Sicherheitsfunktionen, die direkt in das Silizium integriert sind. 00:03:39.920 --> 00:03:42.340 Das Betriebssystem ist speziell für den sicheren Betrieb konzipiert. 00:03:42.840 --> 00:03:44.440 Der Cloud-Dienst verwaltet die gesamte Flotte. 00:03:44.900 --> 00:03:45.820 Hier ist eine hilfreiche Analogie. 00:03:46.160 --> 00:03:47.600 Stellen Sie sich deswegen gesichertes Gebäude vor. 00:03:47.940 --> 00:03:48.960 Der Chip ist die verstärkte Tür. 00:03:49.380 --> 00:03:50.380 Sie ist am Einstiegspunkt stark. 00:03:50.800 --> 00:03:52.620 Das Betriebssystem ist der interne Sicherheitsdienst. 00:03:53.080 --> 00:03:55.880 Es stellt sicher, dass Benutzer nur die Bereiche aufrufen, für die sie zugelassen sind. 00:03:55.880 --> 00:03:57.900 Und der Cloud-Sicherheitsdienst ist die zentrale Überwachungsstation. 00:03:58.400 --> 00:04:01.040 Er überwacht alles, sendet Updates und reagiert auf Probleme. 00:04:01.040 --> 00:04:05.100 Nun stellt sich häufig die Frage, ob Azure Sphere nicht einfach nur eine weitere IoT-Plattform ist. 00:04:05.420 --> 00:04:05.780 Nicht wirklich. 00:04:06.180 --> 00:04:10.500 Bei den meisten IoT-Plattformen wie AWS IoT Core oder Azure IoT Hub geht es darum, 00:04:10.800 --> 00:04:13.120 Geräte mit der Cloud zu verbinden und Daten zu verwalten. 00:04:13.720 --> 00:04:16.080 Bei Azure Sphere geht es speziell um Sicherheit auf Geräteebene. 00:04:16.520 --> 00:04:19.180 Es ist die Grundlage, auf der sichere IoT-Geräte aufgebaut werden können. 00:04:19.580 --> 00:04:21.860 Stellen Sie sich so vor, AWS IoT ist wie ein Postdienst. 00:04:22.300 --> 00:04:24.900 Es transportiert Ihre Daten sicher von Punkt A nach Punkt B. 00:04:25.440 --> 00:04:29.200 Azure Sphere ist wie ein Tresor für Ihre Daten, noch bevor Sie sie dem Postdienst übergeben. 00:04:29.200 --> 00:04:32.860 Sie lösen unterschiedliche Probleme und Sie können beide zusammenverwenden. 00:04:33.280 --> 00:04:34.480 Was macht den Chip also so besonders? 00:04:35.020 --> 00:04:37.760 Lassen Sie uns jede Ebene aufschlüsseln, beginnend mit dem Silizium selbst. 00:04:39.340 --> 00:04:42.160 Ebene 1. Das Silizium. Der Azure Sphere MCU. 00:04:43.120 --> 00:04:45.560 Beginnen wir mit dem Chip selbst, denn dort beginnt alles. 00:04:46.380 --> 00:04:49.460 Das Hardware-Fundament von Azure Sphere ist ein speziell entwickelter Mikrocontroller. 00:04:50.100 --> 00:04:53.380 Derzeit ist der Mediatek MT63 der wichtigste Chip, den man in der Produktion findet. 00:04:54.140 --> 00:04:56.200 Oberflächlich betrachtet sieht er aus wie jeder andere Mikrocontroller. 00:04:56.200 --> 00:05:00.180 Er ist klein, verbraucht relativ wenig Strom und übernimmt grundlegende Rechenaufgaben. 00:05:00.900 --> 00:05:03.220 Was ihn jedoch von anderen unterscheidet, ist das, was er in der Silizium integriert. 00:05:03.480 --> 00:05:06.560 In diesem Chip befindet sich das sogenannte Pluton-Sicherheits-Subsystem. 00:05:07.220 --> 00:05:08.080 Pluton ist keine Software. 00:05:08.560 --> 00:05:11.740 Es ist ein separater, dedizierter Sicherheitsprozessor, der direkt in die Hardware integriert ist. 00:05:12.200 --> 00:05:15.520 Man kann ihn sich als einen winzigen, manipulationssicheren Computer im Hauptcomputer vorstellen. 00:05:15.940 --> 00:05:17.920 Deine einzige Aufgabe ist es, Sicherheitsvorgänge auszuführen. 00:05:18.260 --> 00:05:18.840 Warum ist das wichtig? 00:05:19.120 --> 00:05:21.580 Weil er eine sogenannte Hardware-Vertrauensankerstruktur schafft. 00:05:21.580 --> 00:05:23.460 Das bedeutet das im Klartext. 00:05:23.840 --> 00:05:27.000 Wenn das Gerät eingeschaltet wird, wird als erstes das Pluton-Subsystem ausgeführt. 00:05:27.500 --> 00:05:30.900 Es überprüft seine Eigenidentität auf der niedrigstmöglichen Ebene, dem Silizium selbst. 00:05:31.300 --> 00:05:34.720 Bevor Software geladen wird, bevor das Betriebssystem bootet, bevor irgendetwas anderes passiert. 00:05:35.260 --> 00:05:37.420 So kann der Chip überprüfen, ob er die Person ist, die er vorgibt zu sein. 00:05:37.860 --> 00:05:39.880 Das unterscheidet sich grundlegend von softwarebasierter Sicherheit. 00:05:40.500 --> 00:05:44.380 Bei Software können Sie immer darauf vertrauen, dass vor dem Laden der Sicherheitssoftware nichts manipuliert wurde. 00:05:44.380 --> 00:05:49.500 Wenn jedoch jemand den Bootloader oder die Firmware verändert hat, überprüft Ihre Sicherheitssoftware möglicherweise die falschen Daten. 00:05:49.660 --> 00:05:51.380 Bei hardwarebasierter Vertrauenswürdigkeit gibt es dieses Boot. 00:05:51.700 --> 00:05:54.240 Sie können Pluton nicht verändern, ohne physisch auf den Chip zuzugreifen. 00:05:54.380 --> 00:05:56.600 Und selbst dann ist er so konzipiert, dass er Manipulationen widersteht. 00:05:56.980 --> 00:05:58.680 Von dort aus erzwingt der Chip einen sicheren Start. 00:05:59.020 --> 00:06:02.020 Das Gerät führt nur Software aus, die kryptografisch signiert und genehmigt wurde. 00:06:02.440 --> 00:06:05.560 Wenn jemand versucht, nicht autorisierte Firmware zu laden, lehnt der Chip dies einfach ab. 00:06:05.780 --> 00:06:06.240 Das Gerät schlecht. 00:06:06.520 --> 00:06:07.000 Es läuft nicht. 00:06:07.360 --> 00:06:08.360 Das Gerät bleibt gesperrt. 00:06:08.680 --> 00:06:10.800 Der MT360 verfügt außerdem über einen Cross-Oval-Disk. 00:06:10.800 --> 00:06:15.880 Er kombiniert Echtzeitverarbeitung, wie Sie sie zum Steuern von Motoren oder zum Auslesen von Sensoren benötigen, 00:06:15.960 --> 00:06:17.760 mit Anwendungsverarbeitung für komplexere Aufgaben. 00:06:17.920 --> 00:06:22.880 Das bedeutet, dass ein einzelner Chip sowohl die Low-Level-Steuerung als auch die übergeordnete Konnektivität und Sicherheit verarbeiten kann. 00:06:23.140 --> 00:06:24.660 Es werden keine zwei separaten Prozesse umdreht. 00:06:24.960 --> 00:06:26.580 Warum ist Hardware-Sicherheit nun so wichtig? 00:06:27.140 --> 00:06:28.800 Weil Software-Sicherheit umgangen werden kann? 00:06:29.420 --> 00:06:34.000 Ein cleverer Angreifer kann Fehler im Betriebssystem finden, Sicherheitslücken in Anwendungen ausnutzen 00:06:34.000 --> 00:06:36.360 oder die Software dazu bringen, Dinge zu tun, die sie nicht tun sollen. 00:06:37.000 --> 00:06:38.820 Hardware-Sicherheit ist jedoch viel schwieriger zu knacken. 00:06:38.820 --> 00:06:42.780 Man benötigt physischen Zugriff auf den Chip, spezielle Ausrüstung und viel Zeit und Können. 00:06:43.420 --> 00:06:44.620 Hier ist eine Analogie, die stichhaltig ist. 00:06:45.000 --> 00:06:49.360 Das Pluton-Sicherheits-Subsystem ist wie ein manipulationssicherer Safe, der in das Fundament eines Gebäudes eingebettet ist. 00:06:49.560 --> 00:06:50.260 Man kann ihn nicht bewegen. 00:06:50.640 --> 00:06:52.100 Man kann ihn ohne die richtigen Werkzeuge nicht öffnen. 00:06:52.500 --> 00:06:55.200 Und selbst wenn jemand durch ein Fenster einbricht, ist der Safe immer noch sicher. 00:06:55.660 --> 00:06:57.000 Das ist die Schutzstufe, über die wir sprechen. 00:06:57.600 --> 00:06:58.880 Aber Hardware allein reicht nicht aus. 00:06:59.140 --> 00:07:01.260 Das darüber laufende Betriebssystem ist genauso wichtig. 00:07:02.040 --> 00:07:04.620 Die zweite Ebene, das Betriebssystem, ein abgesichertes Linux. 00:07:05.320 --> 00:07:06.320 Wir haben also diesen sicheren Chip. 00:07:06.420 --> 00:07:07.440 Was wird darauf ausgeführt? 00:07:07.440 --> 00:07:11.820 Ein benutzerdefiniertes, abgesichertes Linux-basiertes Betriebssystem, das speziell für Azure Sphere entwickelt wurde. 00:07:12.280 --> 00:07:14.960 Wenn ich Linux sage, denken Sie vielleicht an Ubuntu oder Debi an. 00:07:15.260 --> 00:07:18.200 Ein allgemeines Betriebssystem, das Sie auf einem Laptop oder einem Server installieren können. 00:07:18.600 --> 00:07:20.260 Das Betriebssystem von Azure Sphere ist ganz anders. 00:07:20.580 --> 00:07:22.100 Es wurde auf das absolute Minimum reduziert. 00:07:22.560 --> 00:07:24.680 Alle nicht unbedingt notwendigen Funktionen wurden entfernt. 00:07:25.040 --> 00:07:28.900 Kein Webserver, keine Desktop-Umgebung, keine unnötigen Treiber, nur die Kernkomponenten, 00:07:28.940 --> 00:07:32.020 die für die Ausführung sicherer Anwendungen und die Kommunikation mit der Cloud erforderlich sind. 00:07:32.900 --> 00:07:33.560 Warum ist das wichtig? 00:07:33.560 --> 00:07:35.960 Weil jede Codezeile eine potenzielle Sicherheitslücke darstellt. 00:07:35.960 --> 00:07:38.280 Je mehr Code, desto mehr Fehler können auftreten. 00:07:38.820 --> 00:07:44.100 Indem Microsoft das Betriebssystem klein hält, reduziert Microsoft das, was Sicherheitsforscher als Trusted Computing Base bezeichnen. 00:07:44.480 --> 00:07:47.240 Also die Menge an Code, der vertrauenswürdig sein muss, damit das System sicher ist. 00:07:48.420 --> 00:07:50.980 Weniger Codezeilen bedeuten weniger Versteckmöglichkeiten für Angreifer. 00:07:51.660 --> 00:07:53.120 Es geht aber nicht nur um das Entfernen-Funktionen. 00:07:53.700 --> 00:07:56.780 Das Betriebssystem erzwingt auch eine sogenannte dynamische Kompartimentierung. 00:07:57.500 --> 00:07:58.880 Das ist ein schicker Begriff für eine einfache Idee. 00:07:58.880 --> 00:08:00.980 Anwendungen sind voneinander isoliert. 00:08:01.700 --> 00:08:05.340 Wenn eine App kompromittiert wird, kann sich das nicht auf andere Apps auswirken, die auf demselben Gerät ausgeführt werden. 00:08:06.160 --> 00:08:10.180 Jede Anwendung wird in einer eigenen Sandbox mit eigenem Speicherplatz und eigenen Berechtigungen ausgeführt. 00:08:10.680 --> 00:08:13.760 Das Betriebssystem steuert auch den Hardwarezugriff über die Optin-Nutzung von Perifliegel. 00:08:14.240 --> 00:08:17.640 Eine Anwendung kann nur Hardwarekomponenten verwenden, für die ausdrücklich Zugriff gewährt wurde. 00:08:18.420 --> 00:08:23.540 Wenn eine App versucht, Daten von einem Sensor auszulesen, für den sie keine Berechtigung hat, wird sie vom Betriebssystem blockiert, ohne Ausnahmen. 00:08:24.560 --> 00:08:27.660 So wird verhindert, dass eine kompromittierte App auf Dinge zugreift, auf die sie nicht zugreifen darf. 00:08:28.300 --> 00:08:30.820 Hier ist nun der Unterschied zu den meisten IoT-Betriebssystemen. 00:08:31.200 --> 00:08:34.340 Microsoft verwaltet und aktualisiert das Betriebssystem, nicht der Gerätehersteller. 00:08:35.040 --> 00:08:37.780 Wenn Microsoft eine Sicherheitslücke findet, wird ein Patch veröffentlicht. 00:08:38.240 --> 00:08:41.900 Dieser Patch wird über den Azure Sphere-Sicherheitsdienst direkt auf die Geräte übertragen. 00:08:42.700 --> 00:08:43.960 Der Hersteller muss nichts weiter tun. 00:08:44.440 --> 00:08:45.980 Er muss den Patch nicht testen oder genehmigen. 00:08:45.980 --> 00:08:48.640 Microsoft kümmert sich um die gesamte Update-Pipeline. 00:08:49.020 --> 00:08:49.760 Das ist ein großer Vorteil. 00:08:50.520 --> 00:08:56.080 In der herkömmlichen IoT-Welt muss der Hersteller bei Entdeckung einer Sicherheitslücke einen fix entwickeln, testen, genehmigen lassen 00:08:56.080 --> 00:08:59.300 und ihn dann irgendwie auf die Geräte bringen, die sich möglicherweise über die ganze Welt verteilen. 00:09:00.380 --> 00:09:02.760 Dieser Prozess kann Monate dauern, wenn er überhaupt stattfindet. 00:09:03.320 --> 00:09:07.340 Bei Azure Sphere erfolgt das Update automatisch, oft innerhalb weniger Tage nach Entdeckung der Sicherheitslücke. 00:09:07.900 --> 00:09:09.380 Warum ist der Betriebssystemansatz so wichtig? 00:09:09.860 --> 00:09:11.920 Denn die meisten IoT-Sicherheitsverletzungen erfolgen auf Software-Ebene. 00:09:12.320 --> 00:09:13.980 Angreifer versuchen in der Regel nicht, die Hardware zu knallen. 00:09:14.500 --> 00:09:15.120 Es ist zu schwierig. 00:09:15.120 --> 00:09:20.020 Sie suchen nach Software-Fehlern, finden ungepatchte Schwachstellen und nutzen schwache Zugriffskontrollen aus. 00:09:20.460 --> 00:09:24.220 Durch die Sperrung des Betriebssystems, die Reduzierung der Angriffsfläche und die Automatisierung von Updates 00:09:24.220 --> 00:09:26.160 beseitigt Azure Sphere die häufigsten Angriffspfade. 00:09:26.580 --> 00:09:29.280 Sie verfügen also über sichere Hardware, auf der ein gesperrtes Betriebssystem ausgeführt wird. 00:09:29.620 --> 00:09:31.860 Doch wie verwalten Sie Tausende dieser Geräte in der Praxis? 00:09:32.460 --> 00:09:33.520 Hier kommt der Cloud-Dienst ins Spiel. 00:09:34.660 --> 00:09:37.280 Ebene 3. Die Cloud, der Azure Sphere-Sicherheitsdienst. 00:09:38.300 --> 00:09:40.900 Sie verfügen also über den sicheren Chip mit einem Hardware-Vertraunzack. 00:09:40.900 --> 00:09:45.020 Sie verfügen über ein gesperrtes Betriebssystem, das Anwendungen isoliert und den Hardware-Zugriff steuert. 00:09:45.680 --> 00:09:46.460 Aber hier ist der Clou. 00:09:46.660 --> 00:09:49.780 Ein Gerät, das am ersten Tag sicher ist, ist es nicht unbedingt auch am tausendte Tag noch. 00:09:50.300 --> 00:09:51.680 Sicherheit ist keine einmalige Einrichtung. 00:09:51.980 --> 00:09:53.140 Es handelt sich um einen fortlaufenden Prozess. 00:09:53.340 --> 00:09:54.520 Hier kommt der Cloud-Dienst ins Spiel. 00:09:54.980 --> 00:09:58.300 Der Azure Sphere-Sicherheitsdienst ist die Kommandozentrale für die gesamte Geräteflotte. 00:09:58.780 --> 00:10:02.100 Jedes Azure Sphere-Gerät stellt während seiner gesamten Lebensdauer eine Verbindung mit diesem Dienst her. 00:10:02.100 --> 00:10:04.160 Diese Verbindung ist nicht optional, sondern zwingend voll. 00:10:04.720 --> 00:10:07.360 Ein Gerät, das den Dienst nicht erreichen kann, funktioniert nicht ordnungsgemäß. 00:10:07.860 --> 00:10:09.300 Das klingt hart, ist aber beabsichtigt. 00:10:10.060 --> 00:10:13.820 So wird sichergestellt, dass jedes Gerät immer verwaltet, überwacht und immer auf dem neuesten Stand ist. 00:10:14.740 --> 00:10:16.400 Ich erkläre Ihnen, was der Dienst tatsächlich tut. 00:10:17.180 --> 00:10:18.900 Erstens die zertifikatbasierte Authentifizierung. 00:10:19.500 --> 00:10:23.660 Jedes Azure Sphere-Gerät wird mit einer eindeutigen, überprüfbaren Identität geliefert, die in die Hardware integriert ist. 00:10:24.080 --> 00:10:27.380 Wenn das Gerät hochfährt und eine Verbindung mit der Cloud herstellt, zeigt es diese Identität an. 00:10:27.380 --> 00:10:33.260 Der Sicherheitsdienst überprüft, ob die Identität gültig ist, ob das Gerät zum richtigen Mandanten gehört und ob es nicht manipuliert wurde. 00:10:34.000 --> 00:10:36.460 Wenn etwas nicht stimmt, kann der Dienst die Verbindung des Geräts blockieren. 00:10:36.880 --> 00:10:41.120 Dies unterscheidet sich grundlegend vom alten Modell, bei dem Geräte einfache Kennwörter oder gemeinsam genutztes Schlüssel verwendet. 00:10:41.420 --> 00:10:43.920 Wenn ein Kennwort gestohlen wird, müssen Sie es auf jedem Gerät ändern. 00:10:44.340 --> 00:10:48.440 Bei der zertifikatbasierten Authentifizierung verfügt jedes Gerät über eigene eindeutige Anmeldeinformationen. 00:10:48.740 --> 00:10:50.920 Die Gefährdung eines Geräts gefährdet nicht den Rest der Flotte. 00:10:51.800 --> 00:10:53.360 Zweitens automatische Over-the-Air-Updates. 00:10:53.880 --> 00:10:54.800 Das ist das ultimative Feature. 00:10:54.800 --> 00:11:02.280 Wenn Microsoft eine Sicherheitslücke im Azure-Sphere-Betriebssystem findet, wird ein Patch entwickelt und über den Sicherheitsdienst direkt an jedes Gerät gesendet. 00:11:03.140 --> 00:11:08.220 Das Gerät lädt das Update herunter, überprüft mithilfe des Hardware-Vertrauensankers, ob es von Microsoft signiert wurde und installiert ist. 00:11:08.680 --> 00:11:10.580 Sie müssen nicht darauf warten, dass der Hersteller einen Fix entwickelt. 00:11:10.900 --> 00:11:13.420 Sie müssen nicht darauf warten, dass IT-Teams Wartungsfenster planen. 00:11:13.980 --> 00:11:16.660 Keine Geräte, die nie aktualisiert werden, weil niemand daran denkt, dies zu überprüfen. 00:11:17.000 --> 00:11:20.460 Das Update erfolgt automatisch, oft innerhalb weniger Tage nach Entdeckung einer Sicherheitslücke. 00:11:20.460 --> 00:11:23.840 Hier ist etwas Wichtiges. Das Gerät kann ein Update nicht ablehnen. 00:11:24.280 --> 00:11:27.360 Wenn der Sicherheitsdienst feststellt, dass ein Update verfügbar ist, muss das Gerät es installieren. 00:11:28.000 --> 00:11:28.920 Das klingt vielleicht nach Kontrolle. 00:11:29.520 --> 00:11:31.300 In der Welt der IoT-Sicherheit ist es jedoch erforderlich. 00:11:31.820 --> 00:11:36.240 Das Mirai-Botnetz entstand, weil Geräte mit bekannten Sicherheitslücken ausgeliefert wurden und niemand diese jemals gepatcht hat. 00:11:36.900 --> 00:11:38.320 Obligatorische Updates verhindern dieses Szenario. 00:11:38.820 --> 00:11:40.080 Drittens Fehlerberichterstattung. 00:11:40.080 --> 00:11:47.460 Wenn auf einem Azure Sphere-Gerät etwas schief geht zum B, ein Absturz, ein Sicherheitsereignis oder ein Hardwarefehler, meldet das Gerät dies an den Sicherheitsdienst. 00:11:48.180 --> 00:11:51.980 Damit erhalten Hersteller und Betreiber Echtzeiteinblicke in den Zustand ihrer gesamten Flotte. 00:11:52.780 --> 00:11:55.380 Wenn sich ein Gerät seltsam verhält, erfahren Sie es sofort. 00:11:56.340 --> 00:11:59.800 Wenn sich bei mehreren Geräten ein Muster herauskristallisiert, können Sie es untersuchen und reagieren. 00:12:00.840 --> 00:12:02.540 Viertens Remote-Überwachung und Nachweis. 00:12:03.060 --> 00:12:06.760 Der Sicherheitsdienst kann überprüfen, ob auf jedem Gerät in Ihrer Flotte noch vertrauenswürdige Software ausgeführt wird. 00:12:06.760 --> 00:12:12.660 Er kann sicherstellen, dass der Startvorgang sauber war, das Betriebssystem nicht geändert wurde und dass es sich um die von Ihnen genehmigten Anwendungen handelt. 00:12:13.320 --> 00:12:17.900 Wenn ein Gerät diese Prüfung nicht besteht, kann der Dienst es zur Untersuchung markieren oder den Zugriff auf ihre Ressourcen sperren. 00:12:18.560 --> 00:12:20.240 Und schließlich die 10-jährige Support-Zusage. 00:12:20.840 --> 00:12:23.700 Microsoft hat sich verpflichtet, Azure Sphere-Geräte ein Jahrzehnt lang zu unterstützen. 00:12:24.280 --> 00:12:30.640 Das bedeutet Sicherheitsupdates, Betriebssystem-Patches und die Verfügbarkeit von Cloud-Diensten für mindestens 10 Jahre ab dem Zeitpunkt, an dem ein Gerät in Betrieb genommen wird. 00:12:30.640 --> 00:12:34.380 Für Industrieanlagen und Infrastrukturen, die jahrelang im Einsatz sind, ist das eine große Sache. 00:12:34.900 --> 00:12:35.700 Hier ist eine Analogie. 00:12:35.700 --> 00:12:40.880 Der Sicherheitsdienst ist wie eine zentrale Überwachungsstation, die jede Tür in einem Gebäude in Echtzeit überwacht. 00:12:41.380 --> 00:12:44.100 Er weiß, wer wann hereingekommen ist und ob sich diese Person dort aufhalten soll. 00:12:44.460 --> 00:12:47.260 Wenn eine Tür beschädigt wird, schickt die Station sofort jemanden los, um sie zu reparieren. 00:12:47.700 --> 00:12:51.340 Außerdem tauscht sie alle paar Monate die Schlöße an allen Türen aus, ohne dass jemand danach fragen muss. 00:12:52.240 --> 00:12:55.200 Betrachten wir nun alle drei Ebenen und schauen, wie sie als ein System funktionieren. 00:12:56.700 --> 00:12:58.500 Wie alles zusammenspielt, ist die wahre Stärke. 00:12:58.500 --> 00:13:00.760 Ich führe sie durch ein realistisches Szenario. 00:13:01.300 --> 00:13:06.420 Stellen Sie sich vor, ein Unternehmen entwickelt einen neuen Industriesensor der Temperatur und Vibration in einer Produktionslinie in einer Fabrik überwacht. 00:13:06.820 --> 00:13:08.060 Dieser Sensor verwendet Azure Sphere. 00:13:08.060 --> 00:13:11.420 Verfolgen wir, was ab dem Moment passiert, indem er zum ersten Mal eingeschaltet wird. 00:13:11.960 --> 00:13:12.400 Schritt 1. 00:13:12.480 --> 00:13:13.100 Der Chip bootet. 00:13:13.700 --> 00:13:15.320 Erinnern Sie sich an das Boot- und Sicherheitssubsystem. 00:13:15.680 --> 00:13:16.620 Das ist, was ausgeführt wird. 00:13:17.240 --> 00:13:22.320 Es überprüft seine eigene Identität auf Hardware-Ebene und stellt dann sicher, dass der Bootloader von Microsoft signiert und genehmigt wurde. 00:13:22.880 --> 00:13:24.480 Erst dann lässt es die Ausführung des Bootloaders zu. 00:13:25.040 --> 00:13:29.060 Wenn jemand versucht hätte, nicht autorisierte Firmware auf den Chip zu flashen, würde der Bootvorgang an dieser Stelle abbrechen. 00:13:30.060 --> 00:13:30.780 Schritt 2. 00:13:30.960 --> 00:13:34.740 Der Bootloader lädt das Betriebssystem, lädt jedoch nicht einfach alles, was im Arbeitsspeicher abgelegt ist. 00:13:35.300 --> 00:13:38.020 Er gleicht das Betriebssystem-Image anhand einer kryptografischen Signatur ab. 00:13:38.360 --> 00:13:42.380 Das Betriebssystem muss sich in einem bekannten, fehlerfreien Zustand befinden, der von Microsoft signiert wurde und nicht manipuliert wurde. 00:13:42.600 --> 00:13:45.260 Wenn das Betriebssystem geändert wurde, verweigert der Chip das Lagen des Betriebses. 00:13:45.480 --> 00:13:46.420 Das Gerät bleibt gesperrt. 00:13:46.840 --> 00:13:47.260 Schritt 3. 00:13:47.540 --> 00:13:51.500 Das Betriebssystem wird gestartet und das Gerät stellt eine Verbindung zum Azure Sphere Sicherheitsdienst her. 00:13:52.260 --> 00:13:54.440 Es legt seine eindeutige zertifikatbasierte Identität vor. 00:13:54.700 --> 00:13:58.980 Der Dienst überprüft, ob dieses Gerät zum richtigen Mandanten gehört und seine Identität gültig ist. 00:13:59.660 --> 00:14:01.800 Wenn alles in Ordnung ist, wird das Gerät da authentifiziert. 00:14:02.460 --> 00:14:02.860 Schritt 4. 00:14:03.340 --> 00:14:05.420 Der Sicherheitsdienst überprüft die Softwareversion des Geräts. 00:14:05.980 --> 00:14:07.200 Wird das neueste Betriebssystem ausgeführt? 00:14:07.640 --> 00:14:09.380 Gibt es Sicherheitspatches, die angewendet werden müssen? 00:14:09.860 --> 00:14:12.400 Wenn Updates verfügbar sind, werden sie sofort vom Dienst bereitgestellt. 00:14:13.020 --> 00:14:15.920 Das Gerät lädt die Updates herunter, überprüft, ob sie signiert sind und installiert sie. 00:14:16.400 --> 00:14:19.480 Erst wenn das Gerät vollständig auf dem neuesten Stand ist, wird mit dem nächsten Schritt fortgeführt. 00:14:19.980 --> 00:14:20.440 Schritt 5. 00:14:20.540 --> 00:14:21.640 Das Gerät nimmt seine Arbeit auf. 00:14:21.800 --> 00:14:27.380 Es beginnt, Telemetriedaten, Temperaturmesswerte, Vibrationspegel und den Betriebsstatus zurück an die Cloud zu senden. 00:14:27.380 --> 00:14:31.040 Die gesamte Kommunikation erfolgt über authentifizierte, verschlüsselte Kanäle. 00:14:31.800 --> 00:14:33.660 Das Gerät empfängt bei Bedarf auch Befehle. 00:14:34.320 --> 00:14:37.260 Dies kann eine Konfigurationsänderung oder eine Anforderung zum Ausführen einer Diagnose sein. 00:14:37.600 --> 00:14:39.280 Jeder Befehl wird überprüft und autorisiert. 00:14:39.880 --> 00:14:41.920 Folgendes geschieht während der Lebensdauer des Geräts. 00:14:42.260 --> 00:14:44.740 Alle paar Wochen oder Monate veröffentlicht Microsoft Sicherheitsupdates. 00:14:45.240 --> 00:14:48.420 Der Azure Sphere Sicherheitsdienst überträgt diese Updates automatisch an das Gerät. 00:14:49.160 --> 00:14:51.060 Das Gerät installiert sie oft ohne Ausfallzeiten. 00:14:51.600 --> 00:14:52.840 Der Anlagenbetreiber muss nichts tun. 00:14:52.840 --> 00:14:56.800 Der Sensor funktioniert einfach weiter, führt aber immer die neueste und sicherste Software aus. 00:14:57.480 --> 00:14:58.340 Wenn etwas schief geht es. 00:14:58.880 --> 00:14:59.020 B. 00:14:59.100 --> 00:15:03.060 Wenn das Gerät abstürzt oder eine Anomalie erkennt, meldet er den Fehler an den Sicherheitsdienst. 00:15:03.740 --> 00:15:04.900 Der Betreiber erhält eine Warnung. 00:15:05.160 --> 00:15:06.260 Er kann den Fehler remote untersuchen. 00:15:06.640 --> 00:15:09.240 Bei Bedarf kann er eine Fehlerbehebung durchführen oder das Gerät neu konfigurieren. 00:15:09.580 --> 00:15:11.580 Und das alles ohne einen Techniker in die Fabrik her schicken zu müssen. 00:15:11.980 --> 00:15:14.100 Die wichtigste Erkenntnis hier ist, etwas ist wert, ist wiederhol zu werden. 00:15:14.460 --> 00:15:16.160 Sicherheit ist kein Feature, das man einem Gerät hinzufügt. 00:15:16.480 --> 00:15:17.840 Sie ist die Grundlage, auf der alles andere läuft. 00:15:18.260 --> 00:15:20.260 Azure Sphere fügt die Sicherheit nicht nachträglich hinzu. 00:15:20.260 --> 00:15:25.140 Das gesamte Gerät, die Hardware, das Betriebssystem und die Cloud-Verwaltung sind von Anfang an auf Sicherheit ausgelegt. 00:15:25.520 --> 00:15:26.800 Das ist die wahre Stärke der Plattform. 00:15:26.940 --> 00:15:29.420 Nicht ein einzelnes Feature, sondern das Zusammenspiel aller drei Ebenen. 00:15:30.100 --> 00:15:34.120 Der Chip stellt den Hardware-Vertrauensanker bereit, das Betriebssystem, die abgesicherte Umgebung 00:15:34.120 --> 00:15:36.580 und der Cloud-Dienst, die laufende Verwaltung und Updates. 00:15:37.500 --> 00:15:39.960 Zusammen ergeben sie etwas, das mehr ist als die Summe seiner Teile. 00:15:40.520 --> 00:15:42.720 Eine Sicherheitsplattform ist jedoch nur so gut wie ihre Erfolgsbelang. 00:15:43.160 --> 00:15:45.220 Sprechen wir also ehrlich über die gefundenen Schwachstellen. 00:15:46.100 --> 00:15:48.440 Das ehrliche Bild, Schwachstellen und Realität. 00:15:48.440 --> 00:15:53.020 Seien wir ehrlich, eine Plattform, die kugelsichere Lösungen verspricht, wird genau unter die Lupe genommen. 00:15:53.520 --> 00:15:54.960 Und Azure Sphere hat ihren Anteil daran gehabt. 00:15:55.440 --> 00:15:58.780 Im Jahr 2020 hat Microsoft die Azure Sphere Security Research Challenge ins Leben. 00:15:59.820 --> 00:16:03.660 Sicherheitsforscher wurden dazu aufgefordert, die Plattform zu untersuchen, Schwachstellen zu finden und diese zu melden. 00:16:03.960 --> 00:16:05.140 Es ist brutal ausnahm das Angebot an. 00:16:05.520 --> 00:16:08.540 Im Laufe der Zeit wurden 31 Schwachstellen im gesamten Stake gefunden. 00:16:09.140 --> 00:16:10.080 Um welche Art von Fehlern handelt es? 00:16:10.080 --> 00:16:13.320 Kernelprobleme, durch die ein Angreifer das System zum Absturz bringen konnte. 00:16:13.440 --> 00:16:17.260 Pfade zur Eskalation von Rechten, durch die eine schädliche App Zugriff auf höherer Ebene erhalten konnte. 00:16:17.580 --> 00:16:18.820 Ausführungen von nicht signiertem Code. 00:16:19.040 --> 00:16:22.120 Die Art von Fehlern, die das Versprechen, dass nur signierte Software ausgeführt werden kann, untergräben. 00:16:22.560 --> 00:16:24.780 Einige davon waren schwerwiegend, einige wenige wurden als kritischer. 00:16:25.120 --> 00:16:26.160 Hier ist nun der wichtige Kontext. 00:16:26.520 --> 00:16:28.020 Microsoft hat diese Untersuchung in Auftrag gegeben. 00:16:28.360 --> 00:16:32.380 Sie haben ein formelles Programm eingerichtet, Forscher bezahlt und jede einzelne gemeldete Sicherheitslücke behoben. 00:16:32.380 --> 00:16:36.620 Jeder dieser 31 Fehler wurde über das automatische Update-System gepatcht, über das wir bereits gesprochen haben. 00:16:36.880 --> 00:16:39.920 Innerhalb weniger Wochen nach der Entdeckung wurden die Fixes auf die Geräte im Einsatz bereitgestellt. 00:16:40.200 --> 00:16:40.740 Und noch etwas. 00:16:41.040 --> 00:16:45.160 Es gibt keine dokumentierten Fälle, in denen diese Sicherheitslücken in der realen Welt ausgenutzt wurden. 00:16:45.660 --> 00:16:46.800 Keine groß angelegten Angriffe. 00:16:47.160 --> 00:16:49.080 Keine Botnetze, die aus Azure Sphere-Geräten aufgebaut wurden. 00:16:49.320 --> 00:16:53.200 Die Untersuchung war gründlich, aber sie war auch, das bedeutet nicht, dass Azure Sphere perfekt ist. 00:16:53.800 --> 00:16:54.640 Keine Plattform ist perfekt. 00:16:54.980 --> 00:16:56.940 Entscheidend ist, wie schnell Probleme gefunden und behoben werden. 00:16:57.300 --> 00:16:59.760 Und in dieser Hinsicht kann Azure Sphere eine starke Erfolgsbilanz vorweisen. 00:16:59.760 --> 00:17:04.300 Die Pipeline für verpflichtende Updates bedeutet, dass jedes Gerät gepatcht wird, wenn eine Sicherheitslücke entdeckt wird. 00:17:04.680 --> 00:17:05.620 Nicht nur einige Geräte. 00:17:05.760 --> 00:17:09.840 Nicht nur Geräte, deren Hersteller sich die Mühe gemacht hat, ein Update zu veröffentlichen, sondern jedes einzelne Gerät. 00:17:10.120 --> 00:17:11.660 Vergleichen Sie das mit dem Rest der IoT-Welt. 00:17:12.300 --> 00:17:16.280 Andere Plattformen weisen ebenfalls Sicherheitslücken auf, aber viele von ihnen verfügen nicht über einen Mechanismus für verpflichtende Abung. 00:17:16.520 --> 00:17:20.180 Eine Sicherheitslücke wird entdeckt, der Hersteller veröffentlicht einen Patch und dann passiert nichts mehr. 00:17:21.000 --> 00:17:23.560 Geräte bleiben jahrelang ungepatcht, weil niemand das Update bereitstellt. 00:17:24.080 --> 00:17:25.280 Azure Sphere beseitigt dieses Problem. 00:17:25.740 --> 00:17:26.680 Der Kompromiss ist jedoch ja. 00:17:26.680 --> 00:17:31.400 Eine eng integrierte Plattform bedeutet starke Sicherheitsgarantien, aber auch Abhängigkeit von Microsoft. 00:17:31.980 --> 00:17:34.340 Sie können das Betriebssystem nicht austauschen oder einen anderen Chip verwenden. 00:17:34.640 --> 00:17:36.440 Sie sind vollständig im Azure Sphere Ökosystem integriert. 00:17:36.740 --> 00:17:38.260 Für manche Organisationen ist das ein Dealbreaker. 00:17:38.940 --> 00:17:41.820 Für andere ist es ein fairer Preis dafür, sich nicht selbst um die Sicherheit kümmern zu müssen. 00:17:42.220 --> 00:17:44.960 Die ehrliche Erkenntnis daraus ist, Azure Sphere ist nicht unverwundbar. 00:17:45.440 --> 00:17:48.880 Es gab Fehler und es wird weitere Fehler geben, aber die Plattform ist so konzipiert, dass sie mit dieser Realität umgehen hat. 00:17:49.220 --> 00:17:53.380 Die Update-Pipeline, der Hardware-Vertrauensanker, das gesperrte Betriebssystem, all das existiert. 00:17:53.380 --> 00:17:55.600 Bei Microsoft wusste, da Schwachstellen gefunden werden würden. 00:17:56.180 --> 00:17:58.220 Das Ziel ist nicht, perfekt zu sein, sondern widerscheinensfähig. 00:17:58.460 --> 00:17:59.380 Also für wen ist das eigentlich da? 00:17:59.840 --> 00:18:00.800 Und wann sollte man sich darum kümmern? 00:18:01.520 --> 00:18:02.140 Für wen ist das gedacht? 00:18:03.260 --> 00:18:03.920 Andungsverlass erbrannt. 00:18:04.300 --> 00:18:05.840 Azure Sphere eignet sich nicht für jedes Gerät. 00:18:06.440 --> 00:18:09.780 Es ist für Geräte vorgesehen, bei denen eine Sicherheitsverletzung mehr kosten würde als das Gerät selbst. 00:18:10.580 --> 00:18:13.100 Denken Sie an industrielle Sensoren, die Fabrikanlagen überwachen. 00:18:13.100 --> 00:18:17.440 Ein kompromittierter Sensor könnte falsche Messwerte senden und die Bediener dazu veranlassen, schlechte Entscheidungen zu tun. 00:18:17.720 --> 00:18:22.000 Oder schlimmer noch, ein Angreifer könnte diesen Sensor als Einfallstor für das Eindringen in das Fabriknetzwerk nutzen. 00:18:22.480 --> 00:18:24.980 Die Kosten einer solchen Sicherheitsverletzung können sich auf Millionen die Produkte zu tun. 00:18:25.760 --> 00:18:30.120 Denken Sie an gewerbliche Geräte, Verkaufsautomaten, HLK-Systeme und Steuerungen für die Gebäudeautomation. 00:18:30.820 --> 00:18:34.000 Diese Geräte stehen an öffentlichen Orten und sind oft jahrelang mit Netzwerken verbunden. 00:18:34.380 --> 00:18:35.160 Niemand aktualisiert sie. 00:18:35.480 --> 00:18:36.240 Niemand denkt an sie. 00:18:36.640 --> 00:18:39.180 Sie sind perfekte Ziele für Angreifer, die nach einem Einstiegspunkt suchen. 00:18:39.180 --> 00:18:43.560 Denken Sie an die Infrastruktur intelligenter Städte, Ampeln, Umweltsensoren und Steuerung für Wassersysteme. 00:18:43.760 --> 00:18:46.960 Wenn diese kompromittiert werden, sind nicht nur Daten, sondern auch physische Ressourcen gefährdet.