KB19 und tab haben zwar schon fast alles gesagt, aber je nach Interpretation der Ausgangsfrage gibt es denke ich auch andere Betrachtungen die man hierbei noch in Erwägung ziehen kann:
Die bereits gegebenen Antworten zielen darauf ab, was ein Anbieter technisch tun könnte. Und ja, hier sind wir uns einig - bei Zugriff auf die physische Hardware ist es nur eine Frage des Aufwandes und der Zeit bis der Hoster zumindest Zugriff auf das laufende OS erhält. Denn selbst wenn dieses vollverschlüsselt mit Entschlüsselungs-Abfrage beim Systemstart läuft, so ist es mittels Evil-Maid-Angriff ja trotzdem möglich das benötigte Kennwort abzufangen (z.b. bei KVM-Virtualisierung indem die Eingaben über die virtuelle Konsole protokolliert werden könnten).
Und wenn man Zugriff auf das OS hat, so ist jegliche Verschlüsselung die im OS-Kernel oder von Userspace-Prozessen am System durchgeführt werden als gebrochen zu betrachten, eine Auswertung eines Memory-Dumps/Snapshots genügt in der Regel - fertige Tools die Schlüssel aus dem Hauptspeicher extrahieren gibt es für die meisten Anwendungsfälle, sodass der technische Aufwand und Zeitaufwand hierfür überschaubar bleibt.
Um dem Anbieter also die technische Möglichkeit zu nehmen auf Klartext-Daten zuzugreifen muss die Verschlüsselung schon erfolgen bevor die Daten auf den Server gelangen, also wenn am Server z.B. eine Owncloud läuft muss die Verschlüsselung der Files direkt auf den Clients (z.b. BoxCryptor etc...) erfolgen. Wenn der Server als Mailserver genutzt wird müssen Mails Ende-zu-Ende (PGP, SMIME, ...) auf den Mailclients verschlüsselt werden, ...
Nun könnte man die Frage also zusammenfassend mit "Verschlüsselung am Server lohnt sich nicht, kann ohnehin gebrochen werden" für sich beantworten. Aber ich rege an das dennoch etwas differenzierter zu betrachten. Für zahlreiche Szenarien in denen einfach ein "Missgeschick" passiert oder zur Abwehr von "neugierigen Mitarbeitern beim Hoster" macht es nämlich durchaus einen Unterschied. Ich kann und möchte hier nicht den Anspruch erheben umfassend Beispiele aufzuzählen, aber auf ein, zwei Beispiele worauf ich hinaus möchte gehe ich kurz ein:
Annahme: Dem Hoster passiert ein Missgeschick. Er sichert zwar vertraglich zu, dass das Rechenzentrum ISO27000-zertifiziert betrieben und Kundendaten sicher gelöscht werden bevor gebrauchte Hardware einem anderen Kunden zugeteilt oder gar ausgeschieden wird - aber wo Menschen arbeiten passieren Fehler. So könnte es also vorkommen, dass eine Disk (physisch) oder ein Disk-Image (virtuell, oder einfach Teile eines virtuellen Image) nicht sauber gelöscht an einen neuen Ziel-Kunden zugeteilt werden. In diesem Fall sind Klartext-Daten auf der Disk freilich der Worst-Case. Verschlüsselte Daten hingegen könnten in zahlreichen Fällen hier halbwegs wirksam verhindern, dass der neue Kunde bzw. der Käufer einer Gebraucht-Disk mit vertretbarem Aufwand an die Klartext-Daten herankommt.
Annahme: Beim Hoster arbeitet ein Malicious-Mitarbeiter, z.b. ein Praktikant mit zu viel Freizeit und Neugierde: Auch gegen diesen sind Schutzmaßnahmen vielfach ausreichend wirksam. Man kann davon ausgehen, dass dieser sich z.B. zwar Zugriff auf eine (virtuelle) Disk verschaffen kann, aber vielleicht doch nicht ganz unauffällig ohne dabei den Kollegen aufzufallen einen Memory-Snapshop der Maschine erzeugen kann.
Annahme: Es ist Container-Virtualisierung (z.B. LXC, openVZ o.ä.) im Einsatz. Hier kann der Anbieter ja völlig transparent einfach im laufenden Betrieb über alle Files des Kunden "drüber-greppen" und/oder auf seine Prozesse Einfluss nehmen. Diesen Usecase mit Verschlüsselung direkt im Container wirkungsvoll abzusichern halte ich zwar für besonders aussichtslos - aber auch hier ist Verschlüsselung besser als gar nichts, denn ein einfaches "grep" oder "copy" im Filesystem beschert auch dann noch keinen Klartext. Ein Minimum an (krimineller) Energie beim Root des Hosts ist auch dann erforderlich.
