Güte von Software Services

30 Milliarden Umsatz werden inzwischen Online im Internet umgesetzt. Das ist mehr, als über Kataloge bestellt wird. Das geht nur, weil inzwischen der überwiegende Teil der Bevölkerung das Internet überhaupt nutzt und auch ein wachsendes Vertrauen in die Zuverlässigkeit der Kaufprozesse im Internet besteht. Neben den großen bekannten Shops gibt es auch eine erhebliche Anzahl kleiner Shops. Hier helfen heute schon Gütesiegel, dass Vertrauen in die Zuverlässigkeit zu stärken und damit Hinderungsgründe zu reduzieren.

EuroCloud Gütesiegel

Das Gleiche wird auch für SaaS, Software Services, gebraucht. Das hat EuroCloud erkannt. Doch eine Gütesiegel von SaaS ist verständlicherweise weitergefasst, als wenn es nur für Shop-Anwendungen gelten muß. eShops sind sozusagen ein Spezialfall eines SaaS. Der Unterschied liegt beispielsweise darin, dass sich die Kosten für die Shopnutzung durch die Umsätze, die mit dem Shop erzielt werden, gedeckt werden.

Komplexitätsreduktion

Die Komplexität ist also groß und die Frage, wie sie so zu reduzieren ist, dass eine Zertifizierung auch einen Nutzen bringt, nicht einfach zu beantworten.

Obwohl den Nutzer von Software Services die technischen Aspekte relativ egal sein sollten, sollte ein Gütesiegel diesen dennoch Beachtung schenken. Auch bei einem Auto kümmert sich der TÜV zu einem erheblichen Teil um die technischen Aspekte.

mögliche Kriterien

1. Nachweis, dass versprochene Servicelevel auch eingehalten werden
2. über die vereinbarten Servicelevel hinaus gibt es wichtige Indikatoren, mit denen die Qualität gemessen wird.
3. Verfügbarkeit der Anwendung in Klassen wie grösser 95%, 98,5%, 99,5%, 99,9%
4. Zugangssicherheit: keine, SSL, VPN, direct connect
5. Lokation: die Anwendung läuft irgendwo, in europa, in Deutschland, auf dedizierten Servern und Platten
6. Datenhaltung: einfach, regelmässige Sicherung, einfache Redundanz, Redundanz an unterschiedlichen Orten
7. Tarifmodelle: Lizenzkauf, Flatrate, pay per function, pay per user, pay per use, transparent wählbar
8. Skalierung: keine, Server, CPUs, on demand
9. Paradigma: public, private, hybrid
10. Bezahlung: prepaid, Kreditkarte, PayPal etc., Rechnung, Abbuchung
11. Softwarequalitätskriterien
12. Infrastruktur: proprietär, public, überwacht
13. Transaktionssicherheit: keine, logging, rückgängig, commit, commit&rollback
14. Anpassbarkeit: keine, im Projekt (private cloud), durch Spezialisten, releasefähig, durch Nutzer
15. Rechtemanagement: kein; Passwort, Nutzer, Funktion, Objekte
16. Betriebsart: einfache Nutzung, Demomode, Projektmode
17. gesetzliche Standards: keine, SOX

Cloud Computing Clusterung für Entscheidungsunterstützung

Wie man sieht kommen hier schnell viele Kriterien zusammen. Bei einigen Kriterien gibt es auch keine entweder oder Entscheidung. Es können mehrere Optionen in Frage in verschiedener Güte. Das wird bei der zusammenfassenden Beurteilung berücksichtigt werden müssen. So ist vorstellbar, dass den einzelnen Punkten nicht einfach ein Häkchen (oder ein Strich) zugewiesen wird, sondern ein Zahlenwert. Die Summe der Zahlenwerte ergäbe dann ein Ranking. Dieses Ranking könnte dann in eine Clusterung gegeben werden:

• Simple Certified Cloud Provider
• Trusted Cloud Provider
• High Performance Provider

Trusted und High Performance Provider wären dann Voraussetzung für geschäftlich unbedenklichen Einsatz in Deutschland. Ob eine Einteilung in drei Gruppen reicht oder es besser fünf oder sieben sein sollten oder ob es Untergruppen geben sollte, ist dabei ersteinmal unerheblich. Vielleicht stellt sich heraus, dass es differenziertere Ausprägungen des Gütesiegels für bestimmte Anwendungsfälle oder Datenarten geben sollte. Das setzt allerdings eine Analyse voraus, welche Daten gruppiert werden können nach der Sensitivität. Das muß sich dann an rechtlichen Vorgaben orientieren. So sind Personaldaten und Vorgangsdaten sensitiver als beispielsweise Nachrichten.

rechtlich korrekte Datenhaltung beim Cloud Computing

Der EuroCloud Verband trägt gerade die Regeln für rechtliche compliance von Cloud Computing zusammen, die dann auch in das Gütesiegel für Software as a Service einfliessen.
Dafür ist notwending, daß wir eine Aufstellung der Bestimmungen brauchen, die Anwendung finden bei der Nutzung von Cloud Computing.

Dieses sollte ausdifferenziert werden nach Datensensibilität, Lokalität und Interessenslage des Kunden/Nutzers von Cloudservices.

Wenn es gesetzliche Mindestanforderungen sowie je nach Branche oder Art der Daten oder Nutzung Spezialanforderungen gibt leiten sich daraus Infrastrukturanforderungen ab.

Die juristischen Ausgangsgrundlagen sind in verschiedenen Gesetzen beschrieben (Übermittlungsleistungen, Auftragsdatenverarbeitung, 203 StGB, 11 StGB, 28 BDSG etc. und zu ergänzen). Für die Praktiker werden hier praktische Anwendungsbeispiele beschrieben werden müssen, die eine Erklärung und verstädnliche Interpretation liefern.

Zielsetzung kann dann sein, einerseits die Complianceregeln, die sich ein Softwareanbieter setzen sollte, zu erarbeiten, andererseits eine Checkliste mit Dos&Donts zusammenzustellen, die einem Nutzer die Entscheidung für einen Cloudservice erleichtert.

Mir ist durch die Gespräche zu dem Thema Cloud Compliance klar geworden, dass eines meiner Projekte sich aus meiner Sicht juristisch in einer nicht ganz klaren Situation befindet. Da hat sich keiner über die rechtliche Compliance Gedanken gemacht. Lediglich die technischen Aspekte (QoS) wurden vertraglich berücksichtigt. Dazu wurden AGBs, die von einem Juristen geprüft waren, verwendet. Für mich ist es wichtig, unseren mittelständischen deutschen Software- und Serviceanbietern eine Hilfestellung für die nationalen und internationalen Gegebenheiten zu geben. Sie müssen ein Gefühl dafür bekommen, wo sie sich juristisch absichern müssen, bzw. wo sie heute und unter welchen Bedingungen in Deutschland Cloud Services anbieten können.
Diese Fokusgruppe von euroCloud hat kompetente Experten und kann einen wertvollen Beitrag zur Aufklärung des rechtlich sicheren Einsatz von Cloud Computing leisten.

Im Rahmen der Gütesiegelbetrachtung wird mit der Konzentration auf die Zielgruppe der Software- und Serviceanbieter ebenfalls ein Beitrtag geleistet werden, wenn es gelingt, die Gewichtung von Muss- und Kannanforderungen abzubilden. Aus rechtlicher Sicht bestätigt sich , dass es nicht 'das EINE' Gütesiegel geben kann: was der eine Service erfüllen muss, muss der andere nicht unbedingt erfüllen. Trotzdem können beide zu Recht ein Gütesiegel beanspruchen.

Auftragsdatenverarbeitung kontra Übermittlungsmodell

Für die Nicht-Juristen unter uns: Bei der Auftragsdatenverarbeitung wird der Cloud-Anbieter vertraglich sehr eng an den Kunden angebunden, insbesondere darf er die Daten nur nach den Weisungen des Kunden behandeln. Der Anbieter wird dadurch datenschutzrechtlich zu einer "internen Abteilung" des Kunden. Folge dieser engen Anbindung ist, dass der Anbieter aus Sicht des Datenschutzrechts kein "Dritter" mehr ist. Erhält der Anbieter vom Kunden personenbezogenen Daten, so liegt keine "Übermittlung" vor, für die ein datenschutzrechtlicher Erlaubnistatbestand benötigt würde. Hierin liegt der "Reiz" einer Auftragsdatenverarbeitung.

Vermeidung von Auftragsdatenverarbeitung

Allerdings hat das Modell auch Nachteile, vorallem, weil § 11 BDSG umfangreiche Vorgaben macht, welche Regelungen in einen Auftragsdatenverarbeitungsvertrag gehören. Und diese sind bei einem Cloud Computing Verhältnis nicht leicht umzusetzen sind. Aus diesem Grund wird teilweise versucht, eine Auftragsdatenverarbeitung zu vermeiden. Der Anbieter ist dann ein Dritter im Sinne des Datenschutzrechtes und die Übermittlung von personenbezogenen Daten bedarf eines Erlaubnistatbestandes. Hierfür kommt vorallem eine Klausel im BDSG in Betracht, die auf einer Interessensabwägung beruht. Mit entsprechenden flankierenden Regelungen (die häufig einer Auftragsdatenverarbeitung ähneln), lässt sich so die Datenübermittlung an einen "Dritten" rechtfertigen.

Nachteile der Übermittlungsvariante

1. Das Modell funktioniert meist nicht mehr, wenn "besondere Arten von Daten" im Sinne des BDSG (z.B. Daten zur Gesundheit, Gewerkschaftszugehörigkeit etc) im Raum stehen, was leider häufig der Fall ist bzw. nicht ausgeschlossen werden kann.
2. Wenn das Verhältnis der Parteien einer Auftragsdatenverarbeitung ähnelt, wirkt die Übermittlungs-Lösung etwas gekünstelt oder besser gesagt: ihr haftet der "Makel" an, es handle sich um eine Umgehung der gesetzlichen Anforderungen für eine Auftragsdatenverarbeitung. Damit will ich nicht sagen, dass die Übermittlungs-Lösung kein gangbarer Weg ist. Ich habe aber schon mehr als einmal erlebt, das der Datenschutzbeauftragte beim Kunden ein solches Modell nicht "durchschaut" und auf einem Auftragsdatenverarbeitungsvertrag besteht. Der deutsche mittelständische Softwareanbieter (unsre Zielgruppe) wird sich dann schwer tun, seinem Kunden das Übermittlungsmodell schmackhaft zu machen.
3. Das Übermittlungsmodell erspart dem Anbieter zwar die Einhaltung von § 11 BDSG, diesen Vorteil erkauft er sich aber, weil er als Datenempfänger mitverantwortlich für die Rechtmäßigkeit der Datenverarbeitung wird, was nach meiner Meinung ein nicht zu unterschätzender Nachteil ist.
4. Was gerne übersehen wird: Das Übermittlungsmodell sprengt die Kette von Auftragsdatenverarbeitungsverhältnissen. Verarbeitet der Cloud-Kunde die Daten seinerseits für einen Kunden, mit dem er einen Auftragsdatenverarbeitungsverhältnis geschlossen hat, kann er regelmäßig einem Übermittlungsmodell nicht zustimmen. Beispiel: Ein Callcenter übernimmt für einen TK-Anbieter den Kundensupport, hierfür erhält das Callcenter Kundendaten des TK-Anbieter, die es als typischerweise als Auftragsdatenverarbeiter verarbeitet. Das Callcenter will nun eine Software im Wege des SaaS Modells nutzen, um die Kundendaten zu verwalten. Dies ist nur möglich, wenn der SaaS Anbieter seinerseits Auftragsdatenverarbeiter ist, da der Vertrag zwischen Callcenter und TK-Anbieter in der Regel vorsieht, dass die Daten nur an Subunternehmer weitergegeben werden die die Daten im Auftrag des Callcenters verarbeiten (und mindestens das gleiche Schutzniveau vorsehen, wie der Vertrag TK-Anbieter/Callcenter).

wichtig: richtige Nutzung der gesetzlichen Rahmen

Ich möchte damit nicht vorschlagen, dass wir uns auf ein Modell festlegen, halte es aber für sinnvoll dem Auftragsdatenverarbeitungsmodell ausreichend Raum zu schenken. Vor allem sollten wir Hinweise geben, wie die gesetzlichen Anforderungen beim Cloud Computing praktisch umgesetzt werden können.

Cloud Computing Vision

Cloud Computing ist in den allermeisten Fällen eine Vision.
Viele Nutzer wissen heute nicht genau, was der Unterschied zwischen Cloud Computing, Software as a Service, Application Service Providing, IT Outtasking, ist. Das ist der kleinste gemeinsame Nenner der Experten. Es wird einem auch nicht leicht gemacht. Je nachdem, wie die Begriffe gebraucht werden, gibt es Unterschiede oder eben auch nicht. Oft sind die Unterschiede wahrhaftig sehr theoretisch. Im professionellen geschäftlichen Umfeld ist es allerdings wichtig, zu wissen, was für eine Art von Service in Anspruch genommen wird.

Ganz klar ist, dass für bestimmte kritische Informationen Cloud Computing in Deutschland nicht eingesetzt werden sollten, da es im Bedarfsfalls schwierig ist, festzustellen, wo die Daten genau lokalisiert sind. Sind sie im Ausland gelagert kann es zu Problemen kommen, da das verboten ist.

Merkmale von Cloud Computing

Laut dem Swiss IT Magazine gehören als bestimmende und beschreibende Merkmale von Cloud Computing folgende Merkmale:

• Ressourcen wie Rechenkapazität, Betriebssystem-, Entwicklung- und Laufzeitplattformen, einzelne Services oder Anwendungssoftware werden von einem Provider zentral bereitgestellt und über ein Netzwerk bezogen.
  Die Bereitstellung erfolgt in einer Multi-Tenant-Umgebung, die viele Bezüger gleichzeitig bedient.
• Die Ressourcen können dynamisch nach Bedarf bezogen werden, wobei insbesondere auch kurzfristig stark erhöhte Bezüge möglich sind.
• Die Abrechnung erfolgt nutzungsgerecht in exakt definierten Einheiten, üblicherweise fein granuliert, so dass nur wirklich genutzte Dienste verrechnet werden.
• Bereitstellung und bezügerseitige Verwaltung erfolgen vollständig automatisiert –Cloud-Ressourcen lassen sich über ein Web-Interface buchen, in Betrieb nehmen und administrieren, ohne dass auf Seite des Providers ein manueller Eingriff nötig ist.
• Das Angebot ist nicht auf einen bestimmten Bezüger maßgeschneidert, sondern steht prinzipiell allen berechtigten Bezügern offen: Zweck, Art und Umfang der Nutzung werden allein durch den Bezüger beziehungsweise die aktuelle Nutzungssituation festgelegt und sind für den Provider somit transparent.

Die meisten werden diesen definierenden Merkmalen wohl beipflichten. Aber schon der erste Punkt ist zwar typisch die Auslagerung von IT an einen lokalen Anbieter. Cloud jedoch heißt übersetzt Wolke und eine Wolke ist eine amorphe Masse und bezogen auf Computing ist eben nicht klar, wo der Server ist und ob die Server, auf denen das Computing stattfindet alle dem gleichen Anbieter gehören.

Best Practice

Wir haben das in einem Projekt selber so gemacht: Da kommt eine Kombination von klassischem Internetprovider 1&1 und Amazon Web Services zum Einsatz. Und bei Amazon wiederum werden unterschiedliche Services genutzt. Bei den Abrechnungssystemen und Bezahlung werden wiederum andere Anbieter genutzt und zwar so, dass es für den Nutzer kaum erkennbar ist, dass hier eine Reihe von Anbietern eingesetzt und orchestriert werden. Also: kein zentraler Anbieter stellt den Service bereit.

Betriebswirtschaftliche Aspekte

Natürlich ist der Grundgedanke von Cloud Computing, dass der Anbieter der Services Economies of Scale nutzt. Das gelingt wahrhaftig dann am besten, wenn viele Benutzer gleichzeitig bedient werden können. Voraussetzung, um von Cloud Computing sprechen zu können, ist das aber nicht. Schon bei der Konkretisierung, der private Cloud, wird es dann nämlich schwer.

Wir können also konstatieren, dass es idealerweise toll ist, wenn eine Cloud Anwendung und ein Cloud Service Anbieter die oben aufgeführten Kriterien erfüllt. Der Verstoß gegen diese Kriterien kann aber geschäftlich trotzdem durchaus Sinn machen – ja sogar gefordert sein und es handelt sich dann dennoch um Cloud Computing.

Flexibilität

Die ideale Cloud Anwendung ist vermutlich gar nicht so wünschenswert – in den allermeisten Fällen. Sehr zweckmässig ist sie, wenn Anwendungen getestet werden sollen: Bei Amazon aber nicht nur dort kann man temporär Serverinstances relativ schnell einrichten und auch wieder schliessen und in der Zwischenzeit damit Dinge testen, die danach z.B. in den Regelbetrieb übernommen werden sollen. Jedoch gerade im Regelbetrieb trifft Cloud Computing auf noch größere Widerstände als im IT Outsourcing. Darauf wird die Providerindustrie sich einstellen müssen. So muss gerade im Cloud Computing volle Kontrolle über die eigenen Daten gewährleistet sein. Es muss zuverlässig nachvollziehbar sein, wer auf die Daten zugegriffen hat. Dagegen mag eingewendet werden, dass viele Unternehmen die Kontrolle auch nicht haben, wenn sie die IT im eigenen Hause betreiben. Das ist so, ist aber gar kein Argument, denn es geht ja darum, unberechtigten Zugriff Dritter zu erkennen und zu verhindern.

fette Clients

Die erfolgreiche Cloud Anwendung wird vermutlich eher eine Art Rich Internet Applikation (RIA) sein, die nicht auf dem Server ausgeführt wird. Diese Anwendung kann vom Anwender so onfiguriert werden, dass sie auf die Datenbestände, die angegeben werden, zurückgreifen kann, unabhängig davon, ob die Daten auf dem Client Rechner, auf einem Unternehmensserver oder ebenfalls in der Cloud liegen. Nach wie vor wird die RIA in Kontakt mit dem Server des Providers sein und dort auch überwacht, gesteuert und gepflegt werden. Gleichzeitig kann die RIA aber so angewendet werden, dass der Provider nicht in Besitz der Daten kommt. Eine derartige Architektur kann dann evtl. auch sehr elegant die Integrationsprobleme, die heute vielen Cloud Anwendungen anhaftet, beseitigen.