Das Thema Cloud ist in all ihren Variationen, Konstellationen, Versionen und Dienste-Spektren allgegenwärtig und dieser umstrittene Hype wird noch eine ziemlich lange Weile andauern.

Während noch viele potenzielle Kunden, ob kommerziell oder privat, der Sache gegenüber skeptisch und mit einem misstrauenden Blick nur bedingt ihre Sympathie entgegenbringen, sind andere hingegen sehr wohl überzeugt, dass dieses Technologiekonstrukt in der Natur Ihrer Bedienung weiterhin die Zukunft der Informations und Kommunikationswelt triumphieren wird, oder gar auf dem Weg dahin ist.

Doch wo ein Markt sich entwickelt oder vielversprechend klingt, da sind dann auch schon ettliche Anbieter, die auf den startenden Zug aufspringen. Es bedarf am Anfang immer an Risikofreudigkeit, mit der gesunden Portion Angst, beim Aufsprung zwischen die Gleise zu geraten und überrollt zu werden. Wenn ich den Markt richtig beobachtet habe, sind wir jedoch bereits in der Phase, wo die Wagons bereits überfüllt sind.

Umso interessanter ist es zu beobachten, wie so manche geistreichen Technologieunternehmen (Nachfolgend „Cloud-Anbieter“ genannt) ihre Lösung eher mit raffinierten Darstellungen vermarkten, statt der richtigen Philosophie zu folgen, die der Sache im Kern nur gerecht werden könnte. Doch es sind im Laufe der Ver-Hype-ung auch Produkte entstanden, die ein geübtes Auge eher als Pseudo bezeichnen würde. Der Laie findet es dennoch originell, denn es steht die gewünschte Funktionalität im Vordergrund, wenn man sich mit den verborgenen Sicherheitsmängel und Risiken einmal abgefunden hat, oder erst garnichts darüber wissen muss.

Andere Laien wiederum vertrauen genau dieser Wolken-Technologie deswegen nicht, weil diese noch zu intransparent ist, wie das Fliegen durch eine Wolke, oder sie erst garnicht aufgeklärt werden. Dass ein Anspruch auch anders, unabhängig, kostensparend bedient werden kann, zum Beispiel durch eine Cloud Lösung (dabei spielt es keine Rolle, ob wir über PaaS, SaaS, IaaS oder XXX..aaS reden) liegt in der Natur der Dinge und ist die Voraussetzung. Wenn der Laie aber die 3. Frage beantwortet haben will, scheiden sich die Geister. Die Fragen sind einfach: 1. Funktioniert es? 2. Ist es sicher? 3. Wie funktioniert es sicher?

Die meisten kommen über die Frage 2 garnicht hinaus, denn es ist an der Stelle auch nicht mehr wichtig, wenn die ersten beiden Fragen beantwortet wurden. Der Rest ist das Risiko beider Parteien. Doch ist es so einfach die Risiken hinzunehmen oder womöglich für etwas zu zahlen, was nur den Anschein erweckt so zu sein?

Um die Praxis dem Leser näher zu bringen, findet nachfolgend eine Erörterung statt, warum nicht jeder Cloud-Anbieter die Cloud, insbesondere die Private-Cloud verstanden hat und nicht jede Private-Cloud auch eine Private-Cloud ist.

Ein Beispiel

Vorneweg: Die Beispiele sollen nicht dazu dienen den oder die Anbieter schlechter oder besser darzustellen, als es mit einer geeigneten Methode zur Qualitätsmessung möglich wäre. Daher dient dieser Beitrag nicht als Ziel einer Gut- oder Schlechtmachung. Der Autor versichert keine weiteren Intensionen was den Illustrierten betrifft, ausser zur Veranschaulichung der differenzierten Betrachtung innerhalb des Beitragsthemas. Ich bin rein zufällig auf die Seiten des Anbieters gestossen, woraufhin dieser Blog entstanden ist.

Im folgenden Beispiel wir der Private-Cloud-Dienst „Exchange Server as a Service“ aus der Private-Cloud Sparte des Anbieters CLOUD-CH.CH angeschaut und kurz erklärt, warum der Dienst lediglich eine klassische Hosting-Geschichte darstellt, nicht die Ansprüche an die Cloud-Sicherheit im Sinne von Best-Practice Ansätzen entspricht (insbesondere mit des umworbenen Sicherheitsstandards) und somit die Vertrauensgrundlage bei den Einäugigen unter den Blinden schwinden lässt. Die folgenden Beurteilungen basieren auf Analysen, die anhand der vom Anbieter veröffentlichten Dokumente/Anleitungen zur Einrichtung von Outlook über ihre „Private-Cloud“ getätigt wurden.

Die PDF Schritt-für-Schritt-Anleitung von CLOUD-CH.CH
http://www.cloud-ch.ch/tl_files/images/itost/PDF/StepByStep/privat%20cloud%20Mail%20Outlook%202010%20step%20by%20step.pdf

Wenn man die ganzen Vorzüge und Funktionen einer Outlook/Exchange Umgebung nutzen will, benötigt man in der Regel eine Microsoft Domäne, einen Exchange Server und einige Outlook Clients. Um Outlook als einfachen Email-Client einzusetzen, benötigt man im Grunde nur einen IMAP oder POP3 Dienst. Doch es ist schon äusserst nützlich, die Exchange-Dienste möglichst im weiten Umfang zu nutzen, ob für Kolaborationszwecke, Termine, Meetings, Synchronisationen, Sharing etc…. Die Backend-Systeme können ja bekanntlich irgendwo im Firmen-Netz aufgebaut sein, zwar möglichst sicher in einem Servernetz, aber irgendwo. Den Laien interessiert es nicht, denn er fühlt sich im eigenen Netz sicher. Das ist zwar ein Irrglaube, aber das ist ein anderes Thema und würde den Rahmen dieses Beitrags sprengen.

Im Zuge der XY as a Service Offerierungen diverser namhafter, unnamhafter oder unbekannter Anbieter, sind auch diverse gängige und populäre Produkte und Dienste in die Wolke gewandert und warten dort darauf ihre bekannten Dienste auch ortsunabhängig an den Mann und die Frau zu bringen. Der Cloud-Anbieter wirbt dabei nicht nur mit den Vorteilen der privaten Cloud, sondern auch mit der fast über die 365 Tage hinausragenden Verfügbarkeit rund um die Welt. Damit der Kunde dabei ein stets wohles und sicheres Gefühl bekommt, wenn er in die Wolke katapultiert wird, werden zeitgemässe, auf dem Markt bekannte und irgendwie auch cool klingende Sicherheitsregelwerke genannt, die man stolz erfüllt. Es ist auch gut so, denn der Kunde will nicht nur einen Dienst in Anspruch nehmen, den er von seinen eigenen Administratoren so noch nie in voller Professionalität bekommen hat, andererseits will er auf den Wolken schweben, ungeachtet der Himmelsrichtung, ohne dabei durch einen Sicherheitsleck abgeschossen zu werden. Man nennt es auch „ge-hackt werden“ oder in Folge dessen „einen Reputationsschaden erleiden“.

Was bei dem Private-Cloud Anbieter in unserem Beispiel angeboten wird, ist nichts anderes, als dass bei diesem Cloud-Anbieter irgendwo in seinem (hoffentlich) geschützten Netzwerk ein physischer oder gar virtueller Exchange Server installiert wurde. Dabei werden die vom Kunden gewünschten Emails anhand ihrer Domain-Zugehörigkeit (also z.B. die Domain „example.com“ bei einer Email-Adresse „kunde@example.com“) vom Cloud-Anbieter über die Registrierung der Domain an die eigenen MX Server über die entsprechenden DNS Einträge geroutet, womöglich dann über die Perimeter-Zonen intern Reverse-ge-NAT-et oder wie üblich über Relays weitergeleitet werden, damit die Emails, welche den Kunden erreichen sollen, auf die in der Private-Cloud angesiedelten Exchange Server des Cloud-Anbieters gelangen. Bisher ist alles noch schön und wir gehen davon aus, dass der Anbieter für Ausfallsicherheit gesorgt hat und die Exchange-Services auf weitere Systeme repliziert haben. Der Grundgedanke einer Private-Cloud ist es jedoch, dass in erster Linie die Nutzung der Dienste, der Informationen und der Daten auch tatsächlich in einer privaten Umgebung dediziert und nur für den Kunden bereitgestellt werden, welche nicht durch öffentliche Zugänge frei erreichbar sind und nicht im Sinne von Internetdiensten agieren. Im Sinne des hier betrachteten Cloud-Anbieters, sind die Systeme, deren Daten sowie die darin verborgenen Informationen erst einmal nicht öffentlich zugänglich. Dies ist aus den bereitgestellten Anleitungen und der darin angegeben Einrichtungsparameter ersichtlich, welche auf interne, nicht öffentliche Domain-Kennungen und Systembezeichnungen hinweisen. So einen Exchange Server mit gigantischem Potenzial und hohen Lizenzkosten pro Kunde zu unterhalten ist jedoch wie mit Kanonen auf Spatzen schiessen und würde das Vorhaben des Anbieters auf Dauer in einem finanziellen Desaster enden lassen.

Deshalb gehen viele Anbieter intern den Weg des Shared Hostings und Shared Platforms. Bei unserem Anbieter ist dies daraus zu erkennen, weil er für alle seine Kunden in der einmaligen Anleitung auch statische Hosts und Systemkennungen für die Einrichtung des Outlook Clients angibt. Auch die interne Domäne zwecks Authentifizierung und Authorisierungsvorgänge ist statisch, so dass es klar wird, dass der Anbieter alle seine Kunden in einer einzigen Domain seines Cloud Rechenzentrums vereint. Er könnte die Kunden anhand ihrer Kennung selbstverständlich auf unterschiedliche Systeme routen, aber im Falle eines Exchange Systems würde dies aus Kosten und Effizienzgründen keinen Sinn machen, ist ein Exchange-Server doch in der Lage, Multidomain  Management zu betreiben und die notwendigen Funktionen anzubieten, den Email-Verkehr und auch alle anderen Funktionen Mandatenfähig zu unterscheiden. Ähnlich verhält es sich für Webdienste eines Internet Service Providers, welcher über virtuelle Hosts seine Mandanten auf Verzeichnisbasis auf einem einzigen Server hostet und ihre Domains virtuell anlegt. Wenn man es so betrachtet, gab es also Clouds schon immer, nur nicht in der Bandbreite der angebotenen Dienste und Plattformen sowie Variationen und insbesondere mit den heutigen Virtualisierungstechniken.

Kommen wir zum Kern der Diskussion. Der Kunde hat bei dem Cloud-Anbieter eine Private-Cloud-Umgebung eingekauft, wurde eingerichtet und denkt nun, der Begriff „Private“ stellt dar, dass alles was der Kunde bei dem Anbieter hat, abgekapselt, privat, isoliert und separiert wäre. Der Anbieter wiederum versteht darunter, dass die Dienste, die er dem Kunden in einer Privaten-Cloud anbietet, nicht für Jedermann zugänglich und zumindest mit einem definierten Niveau auch geschützt ist. Das Verständnis ist also ziemlich divergent und überrascht nicht.

Um den Schutz vor unerlaubten Zugriffen zu gewährleisten, beschreibt der Anbieter in seinem Dokument, wie der Kunde bei sich lokal einen Outlook Client einrichten muss, um an die Exchange Dienste zu gelangen, die der Anbieter in seiner Private-Cloud offeriert und verkauf hat.

Da wir zuvor festgestellt haben, dass es sich immer wieder um die gleichen Systeme handelt, schwindet bei uns nun so langsam der echte, private Cloud Gedanke. Doch wir wollen den Dienst nutzen und machen weiter in der Anleitung. Ich warte schon sehnsüchtig auf die Stelle in der Anleitung, wo ich nach Einrichtung meines Outlooks auf die statische und einzige Domäne des Cloud-Anbieters, nun auch noch einen IPSEC-VPN Client oder der gleichen runterladen und installieren muss, damit ich eine absolut sichere Fernverbindung in die Cloud aufbauen kann, um dann meine Emails auf meinen lokalen Outlook Client abrufen zu können. Ich will ja schliesslich die Vorzüge dieser virtuellen Unabhängigkeit in vollen Zügen nutzen können, egal wo und auf welchem Gerät. Auch mit einem „VPN over SSL“ wäre ich schon fast zufrieden, wenn ich dafür meinen Internet Browser nutzen soll, über ein Applett oder Browser-Addon mich authentifizieren darf. Ich scrolle im Dokument spannend hin und her, um zu erfahren, wie ich denn nun die state-of-the-art verschlüsselte Verbindung in die Wolke aufbauen soll.

Doch auch wenn ich danach lange gesucht habe, VPN ist bei diesem Anbieter Fehlanzeige. Doch wie soll ich denn meine Emails über eine interne, nicht öffentliche Domain beim Cloud-Anbieter denn nun abrufen und versenden können. Ich kehre Zurück in die mit Screenshots voll gepumpten Passagen der Outlook Einrichtung und springe auf den Punkt nach der Einrichtung der Exchange-Domain-Settings.

OHA! Kaum zu fassen und tatsächlich so, wie ich es mir nicht gewünscht hätte es jedoch befürchtet habe.

ES ist eine OWA (Outlook Web Access) Verbindung! Nicht nur, dass ich in der Microsoft Domain des Anbieters als ein weiterer Domain-User angelegt wurde, ich muss nun eine mit Zertifikaten gesicherte SSL Verbindung nutzen, um meine Domain-Credentials hierüber zu senden um im Gegenzug synchronisieren zu dürfen. Das ganze geschieht dann noch über eine NTLM Authentifizierung, dessen Hashwerte zu entschlüsseln heute ein Kinderspiel darstellt.  Es besteht weder VPN Tunnel über SSL oder IPSEC, noch eine sonst absolut abhörsichere Leitung. Es ist dabei nicht einmal bekannt, welche „Cipher Suites“ der Anbieter für seine OWA/SSL einsetzt. Ich gehe zwar davon aus, dass die eingesetzten Zertifikate von einer Vertrauenswürdigen CA ausgestellt bzw. signiert wurden, aber dennoch ist es entscheidend, welche Verschlüsselungsverfahren in Verbindung mit diesen Zertifikaten zustande kommt. Ob der Anbieter bei sich die Strict-Transport-Security oder Forward Secrecy Funktionalität eingeschaltet hat, damit ich auf dem Weg nicht abgehört werden kann? Hat der Cloud Anbieter nicht gehört, dass insbesondere OWA in Verbindung mit „Bring Your Own Device“ (BYOD) sehr gefährlich für ein Unternehmen werden kann?

Nun, der Kunde denkt weiterhin, er ist in der privaten Cloud, sein genutzten Ressourcen geschützt und dediziert, in der für ihn privatisierten stück Wolke. Dabei ist er nur ein Domain-User bei dem Anbieter, der auf einem Exchange Server seine Email-Postfächer und Synchronisationen über eine Multidomain-Hosting-Platform mit anderen Fremden teilt. Seine Synchronisation erfolgt über OWA und wenn der Kunde dies auch auf seinen „Mobile Devices“ so eingerichtet hat, dann definitiv nicht mehr abhörsicher. Insbesondere dann nicht, wenn ein Domain-Admin auf unseriöse Gedanken kommt und mit seinen Super-Rechten intern auf die Postfächer der Kunden zugreift, wozu er in solch einer Universal-Domain in der Lage wäre. Ich vermute einmal, dass bei den meisten Cloud-Anbietern so etwas wie ein „Fraud Prevention System“ oder ein automatisiertes Data Leakage Warn-System Fehlanzeige ist. Wenn überhaupt sind wenige Firmen motiviert, ein echtes 24/7 ISIRT aufzubauen oder intelligente Log-Crawler einzusetzen, die Anomalien auf den Systemen frühzeitig erkennen. Da hilft ein IDS/IPS auch nicht mehr weiter.

Doch der Cloud-Anbieter wirbt mit einem hohen Sicherheitsstandard durch die Erfüllung von „FINMA“ Anforderungen. Warum aber gerade mit den Sicherheitsregularien der eidgenössischen Finanzmarktaufsicht? Womöglich wurde der Cloud-Anbieter zur Einhaltung des FINMA Rundschreibens 2008/21 Anhang 3 (Customer Identification Data in Bezug auf Verlagerung von Kundendaten zu Outsourcing Dienstleistern) von eines seiner Kunden verpflichtet, welches dann logischer Weise eine Bank sein muss. Denn wozu sollte der Anbieter sonst die FINMA Regularien erfüllen müssen. Es gibt sicherlich sinnvollere Sicherheitsstandards, welche wesentlich internationaler sind und ein allgemein verständliches und breiteres Sicherheitsrahmenwerk nach Best Practice Gesichtspunkten mit sich bringen. Auch ein IS027001 oder PCI DSS wäre hierbei vermutlich sinnvoller gewesen, sind doch die FINMA Regularieren hier und da branchenbedingt zu generisches „Wischi-Waschi“ oder hier und da zu fokusiert und können je nach Revisionsprüfer unterschiedlicher Interpretation unterliegen. Aber Langfinger Admins ist kein Sicherheitsstandard gewachsen, es sei denn der Cloud-Anbieter kann alle Kundendaten mit anerkannten Methoden UND einem Schlüssel komplett verschlüsseln, den nur der Kunde kennt. Schöne Vorstellung einer privaten Vorhängeschloss-Wolke im Himmel…

Mein Fazit:

Aus dem ganzen stelle ich fest, dass so manche Cloud-Anbieter die Intension und Philosophie des Cloud Computings sowie die Anforderungen an Sicherheit und Technik nicht richtig verinnerlicht und/oder verstanden haben, oder bewusst eine Verschönerungs- und Ablenkungsstrategie nutzen, um das klassische und recht unsichere Hosting Produkt verpackt in einem Paket in Form einer Wolke mit der Aufschrift „Privat“ an den Kunden zuzustellen. Wenn ich das durch die FINMA Regularien hochgehaltene Bankengeheimnis in Verbindung mit Banken betrachte, welche ihre Daten zu Cloud-Anbietern mit vergleichbaren Konstellationen ausgelagert haben, dann bin ich mir ziemlich sicher, dass ich mir keineswegs sicher sein kann, ob das „strenge“ Bankengeheimnis inkl. Aufsicht auf diesem Weg tatsächlich noch so geheim ist…

Das einzige was hierbei noch eine Weile privat bleiben wird, ist die Tatsache, dass die betroffenen Cloud-Anbieter ihre Kulissen zu Pseudo-Clouds privat halten werden….

Kleines-Praxis-Addon bei cloud-ch.ch:

Was die Sicherheit betrifft, sieht es bei der Beschreibung zur Installation des Citrix Receivers für die Nutzung von Cloud-Apps nicht besser aus. Dort wird man angehalten den Citrix Receiver mit einem HTTP Dienst des Anbieters kommunizieren zu lassen, der die Authentifizierungsinformationen ebenfalls per HTTP, also unverschlüsselt entgegen nimmt, da die meisten Apps beim Aufruf des Links die Credentials bereits laden. Dabei kann man auch nebenbei identifizieren, um welchen Webserver es sich handelt und wann zuletzt das Webinterface verändert wurde.

Zu entnehmen sind die Informationen aus den eigenen Dokumenten des Anbieters, welche auf dem eigenen Portal zum Download angeboten werden.
http://www.cloud-ch.ch/downloads.html
Anleitung Installation und Einrichtung Citrix Receiver für Andriod

Bei den obigen Screenshots, welche zum Zeitpunkt dieses Blogs erstellt wurden, ist es leider eindeutig zu erkennen, dass der Cloud-Anbieter eine ziemlich stark veraltete Citrix Webportal Lösung im Einsatz hat (2010) und der Webserver selbst zuletzt 2012 angefasst wurde. Es ist ein IIS 7.5 Server mit ASP.NET im Einsatz, welches auf das Betriebssystem Windows Server 2008 r2 schliessen lässt. Immerhin ist der Extendet Support für den 2008 R2 Server bis 2020 angesagt. Microsoft selbst äussert sich zum IIS 7.5, dass die Pflege dieser Komponente dem übergeordneten Produkt unterliegt. (https://support.microsoft.com/de-de/lifecycle?p1=14855)

Sowohl Citrix Xenapp als auch IIS 7.5 haben in diesen veralteten Versionen kritische Sicherheitslücken und es bestehen für diverse Lücken Exploits, welche von mir selbstverständlich NICHT in diesem Test angewendet wurden.

Ich bin der Sache jedoch oberflächlich nachgegangen und habe den Verkehr während des Anmeldevorgangs analysiert.

Folgende Test-Anmeldedaten wurden verwendet:

Benutzername: Cloud-ia
Passwort: 123456789
Domain: itost

Das der Anmeldevorgang fehlt schlägt, ist verständlich und wurde absichtlich provoziert, da ich selbst kein Kunde des Cloud-Anbieters bin.

Das Ergebnis ist jedoch leider schockierend.

Wie vermutet, wird der gesamte Authentifizierungsvorgang inkl. der erzeugen CITRIX Session Key unverschlüsselt über das Internet übertragen. Ein Angreifer, der den Datenverkehr abhört, oder Zugriff auf den Computer des Kunden hätte, könnte somit die Anmeldeinformationen entwenden, oder zumindest durch ein Session Hijacking die Sitzung des Kunden klauen und so die Daten des Kunden manipulieren oder entwenden. Bei Bankkunden wäre dies ein Desaster. Und wenn alle Systeme so unsicher und veraltet aussehen, wie dieser Webserver bzw. Gateway, dann wäre es für einen Angreifer interessant zu versuchen, über ein „DNS Poisoning“ Versuch möglichst viele Kunden auf ein verseuchtes Proxy-System umzuleiten, damit möglichst viele Anmeldevorgänge abgegriffen und später missbraucht werden können.

In Gedanken, dass das Glas dennoch halb voll sein könnte, starte ich einen zweiten Versuch, diesmal mit dem Citrix Receiver für Linux Clients um zu schauen, wie sich der Anmeldevorgang mit dem CTX1 Encoding des Clients verhält und ob eine Verschlüsselung des Streams per SSL/TLS erzwungen werden kann.

Anmeldevorgang mit dem Linux Citrix Receiver und den gleichen Anmeldedaten wie vorher über den Webbrowser.

Verständlicher Weise schlägt der Versuch der Anmeldung auch diesmal fehl. Jedoch warnt uns die 32Bit Client Version von Citrix zumindest davor, dass die Verbindung unverschlüsselt sei.

Leider ist auch hierbei deutlich erkennbar, dass keinerlei Verschlüsselung des Anmeldevorgangs, und bei gültigen Anmeldeinformationen, eine verschlüsselte Sitzung möglich ist.

FAZIT DER UNTERSUCHUNG:

Wer einen sicheren Cloud-Anbieter für die Nutzung der angebotenen Cloud-Dienste sucht, der sollte es sich mit Cloud-ch.ch leider nochmals überlegen. Immerhin sind die Angebote von Cloud-Ch.ch recht üppig, doch der Anbieter selbst scheint den heutigen Sicherheitsanforderungen etwas hinterher zu laufen, und das ist mittlerweile fahrlässig.

Immerhin ist die Liste der Anbieter in der Schweiz recht lang: http://www.cloud-finder.ch/markt/cloud-dl-rz-anbieter.html

 

(Alle externen Angaben in diesem Blog basieren auf das Wissen, welches zwischen dem 13. und 14. April 2016 vom Autor ermittelt wurden).