Tag: Cloud

SAP Cloud: Lars Dalgaard wird ein riesiges Loch hinterlassen

Post author By Rene Buest
Post date June 4, 2013

Nun ist er wieder weg, Lars Dalgaard. Er war mein persönlicher Hoffnungsträger für SAP und meiner Einschätzung nach die treibende Kraft hinter der Cloud-Strategie der Walldorfer, welche in den letzten Monat immer mehr an Fahrt aufgenommen hat. Aber nicht nur für die Cloud hat Dalgaard bei SAP einiges umgekrempelt, auch kulturell hätte es dem Unternehmen gut getan, ihn länger in den eigenen Reihen zu haben. Oder war es vielleicht genau das Problem, warum er nach so kurzer Zeit wieder gehen musste.

Glaubwürdige positive Energie

Den Cloud Gedanken hat sich SAP extern durch die damalige Akquisiton von SuccessFactors mit dessen Gründer und CEO Lars Dalgaard einverleibt. Der Däne wurde nach der Übernahme als Verantwortlicher für den SAP Cloud Bereich zur treibenden Kraft hinter den SAP Cloud Services. Und diesen Job hat er gut gemacht. In seiner Key Note, während der Sapphire Now 2012, in welcher er die neue Cloud Strategie von SAP vorstellte, präsentierte Dalgaard sich als explosiver Unternehmer, der seine Startup Gene bei weitem nicht abgelegt hat. Im Gegenteil, mit seiner Motivation brachte er frischen Wind in den etablierten Konzern aus Walldorf.

Ich hatte schon während meines Rückblicks auf die Sapphire Now 2012 geschrieben: “Es bleibt für Dalgaard und vor allem für SAP zu hoffen, dass er seine Cloud Vision verwirklichen und das er mit seinem Startup Charakter auf offene Türen hoffen darf. Denn SAP ist weit weg von dem, was man logischerweise als ein Startup bezeichnen kann.”

Unterschiedliche Unternehmenskulturen

Ist genau dieser Umstand Dalgaard oder besser gesagt SAP nun zum Verhängnis geworden? Lars Dalgaard ist zum 1. Juni 2013 von seinem Vorstandsposten zurückgetreten, hat SAP verlassen und ist als General Partner bei Andreessen Horowitz eingestiegen. Er wird SAP weiterhin für das Cloudgeschäft im Cloud Governance Board beratend zur Seite stehen.

Ich kann an dieser Stelle nur spekulieren. Zwar kenne ich Dalgaard nicht persönlich. Aber seine positive Energie, die er während seiner Vorträge ausstrahlt, zeugen von jemanden, der weiß was er will und eine klare Linie verfolgt. Zugegebenermaßen bin ich auch kein SAP-Experte hinsichtlich der Unternehmenskultur. Allerdings sind schon viele gute Leute fragwürdiger Weise an SAP zerbrochen. Als ein Beispiel sei nur Shai Agassi genannt.

#SAP cannot deal well with external talent. Lars Dalgaard is just another example after Shai Agassi and many others. bloomberg.com/news/2013-05-2…

— Stefan Ried (@StefanRied) 3. Juni 2013

Quo vadis, SAP?

Ein ganzes Unternehmen an einer einzigen und dann auch noch extern eingekauften Person festzumachen ist übertrieben. Dennoch vertrete ich den Standpunkt, dass der Verlust von Lars Dalgaard einen erheblichen Einfluss auf das Cloud-Geschäft von SAP haben könnte. Man erinnere sich an den sehr steinigen Beginn von SAP im Cloud-Bereich mit seiner Produktlinie “SAP Business By Design”, die in ihrer ersten Version den Begriff Cloud-Lösung nicht verdient hatte und ein echter Reinfall war. Mit Business By Design 4.0 hat SAP – unter der Leitung von Lars Dalgaard – noch einmal von Vorne begonnen und der Zug kam ins Rollen.

Es sei SAP zu wünschen, dass sie diese “Dalgaard-Mentalität” nicht verlieren, um damit im Cloud-Markt weiterhin konkurrenzfähig zu bleiben. Denn eines sollte man nicht vergessen. Ein Cloud-Unternehmen muss anders geführt werden, als ein traditionelles Softwareunternehmen. Man vergleiche nur Amazon und Google. Das Gleiche musste auch Microsoft erst verstehen und lernen sich neu zu erfinden. SAP war – mit Lars Dalgaard – bisher zumindest auf dem richtigen Weg.

Tags Cloud, Cloud Computing, SaaS, SAP

Comment

The cloud computing world is hybrid! Is Dell showing us the right direction?

Post author By Rene Buest
Post date May 29, 2013
No Comments on The cloud computing world is hybrid! Is Dell showing us the right direction?

With a clear cut, Dell said good bye to the public cloud and align its cloud computing strategy with own OpenStack-based private cloud solutions, including a cloud service broker for other public cloud providers. At first the move comes surprising, but makes sense when you take a closer look at Dell, whose recent past and especially the current market situation.

Dell’s new cloud strategy

Instead of having an own public cloud offering on the market, Dell will sell OpenStack-based private clouds on Dell hardware and software in the future. With the recent acquisition of cloud management technology Enstratius customers will also be able to deploy their resources to more than 20 public cloud provider.

With a new “partner ecosystem”, which currently consists of three providers and that is further expanded in the future, integration opportunities between the partner’s public clouds and private clouds of Dell customers will be offered. The current partner network includes Joyent, ZeroLag and ScaleMatrix. All three are rather small names in the infrastructure-as-a-service (IaaS) market.

Further, Dell also strengthens its consulting business to show customers which workloads and processes could flow into the public cloud.

Thanks Enstratius, Dell becomes a cloud broker

A view on the current public cloud IaaS market shows that Dell is right with its strategy change. All current IaaS providers of all sizes to chafe in the fight for market share against industry leader Amazon Web Services. Since their innovative strength is limited compared to Amazon and most of them to limit themselves, with the exception of Google and Microsoft, to the provision of pure infrastructure resources (computing power, storage, etc.), the chances of success are rather low. Moreover, into a price war with Amazon the fewest should get involved. That can quickly backfire.

Rather than dealing with Amazon and other public IaaS providers in the boxing ring, Dell positioned itself on the basis of Boomi, Enstratius and other previous acquisitions as a supportive force for cloud service providers and IT departments and provides them with hardware, software and more added values.

In particular, the purchase of Enstratius was a good move and let Dell become a cloud service broker. Enstratius is a toolset for managing cloud infrastructures, including the provisioning, management and automation of applications for – currently 23 – public and private cloud solutions. It should be mentioned that Enstratius in addition to managing a single cloud infrastructure also allows the operation of multi-cloud environments. For this purpose Enstratius can be used as a software-as-a-service and installed in on-premise environments in the own data center as a software.

The cloud computing world is hybrid

Does Dell rise in the range of cloud innovators with this change in strategy? Not by a long shot! Dell is anything but a leader in the cloud market. The trumps in their cloud portfolio are entirely due to acquisitions. But, at the end of the day, that does not matter. To be able to take part in the highly competitive public cloud market, massive investment should have been made that would not have been necessarily promising. Dell has been able to focus on his tried and true strengths and these are primarily in the sale of hardware and software, keyword: “Converged Infrastructures” and the consulting business. With the purchase of cloud integration service Boomi, the recent acquisition of Enstratius and the participation in the OpenStack community externally relevant knowledge was caught up to position itself in the global cloud market. In particular, the Enstratius technology will help Dell to diversify the market and take a leading role as a hybrid cloud broker.

The cloud world is not only public or only private. The truth lies somewhere in the middle and strongly depends on the particular use case of a company, which can be divided into public, private as well as hybrid cloud use cases. In the future, all three variants will be represented within a company. Thereby the private cloud does not necessarily have to be directly connected to a public cloud to span a hybrid cloud. IT departments will play a central role in this case, get back more strongly into focus and act as the company’s own IT service broker. In this role, they have the task of coordinating the use of internal and external cloud services for the respective departments to have an overall view of all cloud services for the whole enterprise. For this purpose, cloud broker services such as Dell’s will support.

Tags Cloud, Cloud Broker, Cloud Computing, Dell, Enstratius, Hybrid, IaaS

Kommentar

Die Cloud Computing Welt ist hybrid! Zeigt uns Dell wo es lang geht?

Post author By Rene Buest
Post date May 28, 2013
No Comments on Die Cloud Computing Welt ist hybrid! Zeigt uns Dell wo es lang geht?

Dell hat sich mit einem klaren Schnitt aus der Public Cloud verabschiedet und richtet seine Cloud Computing Strategie nun mit eigenen auf OpenStack-basierten Private Cloud Lösungen, inkl. einem Cloud-Broker-Service für Public Clouds anderer Anbieter, aus. Dieser Schritt kommt im ersten Moment überraschend, macht aber Sinn, wenn man Dell, dessen jüngste Vergangenheit, aber vor allem den Markt genauer betrachtet.

Dells neue Cloud Strategie

Anstatt ein eigenes Public Cloud Angebot am Markt zu platzieren, wird Dell in Zukunft OpenStack-basierte Private Clouds auf Dell Hardware und Software verkaufen. Mit der erst kürzlich akquirierten Cloud-Management Technologie von Enstratius sollen Kunden darüber hinaus in der Lage sein, ihre Ressourcen zu mehr als 20 Public Cloud Anbieter zu verteilen.

Mit einem neuen “Partner Ecosystem”, das derzeit aus drei Anbietern besteht, in Zukunft aber weiter ausgebaut wird, sollen Integrationsmöglichkeiten zwischen den Public Clouds dieser Partner und den Private Clouds der Dell Kunden angeboten werden. Zu dem aktuellen Partnernetzwerk gehören Joyent, ZeroLag und ScaleMatrix. Alle drei sind eher kleine Namen im Infrastructure-as-a-Service (IaaS) Markt.

Dell stärkt damit ebenfalls weiter sein Beratungsgeschäft, indem Kunden aufgezeigt werden soll, welche Workloads und Prozesse in die Public Cloud fließen können.

Enstratius macht Dell zum Cloud-Broker

Ein Blick auf den aktuellen IaaS Public Cloud Markt zeigt, dass Dell mit seiner Strategieänderung richtig liegt. Alle aktuellen IaaS Anbieter jeder Größe reiben sich im Kampf um Marktanteile gegen den Branchenprimus Amazon Web Services auf. Da sich deren Innovationskraft im Vergleich zu Amazon jedoch auf ein Minimum beschränkt und sich die meisten, mit Ausnahme von Google und Microsoft, auf das Bereitstellen von reinen Infrastruktur-Ressourcen (Rechnerleistung, Speicherplatz, usw.) beschränken, sind die Erfolgsaussichten eher gering. Auf einen Preiskampf mit Amazon sollten sich zudem die wenigsten einlassen, das kann sehr schnell nach hinten losgehen.

Anstatt sich ebenfalls mit Amazon und den anderen Public IaaS Anbietern in den Ring zu stellen, positioniert sich Dell nun auf Basis von Boomi, Enstratius und weiteren früheren Akquisitionen als unterstützende Kraft für Cloud Service Anbieter und IT-Abteilungen und versorgt diese mit Hardware, Software und weiteren Mehrwerten.

Insbesondere der Kauf von Enstratius war ein guter Schachzug und macht Dell zum Cloud-Service-Broker. Bei Enstratius handelt es sich um ein Toolset zur Verwaltung von Cloud-Infrastrukturen, darunter die Bereitstellung, die Verwaltung und die Automatisierung von Applikation für – aktuell 23 – Public und Private Cloud Lösungen. Zu erwähnen ist, dass Enstratius neben dem Verwalten von einer Cloud-Infrastruktur ebenfalls den Betrieb von Multi-Cloud Umgebungen ermöglicht. Dazu kann Enstratius als Software-as-a-Service genutzt, als auch in on-Premise Umgebungen im eigenen Rechenzentrum als Software installiert werden.

Die Cloud Computing Welt ist Hybrid

Steigt Dell mit diesem Strategiewechsel nun in die Reihe der Cloud-Innovatoren auf? Bei Weitem nicht! Dell ist alles andere als ein führender Anbieter im Cloud Markt. Die Trümpfe im Cloud-Portfolio sind einzig und allein auf Akquisitionen zurückzuführen. Unterm Strich spielt das aber keine Rolle. Um im mittlerweile stark umkämpften Public Cloud Markt ein Wörtchen mitreden zu können, hätten massive Investitionen getätigt werden müssen, die nicht zwangsläufig erfolgsversprechend gewesen wären. Dell hat verstanden sich auf seine altbewährten Stärken zu konzentrieren und die liegen in erster Linie im Verkauf von Hardware und Software, Stichwort “Converged Infrastructures” und dem Beratungsgeschäft. Mit dem Kauf des Cloud-Integrations-Service Boomi, der jüngsten Akquisition von Enstratius und der Beteiligung an der OpenStack Gemeinde wurde extern entsprechendes Wissen eingeholt, um sich im weltweiten Cloud Markt zu positionieren. Insbesondere die Enstratius Technologie wird Dell dabei helfen, sich im Markt zu diversifizieren und als Hybrid Cloud-Broker eine führende Rolle einzunehmen.

Die Cloud Welt ist nicht nur Public oder nur Private. Die Wahrheit liegt irgendwo mittendrin und hängt stark von dem jeweiligen Use Case eines Unternehmens ab, die sich in Public, Private aber auch Hybrid Cloud Use Cases unterteilen. In Zukunft werden innerhalb eines Unternehmens alle drei Varianten vertreten sein. Dabei muss die Private Cloud nicht zwangsläufig direkt mit einer Public Cloud verbunden sein, um eine Hybrid Cloud aufzuspannen. Die IT-Abteilungen werden in diesem Fall eine zentrale Rolle spielen, wieder stärker in den Fokus rücken und als unternehmenseigener IT-Service-Broker auftreten. In dieser Rolle haben sie die Aufgabe, die eingesetzten internen und externen Cloud-Services der jeweiligen Fachabteilungen zu koordinieren, um für das Unternehmen den Gesamtüberblick aller Cloud-Services zu haben. Hierbei werden sie Cloud-Broker Services wie der von Dell unterstützen.

Tags Cloud, Cloud Broker, Cloud Computing, Dell, Enstratius, Hybrid, IaaS

Insights @en

Security Comparison: TeamDrive vs. ownCloud

Post author By Rene Buest
Post date May 27, 2013
No Comments on Security Comparison: TeamDrive vs. ownCloud

Dropbox polarized within the IT departments. From the executive board up to the ordinary employees, people rely on the popular cloud storage service. This is mainly due to the ease of use that is not provided by internal IT departments today. In particular two in Germany developed solutions attack here, which allow companies to implement their own DropBox similar functions within a self-managed IT infrastructure, TeamDrive and ownCloud. TeamDrive represents a fully commercial and proprietary approach. ownCloud an open source approach, but also offers a commercial version. Both claim the title of “Dropbox for the Enterprise”. However, if we are moving exactly in this environment, the issue of security plays a very important role.

Background: TeamDrive and ownCloud

TeamDrive and ownCloud have two different business models. TeamDrive positioned itself as a fully commercial product for companies in the market. ownCloud uses the open source community in order to gain market share. With a commercial version, ownCloud also addresses the market for professional business solutions.

About TeamDrive

TeamDrive is a file sharing and synchronization solution for companies that do not want to store their sensitive data on external cloud services and would also enable their teams to synchronize data or documents. Therefore TeamDrive monitors any folder on a PC or laptop that can be used and edit together with invited users. With that data is available at any time, also offline. The automatic synchronization, backup and versioning of documents protect users from data loss. With the possibility of TeamDrive to operate the registration and hosting server in the own data center, TeamDrive can be integrated into existing IT infrastructures. For this TeamDrive provides all the necessary APIs.

About ownCloud

ownCloud is an open source file sync and sharing solution for companies and organizations that want to continue to retain control of their data and do not want to rely on external cloud storages. The core of the application consists of the ownCloud server on which the software seamlessly integrates with the ownCloud clients into the existing IT infrastructure and enables the continued use of existing IT management tools. ownCloud serves as a local directory and can be mounted with different local storages. Thus, files are available to all employees on all devices. In addition to a local storage directories can also be connected via NFS and CIFS.

TeamDrive and ownCloud: Security Architecture

In this comparison it is about the security architecture behind TeamDrive and ownCloud. The other functions of both solutions are not considered. So it is about the consideration of encryption techniques, data management, data processing and the user authorization, if information is available. It is assumed that basic knowledge on security exists.

TeamDrive: End-to-End Encryption

Despite its commercial approach TeamDrive is quite informative and provides some security information publicly available. Including on the topic of encryption. They also advertise with the data protection seal of the “Independent Centre for Privacy Protection Schleswig-Holstein”. After a request extensive information has been readily made available, whereby some underlie a NDA (Non-Disclosure Agreement).

Ciphering Method

TeamDrive sets on the following encryption mechanisms:

Advanced Encryption Standard – AES 256
To encrypt the data TeamDrive uses the Advanced Encryption Standard (AES) encryption system with a 256-bit key and sets on the C code implementation of the OpenSSL library.
Diffie-Hellman and RSA 3072
For key exchange TeamDrive sets on the Diffie-Hellman algorithm for its older clients. New clients using RSA 3072. The Diffie-Hellman implementation is based on the C code implementation as it is provided by the OpenSSL library.
Message Digest 5/6 – MD5/MD6
The TeamDrive hash function is based on the MD5/ MD6 algorithm, where the hash value is stored as a random string (salt).
PrimeBase Privacy Guard – PBPG
The PrimeBase Privacy Guard (PBPG) is a proprietary public/ private key system that sets on the Diffie-Hellman key exchange and AES encryption. For the user the behavior of PBPG is similar to the known public/ private key systems of PGP or GnuPG. The PBPG encryption generates random changes and verifies the files during the exchange, so PBPG can detect whether a message or keys have been tampered or altered otherwise. Two messages are never the same. Here, a key pair is generated not only for each user, but also for each installation. The PBPG implementation is open and can be verified by partners and other interested parties, if required.

System Architecture

In TeamDrive data is stored in a so-called Space which determined the number of users who can access. The exchange takes place on a Space Depot, which lies on a TeamDrive Enterprise Hosting Server, a TeamDrive Personal Server or WebDAV.

Each Space has its own 256-bit AES key used to encrypt the data in this Space, if the data leaves the user’s device. Only the TeamDrive software, which is installed on the device of the other users of a Space, has knowledge of the key.

Each server on which a Space Depot is available, is responsible for storing, forwarding and adapting to changes within the Space. So the clients can also exchange data even if not all are online at the same time. Any data that is stored on the server is encrypted by using the 256 bit AES key of the Space.

User Authorization

The registration of a user is done with the TeamDrive client software that checks him against the TeamDrive registration server. This is basically done by entering an email address or a username and a password.

The authorization between the TeamDrive client and the TeamDrive registration server is based on the public key of the registration server. Information such as the e-mail address and the registration password plus other data of the user are transferred in an encrypted form to the registration server using the public key of the registration server.

Only the activation code is sent unencrypted over an unencrypted e-mail to the user. In addition, an encrypted response with the device ID is sent to the TeamDrive client. After the activation by the user, the client software will generate a PBPG key and a matching public key. Following the client software sends the registration password and the public key encrypted back to the registration server using the public key of the server. The activation code is verified and the public key of the user stored. All of the following messages that are sent to the registration server are encrypted with the PBPG public key of the user and need the device ID and the registration password for authorization.

Data Storage and Processing

To generate a Space, the user needs a Space Depot and its password. This tells the TeamDrive client which server it needs to contact in order to create the Space. Subsequently the client software asks for the public key of the TeamDrive Hosting Server. The client software sends the device ID, the Space Depot id, username, user ID, the user’s public key and the name of the Space as an encrypted message to the TeamDrive server. The message is encrypted with the public key of the server. The Space Depot ID and password are checked. For the encrypted transmission of the response the user’s public key is used. The TeamDrive server creates a new Space on the specified Space Depot. A 128-bit “authorization code” is randomly generated for the new Space and sent back to the client.

To access a Space the URL, an authorization code and a Space data key is required. The URL contains the address of the server which is addressed to the Space Depot that includes the contents of the Space, and the Space ID. Changes in the Space are uploaded or downloaded to the Space in the Space Depot. For this purpose, HTTP PUT and POST methods are used. Before a file leaves the client, it is compressed and encrypted with a 256-bit AES key.

To access a Space, the TeamDrive client opens a session with the server. First therein the ID of the Space, to be accessed, is transmitted. After successful testing the server generates a new session ID with a 128-bit random number (RND) and sends it back to the client which stores it locally. For uploading and deleting data, the client uses the RND and the authorization code of the Space and links these in a xor operation including a MD5 operation on the result. The result will be sent along with the session ID and the encrypted data to the server.

The security of a Space Depot is ensured that after each request a random RND value is returned that must be recalculated to a local value each time by the client. In addition a MD5 hash guarantees that the authorization code of the Space cannot be derived. Even if the RND and the local value are known on the client side. This will also prevent that an attacker can infiltrate into a session to upload data to the server.

Summary

The data security in a TeamDrive Space is ensured by encrypting the data with a 256-bit AES key. For this, the key is only known by the TeamDrive clients, which are member of a Space. Provider of storage services based on TeamDrive or system administrators do not have access to the data. The exchange of Space authorization keys between TeamDrive users follows with a secure public/ private key method, which uses a 256-bit AES encryption itself. The access to a Space Depot or a Space is protected with a 128-bit authorization code. The authorization code prevents that the storage of a Space Depot or a Space cannot be used by unauthorized third parties.

In addition to the encrypted data storage on the servers and the clients the data is also always fully encrypted during transmission, whereby TeamDrive delivers a complete end-to-end encryption of the data.

It should also be noted that TeamDrive has received the data protection seal of the “Independent Centre for Privacy Protection Schleswig Holstein”. The official approval number is 2-3/2005. In addition, TeamDrive was named as a “Cool Vendor in Privacy” 2013 in May by Gartner.

ownCloud: Server-side Encryption

At ownCloud one looks in vain for public security information, provided by ownCloud itself. This is a little surprising, since there are apparently many open questions even in the ownCloud community [1], [2] regarding the server-side encryption and encryption in general. Only a blog post can be found in which the fundamental understanding of ownCloud on security is displayed publicly. However, questions on direct demand ownCloud answered without hesitation and made more information available.

Ciphering Method

For data encryption ownCloud 5.0 sets on the Advanced Encryption Standard (AES) with a 256-bit key.

Security blogger Pascal Junod had dealt with the encryption of ownCloud 4.0 in early 2012. The necessary information can be found in the OC_Crypt class. Junod has analyzed the PHP file in this context and published relevant information. Thus, the key is generated in the mt_rand() PHP routine. That implemented the Mersenne Twister, a pseudo-random number generator. Junod commented that this is not a cryptographically good quality. The generated key is encrypted with the user password in conjunction with the symmetric block encryption algorithm Blowfish in ECB mode and then stored in the encryption.key. Junod comes to the conclusion that an attacker who owned this file could get the password using the brute-force method. He also aware, that this key is used for encryption of all the data of a user and the data to be encrypted on the server side. He describes other ways to steal the encryption.key. The password, which is responsible for the encryption of the file is transmitted in clear text (plain HTTP) from the client to the server. If the connection is not secured with HTTPS, everyone is able to intercept the communication, steal the password and could therefore access the ownCloud account and all data. Furthermore, the encryption.key is stored in plain text in the session data on the server side. Most of the time in the /tmp directory. This means that a malicious ownCloud server administrator would be able to decipher the data. Junod also indicates that the encryption is done on the server side, so a system administrator could intentionally manipulate the ownCloud installation. He therefore recommends never use ownCloud 4.0 to store confidential information.

ownCloud confirmed in the inquiry that ownCloud 5.0 itself does not implement a fully integrated end-to-end encryption in the software. However, this can be implemented with third-party tools. Furthermore, encryption is done “at rest“. This means that the data will be physically stored in encrypted form. The connection between the devices and the server is secured with SSL. The key exchange is authorized via the Provisioning API. A comprehensive key management follows in the future.

System Architecture

ownCloud has a plugin for server-side encryption administrators can use to store data encrypted on the server. Users get access to the data and can share them as if they are unencrypted. The new plugin in ownCloud 5.0 replaces the vulnerability in ownCloud 4.0, in which a malicious system administrator could bypass the security architecture by making adjustments to the ownCloud source code to integrate a backdoor or a password sniffer. For data encryption during transmission from the server to the device SSL is used. The password can be changed by a user at any time. All files are encrypted with the new password afterwards.

For server-side security, the administrator must enable the encryption app in the ownCloud management console and set the hook “encryption” in the admin interface. Then a key pair (public/ private) will be created for all users. For this purpose, the user password is used to protect the private key. In addition, for each file uploaded to the server, a symmetric key pair is created. The uploaded user data is encrypted and stored with the symmetric key. As algorithm the Advanced Encryption Standard (AES 256) is used. The symmetric key is encrypted with the private key of the user and stored on the server. If the data is retrieved from the server, it is first decoded and then sent via an SSL connection to the client. The encryption routine behaves with other applications connected to ownCloud, such as the web interface, the versioning and the algorithm for synchronization, exactly the same. If a user changes his password, the private key is decrypted with the old password, and re-encrypted with the new password.

For the user an uploaded and encrypted file on the ownCloud server resembles as a non-encrypted file. The encryption is completely transparent to him. If a file is shared with other users, the public keys of each of these users are stored in the encrypted file. These users can use it to access the file and make changes to it, as it is an unencrypted file. It’s the same with a folder. Users can not open files that are not intended for them. Should a malicious user try to obtain access to the storage backend, files and keys are unreadable.

If the appropriate plug-in is enabled, a system administrator is able to see all files that are stored on ownCloud over the command line. However, the content of the files is encrypted. Regular backups can still be made, but all the files remain encrypted. Even if the data is copied outside the system. An administrator can also configure additional settings to exclude certain file sizes and formats for the encryption.

Summary

With version 5.0 ownCloud now offers server-side data encryption. However, an administrator must explicitly activate a plug-in to encrypt files with AES 256. If a file leaves the ownCloud server it is first decrypted and transmitted over an SSL connection to the ownCloud client. This means that a complete end-to-end encryption is currently not available with simple on-board tools, what ownCloud confirms.

The ownCloud encryption module has been developed for the use within an enterprise data center on the company’s own servers, administered by trusted administrators.

Management Advisory: TeamDrive vs. ownCloud

The comparison of TeamDrive with ownCloud virtually also confronts a commercial with an open source approach. However, what here a little irritates is the openness of the commercial vendor TeamDrive towards ownCloud. Commercial vendors are often criticized for talk little about their security architecture. In this case, we see exactly the opposite. This is probably because ownCloud have not much security respectively encryption implemented to talk about. First with the ownCloud version 5.0, a module for server-side encryption is implemented. However, that there is a need for information and in particular for security, show the questions from the ownCloud community. Here the ownCloud community is still claimed to demand for more public information and security.

In this context the content of the above-mentioned blog article by ownCloud makes sense, which reflects the basic safety philosophy of ownCloud. For ownCloud encryption is an important point. But the focus should rather be on the control of the data.

Security vs. Flexibility

TeamDrive sets on a fully integrated approach and also provides an end-to-end encryption of all data that is transferred from the server to the client of the respective device. Thus, TeamDrive allows despite of a very high claim to the uncomfortable topic of security, the convenient use of a cloud storage service. ownCloud decodes the data first after they are loaded from the server and transfers it over an SSL connection. The lack of on-board tools for an end-to-end encryption can be achieved with external third-party solutions. However, it should be considered that the integration is costlier with it and whether an open source approach provides a cost advantages especially in this case.

But, it should be noted that ownCloud, due to its open source approach, offers more flexibility as TeamDrive and thereby can be completely adapted to the own IT infrastructure according to the own needs. In terms of security ownCloud still need to catch up. This has the consequence that the solution per se does not meet the current safety standards of businesses and is therefore only conditionally recommended.

At the end of the day, the decision must be made whether a company expects a commercial and integrated approach including security mechanisms based on on-board tools and an open source software that requires additional external security solutions which must be integrated themselves. Who is looking for an all-in-one solution, including complete end-to-end encryption and at the same time more security, should decide for TeamDrive.

Tags Cloud, Cloud Computing, Cloud Storage, Comparison, Dropbox, ownCloud, Security, Storage, TeamDrive

Insights @de

Sicherheitsvergleich: TeamDrive vs. ownCloud

Post author By Rene Buest
Post date May 24, 2013
1 Comment on 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.

Tags Cloud, Cloud Computing, Cloud Storage, Dropbox, ownCloud, Sicherheit, Storage, TeamDrive, Vergleich

Analysis

Google Compute Engine: Google is officially in the game

Post author By Rene Buest
Post date May 23, 2013
No Comments on Google Compute Engine: Google is officially in the game

Google officially gets in the battle for market share in the infrastrucuture-as-a-service (IaaS) area. What was only determined for a selected group of customers starting one year ago, the company from Mountain View has now made available for the general public as part of the Google I/O 2013. It’s about their cloud computing offering, Google Compute Engine (GCE).

News about the Google Compute Engine

With App Engine, BigQuery and Cloud Storage, Google has steadily expanded its cloud portfolio since 2008. What was missing was an infrastructure-as-a-service solution that can be used as needed to start virtual machines. The Google Compute Engine (GCE) released Google to its I/O 2012 in a closed beta, to use virtual machines (VM) with the Linux operating system on the Google infrastructure, which is also used by Gmail and other services.

Together with the Google I/O 2013, the GCE has now reached the general availability. Furthermore, Google has launched the Cloud Datastore, a by Google fully managed NoSQL database for non-relational data. Independent from the GCE the service provides automatic scalability, ACID transactions, and SQL-like queries and indexes. In addition, there is a limited preview of the PHP programming language for App Engine. With that Google wants to address developers and users of open source applications such as WordPress. Beyond that, the integration has been improved with other parts of the cloud platform such as Cloud SQL and Cloud Storage. Further, Google looks at the feedback of its users, that it should be possible to develop simple modularized applications on the App Engine. In response, it is now possible to partition applications into individual components. Each with its own scaling, deployment, versioning and performance setting.

More news

Other major announcements include more granular billing, new instance types as well as an ISO 27001 certification:

Granular billing: Each instance type is now billed per minute, where 10 minutes will be charged at least.
New instance types: There are new micro and small instance types that are meant to process smaller workloads inexpensive and require little processing power.
More space: The size of the “Persistent Disks”, which can be connected to a virtual instance have been extended up to 8.000 percent. This means that now a persistent disk can be attached with a size of up to 10 terabytes to a virtual machine within the Compute Engine.
Advanced routing: The Compute Engine now supports based on Google’s own SDN (Software Defined Network) opportunities for software-defined routing. With that instances can act as gateways and VPN server. In addition it can be use to develop applications so that they run in the own local network and in the Google cloud.
ISO 27001 certification: The Compute Engine, App Engine and Cloud Storage are fully certified with ISO 27001:2005.

Developer: Google vs. Amazon vs. Microsoft

First, the biggest announcement for the Google Compute Engine (GCE) is its general availability. In recent months, the GCE was held up by every news as THE Amazon killer, although it was still in a closed beta, and thus there was no comparison at eye level. The true time reckoning begins now.

Many promise from the GCE that Google creates a real competitor to Amazon Web Services. The fact is that the Google Compute Engine is an IaaS offering and Google due to its core business, have the expertise to build highly scalable infrastructures and to operate them highly available. The Google App Engine also shows that Google knows how to address developers, even if the market narrows here with increasingly attractive alternatives.

A lack of diversification

Having a look at the compute engine, we see instances, storage, and services for the storing and processing of structured and unstructured data (Big Query, SQL Cloud and Cloud Datastore). Whoever sees Google as THE Amazon killer from this point, should scale down its expectations once a little. Amazon has a very diversified portfolio of cloud services that enables to use the Amazon cloud infrastructure. Google needs to tie in with it, but this should not be too difficult, since many Google services are already available. A look at the services of Amazon AWS and the Google Cloud Platform is worthwhile for this reason.

Hybrid operation for applications

Google may not be underestimated in any case. On the contrary, from a first performance comparison between the Google and Amazon cloud, Google emerged as the winner. This lies inter alia in the technologies that Google is constantly improving, and on its global high-performance network. What is particularly striking, Google now offers the possibility to develop applications for a hybrid operation in the own data center and for the Google cloud. This is an unexpected step, since Google have been rather the motto “cloud only”. However, Google has been struggling lately with technical failures similar to Amazon, which does not contribute to the strengthening of trust in Google.

A potshot is the new pricing model. Instances are now charged per minute (at least 10 minutes of use). Amazon and Microsoft still charge their instances per hour. Whether the extension of the “Persistent Disks” up to 10 terabytes will contribute a diversification we will see. Amazon is also under developers regarded as the pioneer among IaaS providers, which will make it not easier for Google to gain market share in this segment. In addition, Google may assume that, next to ordinary users, developers also do not want to play Google’s “service on / off” games.

Amazon and Microsoft are already one step ahead

Where Google with its SaaS solution Google Apps massively tries to penetrate corporate customers for quite some time, the Compute Engine is aimed primarily at developers. Amazon and Microsoft have also begun in this customer segment, but long since begun to make their infrastructures respectively platforms attractive for enterprise customers. Here is still much work for Google, if this customer segment is to be developed, which is inevitably. However, in this area it is about much more than just technology, but about creating trust and to consider organizational issues (data protection, contracts, SLAs, etc.) as valuable.

Google’s problem: volatility

No doubt, Google is by far the most innovative company on our planet. But equally the most volatile and data hungriest. This also developers and especially companies both observed and should ask the question how future-proof the Google cloud portfolio is. If the compute engine is a success, don’t worry about it! But what if it is for Google(!) a non-seller. One remembers the Google Reader, whose user numbers were not sufficient enough for Google. In addition, the compute engine has another KPI, revenue! What does Google do when it’s no longer economic?

Tags Cloud, Cloud Computing, Cloud Platform, Compute Engine, Google, IaaS

Analysen

Google Compute Engine: Google ist offiziell im Spiel

Post author By Rene Buest
Post date May 22, 2013
No Comments on Google Compute Engine: Google ist offiziell im Spiel

Nun steigt auch Google offiziell in den Kampf um Marktanteile im Infrastrucuture-as-a-Services (IaaS) Bereich ein. Was seit einem Jahr nur einem ausgewählten Personen- bzw. Kundenkreis bestimmt war, hat das Unternehmen aus Mountain View jetzt im Rahmen der Google I/O 2013 der Allgemeinheit verfügbar gemacht. Die Rede ist von seinem Cloud Computing Angebot, der Google Compute Engine (GCE).

Neuigkeiten zur Google Compute Engine

Mit der Google App Engine, BigQuery und dem Google Cloud Storage hat Google seit 2008 sein Cloud Portfolio stetig ausgebaut. Was noch fehlte war eine Infrastructure-as-a-Service Lösung, mit der virtuelle Maschinen bei Bedarf genutzt werden können. Die Google Compute Engine (GCE) brachte Google zu seiner I/O 2012 in einer geschlossenen Beta auf den Markt, um virtuelle Maschinen (VM) mit dem Linux Betriebssystem auf der Google Infrastruktur, die auch von Google Mail und anderen Services eingesetzt wird, zu nutzen.

Zusammen mit der Google I/O 2013 hat die GCE nun auch den Status der allgemeinen Verfügbarkeit erreicht. Weiterhin hat Google einen Cloud Datastore, eine von Google vollständig verwaltete NoSQL Datenbank für nicht relationale Daten, veröffentlicht. Der von der GCE unabhängige Service bietet eine automatische Skalierbarkeit, ACID Transaktionen sowie SQL-artige Anfragen und Indizes. Weiterhin gibt es eine eingeschränkte Vorschau der Programmiersprache PHP für die App Engine. Damit will Google Entwickler und Nutzer von Open-Source Applikationen wie z.B. WordPress ansprechen. Zudem wurde die Integration mit anderen Teilen der Cloud Plattform wie Google Cloud SQL und Cloud Storage verbessert. Darüber hinaus geht Google auf die Rückmeldung seiner Nutzer ein, dass es möglich sein sollte, Applikationen auf der App Engine einfacher modularisiert zu entwickeln. Als Reaktion darauf ist es nun möglich, Applikationen in einzelne Komponenten zu partitionieren. Jede mit ihrer eigenen skalierungs-, bereitstellungs-, versionierungs- und performance- Einstellung.

Weitere Neuigkeiten

Zu den weiteren größeren Ankündigungen gehören u.a. eine granularere Abrechnung, neue Instanz-Typen sowie eine ISO 27001 Zertifizierung:

Genauere Abrechnung: Jeder Instanz-Typ wird nun pro Minute abgerechnet, wobei 10 Minuten mindestens berechnet werden.
Neue Instanz-Typen: Es gibt nun neue Micro- und Small Instanz-Typen, die dafür gedacht sind, kostengünstig kleinere Workloads zu verarbeiten, die nur wenig Rechenleistung benötigen.
Mehr Speicherplatz: Die Größe der “Persistent Disks”, die mit einer virtuellen Instanz verbunden werden können, wurden um bis zu 8.000 Prozent erweitert. Das bedeutet, dass nun eine Persistent Disk mit einer Größe von bis zu 10 Terabyte an eine virtuelle Maschine der Compute Engine angehängt werden kann.
Erweitertes Routing: Die Compute Engine unterstützt nun basierend auf dem eigenen SDN (Software-Defined Networking) Möglichkeiten für das Software-Defined Routing. Damit lassen sich Instanzen als Gateways und VPN-Server einsetzen und Applikationen so entwickeln, dass diese im eigenen lokalen Netzwerk als auch in der Google Cloud laufen.
ISO 27001 Zertifizierung: Die Compute Engine, App Engine und Cloud Storage wurden vollständig mit ISO 27001:2005 zertifiziert.

Entwickler: Google vs. Amazon vs. Microsoft

Zunächst, die größte Ankündigung für die Google Compute Engine (GCE) ist ihre allgemeine Verfügbarkeit. In den letzten Monaten wurde die GCE nach jeder Neuigkeit als DER Amazon Killer hochgehalten, obwohl sie sich noch in einer geschlossenen Beta befand und somit kein Vergleich auf Augenhöhe bestand. Die wirkliche Zeitrechnung beginnt jetzt.

Viele versprechen sich von der GCE, dass Google damit einen echten Konkurrenten zu den Amazon Web Services schafft. Fakt ist, das es sich bei der Google Compute Engine um ein IaaS Angebot handelt und Google auf Grund seines Kerngeschäfts über die Expertise, hochskalierbare Infrastrukturen aufzubauen und diese hochverfügbar zu betreiben, verfügt. Die Google App Engine zeigt darüber hinaus, dass Google es versteht, Entwickler anzusprechen, auch wenn sich der Markt hier mit zunehmend attraktiven Alternativen verengt.

Es fehlt die Diversifikation

Schauen wir uns die Compute Engine an, dann sehen wir Instanzen, Speicherplatz, sowie Services für das Speichern und Verarbeiten von strukturierten und unstrukturierten Daten (Big Query, Cloud SQL und Cloud Datastore). Wer Google unter diesen Gesichtspunkten daher als DEN Amazon Killer sieht, sollte seine Erwartungen erst einmal ein wenig herunterschrauben. Amazon hat ein sehr diversifiziertes Portfolio an Cloud Services, mit denen die Amazon Cloud Infrastruktur genutzt werden kann. Daran muss Google erst einmal anknüpfen, was sich allerdings nicht als all zu schwer erweisen dürfte, da viele Google Services bereits vorhanden sind. Ein Blick auf das Serviceangebot von Amazon AWS und der Google Cloud Platform ist aus diesem Grund lohnenswert.

Hybrid Betrieb für Applikationen

Google darf auf keinen Fall unterschätzt werden. Im Gegenteil, aus einem ersten Performance-Vergleich zwischen der Google Cloud Platform und Amazon AWS ging Google als Sieger hervor. Das liegt u.a. an den Technologien, die Google ständig verbessert sowie an seinem weltweiten hochperformanten Netzwerk. Was besonders auffällt, Google bietet nun die Möglichkeit, Applikationen für einen hybrid Betrieb, im eigenen Rechenzentrum und in der Google Cloud, zu entwickeln. Das ist ein unerwarteter Schritt, da bei Google bisher eher die Devise “Cloud only” lautete. Allerdings hat auch Google in letzter Zeit ähnlich wie Amazon mit technischen Ausfällen zu kämpfen gehabt, was nicht zur Stärkung des Vertrauens in Google beiträgt.

Ein Seitenhieb ist das neue Preismodell. Instanzen werden nun pro Minute (mindestens 10 Minuten Nutzung) abgerechnet. Amazon und auch Microsoft rechnen ihre Instanzen derzeit noch pro Stunde ab. Ob die Erweiterung der “Persistent Disks” auf bis zu 10 Terabyte zur Diversifikation beiträgt wird sich zeigen. Amazon gilt auch unter Entwicklern als der Vorreiter unter den IaaS Anbietern, was es für Google nicht einfacher machen wird in diesem Segment (Entwickler) ausreichend Marktanteile zu gewinnen. Außerdem darf Google davon ausgehen, dass neben den gewöhnlichen Nutzern, ebenfalls Entwickler keine Lust auf Googles “Service an/aus” Spielchen haben.

Amazon und Microsoft sind schon einen Schritt voraus

Wo Google mit seiner SaaS Lösung Google Apps seit geraumer Zeit massiv auch Unternehmenskunden angeht, richtet sich die Compute Engine in erster Linie an Entwickler. Amazon und Microsoft haben auch in diesem Kundensegment angefangen, aber längst damit begonnen, ihre Infrastrukturen respektive Plattformen für Unternehmenskunden attraktiver zu machen. Hier wird auf Google noch viel Arbeit zukommen, wenn dieses Kundensegment erschlossen werden soll, was zwangsläufig unumgänglich ist. Allerdings geht es in diesem Bereich um viel mehr als nur Technologien, sondern darum, Vertrauen zu schaffen und organisatorische Themen (Datenschutz, Verträge, SLA, usw.) für wertvoll zu erachten.

Googles Problem: Unbeständigkeit

Keine Frage, bei Google handelt es sich mit Abstand um das innovativste Unternehmen auf unserem Planeten. Aber gleichermaßen auch um das Unbeständigste und Datenhungrigste. Das werden auch Entwickler und speziell Unternehmen beobachtet haben und beide sollten sich die Frage stellen, wie Zukunftssicher das Google Cloud Portfolio überhaupt ist. Wird die Compute Engine ein Erfolg, braucht man sich keine Sorgen machen. Aber was ist, wenn sie für Google(!) zum Ladenhüter wird. Man erinnere sich an den Google Reader, dessen Nutzerzahlen für Google nicht mehr ausreichend genug waren. Hinzu kommt, dass die Compute Engine einen weiteren KPI hat, den Umsatz! Was macht Google, wenn dieser nicht mehr stimmen sollte?!

Tags Cloud, Cloud Computing, Cloud Platform, Compute Engine, Google, IaaS

Kommentar

Microsoft SkyDrive Erfahrungsbericht – Ein Rückblick nach 6 Monaten intensiver Nutzung

Post author By Rene Buest
Post date May 17, 2013
1 Comment on Microsoft SkyDrive Erfahrungsbericht – Ein Rückblick nach 6 Monaten intensiver Nutzung

Ich nutze Microsoft SkyDrive nun intensiv seit November 2012. Ich habe den Cloud-Storage Service aus Redmond in einem zurückliegenden Artikel hinsichtlich seiner Diversifikation zu Dropbox und anderen Angeboten gelobt. Dieses zu recht, denn die Integration in die weiteren Services von Microsoft ist wirklich gut gelöst. Jedoch sind auch andere Faktoren bei der Nutzung entscheidend und hier sieht es nicht ganz so rosig aus.

Geschwindigkeit: Der Caterham F1 unter den Cloud Storages

Das ist wirklich ein analog sehr gut gewähltes Beispiel. SkyDrive kommt einfach nicht aus dem Knick. Die initiale Synchronisation hat ernsthaft(!) fast zwei Wochen benötigt! Ich muss zu SkyDrives Verteidigung sagen, dass ich nur hinter einer 4 MBit (3,7 Mbit/s) Leitung mit 288 kbit/s Upload sitze. Dennoch war die immer so oft gewählte Marketing-Floskel “Customer Experience” mit Dropbox viel galaktischer. Sicherlich war ich mit Dropbox, welches ich vorher genutzt habe, verwöhnt. Das hängt u.a. mit der Deduplizierung zusammen, die SkyDrive nicht verwendet.

Dennoch bin ich nicht der Einzige, der sich über die Geschwindigkeit beklagt. In der Microsoft Community wird ebenfalls von einer “Terrible Skydrive speed performance” gesprochen.

Transparenz: Man weiß nicht was SkyDrive macht

Das ist wirklich das Schlimmste! Man weiß einfach nicht was SkyDrive im Hintergrund macht. Nach dem Start zeigt das Symbol in der Taskleiste “Änderungen werden gesucht” an. Das kann schon mal etwas länger dauern. Eine Statusanzeige wie “x Prozent von y”? Fehlanzeige!

Werden Dateien synchronisiert, verwendet SkyDrive die Statusanzeige: “Änderungen werden verarbeitet”. Ja, aber welche Dateien genau? Und wie lange dauert die Synchronisation noch? Was heißt denn Änderungen werden verarbeitet? Und warum dauert das z.B. mal 2 Stunden, ohne das etwas passiert? Ein Benutzer wird hier total im Stich gelassen. Das ist besonders ärgerlich, wenn man “mal eben” etwas in den SkyDrive Ordner kopiert, um es unterwegs auf einem anderen Gerät nutzen zu können.

Unzuverlässig: SkyDrive Client hängt sich immer wieder auf

In diesem Zusammenhang kommt es dann auch zu dem sehr unglücklichen Umstand, dass sich der SkyDrive Client im Hintergrund anscheinend aufhängt. Da man jedoch nicht weiß, was genau im Hintergrund passiert, ist man als Nutzer völlig aufgeschmissen. Man möge dann meinen, unter “Synchronisationsprobleme anzeigen”, mit einem Rechtsklick auf das SkyDrive Icon in der Taskleiste, gibt es mehr Informationen. Leider nicht, dieser ist ständig grau. Bedeutet also, dass alles in Ordnung ist. Ich frage mich dann aber, wie alles in Ordnung sein kann, wenn “Änderungen werden verarbeitet” über 9 Stunden für eine Dateigröße von nicht einmal 2MB angezeigt wird. Das ist KEIN SCHERZ!

Manchmal kann man dieses Problem lösen, wenn man den SkyDrive Client beendet und neu startet. Oftmals bringt das aber nichts. Das bedeutet dann, man muss die Dateien, die man eigentlich synchronisieren möchte, wieder aus dem SkyDrive Ordner nehmen, den Client neu starten und die Dateien einzeln hochladen lassen, bis “Alles Aktuell” ist. Jedoch hat auch das sehr oft nicht funktioniert. Dann heißt die Devise: Browser auf; SkyDrive.com öffnen; und alles von Hand in die entsprechenden Ordner hochladen!

Ich habe mal einen Blogbeitrag gefunden, in dem erklärt wurde, dass dieses Problem wohl an der lokalen SkyDrive Datenbank liegen soll. Die Lösung war, die Verknüpfung des PCs mit SkyDrive aufzuheben und neu zu erstellen. Dann wird die Datenbank neu abgeglichen, was quasi einer initialen Synchronisation entspricht. Unter Windows 7 hat es funktioniert. Allerdings ist das KEINE Lösung! Seit Windows 8 ist SkyDrive jedoch direkt mit dem Benutzer in das Betriebssystem integriert. Somit ist “Diese Option nicht verfügbar, da Sie mit einem Microsoft-Konto angemeldet sind.”

Just wo ich diesen Artikel schreibe, bin ich gerade dabei, eine 3,85 MB PDF-Datei hochzuladen. Status: “Änderungen werden verarbeitet” – “Letztes Update vor 58 Minuten”. Und ich habe den Client bereits zwei Mal neu gestartet.

Kosten: Unschlagbar

Hinsichtlich der Kosten gibt es keinen Kritikpunkt. Neue SkyDrive Nutzer erhalten 7GB kostenlosen Speicher. Die Speichererweiterungen werden in drei Kapazitätsstufen angeboten. Diese erweitern das kostenlose und bestehende SkyDrive Kontingent. 20GB Speicher kosten 8,00 € pro Jahr, 50GB 19,00 € pro Jahr und 100GB 37,00 € pro Jahr.

Mobile Clients: Gut bedienbar und schnell

Auch an den mobilen Clients gibt es meinem Befinden nach nichts zu kritisieren. Bis auf Linux, stehen für alle Betriebssysteme inkl. iOS und Android Clients zur Verfügung. Die mobilen Clients sind gut und flüssig zu bedienen. Auch der Zugriff auf die Daten im SkyDrive geht schnell.

Unter diesem Umständen nur bedingt empfehlenswert

Trotz der vergleichsweise geringen Kosten, der guten Integration in andere Microsoft Produkte sowie der guten mobilen Clients, kann ich SkyDrive unter den Gesichtspunkten der Geschwindigkeit aber insbesondere der Verlässlichkeit bisher nur bedingt weiterempfehlen. Vielleicht mache ich auch etwas falsch oder habe irgendwo ein Häkchen falsch gesetzt, was ich beides bezweifle, weil SykDrive hier wirklich auf Einfachheit setzt, was wiederum gut ist.

SkyDrive Pro habe ich mir bisher noch nicht angeschaut. Wenn das Produkt, wohl gemerkt für Unternehmen(!), allerdings genau so implementiert ist, dann gute Nacht!

Tags Cloud, Cloud Computing, Cloud Storage, SkyDrive