CW: Cloud Computing ist ein Leitthema der diesjährigen CeBIT. Was darf sich ein Anwender darunter vorstellen?

Rickmann: Es gibt eine Definition des National Institute of Standards & Technology (NIST) der USA, der wir auch folgen, und die spezifiziert Cloud Computing.

CW: Was gehört dazu?

Rickmann: Dazu zählt einmal der Self-Service durch Abruf, also das eigenständige Bestellen und Konfigurieren von Rechenleistung. Dann ist es ein messbarer Service, wobei der Anwender genau darüber informiert ist, wie viel Leistung er eigentlich abnimmt. Die Elastizität ist ein weiteres Kriterium. Oder anders ausgedrückt, der Anwender kann, wann immer er will, auf eine unbegrenzte Rechner- oder Speicherkapazität zugreifen. Als Viertes hilft dem Anwender ein Pool von Fachleuten, so dass er dieses Know-how nicht vorhalten muss.

Er bezieht ein Komplettangebot als gemanagten Service. Und letztlich gehört zu Cloud Computing der Breitband-Netzzugang. Das sind die fünf Kriterien, die Sie benötigen, um Cloud Computing zu beschreiben. Pragmatisch gesprochen: Rechnerleistung aus dem Netz so viel der Anwender möchte, wann er möchte und variabel bezahlbar.

CW: Was hat der Anwender unter dem Strich davon? Eine Kostenersparnis gegenüber seiner bisherigen IT?

Rickmann: Der große Vorteil ist, dass der Anwender keine großen Anfangsinvestitionen tätigen muss. Er kann mit kleinem Budget sofort auf große Rechenkapazitäten zugreifen - und auch nur dann, wenn er es möchte und braucht. Kostenpflichtigen Leerlauf gibt es nicht. Das sind für mich die entscheidenden Vorteile. Und die Cloud erlaubt es, bei Spitzenlasten schnell auf weitere Ressourcen zuzugreifen, die sonst gekauft werden müssten und später brachlägen. Ein weiterer Pluspunkt ist die Möglichkeit, Services aus unterschiedlichen Lokationen zu beziehen, die man zudem virtualisieren kann.

CW: Also eine IT, die mit meinem Unternehmenserfolg mitwächst, ohne dass ich wie bei der klassischen IT das Ganze vorfinanzieren muss?

Rickmann: Ja, das ist auch eine sehr gute Definition, die Cloud Computing plastisch veranschaulicht.

Cloud-Kürzel und Private Cloud

CW: Die Anwender werden mit Cloud-Begriffen und -Kürzeln überhäuft. Inwieweit unterscheidet sich Cloud von Konzepten, die unter Begriffen wie ASP, SaaS, Virtualisierung und Hosted VoIP vor zwei bis drei Jahren en vogue waren?

Rickmann: Die Techniken sind jetzt wesentlich reifer. So sind die Zugriffsmöglichkeiten deutlich standardisierter geworden, und die nötigen Bandbreiten sind nun da. Viele technische Voraussetzungen, die früher etwa beim Application-Service-Providing (ASP) fehlten, sind heute geschaffen. Diese Techniken sind inzwischen Standard und abrufbar. Das ist ein wesentlicher Unterschied für die Voraussetzungen für Cloud Computing. Ansonsten finden Sie alle die Begriffe, die Sie genannt haben, in Cloud Computing wieder. Allerdings sind noch nicht alle diese Ansätze reif genug, um die genannten fünf Kriterien zu erfüllen.

CW: Das heißt konkret?

Rickmann: Bleiben wir bei ASP.Hier ist es nicht unbedingt gewährleistet, dass ich die Lösung hoch- skalierbar beim Provider abrufen kann. Ebenso ist ein schnelles Hoch- und Runterfahren der Rechenleistung bei den bisherigen ASP-Modellen nicht gewährleistet. Gerade diese Anpassung an einen unterschiedlichen Bedarf ist für mich aber der entscheidende Unterschied zwischen Cloud und den herkömmlichen Verfahren. Beim Cloud Computing sind Voraussetzungen und Standards geschaffen, um variabel Leistung abzurufen.

CW: Cloud ist demnach die ausgereifte Version bereits bekannter Ansätze wie Application-Service-Providing?

Rickmann: Ja, das können Sie so sagen. Und ich bleibe bei der Eingangsdefinition. Wenn nur Teile dieser Kriterien erfüllt werden, dann ist es für mich keine vollständige Cloud-Lösung.

CW: Das ist die technische Seite. Wo ziehen Sie die Grenzlinie zwischen Public und Private Cloud?

Rickmann: Hier werden beide Cloud- Modelle über die Applikationsseite definiert (breit versus standardisiert). Allerdings gibt es in beiden Cloud-Modellen beispielsweise auch reine Infrastrukturangebote, was eine Definition erschwert. Die Unterscheidung ergibt sich deshalb zunächst einmal über die Sicherheit einer Cloud-Umgebung, wodurch dann eben in dem einen Fall (private) in der Regel nur wenige Nutzer über eine hohe Technologiebandbreite (Applikationen, aber auch Infrastrukturplattformen etc.) verfügen. Bei der (unsicheren) Public Cloud hingegen greifen dagegen in der Regel viele Nutzer auf ein bestimmtes, klar eingegrenztes Technologieangebot zurück.

CW: Ist die Private Cloud damit auf Unternehmensnetze beschränkt?

Rickmann: Bereits heute gibt es Anwendungen aus der Cloud, die unternehmensübergreifendes Zusammenarbeiten ermöglichen. In diesen Collaboration Services existieren klare Rollenverteilungen, Zugriffsbestimmungen und -einschränkungen, die ein sicheres Miteinander über Firmengrenzen hinweg in einer Private Cloud erlauben.

CW: Kann ich die Modelle auch hinsichtlich der Lokationen unterscheiden? Bei der Private Cloud weiß ich, wo das RZ steht, bei der Public Cloud dagegen nicht. Meine Daten könnten in China oder den USA liegen?

Rickmann: Beim Private-Cloud-Ansatz - und so verstehen wir ihn auch bei T-Systems - weiß der Anwender zu 100 Prozent, wo seine Daten gehostet werden. Er kann also die technischen Vorteile der Cloud nutzen, ohne dass gesetzliche Vorgaben wie Compliance und Datenschutz zu kurz kommen. Das sind Punkte, nach denen unsere Kunden jeden Tag in jedem Projekt fragen und die ein Muss für sie sind.

Public Cloud und Apps

CW: Und wo ist das Problem bei der Public Cloud?

Rickmann: Bei der Public Cloud haben Sie keinerlei Sicherheit, wo Ihre Daten gehostet werden. Damit haben Sie aufgrund des Patriot Act (in den USA) und anderer gesetzlicher Vorschriften auch keine hundertprozentige Gewissheit darüber, wer außer Ihnen noch auf Ihre Daten zugreift. Allerdings werden Anbieter auch Public-Cloud-Angebote, gepaart mit Infrastructure as a Service, schnüren. Hier wird der Hosting-Ort dann zugesichert.

CW: Wo sehen Sie bei einer Cloud-Migration typische Fallstricke?

Rickmann: Entscheidend ist, dass ein Anwender überprüft, inwieweit seine Applikationslandschaft überhaupt virtualisierbar ist. Diese Hausaufgaben gilt es vorher zu machen. Dazu zählt auch die Frage: Was will ich in die Cloud bringen, und was betreibe ich weiter selbst? Oder wie sieht es mit der Interoperabilität aus? Anwender, die glauben, sie könnten einfach in die Cloud migrieren, werden in Probleme rennen. Meine Empfehlung ist, dies vorher zu prüfen, bevor über ein Cloud-Modell nachgedacht wird.

CW: Sie sprachen Applikationen an. Gibt es Anwendungen die für die Cloud besonders geeignet sind?

Rickmann: Ja, moderne Standardapplikation etwa von SAP können Sie gut in die Cloud bringen. In meinen Augen ist ein Großteil der SAP-Anwendungen für die Private Cloud bereit. Bei der Telekom betreiben wir SAP aus der Private Cloud und wickeln so 1,5 Millionen Rechnungen pro Monat ab.

CW: Und was eignet sich nicht?

Rickmann: Anwendungen, die durch die Migration höhere Kosten verursachen könnten als vorher. Beispielsweise Legacy-Systeme, die - wegen veralteter Software und proprietärer Schnittstellen - nur mit hohem Aufwand in die Cloud-Umgebung eingepasst und betrieben werden können. Auch Anwendungen in Produktionsbetrieben können hierunter fallen. Zwar kann etwa die Logistik-IT rund um die Herstellung eines Autos in der Wolke liegen, jedoch wäre es fatal, wenn an der Produktionsstraße zeitkritische Prozesse unterbrochen würden. Deshalb gilt hier das Prinzip der verteilten Intelligenz: so viel wie möglich in die Wolke - so viel wie nötig am Produktionsstandort.

CW: Wo liegen für den Anwender im LAN und WAN die Herausforderungen bei der Cloud-Migration?

Rickmann: Das ist ein Riesenthema, denn die Leitungsanforderungen werden größer. Auch die Anpassung an die Kundenbedürfnisse und damit eine Variabilisierung wird kommen, ebenso wie SLAs für die Leitung. (jh)

Security-Tipps für die Cloud
Wer sich für Cloud Computing entscheidet, sollte den Anbieter nach den Standards ISO 27001 und 27002 fragen. Dieser und sieben weitere Ratschläge von Cyber-Ark.

1. Management privilegierter Benutzerkonten:
Der Service-Provider muss ein Privileged-Identity-Management-System für die Verwaltung privilegierter Accounts im gesamten IT-Betrieb implementiert haben. Das soll dem Nutzer der Cloud garantieren, dass Policies, Prozesse und Practices seine Anforderungen an die Datensicherheit erfüllen. Dabei sollte der Dienstleister Standards wie ISO 27001 oder 27002 einhalten.

2. Policy-Konformität:
Die Policies und Prozesse des Privileged Identity Management auf Providerseite müssen denen des Unternehmens entsprechen. Im Idealfall sind alle ISO-basiert.

3. Evaluierung:
Im Auswahlprozess sollten Entscheider die Security-Struktur des Service-Providers genau überprüfen und evaluieren. Dabei ist insbesondere darauf zu achten, dass Tools für das Privileged Identity Management eingesetzt werden, die die Security-Policies und -Prozesse automatisch unterstützen.

4. Dokumentation:
Die Richtlinien und Prozesse des Privileged Identity Management müssen Audit- und Reporting-Anforderungen erfüllen. Die verwendeten Lösungen und Technologien sollten dabei schriftlich in Verträgen und Service Level Agreements festgehalten werden.

5. Definition von Rollen:
Policies müssen den privilegierten User-Zugang regeln und limitieren. Dabei ist eine "Separation of Duties" zwingend erforderlich.

6. Keine versteckten Passwörter:
Es sollten keine eingebetteten Applikationspasswörter verwendet werden, die Zugang zu Backend-Systemen oder Datenbanken bieten.

7. Überwachung:
Der Service-Provider muss die privilegierten Benutzerkonten permanent kontrollieren und überwachen.

8. Reporting:
Zu allen privilegierten User-Accounts muss es hinsichtlich Zugriffen und Aktivitäten Protokolle und Reportings geben. Dabei sollte der Service-Provider seinem Kunden ein wöchentliches oder zumindest monatliches Reporting zur Verwendung privilegierter Accounts zur Verfügung stellen.