Freigeben über

Leitfäden zur Reduzierung von siliziumbasierten Mikroarchitekturen und spekulative Ausführungen von Side-Channel-Sicherheitsrisiken

  • Artikel

Gilt für: ✔️ Linux-VMs ✔️ Windows-VMs ✔️ Flexible Skalierungsgruppen ✔️ Einheitliche Skalierungsgruppen

Dieser Artikel enthält Leitfäden für eine neue Klasse von Sicherheitsrisiken durch siliziumbasierte Mikroarchitekturen und spekulative Ausführungen von Seitenkanalangriffen, die sich auf viele moderne Prozessoren und Betriebssysteme auswirken. Dazu gehören Intel, AMD und ARM. Spezifische Details zu diesen siliziumbasierten Sicherheitsrisiken finden Sie in den folgenden Sicherheitshinweisen und CVEs:

Die Offenlegung dieser CPU-Sicherheitsrisiken hatte Fragen von Kund*innen zur Folge, die sich mehr Klarheit wünschen.

Microsoft hat Maßnahmen zur Minderung dieser Risiken für alle Clouddienste bereitgestellt. Die Infrastruktur, in der Azure ausgeführt und Kundenworkloads voneinander isoliert werden, ist geschützt. Dies bedeutet, dass ein potenzieller Angreifer, der dieselbe Infrastruktur nutzt, Ihre Anwendung über diese Sicherheitsrisiken nicht angreifen kann.

In Azure wird nach Möglichkeit die Wartung mit Speicherbeibehaltung genutzt, um die Auswirkungen für Kunden möglichst gering zu halten und auf Neustarts verzichten zu können. In Azure werden diese Methoden eingesetzt, wenn systemweite Updates am Host vorgenommen werden, um unsere Kunden zu schützen.

Weitere Informationen dazu, wie die Sicherheit in alle Bereiche von Azure integriert ist, finden Sie auf der Website mit der Dokumentation zur Azure-Sicherheit.

Hinweis

Seit der ersten Veröffentlichung dieses Dokuments wurden mehrere Varianten dieser Sicherheitsrisikoklasse öffentlich gemacht. Microsoft investiert weiterhin stark in den Schutz seiner Kunden und in die Bereitstellung von Anleitungen. Diese Seite wird aktualisiert, wenn weitere Fehlerbehebungen veröffentlicht werden.

Kund*innen, die auf ihrer VM nicht vertrauenswürdigen Code ausführen, müssen Maßnahmen ergreifen, um sich vor diesen Sicherheitsrisiken zu schützen. Dazu sollten sie die Leitfäden unten zu allen Sicherheitsrisiken lesen.

Andere Kunden sollten diese Sicherheitsrisiken aus einer Perspektive der tiefgehende Verteidigung bewerten und die Auswirkungen der gewählten Konfiguration auf Sicherheit und Leistung berücksichtigen.

Betriebssysteme auf dem neuesten Stand halten

Ein Betriebssystemupdate ist zwar nicht erforderlich, um Ihre in Azure ausgeführten Anwendungen gegenüber anderer Azure-Kundschaft zu isolieren, aber es gilt immer als bewährte Methode, die Software auf dem neuesten Stand zu halten. Die neuesten Sicherheitsupdates für Windows enthalten Maßnahmen zur Minderung dieser Sicherheitsrisiken. Auch für Linux-Distributionen wurde mehrere Updates zu diesen Sicherheitsrisiken veröffentlicht. Hier sind unsere empfohlenen Maßnahmen zur Aktualisierung Ihres Betriebssystems aufgeführt:

Angebot Empfohlene Maßnahme
Azure Cloud Services Aktivieren Sie automatische Updates, oder stellen Sie sicher, dass das neueste Gastbetriebssystem ausgeführt wird.
Virtuelle Azure Linux-Computer Installieren Sie Updates vom Anbieter Ihres Betriebssystems. Weitere Informationen finden Sie unter Linux in diesem Dokument.
Virtuelle Azure Windows-Computer Installieren Sie das aktuelle Sicherheitsrollup.
Weitere Azure PaaS-Dienste Für Kundschaft, die diese Dienste verwendet, sind keine Maßnahmen erforderlich. Azure hält Ihre Betriebssystemversionen automatisch auf dem neuesten Stand.

Zusätzliche Anleitungen für den Fall, dass nicht vertrauenswürdiger Code ausgeführt wird

Für Kund*innen, die für nicht vertrauenswürdige Benutzer*innen die Ausführung von beliebigem Code zulassen, kann es ratsam sein, für ihre Instanzen von Azure Virtual Machines oder Cloud Services zusätzliche Sicherheitsfunktionen zu implementieren. Diese Features bieten Schutz vor den prozessinternen Offenlegungsvektoren, mit denen mehrere Sicherheitsrisiken vom Typ „Spekulative Ausführung“ beschrieben werden.

Beispielszenarien, für die zusätzliche Sicherheitsfunktionen empfohlen werden:

  • Sie lassen zu, dass Code, den Sie nicht als vertrauenswürdig ansehen, auf Ihrer VM ausgeführt wird.
    • Beispielsweise lassen Sie für einen Ihrer Kunden das Hochladen einer Binärdatei oder eines Skripts zu, die bzw. das Sie dann in Ihrer Anwendung ausführen.
  • Sie lassen für Benutzer und Benutzerinnen, die Sie nicht als vertrauenswürdig ansehen, das Anmelden auf Ihrer VM mit Konten mit geringen Rechten zu.
    • Beispielsweise lassen Sie zu, dass sich ein Benutzer mit geringen Rechten an einer Ihrer VMs per Remotedesktop- oder SSH-Verbindung anmeldet.
  • Sie lassen für nicht vertrauenswürdige Benutzer den Zugriff auf virtuelle Computer zu, die über die geschachtelte Virtualisierung implementiert werden.
    • Beispielsweise steuern Sie den Hyper-V-Host, aber ordnen die VMs nicht vertrauenswürdigen Benutzern zu.

Kundschaft, die kein Szenario mit nicht vertrauenswürdigem Code implementiert, muss diese zusätzlichen Sicherheitsfunktionen nicht aktivieren.

Aktivieren von zusätzlicher Sicherheit

Sie können auf Ihrer VM oder in Ihrem Clouddienst zusätzliche Sicherheitsfunktionen aktivieren, wenn Sie nicht vertrauenswürdigen Code ausführen. Stellen Sie gleichzeitig sicher, dass Ihr Betriebssystem auf dem neuesten Stand ist, um Sicherheitsfunktionen auf Ihrem virtuellen Computer oder in Ihrem Clouddienst zu aktivieren.

Windows

Ihr Zielbetriebssystem muss aktuell sein, damit Sie diese zusätzlichen Sicherheitsfunktionen aktivieren können. Es sind zwar standardmäßig mehrere Maßnahmen zur Risikominderung aktiviert, aber die hier beschriebenen zusätzlichen Features müssen manuell aktiviert werden und können sich auf die Leistung auswirken.

Option 1:

Schritt 1: Befolgen Sie die Anweisungen unter KB4072698, um mit dem SpeculationControl-PowerShell-Modul sicherzustellen, dass der Schutz aktiviert ist.

Hinweis

Wenn Sie dieses Modul bereits zu einem früheren Zeitpunkt heruntergeladen haben, müssen Sie die neueste Version installieren.

Informationen zum Überprüfen, ob ein Schutz vor diesen Sicherheitsrisiken aktiviert ist, finden Sie unter Grundlegendes zur Ausgabe des PowerShell-Skripts „Get-SpeculationControlSettings“.

Wenn kein Schutz aktiviert ist, wenden Sie sich an den Azure-Support, um zusätzliche Kontrollen auf Ihrer Azure-VM zu aktivieren.

Schritt 2: Befolgen Sie die Anweisungen in KB4072698, um die Betriebssystemunterstützung für KVAS (Kernel Virtual Address Shadowing) und BTI (Branch Target Injection) zu aktivieren, damit Schutz über die Session Manager-Registrierungsschlüssel aktiviert wird. Es ist ein Neustart erforderlich.

Schritt 3: Für Bereitstellungen mit Verwendung von geschachtelter Virtualisierung (nur D3 und E3): Diese Anleitung gilt innerhalb der VM, die Sie als Hyper-V-Host verwenden.

  1. Befolgen Sie die Anleitung unter KB4072698, um den Schutz über die MinVmVersionForCpuBasedMitigations-Registrierungsschlüssel zu aktivieren.
  2. Legen Sie den Typ des Hypervisorplaners auf Core fest, indem Sie diese Anweisungen ausführen.

Option 2:

Deaktivieren von Hyperthreading auf der VM: Kund*innen, die nicht vertrauenswürdigen Code auf einer VM mit Hyperthreading ausführen, können das Hyperthreading deaktivieren oder zu einer VM-Größe ohne Hyperthreading wechseln. Eine Liste mit VM-Größen mit Hyperthreading finden Sie in diesem Dokument. (Bei diesen VM-Größen beträgt das Verhältnis zwischen vCPU und Kern 2:1.) Mit dem folgenden Skript können Sie über die Windows-Befehlszeile auf der VM ermitteln, ob Hyperthreading für Ihre VM aktiviert ist.

Geben Sie wmic ein, um die interaktive Benutzeroberfläche aufzurufen. Geben Sie dann den folgenden Befehl ein, um die Menge der physischen und logischen Prozessoren auf der VM anzuzeigen.

CPU Get NumberOfCores,NumberOfLogicalProcessors /Format:List

Wenn die Anzahl logischer Prozessoren die Anzahl physischer Prozessoren (Kerne) übersteigt, ist Hyperthreading aktiviert. Wenn Sie eine VM mit Hyperthreading ausführen, wenden Sie sich an den Azure-Support, um Hyperthreading zu deaktivieren. Nach Deaktivierung des Hyperthreadings ist ein vollständiger Neustart des virtuellen Computers erforderlich. Unter Anzahl der Kerne erfahren Sie, warum sich die Anzahl Ihrer VM-Kerne verringert hat.

Option 3

Für CVE-2022-23816 und CVE-2022-21123 (AMD CPU Branch Type Confusion) befolgen Sie Option 1 und Option 2 oben.

Linux

Für die Aktivierung der internen zusätzlichen Sicherheitsfunktionen ist es erforderlich, dass das Zielbetriebssystem auf dem aktuellsten Stand ist. Einige Maßnahmen zur Risikominderung sind standardmäßig aktiviert. Im folgenden Abschnitt werden die Funktionen beschrieben, die standardmäßig deaktiviert sind bzw. für die eine Hardwareunterstützung (Microcode) benötigt wird. Die Aktivierung dieser Funktionen kann zu einer Beeinträchtigung der Leistung führen. Weitere Informationen finden Sie in der Dokumentation Ihres Betriebssystemanbieters.

Schritt 1: Deaktivieren von Hyperthreading auf dem virtuellen Computer: Kunden, die nicht vertrauenswürdigen Code auf einem virtuellen Computer mit Hyperthreading ausführen, müssen das Hyperthreading deaktivieren oder zu einem virtuellen Computer ohne Hyperthreading wechseln. Eine Liste mit VM-Größen mit Hyperthreading finden Sie in diesem Dokument. (Bei diesen VM-Größen beträgt das Verhältnis zwischen vCPU und Kern 2:1.) Um zu ermitteln, ob Sie eine VM mit Hyperthreading ausführen, führen Sie auf der Linux-VM den Befehl lscpu aus.

Bei Thread(s) per core = 2 ist Hyperthreading aktiviert.

Bei Thread(s) per core = 1 ist Hyperthreading deaktiviert.

Beispielausgabe für einen virtuellen Computer mit aktiviertem Hyperthreading:

CPU Architecture:      x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1

Wenn Sie eine VM mit Hyperthreading ausführen, wenden Sie sich an den Azure-Support, um Hyperthreading zu deaktivieren. Nach Deaktivierung des Hyperthreadings ist ein vollständiger Neustart des virtuellen Computers erforderlich. Unter Anzahl der Kerne erfahren Sie, warum sich die Anzahl Ihrer VM-Kerne verringert hat.

Schritt 2: Informationen zum Abwehren der folgenden CPU-basierten Sicherheitsrisiken für den Arbeitsspeicher finden Sie in der Dokumentation Ihres Betriebssystemanbieters:

Anzahl Kerne

Bei der Erstellung eines virtuellen Computers mit Hyperthreading ordnet Azure zwei Threads pro Kern zu. Diese werden als vCPUs bezeichnet. Wird Hyperthreading deaktiviert, entfernt Azure einen Thread und zeigt Singlethread-Kerne (physische Kerne) an. Aufgrund des Verhältnisses von 2:1 zwischen vCPU und CPU sieht es nach der Deaktivierung des Hyperthreadings so aus, als hätte sich die CPU-Anzahl des virtuellen Computers halbiert. Ein Beispiel: Bei einem virtuellen Computer vom Typ „D8_v3“ handelt es sich um einen virtuellen Computer mit Hyperthreading, der auf acht vCPUs (vier Kerne mit jeweils zwei Threads pro Kern) ausgeführt wird. Wenn nun Hyperthreading deaktiviert wird, geht die CPU-Anzahl auf vier physische Kerne mit einem einzelnen Thread pro Kern zurück.

Nächste Schritte

Weitere Informationen dazu, wie die Sicherheit in alle Bereiche von Azure integriert ist, finden Sie in der Dokumentation zur Azure-Sicherheit.