Tag: Vergleich


Sicherheitsvergleich: TeamDrive vs. ownCloud

Dropbox polarisiert innerhalb der IT-Abteilungen. Vom Vorstand bis hin zum normalen Mitarbeiter greifen viele auf den beliebten Cloud-Storage Service zurück. Das liegt vor allem an der einfachen Nutzung, die von den internen IT-Abteilungen heute nicht so unkompliziert bereitgestellt wird. Hier greifen insbesondere zwei aus Deutschland heraus entwickelte Lösungen an, die es Unternehmen erlauben, eigene Dropbox ähnliche Funktionen innerhalb einer selbstverwalteten IT-Infrastruktur zu implementieren, TeamDrive und ownCloud. TeamDrive vertritt dabei einen vollständig kommerziellen und proprietären, ownCloud hingegen einen vermeintlichen Open-Source Ansatz, dem aber ebenfalls eine kommerzielle Version zu Grunde liegt. Beide beanspruchen für sich den Titel "Dropbox für Unternehmen". Bewegen wir uns allerdings genau in diesem Umfeld, spielt das Thema Sicherheit eine sehr wichtige Rolle.

Hintergrund zu TeamDrive und ownCloud

TeamDrive und ownCloud verfolgen zwei unterschiedliche Geschäftsmodelle. Wo sich TeamDrive als vollständig kommerzielles Produkt für Unternehmen am Markt positioniert, setzt ownCloud auf die Open-Source Community, um damit Marktanteile zu gewinnen. Mit einer kommerziellen Version adressiert ownCloud allerdings auch den Markt für professionelle Unternehmenslösungen.

Über TeamDrive

TeamDrive ist eine Filesharing und Synchronisations-Lösung für Unternehmen, die ihre sensiblen Daten nicht bei externen Cloud-Services speichern wollen und es ihren Teams zudem ermöglichen möchten, Daten oder Dokumente zu synchronisieren. Dazu überwacht TeamDrive beliebige Ordner auf einem PC oder Notebook, die man mit eingeladenen Anwendern gemeinsam nutzen und bearbeiten kann. Damit stehen Daten jederzeit, auch offline zur Verfügung. Eine automatische Synchronisation, Backups und Versionierung von Dokumenten schützen die Anwender vor Datenverlust. Mit der Möglichkeit die TeamDrive Registration- und Hosting-Server im eigenen Rechenzentrum zu betreiben, lässt sich TeamDrive in vorhandene IT-Infrastrukturen integrieren. Dafür stehen alle notwendigen APIs zur Verfügung.

Über ownCloud

ownCloud ist eine Open-Source Filesync- und –sharing-Lösung für Unternehmen und Organisationen, die ihre Daten weiterhin selbst unter Kontrolle behalten möchten und nicht auf externe Cloud-Storages zurückgreifen wollen. Der Kern der Anwendung besteht aus dem ownCloud Server über welchen sich die Software zusammen mit den ownCloud-Clients nahtlos in die existierende IT-Infrastruktur integriert und die Weiternutzung bereits vorhandener IT-Management-Tools ermöglicht. ownCloud dient als lokales Verzeichnis, bei dem unterschiedliche lokale Speicher gemountet werden. Dadurch stehen die entsprechenden Dateien allen Mitarbeitern auf allen Geräten zur Verfügung. Neben einem lokalen Storage können ebenfalls Verzeichnisse über NFS und CIFS angebunden werden.

TeamDrive und ownCloud: Die Sicherheitsarchitektur

In diesem Vergleich soll es um die Sicherheitsarchitektur hinter TeamDrive und ownCloud gehen. Der sonstige Funktionsumfang der beiden Lösungen wird nicht betrachtet. Es geht also um die Betrachtung der Verschlüsselungsverfahren, Datenhaltung, Datenverarbeitung und der Benutzerautorisierung, soweit Informationen zur Verfügung stehen. Dabei wird davon ausgegangen, dass grundlegende Kenntnisse zum Thema Sicherheit bekannt sind.

TeamDrive: End-to-End Verschlüsselung

TeamDrive ist trotz seines kommerziellen Ansatzes recht auskunftsfreudig und stellt einige Sicherheitsinformationen öffentlich zur Verfügung. Darunter zu dem Thema Verschlüsselung. Zudem wird mit dem Datenschutzsiegel des „Unabhängigen Landeszentrum für Datenschutz Schleswig-Holstein (ULD)“ geworben. Nach einer Anfrage wurden bereitwillig umfangreiche Informationen zur Verfügung gestellt, wobei einige jedoch einem NDA (Non-Disclosure Agreement) unterliegen.

Verschlüsselungsverfahren

TeamDrive setzt auf die folgenden Verschlüsselungsmechanismen:

  • Advanced Encryption Standard – AES 256
    Zur Verschlüsselung der Daten setzt TeamDrive auf das Advanced Encryption Standard (AES) Kryptosystem mit einem 256 Bit Schlüssel und verwendet die C Code Implementation der OpenSSL library.
  • Diffie-Hellman und RSA 3072
    Für den Schlüsselaustausch setzt TeamDrive bei seinen älteren Clients auf den Diffie-Hellman Algorithmus. Neue Clients hingegen verwenden RSA 3072. Die Diffie-Hellman Implementierung basiert dabei auf der C Code Implementation wie sie von der OpenSSL library zur Verfügung gestellt wird.
  • Message Digest 5/6 – MD5/MD6
    Der TeamDrive Hash-Funktionalität liegt der MD5 bzw. MD6 Algorithmus zu Grunde, wobei der Hashwert mit einer zufällig gewählten Zeichenfolge (Salt) gespeichert wird.
  • PrimeBase Privacy Guard – PBPG
    Der PrimeBase Privacy Guard (PBPG) ist ein proprietäres Public/Privat Schlüsselsystem, das auf dem Diffie-Hellman Schlüsselaustausch und der AES Verschlüsselung aufsetzt. Das Verhalten von PBPG für den Anwender gleicht dem bekannten Public/Privat Schlüsselsystemen von PGP oder GnuPG. Die PBPG-Verschlüsselung generiert zufällige Änderungen und verifiziert die Dateien während des Austauschs, damit PBPG erkennen kann, ob eine Nachricht oder ein Schlüssel manipuliert oder anderweitig verändert worden sind. Zwei Nachrichten sind dabei niemals gleich. Dabei wird nicht nur für jeden Benutzer ein Schlüsselpaar erzeugt, sondern ebenfalls für jede Installation. Die PBPG Implementierung ist offen und kann bei Bedarf von Partnern und anderen Interessierten überprüft werden.

Systemarchitektur

Daten werden bei TeamDrive in einem sogenannten Space gespeichert, auf dem eine festgelegte Anzahl von Nutzern Zugriff erhalten kann. Der Austausch findet über ein Space Depot statt, welches auf einem TeamDrive Hosting Server oder WebDAV liegen kann.

Jeder Space verfügt über seinen eigenen 256 Bit AES Schlüssel, der für die Verschlüsselung der Daten in diesem Space genutzt wird, wenn die Daten das Endgerät des Nutzers verlassen. Dabei hat nur die TeamDrive Software, welche auf dem Endgerät der anderen Nutzer eines Spaces installiert ist, Kenntnisse über den Schlüssel.

Jeder Server auf dem ein Space Depot zur Verfügung steht, ist für das Speichern, Weiterleiten und Anpassen von Veränderungen innerhalb des Depots verantwortlich. Damit können die Clients auch dann Daten austauschen, wenn nicht alle zur selben Zeit online sind. Alle Daten, die auf dem Server gespeichert sind, werden mit einem 256 Bit AES Schlüssel des Spaces verschlüsselt.

Benutzerautorisierung

Die Anmeldung eines Nutzers erfolgt über die TeamDrive Client-Software, die ihn gegen den TeamDrive Registrierungsserver überprüft. Das erfolgt grundsätzlich über die Eingabe einer E-Mail Adresse oder eines Benutzernamens und eines Passworts.

Die Autorisierung zwischen dem TeamDrive Client und dem Registrierungsserver erfolgt auf Basis des Public Key des Registrierungsserver. Informationen wie die E-Mail-Adresse und das Registrierungspasswort plus weitere Daten des Benutzers werden unter der Verwendung des Public Key des Registrierungsservers verschlüsselt an den Registrierungsservers übertragen.

Einzig der Aktivierungscode wird unverschlüsselt über eine ebenfalls unverschlüsselte E-Mail an den Nutzer verschickt. Zudem wird eine verschlüsselte Antwort mit der Device ID an den TeamDrive Client gesendet. Nach der Aktivierung durch den Nutzer generiert die Client-Software einen PBPG Key und einen passenden Public Key. Im Anschluss schickt die Client-Software das Registrierungspasswort und den Public Key verschlüsselt, unter Verwendung des Public Keys des Servers, an den Registrierungsserver zurück. Der Aktivierungscode wird verifiziert und der Public Key des Nutzers gespeichert. Alle im Anschluss folgenden Nachrichten, die an den Registrierungsserver geschickt werden, sind mit dem PBPG Public Key des Nutzers verschlüsselt und benötigen die Geräte-ID und das Registrierungspasswort zur Autorisierung.

Datenhaltung und Verarbeitung

Zum Erzeugen eines Space, benötigt der Benutzer ein Space Depot und dessen Passwort. Damit weiß der TeamDrive-Client, mit welchem Server er Kontakt aufnehmen muss, um den Space zu erzeugen. Anschließend fordert die Client-Software den Public Key des TeamDrive Hosting Servers an. Die Client Software sendet die Geräte-ID, die Space Depot ID, Benutzername, Benutzer-ID, den Public Key des Benutzers und den Namen des Spaces als verschlüsselte Nachricht an den TeamDrive Server. Die Nachricht wird mit dem Public Key des Servers verschlüsselt übertragen. Die Space Depot ID und das Passwort werden überprüft. Für die verschlüsselte Übertragung der Antwort wird der Public Key des Benutzers verwendet. Der TeamDrive Server erstellt einen neuen Space auf dem vorgegebenen Space Depot. Ein 128 Bit "Genehmigungscode" wird zufällig für den neuen Space erzeugt und an den Client zurückgesendet.

Für den Zugriff auf einen Space wird die entsprechende URL, ein Autorisierungscode und ein Space Datenschlüssel benötigt. In der URL ist die Adresse des Servers, über die das Space Depot mit dem Inhalt des Spaces angesprochen wird, sowie die Space ID, enthalten. Veränderungen in dem Space werden auf das Space Depot und in den Space hochgeladen bzw. heruntergeladen. Dabei werden HTTP PUT und POST Methoden verwendet. Bevor eine Datei den Client verlässt, wird diese komprimiert und mit dem 256-Bit AES Schlüssel verschlüsselt.

Um auf einen Space zuzugreifen, öffnet der TeamDrive Client eine Session mit dem Server. Darin wird zunächst die ID des Space, auf den der Zugriff stattfinden soll, übertragen. Der Server erzeugt nach erfolgreicher Prüfung eine neue Session ID mit einer 128-Bit Zufallszahl (RND) und sendet diese an den Client zurück, der hier lokal abgelegt wird. Für das Hochladen und Löschen von Daten verwendet der Client die RND und den Autorisierungscode des Space und verknüpft diese xor inkl. einer MD5 Operation auf dem Ergebnis. Das Ergebnis wird zusammen mit der Session ID und den verschlüsselten Daten an den Server geschickt.

Die Sicherheit eines Space Depot wird dadurch sichergestellt, dass nach jeder Anfrage ein zufälliger RND Wert zurückgesendet wird, die der Client jedes Mal für einen lokalen Wert neu berechnen muss. Zudem garantiert ein MD5 Hash, dass der Autorisierungscode des Space nicht abgeleitet werden kann. Auch dann wenn der RND und der lokale Wert auf der Client-Seite bekannt sind. Damit wird ebenfalls verhindert, dass ein Angreifer in eine Session eindringen kann, um Daten auf den Server hochzuladen.

Zusammenfassung

Die Datensicherheit in einem TeamDrive Space wird durch die Verschlüsselung der Daten mit einem 256-Bit AES Schlüssel sichergestellt. Dabei ist der Schlüssel nur den TeamDrive Clients bekannt die Mitglied eines Space sind. Anbieter von Storage-Services auf Basis von TeamDrive oder Systemadministratoren haben keinen Zugriff auf die Daten. Der Austausch der Space Autorisierungsschlüssel unter TeamDrive Nutzern erfolgt mit einem sicheren Public/Privat-Key Verfahren, welches selbst eine 256-Bit AES Verschlüsselung verwendet. Der Zugriff auf ein Space Depot bzw. einem Space wird mit einem 128-Bit Autorisierungscode geschützt. Mit dem Autorisierungscode wird verhindert, dass der Speicherplatz eines Space Depot bzw. eines Space von unautorisierten Dritten verwendet werden kann.

Neben der verschlüsselten Speicherung der Daten auf den Servern und den Clients, werden die Daten ebenfalls während der Übertragung immer komplett verschlüsselt, wodurch TeamDrive eine vollständige End-to-End Verschlüsselung der Daten gewährleistet.

Weiterhin ist zu erwähnen, dass TeamDrive von dem "Unabhängigen Landeszentrum für Datenschutz in Schleswig Holstein (ULD)" das Datenschutzgütesiegel erhalten hat. Die Prüfnummer lautet 2-3/2005. Darüber hinaus wurde TeamDrive im Mai 2013 von Gartner zum "Cool Vendor in Privacy" 2013 benannt.

ownCloud: Serverseitige Verschlüsselung

Bei ownCloud sucht man vergeblich nach öffentlichen Sicherheitsinformationen, die von ownCloud selbst zur Verfügung gestellt werden. Das verwundert ein wenig, da selbst in der ownCloud Community scheinbar viele offene Fragen [1], [2] hinsichtlich der Serverseitigen Verschlüsselung und der Verschlüsselung im Allgemeinen bestehen. Einzig ein Blog-Beitrag ist zu finden, in dem das grundsätzliche Verständnis von ownCloud zum Thema Sicherheit öffentlich dargestellt wird. Auf direkte Nachfrage bei ownCloud wurden jedoch anstandslos Fragen beantwortet und weitere Informationen zur Verfügung gestellt.

Verschlüsselungsverfahren

Für die Verschlüsselung der Daten setzt ownCloud 5.0 auf den Advanced Encryption Standard (AES) mit einem 256 Bit Schlüssel.

Der Sicherheitsblogger Pascal Junod hatte sich Anfang 2012 mit der Verschlüsselung von ownCloud 4.0 auseinandergesetzt. Die notwendigen Informationen sind in der OC_Crypt class zu finden. Junod hat in diesem Zusammenhang diese PHP Datei analysiert und entsprechende Informationen veröffentlicht. Demnach wird der Schlüssel in der mt_rand() PHP Routine generiert. Die den Mersenne Twister, einen Pseudozufallszahlengenerator, implementiert. Junod kommentiert, das es sich dabei nicht um eine kryptographisch gute Qualität handelt. Der generierte Schlüssel wird mit dem Benutzerpasswort in Verbindung mit dem symmetrischen Blockverschlüsselungsalgorithmus Blowfish im ECB Mode verschlüsselt und anschließend in der encryption.key gespeichert. Junod kommt zu der Schlussfolgerung, dass ein Angreifer im Besitz dieser Datei über die Brute-Force-Methode an das Passwort gelangen könnte. Er macht zudem darauf aufmerksam, dass dieser Schlüssel für die Verschlüsselung sämtlicher Daten eines Nutzers verwendet wird und dass die Daten serverseitig verschlüsselt werden. Er beschreibt weitere Möglichkeiten, um die encryption.key zu stehlen. So wird das Passwort, welches für die Verschlüsselung der Datei zuständig ist, in Klartext (einfaches HTTP) vom Client an den Server übertragen. Wird die Verbindung nicht mit HTTPS gesichert, ist jeder in der Lage die Kommunikation abzuhören und das Passwort zu stehlen und könnte somit auf den ownCloud Account und sämtliche Daten zugreifen. Weiterhin wird die encryption.key im Klartext in den Sitzungsdaten auf der Serverseite gespeichert. Die meiste Zeit im /tmp Verzeichnis. Das bedeutet, dass ein böswilliger ownCloud Serveradministrator in der Lage wäre, die Daten zu entschlüsseln. Zudem weißt Junod darauf hin, dass die Verschlüsselung serverseitig vorgenommen wird, wodurch ein Systemadministrator mutwillig die ownCloud Installation manipulieren könnte. Er empfiehlt daher ownCloud 4.0 niemals einzusetzen, um vertrauliche Informationen zu speichern.

ownCloud bestätigt in der Anfrage, dass ownCloud 5.0 selbst keine vollständig integrierte End-to-End Verschlüsselung in der Software implementiert hat. Dies kann jedoch mit Tools von Drittanbietern realisiert werden. Weiterhin wird Verschlüsselung "at rest" betrieben. Das bedeutet, dass die Daten physikalisch in verschlüsselter Form gespeichert werden. Die Verbindung zwischen den Endgeräten und dem Server wird mit SSL gesichert. Der Schlüsselaustausch erfolgt autorisiert über die Provisioning API. Ein umfangreiches Schlüsselmanagement soll in Zukunft folgen.

Systemarchitektur

ownCloud verfügt über ein Plugin für die serverseitige Verschlüsselung, mit der Administratoren die Daten verschlüsselt auf dem Server ablegen können. Nutzer erhalten Zugriff auf die Daten und können diese teilen, als seien sie unverschlüsselt. Das neue Plugin in ownCloud 5.0 ersetzt dabei die Sicherheitslücke in ownCloud 4.0, bei der ein böswilliger Systemadministrator die Sicherheitsarchitektur umgehen konnte, indem er Anpassungen am ownCloud Quellcode vornehmen konnte, um eine Backdoor oder einen Passwort Sniffer zu integrieren. Für die Verschlüsselung der Daten während der Übertragung vom Server zum Endgerät wird SSL verwendet. Das Passwort kann von einem Nutzer jederzeit geändert werden. Sämtliche Dateien werden anschließend mit dem neuen Passwort verschlüsselt.

Für eine serverseitige Sicherheit muss der Administrator die Verschlüsselungs-App in ownCloud der ownCloud Managementkonsole aktivieren und den Hacken „Verschlüsselung“ in der Admin-Oberfläche setzen. Anschließend wird ein Schlüsselpaar (Public/ Private) für alle Nutzer erstellt. Hierzu wird das Nutzerpasswort verwendet, um den privaten Schlüssel zu schützen. Darüber hinaus wird, für jede auf den Server hochgeladene Datei, ein symmetrisches Schlüsselpaar erstellt. Die von dem Nutzer hochgeladenen Daten werden mit dem symmetrischen Schlüssel verschlüsselt und gespeichert. Als Algorithmus wird der Advanced Encryption Standard (AES 256) verwendet. Der symmetrische Schlüssel wird mit dem privaten Schlüssel des Nutzers verschlüsselt und auf dem Server abgelegt. Werden die Daten von dem Server abgerufen, werden sie zunächst entschlüsselt und anschließend über eine SSL-Verbindung an den Client gesendet. Die Verschlüsselungsroutine verhält sich mit anderen, an ownCloud angebundenen Applikationen, wie der Web-Oberfläche, der Versionierung und dem Algorithmus für die Synchronisierung, exakt gleich. Ändert ein Nutzer sein Passwort, wird sein privater Schlüssel mit dem alten Passwort entschlüsselt und mit dem neuen Passwort erneut verschlüsselt.

Für den Nutzer gleicht eine auf den ownCloud Server hochgeladene und anschließend verschlüsselte Datei wie eine nicht verschlüsselte Datei. Die Verschlüsselung ist für ihn vollständig transparent. Wird eine Datei mit einem anderen Nutzer geteilt, werden die öffentlichen Schlüssel von jedem dieser Nutzer in der verschlüsselten Datei hinterlegt. Diese Nutzer können damit auf die Datei zugreifen und Änderungen an ihr vornehmen, als handelt es sich um eine unverschlüsselte Datei. Genauso verhält es sich mit einem Ordner. Nutzer können keine Dateien öffnen, die nicht für sie bestimmt sind. Sollte ein böswilliger Nutzer versuchen, Zugriff auf das Speicher-Backend zu nehmen, werden die Dateien und Schlüssel darin unlesbar.

Ist das entsprechende Plug-In aktiviert, ist ein Systemadministrator in der Lage, über die Kommandozeile, alle Dateien zu sehen, die auf ownCloud gespeichert sind. Allerdings sind die Inhalte der Dateien verschlüsselt. Es können weiterhin normale Backups vorgenommen werden, jedoch bleiben alle Dateien verschlüsselt. Selbst dann, wenn die Daten nach außerhalb des Systems kopiert werden. Ein Administrator kann zudem weitere Einstellungen vornehmen, um bestimmte Dateigrößen und -formate von der Verschlüsselung auszuschließen.

Zusammenfassung

Mit der Version 5.0 bietet ownCloud nun auch serverseitige Verschlüsselung der Daten an. Jedoch muss von einem Administrator dazu explizit ein Plug-In aktiviert werden, um Dateien mit AES 256 zu verschlüsseln. Verlässt eine Datei den ownCloud Server wird sie zunächst entschlüsselt und über eine SSL-Verbindung an den ownCloud-Client übertragen. Das bedeutet, dass eine vollständige End-to-End Verschlüsselung derzeit mit einfachen Bordmittel nicht zur Verfügung steht, was ownCloud selbst bestätigt.

Das ownCloud Encryption-Module wurde für den Einsatz innerhalb eines Unternehmens-Rechenzentrum, auf unternehmenseigenen Servern und unter der Verwaltung von vertrauensvollen Administratoren, entwickelt.

Empfehlung für das Management: TeamDrive vs. ownCloud

Der Vergleich von TeamDrive mit ownCloud stellt gewissermaßen auch einen kommerziellen einem Open-Source Ansatz gegenüber. Was hier jedoch ein wenig irritiert ist die Offenheit des kommerziellen Anbieters TeamDrive gegenüber ownCloud. Kommerzielle Anbieter werden oftmals kritisiert, wenig über ihre Sicherheitsarchitektur zu sprechen. In diesem Fall sehen wir genau das Gegenteil. Das mag bei ownCloud möglicherweise daran liegen, dass bisher nicht viel Sicherheit respektive Verschlüsselung implementiert war, über die man sprechen konnte. Erst mit der ownCloud Version 5.0 wurde ein Modul für die serverseitige Verschlüsselung implementiert. Dass allerdings Informations- aber insbesondere Sicherheitsbedarf besteht, zeigen die Fragen aus der ownCloud Community. Hier ist die ownCloud Community auch weiterhin gefordert, mehr öffentliche Informationen und Sicherheit einzufordern.

In diesem Zusammenhang macht der Inhalt des oben angesprochenen Blog-Artikels von ownCloud Sinn, der die grundlegende Sicherheitsphilosophie von ownCloud widerspiegelt. ownCloud sieht das Thema Verschlüsselung zwar als einen wichtigen Punkt an. Der Fokus sollte aber eher auf der Kontrolle der Daten liegen.

Sicherheit vs. Flexibilität

TeamDrive setzt auf einen vollständig integrierten Ansatz und bietet zudem eine End-to-End Verschlüsselung aller Daten, die vom Server zum Client des jeweiligen Endgeräts übertragen werden. Damit ermöglicht es TeamDrive trotz eines sehr hohen Anspruchs an das unbequeme Thema Sicherheit, die bequeme Nutzung eines Cloud-Storage Service. ownCloud entschlüsselt die Daten erst wenn diese vom Server geladen werden und überträgt sie in einer SSL-Verbindung. Die fehlenden Bordmittel zur End-to-End Verschlüsselung lassen sich mit externen Lösungen von Drittanbietern erreichen. Hier sollte jedoch bedacht werden, dass die Integration damit aufwändiger wird und ob ein Open-Source Ansatz speziell in diesem Fall noch Kostenvorteile bietet.

Verschwiegen werden darf nicht, dass ownCloud auf Grund seines Open-Source Ansatzes mehr Flexibilität bietet als TeamDrive und damit vollständig den eigenen Bedürfnissen nach an die eigene IT-Infrastruktur angepasst werden kann, wenn das erforderlich ist. Hinsichtlich der Sicherheit besteht bei ownCloud allerdings noch Nachholbedarf. Das hat zur Folge, dass die Lösung per se nicht den aktuellen Sicherheitsansprüchen von Unternehmen entspricht und daher nur bedingt zu empfehlen ist.

Am Ende muss die Entscheidung getroffen werden, ob ein Unternehmen einen kommerziellen und integrierten Ansatz inklusive Sicherheitsmechanismen anhand von Bordmittel erwartet oder eine Open-Source Software, für die weitere externe Sicherheitslösungen benötigt werden, die selbst zu integrieren sind. Wer eine All-in-One Lösung inklusive vollständiger End-to-End Verschlüsselung und damit gleichzeitig mehr Sicherheit sucht, sollte sich für TeamDrive entscheiden.



Google Cloud Platform vs. Amazon Web Services – Ein erster Vergleich

Nachdem Google sein Cloud Portfolio mit der Compute Engine erweitert hat, fangen erste Medien an darin den Killer der Amazon Web Services zu sehen. Ein Grund mal die Cloud Services von Google und Amazon gegenüberzustellen. Wer sich für einen direkten Vergleich von Microsoft Windows Azure mit den Amazon Web Services interessiert, sollte hier weiterlesen.

Der Vergleich: Google Cloud vs. Amazon Cloud

Die folgende Tabelle stellt das Cloud Services Portfolio 1:1 gegenüber und schafft Klarheit, wer in welchem Bereich was anbietet, wie der Name des jeweiligen Service lautet und unter welcher URL weitere Informationen zu diesem zu finden sind.

Funktion

Amazon Web Services

Google Cloud Platform

Rechenleistung

Virtuelle Maschinen Elastic Compute Cloud Full Virtual Machines (Google Compute Engine)
High Performance Computing Cluster Compute Instances
-
MapReduce Elastic Map Reduce Google App Engine
Dynamische Skalierung Auto Scaling Google Compute Engine

Speicher

Unstrukturierter Speicher Simple Storage Service Google Cloud Storage
Flexible Entities SimpleDB
-
Block Level Storage Elastic Block Store Persistent disk (Google Compute Engine)

Datenbanken

RDBMS Relational Database Service Google Cloud SQL, BigQuery
NoSQL DynamoDB "Google F1"

Caching

CDN CloudFront
-
In-Memory ElastiCache
-

Netzwerk

Load Balancer Elastic Load Balancer
-
Hybrid Cloud Virtual Private Cloud
-
Peering Direct Connect
-
DNS Route 53 Public DNS

Messaging

Async Messaging Simple Queue Service
-
Push Notifications Simple Notification Service
-
Bulk Email Simple Email Service
-

Monitoring

Ressourcen Monitoring CloudWatch
-

Sicherheit

Identitätsmanagement Identity Access Management
-

Deployment

Ressourcenerstellung CloudFormation
-
Web Application Container Elastic Beanstalk Google App Engine

Wie man sieht, ist das Google Cloud Portfolio im Vergleich zum Service Angebot der Amazon Web Services noch sehr dünn. Falls ich etwas bei Google übersehen habe, macht mich darauf bitte aufmerksam. Ich werde das dann umgehend nachtragen.



Amazon Web Services vs. Microsoft Windows Azure – Ein direkter Vergleich

Viele Unternehmen befinden sich derzeit in der Evaluation von Public Cloud Services wie IaaS. Die ersten Gedanken streifen dann die beiden großen und vermeintlich bekanntesten Anbieter in der Szene - die Amazon Web Services und Microsoft Windows Azure.

Beide verfügen mittlerweile über ein sehr umfangreiches und stetig wachsendes Angebot an Cloud Services. Möchte man beide Portfolios jedoch miteinander vergleichen steigen die Herausforderungen mit der Anzahl der Services.

Amazon Cloud vs. Windows Azure

Die folgende Tabelle stellt das Cloud Service Portfolio 1:1 gegenüber und schafft Klarheit, wer in welchem Bereich was anbietet, wie der Name des jeweiligen Service lautet und unter welcher URL weitere Informationen zu diesem zu finden sind.

Funktion

Amazon Web Services

Microsoft Windows Azure

Rechenleistung

Virtuelle Maschinen Elastic Compute Cloud Role Instances
High Performance Computing Cluster Compute Instances HPC Scheduler
MapReduce Elastic Map Reduce Hadoop on Azure
Dynamische Skalierung Auto Scaling Auto Scaling Application Block

Speicher

Unstrukturierter Speicher Simple Storage Service Azure Blob
Flexible Entities SimpleDB Azure Tables
Block Level Storage Elastic Block Store Azure Drive
Archivierung Amazon Glacier
Stroage Gateway AWS Storage Gateway

Datenbanken

RDBMS Relational Database Service SQL Azure
NoSQL DynamoDB Azure Tables

Caching

CDN CloudFront CDN
In-Memory ElastiCache Cache

Netzwerk

Load Balancer Elastic Load Balancer Fabric Controller / Traffic Manager
Hybrid Cloud Virtual Private Cloud Azure Connect
Peering Direct Connect
-
DNS Route 53
-

Messaging & Anwendungen

Async Messaging Simple Queue Service Azure Queues
Push Notifications Simple Notification Service Service Bus
Bulk Email Simple Email Service
Workflows Amazon Simple Workflow Service
Suche Amazon CloudSearch

Monitoring

Ressourcen Monitoring CloudWatch System Center

Sicherheit

Identitätsmanagement Identity Access Management Azure Active Directory

Deployment

Ressourcenerstellung CloudFormation
-
Web Application Container Elastic Beanstalk Web Role


Cloud Computing vs. On-Premise und Managed Services

Arten, wie Unternehmen Informationstechnologie für sich einsetzen, gibt es im Grunde genommen nicht viele. Die eine besteht darin, alles selbst zu machen. Die andere darin, alles zu einem Drittanbieter auszulagern. Die dritte ist, eine hybride Lösung zu nutzen, also bestimmte Dinge selbst zu betreiben und gewisse Bereiche verarbeiten zu lassen.

Grundsätzlich unterscheiden wir also den Betrieb einer eigenen IT-Infrastruktur, auch als On-Premise bezeichnet, und den Ansatz des Outsourcingmodells. Für das Outsourcing wird auch oft der englische Begriff Managed Services verwendet.

On-Premise

Beim On-Premise, also dem Betrieb einer eigenen IT-Infrastruktur, verfügt ein Unternehmen über eine vollständig eigene intern zu verwaltende IT-Umgebung. Das gilt selbst dann, wenn das Unternehmen Server in einer Co-Location eines Rechenzentrums angemietet hat. In diesem Fall müssen also sämtliche Vorabinvestitionen in Hardware und Software sowie Kosten für Strom, Kühlung und Personal geleistet werden. Fällt einer oder mehrere Server aus, entstehen dadurch weitere Kosten sowie der Zwang, diese schnellstmöglich durch funktionsfähige Geräte zu ersetzen.

Managed Services

Bei den Managed Services, also der Auslagerung des Betriebs und der Verwaltung der IT-Aufgaben, wird ein externer Dienstleister mit der Wartung beauftragt. In diesem Fall befinden sich die Server im Eigentum des Dienstleisters. Dieser ist für den reibungslosen Betrieb der Infrastruktur zuständig und hat dafür zu sorgen, dass ein fehlerhafter Server umgehend oder je nach dem vereinbarten Service Level Agreement (SLA) auszutauschen.

Der Dienstleister verfügt somit über die Expertise, dem Unternehmen den einwandfreien Betrieb der Server zu garantieren. Des Weiteren ist er für die Wartung der Betriebssysteme verantwortlich, die auf den Servern installiert sind. Das beinhaltet die Versorgung mit Patches etc. und die Betreuung der gesamten Netzwerkinfrastruktur, in der die Server untergebracht sind. Das Unternehmen hat mit dem Dienstleister in der Regel einen langfristigen Vertrag und zahlt diesem für die erbrachten Leistungen eine monatliche oder jährliche Gebühr.

Der Vergleich

Zu diesen beiden IT-Nutzungsmodellen gesellt sich nun das Cloud Computing. In Diskussionen zum Thema Cloud Computing wird von Skeptikern in der Regel die Meinung vertreten, dass Cloud Computing keine nennenswerten Vorteile birgt und es sich dabei nur um alten Wein in neuen Schläuchen handelt.

IT-Manager stehen immer denselben Situationen gegenüber. Dabei entstehen Fragen hinsichtlich der korrekten Softwarelizensierung, in deren Falle viele Unternehmen tappen, da die Übersicht dabei schnell verloren gehen kann. Auch der Zeitpunkt und die Art und Vorgehensweise beim nächsten unternehmensweiten Softwareupdate darf an dieser Stelle nicht unterschätzt werden. Wie verhält es sich beim Ausfall einer Hardware in der Nacht? Zum einen muss dafür das benötigte Personal verfügbar und zum anderen die entsprechende Ersatzhardware vorhanden sein. Ähnlich verhält es sich bei der grundsätzlichen Verwaltung der bestehenden Serverlandschaft und der Entsorgung ausrangierter Althardware, die ordnungsgemäß beseitigt werden muss. Ein weiterer nicht zu unterschätzender Punkt ist die Erweiterung der IT-Infrastruktur. Von der Planung über die Entscheidung bis hin zur letztendlichen Bestellung, Lieferung, der endgültigen Installation und des Testlaufs können dabei mehrere Monate verstreichen. Aber auch steuerrechtliche Themen wie die Abschreibung der IT-Vermögenswerte sind Bereiche, die bei dem Betrieb einer IT-Infrastruktur mit bedacht werden müssen.

Ein Vergleich soll zeigen, dass dem nicht so ist. George Reese hat zu diesem Thema die oben genannten Nutzungsmodelle, On-Premise und Managed Services dem Cloud Computing gegenübergestellt und die Attribute “Investitionskapital”, “Betriebskosten”, “Bereitstellungszeit”, “Flexibilität”, “Anforderungen an das Mitarbeiter KnowHow” und “Zuverlässigkeit” miteinander verglichen. Hierbei hat er eine Gewichtung bzgl. der Wichtigkeit der jeweiligen Attribute auf die entsprechende IT-Nutzung vorgenommen.

Investitionskapital

  • On-Premise:            signifikant
  • Managed Services:   moderat
  • Cloud Computing:     unerheblich

An dieser Stelle gilt es die Frage zu stellen, wie viel Kapital zur Verfügung steht, um die eigene Infrastruktur aufzubauen bzw. Änderungen an dieser vorzunehmen. Bei dem Betrieb eines Eigenen Rechenzentrums muss bspw. in die dafür benötigte Hardware vorab gezielt investiert werden, selbst dann, wenn die Hardware zu dem Zeitpunkt noch nicht benötigt wird. Somit kommt dem Investitionskapital eine hohe Bedeutung zu. Im Falle der Managed Services entstehen Setup Gebühren für die Einrichtung des Systems, die jedoch als angemessen betrachtet werden können. Beim Cloud Computing entstehen keine Vorabinvestitionen und Verpflichtungen. Das Investitionskapital ist an dieser Stelle daher marginal.

Betriebskosten

  • On-Premise:            moderat
  • Managed Services:   signifikant
  • Cloud Computing:     nutzungsbasiert

Die laufenden Kosten für das eigene Rechenzentrum beziehen sich auf die Kosten für das Personal und/ oder Subunternehmer, die für die Verwaltung und den Betrieb der Infrastruktur zuständig sind. Dazu kommen die Kosten für die Gebäude sowie die Nebenkosten, die während des Betriebs entstehen. Erhebliche Abweichungen der laufenden Kosten entstehen speziell mit Subunternehmern, wenn Notfälle oder andere Probleme eintreten und Sonderzahlungen z.B. durch Mehrarbeit entstehen. Managed Services sind verhältnismäßig teuer, jedoch sind die monatlichen Kosten vertraglich fest geregelt, sodass die Aufwendungen, die aufgebracht werden müssen, planbar sind, da diese sehr selten variieren. Die laufenden Kosten beim Einsatz von Cloud Computing hängen von der Art, Länge und Häufigkeit der jeweiligen Nutzung ab. Jedoch besteht hier der entscheidene Vorteil darin, dass nur dann Kosten entstehen, wenn ein Service genutzt wird. Die Abrechnung erfolgt auf Basis der tatsächlichen Nutzung - nicht mehr und nicht weniger. Im Vergleich zu den Managed Services sind die Personalkosten höher, aber deutlich günstiger als bei dem Betrieb eines eigenen Rechenzentrums.

Bereitstellungszeit

  • On-Premise:            signifikant
  • Managed Services:   moderat
  • Cloud Computing:     keine

Die Bereitstellungszeit ist ein entscheidender Faktor, wenn es darum geht, wie lange es dauert, bis z.B. ein neuer Server der bestehenden Infrastruktur hinzugefügt wird. Im Falle eines eigenen Rechenzentrums oder der Managed Services erfolgt zunächst die Planung gefolgt von der sich anschließenden Bestellung und der damit verbunden Wartezeit, bis die neue Komponente endgültig in Betrieb genommen und zunächst getestet wird, bis sie dann am Ende in den Live-Betrieb gehen kann. Bei der Zusammenarbeit mit einem Managed Services Provider ist die Wartezeit geringer im Vergleich zum eigenen Rechenzentrum, vorausgesetzt der Provider hat die benötigten Komponenten vorrätig. Bei der Nutzung des Cloud Computing vergehen von der Entscheidung für einen neuen Server bis zu seiner vollständigen Bereitstellung hingegen nur wenige Minuten.

Flexibilität

  • On-Premise:            limitiert
  • Managed Services:   moderat
  • Cloud Computing:     flexibel

Infrastrukturen sind heutzutage z.T. extremen Anforderungen und unerwarteten Belastungen ausgesetzt. Aus diesem Grund gilt es darauf zu achten, inwieweit eine Infrastruktur etwaige unvorhergesehene Spitzenlasten beherrschen kann, indem sie bei Bedarf weitere Ressourcen bereitstellt. Ein Beispiel wäre eine beschränkte Speicherplatzgröße. Wie verhält sich die Infrastruktur, wenn das Limit des Speicherplatzes plötzlich erreicht ist. Rechenzentren, die selbst betrieben werden, haben von Natur aus eine sehr feste Kapazität und das Hinzufügen von weiteren Ressourcen kann bei Bedarf nur durch den Einsatz von mehr Kapital vorgenommen werden. Zudem ist der Zeitraum von der Notwendigkeit weiterer Ressourcen bis zur endgültigen Bereitstellung sehr lang. Ein Managed Service Provider kann hier temporär mit weiteren Ressourcen aushelfen, indem bspw. die Bandbreite erhöht oder der kurzfristige Zugriff auf alternative Speichermöglichkeiten gewährt wird. Bei der Verwendung des Cloud Computing hingegen kann die entsprechende Cloud Infrastruktur so eingerichtet werden, dass sie im Falle weiterer benötigter Kapazitäten diese automatisch hinzufügt und wieder entfernt, wenn sie nicht mehr benötigt werden.

Anforderungen an das Mitarbeiter Know How

  • On-Premise:            signifikant
  • Managed Services:   limitiert
  • Cloud Computing:     moderat

Bei diesem Attribut geht es um die Frage, wieviel Know How innerhalb des Unternehmens benötigt wird, um die IT-Umgebung zu betreiben. Beim dem Betrieb eines eigenen Rechenzentrums werden entsprechendes Personal oder Subunternehmer benötigt, die über die notwendigen Kenntnisse der Infrastruktur verfügen. Dazu gehört u.a. das Wissen über die Serverhardware und die Betriebssysteme sowie die Betreuung der Systeme, z.B. das Einspielen von Patches, um die Systeme auf dem aktuellen Stand zu halten. Den Vorteil haben an dieser Stelle die Managed Services Provider, da diese sich um die Wartung der Infrastruktur kümmern. Je nachdem wie die Nutzung von Cloud Computing erfolgt, sind entweder mehr oder weniger Kenntnisse erforderlich. Unterstützung bieten hier bspw. Cloud Infrastruktur Manager (Software), die dabei helfen, die verwendete Cloud Umgebung zu verwalten. Jedoch sind hier trotzdem Kenntnisse bzgl. der Einrichtung und der Konfiguration der virtuellen Maschinen Images notwendig.

Zuverlässigkeit

  • On-Premise:            variiert
  • Managed Services:   hoch
  • Cloud Computing:     moderat bis hoch

Die Zuverlässigkeit der Infrastruktur ist ein weiterer wichtiger Punkt, den es zu beachten gilt. Der Aufbau einer hochverfügbaren Infrastruktur im eigenen Rechenzentrum hängt von dem jeweiligen Personal und des verfügbaren Kapitals ab, das in die Infrastruktur investiert werden soll. Ein Managed Services Provider ist an dieser Stelle die bewährteste Alternative. Jedoch ist hier ein Standortvorteil, den eine Cloud auf Grund ihrer Rendundanz bietet, nicht vorhanden. Einer Cloud Infrastruktur fehlt hingegen (noch) die nachgewiesene Erfolgsbilanz der Stabilität.

Fazit

Der Vergleich zeigt, dass es für den Großteil der Unternehmen keinen Sinn mehr ergibt, eine eigene Infrastruktur von Grund auf neu aufzubauen. Lediglich Unternehmen, die bereits hohe Investitionen in das eigene Rechenzentrum vorgenommen haben oder diejenigen, die auf Grund von rechtlichen Hindernissen oder anderweitiger Regularien ihre Daten nicht bei einem Drittanbieter speichern dürfen, können zunächst davon absehen. Sie sollten sich für zukünftige Investionen aber zumindest Gedanken über den Ansatz eines Hybrid Cloud Modells machen.

Alle anderen Unternehmen sollten schließlich auf einen Managed Service Provider oder einen Cloud Computing Anbieter zurückgreifen. Speziell das Pay as you Go Modell und der flexible Ressourcenbezug des Cloud Computing führt bei jedem Unternehmen zu einer höheren Flexibilität und somit einer besseren Agilität und erhöht die Innovationsfreudigkeit bei den Mitarbeitern.