Schlagwort-Archive: Tag 1

Dare to Bare – Container auf Bare Metal

Dadurch, dass entweder die Virtualisierungsplattform oder der IaaS Layer wegfallen, wird die Infrastruktur sofort weniger komplex. Das wirkt sich positiv auf den Betrieb aus. Es gibt weniger Netzwerke, Hosts und Disks, die verwaltet werden müssen, daher kann die Infrastruktur auch von weniger Leuten betrieben werden.

Jeder Layer weniger in der Infrastruktur führt logischerweise auch dazu, dass das System weniger fehleranfällig wird, es gibt eine Ebene weniger, auf der etwas schief gehen kann, bzw. um die sich jemand kümmern muss.

Das Thema Performance wurde bereits in der Einleitung angesprochen: Ressourcen sind auf Bare Metal effizienter nutzbar. Es können also die gesamten Hardware-Ressourcen genutzt werden, da keine Ressourcen für die Hardwareemulation durch einen Virtualisierungslayer verwendet werden.

Damit eliminiert man eine doppelte Datenkapselung und auch das Networking wird schneller. Es sind also nicht zwei SDNs übereinandergestapelt, sondern es gibt nur eines, was die Performance erhöht.

Interessant ist auch, dass man für eine solche Cloud sehr gut recht einfache Hardware ohne grossartige Redundanzen verwenden kann. Es ist nicht nötig, in doppelte Stromversorgungen oder redundante Netzwerkanbindungen zu investieren, da bei einem Ausfall eines Systems das Containermanagement dafür sorgt, das die Container direkt neu auf einem anderen System gestartet werden, bzw. sowieso in mehreren Instanzen bereits über mehrere Systeme verteilt sind. Wenn also ein Server kaputt ist, wird er einfach durch einen neuen ersetzt, der muss nur eingeschaltet werden, den Rest erledigt das Cloudmanagement.

Wenn man die Services, die einen IaaS Layer bilden, wie zum Beispiel OpenStack, in Containern laufen lässt, dann schlägt man zwei Fliegen mit einer Klappe: Das Containerframework sorgt nämlich auch bei diesen Services für Hochverfügbarkeit und zugleich stellen die IaaS Services einen willkommenen Mehrwert dar, beispielsweise im Bereich Storage und Bare Metal Management. Und man kann für den Anwendungsfall VM bzw. Cloud-Instanz auch diese zur Verfügung stellen.

Zum Schluss noch ein kurzer Abstecher ins Reich der Sicherheit. Wer seine Anwendung auf Bare Metal Hosts laufen lässt und diese selber betreibt, hat die Sicherheit in eigenen Händen. Mit einer VM in einer Public Cloud sieht es schon anders aus, ein Leck auf irgendeiner anderen VM in der Umgebung kann sich durchaus auch auf die eigene VM auswirken. In einer Bare Metal Umgebung lassen sich Anwendungen oder auch Kunden bei Bedarf physisch trennen.

Natürlich gibt es auch Nachteile, wenn man seine Container auf Bare Metal betreibt. Einer davon ist, dass die Plattform sich nicht so flexibel skalieren lässt, wie das auf Public Cloud Instanzen der Fall ist. Man muss eben rechtzeitig neue Hardware bestellen und ins Rack einbauen, wenn man so eine Plattform selbst InHouse betreiben will. Doch es gibt zunehmend mehr Cloud Provider, die einem Bare Metal Performance für Container anbieten. Wenn man die fallenden Kosten für Hardware und die immer komplexer werdenden Container Ökosysteme in Betracht zieht, scheint der Bare Metal Cloud ein Platz in der Zukunft sicher.

Die Cloud ist der Computer von jemand anderem

Beinahe jeden Tag kann man etwas über «Datenreichtum» lesen. Das ist ein Jargonbegriff dafür, wenn auf einmal die Daten eines Unternehmens für jeden im Internet zur Verfügung stehen – sehr oft finden sich diese Daten dann in «der Cloud». Das will ein Unternehmen auf der einen Seite natürlich absolut vermeiden, auf der anderen Seite wird von ihm gefordert, effizient und konkurrenzfähig zu bleiben. Cloud Computing in jeder Ausprägung drängt sich zur Effizienzsteigerung geradezu auf. Doch worauf muss man achten, damit man nicht auf einmal mit einem Daten- Super-GAU in der Zeitung steht? Worauf kommt es denn wirklich an? Die Antwort auf diese Frage ist wie immer nicht einfach.

Eine Verschlüsselung schützt nur bedingt

Zunächst muss einem ganz klar sein, dass man seine Daten aus der Hand gibt. Diese Tatsache darf man nie aus den Augen verlieren: eine Verschlüsselung schützt Daten, die gerade nicht  benutzt werden, und sichert sie auf dem Übertragungsweg. Im Speicher zur Verarbeitung hingegen sind Daten immer unverschlüsselt Auch die beste Verschlüsselung nützt nichts, den wer Zugriff auf den Speicher hat, kommt auch an die Daten. Also ist die nächste Frage: Wer hat Zugriff auf diesen Speicher? Auf jeden Fall der Cloud-Anbieter und je nach Gesetzeslage im Land des Anbieters auch die Behörden des jeweiligen Landes. Dies führt zur Vertrauensfrage: Wem vertraue ich meine Daten an? Ist die Auslagerung mit der Sorgfaltspflicht vereinbar? Besitzt der Cloud-Anbieter die notwendige Kompetenz im Security-Bereich? Sind aussagekräftige Zertifizierungen nac ISO vorhanden und werden SLAs angeboten?

Daten nach Vertraulichkeit klassifizieren

Mit diesen Fragen im Hinterkopf müssen die Daten hinsichtlich ihrer Vertraulichkeit klassifiziert werden. Dann erfolgt die Absicherung ganz klassisch nach den Prinzipien «Need to Know» und «Least Privilege», aus denen sich ergibt, welche Daten «raus» und welche nur intern verarbeitet werden dürfen. Erst vorbereitete Patentanträge gehören nicht auf ein Cloud-Laufwerk! Nachdem klar ist, welche Daten in der Cloud sind, muss dafür gesorgt werden, dass sie nicht unbefugt manipuliert werden können beziehungsweise dass Manipulationen sofort erkannt werden. Hier gelten die gleichen Regeln wie innerhalb der eigenen Infrastruktur: die technische Umsetzung von Verschlüsselung und Integritätschecks muss neuesten und höchsten Standards genügen. Manipulierte Berechnungen eines tragenden Bauteils können den Mitbewerbern ungeahnte Vorteile am Markt verschaffen. Sicherlich ist es auch eine gute Investition, die Einhaltung dieser Regeln regelmässig und unabhängig überprüfen zu lassen.

Worauf es bei der Cloud Security wirklich ankommt

Wer dies alles richtig umgesetzt und die Datenklassifizierung bezüglich der «Cloud-Fähigkeit» in seiner Security Policy verankert hat, ist weitestgehend auf der sicheren Seite. Dass dort für Server und Speicher in der Cloud die gleichen beziehungsweise strengere Sicherheitsmassnahmen definiert sein müssen wie für interne Systeme, versteht sich von selbst. Auch hier schadet ein Audit nicht, eine unabhängige Partei ist nicht von der eigenen Betriebsblindheit betroffen. Worauf es also wirklich ankommt, ist, sich stets darüber im Klaren zu sein, dass eine Cloud der Computer von jemand anderem ist, daraus die richtigen Schlüsse zu ziehen und eine klare Linie zu haben, was man dort tut, und was besser nicht.