3. April 2010
Cloud = Wolke, Computing = Rechnen, Cloud Computing ist also das „Rechnen in der Wolke“. Ok, ich denke nach 30 Sekunden, den Vortrag hätte ich mir sparen können. Für meinen Geschmack wird das zu trivial und oberflächlich.
Lustige (und unvollständige) Liste der Cloud Computing Anbieter (alphabetisch): 3tera, Amazon, Google, Microsoft, Rackspace, Salesforce.com, Yahoo, Zoho.
Lustige Unterscheidung: Public und Private Cloud. Na gut. Public = bei anderen; Private = bei mir.
Lustige Abkürzungen: IaaS (Infrastructure as a Service = man mietet sich virtuell einen Server), z.B. Amazon EC2, 3tera; PaaS (Platform as a Service = man mietet sich ein Framework auf einer definierten Betriebssystemplattform), z.B. Google App Engine, Windows Azure und SaaS (Software as a Service = man mietet sich ein Programm), z.B. Google Apps, Salesforce.com.
Lustige Anwendungszwecke: Online-Backup, File-Sharing, Online-Communitys (Facebook, Twitter, etc.), Online-Dienste (Mail, Office, Kalender).
Lustige Open Source Frameworks: Eucalyptus (Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems), openQRM und Ubuntu Enterprise Cloud (UEC).
Die Vor- und Nachteile der Cloud werden im Vortrag einfach direkt zusammengewürfelt, ohne zwischen den Anbieterformen (IaaS, PaaS, SaaS) und den konkreten Angeboten zu unterscheiden. Ein virtuelles System kann man ggf. zu einem anderen Anbieter umziehen. Bei Amazon kann man sogar das Rechenzentrum spezifizieren (wenn z.B. Daten in der EU gespeichert werden müssen). Eine Google App kann man halt nicht umziehen und die Daten auch nur schwer exportieren.
Was mir in dem Vortrag fehlte, war vor allem eine Analyse von Cloud Computing zum Thema Datenschutz und Datensicherheit. Was ist, wenn die Daten bei einem US-Anbieter liegen? Wie sieht es allgemein mit der Sicherheit aus, kann man sich z.B. auf das Patchmanagement des Anbieters verlassen? Wie können Schlagwörter wie „Virenschutz in the Cloud“ interpretiert werden.
Und ja, es war zu trivial und oberflächlich.
Politisch ist das Profilierung ein heikles Thema, das gesellschaftlich in der angewandten Form sicher nicht akzeptiert würde. Praktisch ist es hochspannend zu sehen, wie knappe Ressourcen zugewiesen werden. Ich denke, vergleichbares werden wir in der Medizin (Medikamente, Operationen) in naher Zukunft auch verstärkt erleben.
Profiliert wird laut Vortrag nach den Kriterien:
- Arbeitsmark (wie hoch ist die lokale Arbeitslosigkeitsrate, wie viele offene Stellen gibt es)
- Motivation (wie bereit ist der Arbeitslose, Stellen in der größeren Entfernung zu suchen, weniger Gehalt zu akzeptieren, etc.)
- Qualifikation (welche Berufserfahrung hat ein Arbeitsloser)
- Hemmnisse (welche weiteren Probleme stehen einer Arbeitsaufnahme entgegen? beispielsweise Alter über 50, Kinder, kein Führerschein, keiin Auto, …)
Unterschieden wird nach
- Marktkunden (dürften leicht wieder eine Stelle finden) erhalten eine hohe finanzielle Förderung aber wenig Betreuung
- Aktivierungskunden (müssen motiviert (und/oder schikaniert) werden) und
- Förderungskunden (werden qualifiziert, erhalten Weiterbildungsmaßnahmen) erhalten eine mittlere finanzielle Förderung aber eine intensive Betreuung
- Betreuungskunden (werden nur noch verwaltet) erhalten kaum finanzielle Förderung und wenig Betreuung.
Sobald ein „Kunde“ zwei „Probleme“ hat, fällt er praktisch in die Gruppe der Betreuunngskunden hinein, die nur noch verwaltet werden. Insbesondere Arbeitslose in wirtschaftlichen Randgebieten haben weniger Chancen auf Förderung als Arbeitslose in wirtschaftlich guten Gebieten, da der schlechte Arbeitsmarkt bereits als erstes Prroblem gilt und ein zweites Problem dann zum Betreuungskunden führt. Ein gleichqualifizierter und gleichmotivierter Arbeitsloser würde beispielsweise in München gefördert (wirtschaftlich gute Region), in Neubrandenburg (Mecklenburg-Vorpommern) jedoch nicht.
Ziel der Förderung der Arbeitsagenturen ist oft primär, durch Einsatz von Mittel die Bezugsleistung des Arbeitslosengeldes zu verringern und damit Bundesgeld einzusparen. Bezieher von Hartz 4 erhalten ihr Geld von den Kommunen, deren Förderung ist der Arbeitsagentur weitgehend egal, da das Geld aus einem anderen Haushalt kommt.
Während der Laufzeit eines Programms lassen sich noch einige Tricks umsetzen, um die Sicherheit von Programmen zu verbessern, indem beispielsweise Exploits für mögliche Buffer Overflows erschwert oder verhindert werden. Dafür kommen Techniken wie Stack Randomization (d.h. der Stackanfang wird bei jedem Programmstart zufällig auf eine etwas andere Adresse gesetzt, Einsprungadressen für Exploits verändern sich dann bei jedem Programmaufruf, ein Exploit wird unzuverlässig), Shared Library Randomization (d.h. gemeinsam genutzte Bibliotheken wie die Libc werden in zufälliger Reihenfolge und zufällig an unterschiedliche Adressen gemappt, sogenannte Return-to-Libc-Exploits, die eine bestimmte Adresse der in der Libc anspringen müssen werden dadurch unzuverlässig), etc. zum Einsatz.
Aktuelle verbreitete Maßnahmen sind:
- data/code separation (siehe Harvard Architektur)
- randomized stack bottom
- shared libs randomization
- randomized malloc
Viele dieser Maßnahmen wurden als erstes in OpenBSD implementiert. Mögliche Verbesserungen enthalten
- section starting address randomization (16 Bit Entropie)
- randomized loading order (abhängig von der Anzahl der Bibliotheken)
Zu den obskureren Verfahren gehört dann wohl
- executable randomization (pie executables)
- gaps filled with bad stuff (keine NOP-Sleds mehr)
- morphing executables (ah … die Virenscanner freuen sich)
Einige dieser Maßnahmen würden bis zu 10% Performanceeinbußen mitbringen, hier wäre eine Abwägung zwischen Leistung und Sicherheit notwendig.