Systeme und ihr Umfeld / RZ-Plattform-Management

Von IPMI zu Redfish

Entwicklungen zur Sicherheit des Plattform-Managements im Rechenzentrum

Neue Aufgaben und Architekturen im Rechenzentrum benötigen neue Verfahren zum Server-Management. Dieser Artikel skizziert zunächst etablierte Ansätze zum Plattform-Management und beschreibt dann neuere Herangehensweisen wie die Redfi sh Scalable-Platforms-Management-API-Specifi cation inklusive sicherheitsrelevanter Seiteneffekte sowie Hardware-Root-of-Trust-Verfahren als Möglichkeit zur Sicherung von Systemintegrität.

Von Markus Leberecht, München

Firmware-Integrität

Während Redfish hilft, die übergeordneten Herausforderungen von Plattform-Management-Kommunikation und -Zugang zu adressieren, bleibt doch weiterhin offen, ob ein Serversystem bereits in einem wunschgemäß funktionsfähigen Zustand provisioniert wurde: Eine Fehlkonfiguration der Server-Firmware – sei es aufgrund falscher Prozessentscheidungen, menschlicher Fehler oder wegen Malware auf Firmware-Ebene – ist durch typische Plattform-Management-Verfahren nicht verlässlich aufzudecken.

Doch es gibt bereits Herangehensweisen, die einem Serversystem ermöglichen, seine eigene Konfiguration zu validieren: Während man zwar große Firmware- und Software-Komponenten kaum Byte für Byte mit Referenzumgebungen vergleichen kann, genügt doch die Berechnung von Hashfunktionen der betreffenden Speicherregionen in der Regel, um eine Konfiguration vollständig zu charakterisieren. Durch Vergleich von aktuell errechneten Hashwerten mit zuvor ermittelten Referenzwerten lässt sich eine einigermaßen robuste Aussage über die resultierende Integrität treffen – also mithin die Frage beantworten, ob Firmware und Software in exakt der erwarteten Konfiguration gemessen oder aber modifiziert wurde.

Eine verbreitete Methode, solche Hashwerte nach Berechnung für den späteren Vergleich sicher in einem auf dem Mainboard aufgelöteten oder unauflösbar aufgesteckten Trusted-Platform-Module (TPM) zu speichern, wurde von der Trusted Computing Group in der „TCG PC Specific Implementation Specification for Conventional BIOS“ beschrieben [8]. Die Berechnung und Speicherung der Hashwerte müssen naturgemäß selbst auf abgesicherte Weise stattfinden, bevor das Hauptbetriebssystem eines Servers startet und damit andere Software die Kontrolle über das System übernimmt. Besondere Eigenschaften des TPM stellen dabei sicher, dass Modifikationen der gespeicherten Werte außerhalb der eigentlichen Berechnung – also des Messprozesses – wirksam verhindert werden oder zumindest stets nachweisbar sind.

Aktuelle Verfahren zur Generierung solcher Hashes unterscheiden sich in der Art der Eigensicherung und anhand der Wurzel ihrer Vertrauenskette.

Trusted Execution

Intels „Trusted Execution Technology“ (TXT) etabliert seinen Root of Trust für die Messung durch die Authentifizierung von dediziertem, Intel-signiertem Messcode und dessen Ausführung in einem isolierten Systemzustand. Der Messprozess besteht dabei aus zwei klar getrennten Phasen: Während der ersten, die direkt nach einem System-Reset oder dem Einschalten abläuft, misst der Code die Firmware-Konfiguration und speichert die Hashwerte im TPM. Die zweite Phase läuft in der Regel direkt vor dem Start des auf dem System installierten Bootstacks, der heutzutage häufig aus dem Hypervisor und seinen Gerätetreibern besteht. In diesem Falle misst der authentifizierte Code genau diese Software-Komponenten, bevor sie ausgeführt warden, und speichert erneut die resultierenden Hashes im TPM.

Intels Virtualization-Technology (VT) wird schließlich genutzt, um die Isolation der Speicherbereiche aufrechtzuerhalten, in die diese Software geladen wird – sie verbessert so die Erhaltung der Integrität dieses Measured-Launch-Environment. Durch diesen Prozess spannt TXT eine Vertrauenskette von der anfänglichen hardwareüberwachten Schlüsselvalidierung bis in das erste Bare-Metal- Betriebssystem eines Servers. Dieser Prozess funktioniert heute mit den allermeisten Linux-Implementierungen und auf VMware-Systemen. Durch den Einsatz eines infrastrukturweiten Attestierungsdienstes können diese Hashes wiederum aus den TPMs zusammengezogen und gegen eine Datenbank von Referenzwerten verglichen werden.

Secure Boot

Im Umfeld von Microsoft-Lösungen wird ein etwas anderer Ansatz gewählt: Der Schlüsselcheck durch eine Unifi ed-Extensible-Firmware-Interface-(UEFI)-Umgebung wird im Rahmen des UEFI-Secure-Boot-Verfahrens dazu genutzt, die Signatur eines kompatiblen und gesicherten Bootloaders zu überprüfen. Beim Bootvorgang eines entsprechenden Microsoft-Betriebssystems wird dessen Trusted-Boot-Prozedur die maßgeblichen kritischen Teile des Betriebssystemkerns messen, die dann im Fortgang weitere Überprüfungen durchführen, bevor das System in den Wirkbetrieb übergeht. Über die Option des „Measured Boot“ werden diese Hashes für einen späteren Vergleich oder die Konsolidierung mittels externem Attestierungsdienst auch in das TPM übertragen – wenn auch nicht mit der gleichen Semantik wie bei Intels TXT.

Verbreitung und Ausblick

Zum Redaktionsschluss dieser <kes> sind Intels Verfahren in Partnerprodukten für das VMware-Ökosystem nutzbar, um das Aufspannen kritischer Anwendungen in Cloud-Umgebungen wie OpenStack [9] zu steuern. Sie sind weiterhin als ein Measured-Boot-Verfahren in Linux-Distributionen und Open-Source-Hypervisoren (Xen wie auch KVM) verfügbar.

Passende Attestierungsdienste sind als Open- Source-Implementierungen (OpenAttestation [10]) oder als kommerzielles Produkt von Intel (Cloud Integrity Technology [11]) erhältlich. Beide nutzen einen TXT-unterstützten Measured-Boot-Vorgang und zielen hauptsächlich darauf ab, darauf aufgesetzten Cloud-Umgebungen notwendige „Trust“-Zustands-Informationen zur Orchestrierung zu liefern.

Auch Microsofts Lösung ist seit Windows 8.1 interoperabel mit den TCG-Mechanismen auf Plattform- Ebene, wobei die Sicherheit von der Integrität der Systemsoftware an sich abhängig bleibt. Zum jetzigen Zeitpunkt ist dem Autor allerdings kein kommerzieller Hersteller bekannt, der Microsofts Mechanismus zur Sicherung der Plattform-Integrität im Management der Rechenzentrums- Infrastruktur nutzt.

Mit der Verfügbarkeit und prinzipiell weiten Verbreitung dieser Verfahren zur lokalen oder Fern-Attestierung böte sich aber die Gelegenheit, die Genauigkeit von Plattform-Management-Informationen in großen Configuration-Management-Systemen zu erhöhen. Hierdurch würde sich die Gefahr von fehlkonfi gurierten Systeminstanzen und potenziell kompromittierten Schutzverfahren verringern.

Vor allem die Möglichkeit, Server-Fingerabdrücke auch ohne einen volloperablen Systemzustand zu generieren, stellt eine einzigartige Möglichkeit dar: Konfi gurationsdatenbanken, die derartige Daten automatisch direkt von den Servern oder aus einem zentralen Attestierungsdienst erhalten, würden nicht länger die teils kritische Nutzung von In-Band-Werkzeugen wie Software-Agenten benötigen, die beispielsweise parallel zu produktiven Anwendung und eventuell fremder Kontrolle ablaufen müssten.

Fazit

Das Management moderner Rechenzentren steigt in seiner Komplexität. Die dynamische Anlage von Diensten auf einer größtenteils virtualisierten oder cloudbasierten Infrastruktur bringt höchste Sicherheitsanforderungen für das Plattform-Management mit sich. Ältere Management-Methoden, basierend auf Protokollen wie IPMI, können dies teilweise nur schwer leisten und lassen dadurch Sicherheitsaspekte unbehandelt.

Das „DMTF Redfi sh Scalable Platform Management API“ adressiert eine Reihe dieser Herausforderungen durch neuartige Protokolle, basierend auf modernen Architekturen wie RESTful HTTP, JSON und OData. Es ermöglicht hierdurch eine einfachere Implementierung von Sicherheitsaspekten auf Systemen, die dieses API in der Zukunft unterstützen werden. Hierdurch macht Redfish das Thema Plattform-Management zugänglicher für heutige Rechenzentren und ihre Trends wie DevOps (vgl. <kes> 2014#4, S. 6).

Da mehr und mehr Akteure und Instanzen an der Verwaltung einer Plattform beteiligt sind, werden konsistente Versionen und Konfi gurationen von Firmware und Software zu Schlüsselelementen für stabile und sichere Plattformen. Mechanismen wie Hardware-Root-of-Trustbasierte lokale Attestierung und sichere Ablage von Hashes im TPM machen dies möglich, indem sie Attestierungsdaten direkt an ihrer Quelle erzeugen.

Sie vermeiden daher, externe Informationen aus vielen Management-Datenbanken zusammenführen zu müssen, deren Konsistenz außerhalb der Verfügungsgewalt des Plattform-Management-Teams liegen mag. Da Attestierung in der Lage ist, die Integrität von Firmware- Revision und -Konfi guration sowie des „Bare-Metal“- installierten Software-Stacks sicherzustellen, hilft sie dabei, ein robustes Fundament für die Server-Sicherheit aufzubauen, das dann auch höheren Softwareschichten zugutekommt.

Dr. Markus Leberecht (CISSP) arbeitet im Bereich Cloud Architecture & Security bei der Intel Deutschland GmbH.