Compliance und Technik sind kein Widerspruch

Es gehört zur Realität jedes Unternehmens, dass es unterschiedlichsten Compliance-Vorgaben unterliegt. Besonders bei der Nutzung von Cloud-Services stehen Firmen vor einer Fülle verschiedener technischer Optionen und stellen sich die Frage, welche Sicherheitsaspekte wo zu verorten sind. Grundsätzlich sollten Cloud-Angebote dabei stets sicherheitsrelevante Faktoren abdecken.

Die Überlegung bei der Einführung von Cloud-Services sollte nicht – wie so oft – auf die Betrachtung der Technologie, sondern der Risiken abzielen. Bei Amazon Web Services (AWS) etwa gilt der Grundsatz „work backwards from the customer”. Das bedeutet in diesem Fall konkret: Am Anfang steht die Erwägung der Risiken: „work backwards from the risk“.

Faktoren der Compliance-Audits

Risiken werden durch die Einhaltung sinnvoller Regeln begrenzt, die Compliance-Vorgaben zusammenfassen. Beispiele dafür sind organisatorische Faktoren: Sind die Strukturen beziehungsweise Prozesse klar definiert? Bestehen kulturelle Risiken? Sind die Mitarbeiter für ihre Aufgaben genügend ausgebildet? Oder die Kriterien sind physischer Natur: Wie ist der Zutritt zu Gebäuden geregelt? Wie sind Stromversorgung und Kühlung gesichert? Wie schützt sich das Unternehmen vor Elementarschäden? Auch das IT-System muss Vorgaben erfüllen, etwa ob nur autorisierte Personen Zugriff besitzen, wie Systemzugriffe nachverfolgt werden oder wie im Falle von Systemänderungen zu verfahren ist. Nicht zuletzt spielen auch der Datenschutz und die Datensicherheit eine Rolle. Beispielsweise gilt es zu verhindern, dass auf bereits gelöschte Daten wieder zugegriffen werden kann.

Mechanismus des Risikomanagements

Die Vorgaben einer Compliance haben im Wesentlichen zwei Quellen: regulatorische Vorschriften sowie die Ergebnisse einer Risikobewertung. Im Idealfall sollte die eigene Risikobewertung so umfassend sein, dass sie die regulatorischen Vorschriften vorwegnimmt – was in der Praxis jedoch selten zutrifft. Um die Rechte der Bürger zu schützen, regeln sowohl der Staat als auch Verbände wie etwa der im Finanzsektor tätige Payment Card Industry Security Standards Council (PCI SSC) oder Standardisierungskörperschaften wie die Internationale Organisation für Normung (ISO) die Sicherheits- und Compliance-Maßnahmen. Das Resultat beider Vorgaben – die des Staates und der Verbände sowie die aus der eigenen Risikobewertung – ist die Risikoliste. Hier sind alle möglichen Gefahren und Risiken erfasst, auf die Unternehmen vorbereitet sein müssen. Sie bildet damit die Grundlage für die regelmäßigen Kontrollverfahren, die von Auditoren durchgeführt werden. Je nach Ergebnis der Kontrollen werden technische oder organisatorische Maßnahmen angeordnet und durchgeführt.

Meist sind entsprechende Maßnahmen bereits an anderer Stelle ergriffen worden, so dass eine breite Erfahrungsbasis vorliegt. Anschließend werden die Risiken entweder beseitigt oder minimiert. Ist dies nicht möglich, werden sie mit Detective Controls unterlegt, damit Daten über die Risikowahrscheinlichkeit vorhanden sind. Bei den Detective Controls handelt es sich um Mechanismen, die bei Erreichen einer bestimmten Risikostufe eine Warnung ausgeben. Das Risiko ergibt sich durch die Multiplikation von Wahrscheinlichkeit und potenziellem Schaden. Lässt sich ein Risiko nicht beheben, obliegt es den Vertretern der möglicherweise betroffenen Bereiche, vorbereitende Schritte einzuleiten beziehungsweise Notpläne zu erstellen.

Komponenten für die Risikobewertung

Nachdem der Mechanismus, also wie das Risikomanagement erfolgt, ausreichend bestimmt wurde, wird nun betrachtet, welche Faktoren hier eine Rolle spielen. Hierzu wird das Scoping angewendet, das den Umfang von Aufgaben oder Untersuchungen in komplexen Planungs-, Management- und Herstellungsprozessen definiert. Dabei bezieht sich die Definition auf dieselben Quellen wie die Vorgaben einer Compliance. Auch hier resultieren die Vorgaben aus der internen Risikobewertung und dem regulativen Rahmen. Sie ergeben die besagte Risikoliste, aus der die Risikobereitschaft ermittelt wird. Das ist die Grundlage für die Entscheidung, welche Cloud-Dienste für die Implementierung in Frage kommen. Die Risikobereitschaft unterscheidet sich dabei von Unternehmen zu Unternehmen. So lässt sich das Risiko etwa bei der Nutzung einer Elastic Cloud, mit der vorgefertigte SaaS-Lösungen für Enterprise Search, Protokollierung, APM und Metriken implementiert werden, schnell begrenzen. Bei anderen Services, etwa wenn der Cloud-Anbieter das Active Directory des Unternehmens verwalten soll, ergibt sich ein anderes Bild. IT-Entscheider müssen daher bei jedem Dienst für sich abwägen, ob dieser mit der eigenen Risikobereitschaft in Einklang steht. Sie können zwar in der Cloud nahezu jeden Service nutzen, aus der Risikobetrachtung ergibt sich jedoch meist eine Einschränkung der infrage kommenden Dienste.

Wichtig beim Scoping ist zudem die genaue Beschreibung des zu nutzenden Service. Es ist ein Unterschied in der Definition, ob ein Unternehmen sein Kundenmanagementsystem bei einem Cloud-Provider oder auf angemieteten Servern an einem festgelegten Ort betreibt und auch das Betriebssystem selbst verwaltet. Das ist eine vollkommen andere Ausgangslage. Wenn der Auftragsgegenstand mitsamt den Diensten und den Speicherorten im Cloud-Vertrag genau benannt ist, erleichtert das die Einhaltung von Datenschutz und anderen Regulationen.

Ständige Überprüfung der Compliance-Maßnahmen

Die Überprüfung der Systeme auf die Einhaltung der Compliance-Vorgaben ruht auf drei Säulen. Bei den vom Cloud-Anbieter bereitgestellten Services werden die Kontrollen direkt von ihm selbst durchgeführt. Das ist ein für den Kunden transparenter Prozess. Dann gibt es Bereiche, in denen der Provider und der Kunde die Kontrollen gemeinsam vornehmen. Ein Beispiel dafür ist die Prüfung, ob die Passwort-Policy korrekt implementiert ist. Basis dafür kann beispielsweise die Richtlinie der PCI SSC sein. Der Cloud-Dienstleister überprüft hierbei den Zugang zu seinem Angebot, während der Anwender die Zugriffsberechtigungen zu seiner Datenbank kontrolliert. Es entsteht eine gemeinsame Verantwortung dem Regulator gegenüber.

Zuletzt gibt es den Bereich, für den der Anwender allein verantwortlich ist, der vollständig in seiner Hand liegt und auf den der Cloud-Provider keinen Einblick hat. Ein Beispiel ist das Identity Access Management. Hier kann der Provider zwar beratend tätig werden, aber die Kontrolle kann er nicht durchführen. Er gibt seinen Kunden allerdings die nötigen Mittel, um diesen Prozess zu vereinfachen. Das können etwa APIs oder Konsolen-Befehle sein, die die nötigen Schritte vorgeben. Auf diese Weise kann der Kunde seine Risiken vollständig oder zumindest teilweise ausschließen beziehungsweise mit Detective Controls unterlegen.

Implementierung und Verantwortlichkeiten

Im Anschluss an die vorangegangenen Prozesse – und somit als Basis der Implementierungsphase – sollten Service Control Policies (SCP) definiert werden. Damit können Unternehmen ihren IT-Administratoren klare Richtlinien vorgeben, etwa in welchen Rechenzentren gehostet werden soll. An der Definition dieser Guidelines sollten alle Stakeholder beteiligt sein – zumindest Vertreter aus Datenschutz, Risikomanagement, der Rechtsabteilung sowie der betreffenden Fachabteilungen. Sie definieren gemeinsam ein Gerüst und benennen einen Verantwortlichen. Es ist naheliegend, einen Vertreter aus dem Datenschutz für diese Aufgabe auszuwählen.

Um das Team, das sich um die technische Implementierung kümmern soll, personell zu gut wie möglich aufzustellen, sollte es aus möglichst vielen Datenanalysten bestehen. Für einen Arbeitskreis aus zehn Personen beispielsweise empfiehlt es sich, sieben Datenexperten sowie drei Datenschützer beziehungsweise IT-Sicherheitsexperten zu benennen. Denn der Schwerpunkt dieser Aufgabe liegt klar auf der Datenanalytik.

Nicht zuletzt ist darauf zu achten, dass das Management des Unternehmens ausreichend für die Service Control Policies sensibilisiert ist. Denn die Geschäftsführung muss die Implementierung von Maßnahmen zur Einhaltung der Compliance aktiv unterstützen.

Vorgeschriebene Nachweise

Der Nachweis, ob ein System den Anforderungen genügt, erfolgt über allgemein anerkannte Standards wie ISO 27001, AICPA SOC, PCI DSS oder C5. Das sind so genannte Typ-2-Reports. Diese Klassifikation sagt aus, dass das zu kontrollierende Objekt vom Prüfer in Augenschein genommen werden muss. Dieser inspiziert das Setup und die Arbeitsweise des Rechners, der Software oder des Dienstes. Verfasst seinen Prüfbericht  und stellt gegebenenfalls ein Zertifikat aus. Durchgeführt wird die Prüfung von einem vereidigten Wirtschaftsprüfer, der im Falle des C5 Berichts beim Bundesamt für Sicherheit in der Informationstechnik (BSI) akkreditiert ist.

Findet etwa eine Prüfung gemäß C5 statt, geht es um folgendes: die Sensibilisierung des Managements für Compliance-Vorgaben, die Kunden-Segregierung, das Change Management, spezifische Kontrollen im Netzwerk, das Schlüssel-Management sowie Disaster-Recovery-Maßnahmen. Diese Kontrollen beziehen sich jeweils auf die Ziele, nicht auf die zugrundeliegende Technologie. Welche Abwehrmaßnahmen für spezifische Risiken getroffen werden, muss ein Unternehmen nicht offenlegen – auch deshalb nicht, weil das die Sicherheit beeinträchtigen könnte. Aus diesem Grund kann die technische Basis bei Beibehaltung der Compliance-Ziele beliebig skalieren und sich neuen Gegebenheiten dynamisch anpassen.

Compliance und Technik sind kein Widerspruch. Es ist durchaus möglich, die Einhaltung der Compliance-Richtlinien sicherzustellen und gleichzeitig mittels Cloud-Services die notwendige Flexibilität in der technischen Umsetzung beizubehalten. Wenn der Mechanismus einer Compliance-Prüfung verstanden wird, die richtigen Einflussfaktoren benannt sind und Klarheit bezüglich der Risikobereitschaft besteht, können Unternehmen das richtige Portfolio aus Cloud-Diensten wählen und so eine sichere Umsetzung ihrer Geschäftsziele erreichen.