Die Cloud ist Realität bei vielen Unternehmen. Der Trend ist klar und die erhofften Vorteile scheinen sich zu bewahrheiten – zumindest nimmt die Zahle der Cloud-Services, welche durch Unternehmen betrieben werden, stetig zu. Ob Transformation oder der Aufbau neuer Infrastruktur, die IT-Security darf nicht zu kurz kommen. Letztlich bietet der Gang in die Cloud die Möglichkeit, IT-Security wieder fester Bestandteil der Infrastruktur werden zu lassen. Insbesondere dann, wenn historisch gewachsene On-Prem Infrastrukturen keine adäquate Maturität der Security aufweisen.

Gerade die Agilität und Flexibilität der Cloud lässt manches Unternehmen raschen Schrittes Services und Infrastrukturen produktiv schalten und vergisst doch wieder den einen oder anderen Security-Aspekt. Weiter kann es passieren, dass die Cloud-Lösungen mit absolut nicht kritischen Funktionen erprobt werden. Dann, wenn man ja schon einen Microsoft Azure Account hat, ja dann könnte man doch noch schnell diesen oder jenen Server zusammenklicken… Und schon wächst das Ganze innert kurzer Zeit zu einer ansehnlichen aber oft chaotischen Infrastruktur heran. Besonders schade ist es dann, wenn z.B. schon bereits etablierte und erprobte Security-Konzept aus der “alten” On-Prem-Infrastruktur einfach, sozusagen im Rausch der Cloud-Agilität, vergessen gehen respektive nicht implementiert werden. Darum sind hier einige Gedanken in Bezug auf Security und die Cloud zusammengefasst. Als Referenz wird auf die Azure Cloud von Microsoft verwiesen.

Cloud Konstrukt

Eine Cloud, egal in welcher Form, für sein Unternehmen zu nutzen, setzt ein gewisses Verständnis des Konstrukts voraus. Dazu folgende zwei Betrachtungsweisen:

• Die Cloud selbst ist ein Asset. Dabei weist sie mindestens Eigenschaften analog einer Applikation auf.
• Die in der Cloud betriebenen Ressourcen sind ebenfalls Assets.

Damit lässt sich relativ klar die Frage des Titels beantworten: Die Cloud selbst sollte als Asset in das bestehende Cyber Security Framework integriert werden und die bestehenden Security Controls sollten auf die Ressourcen in der Cloud appliziert werden.

1. Cloud selbst wird als Asset aufgenommen
2. Cloud Ressourcen werden als Asset aufgenommen
3. Entsprechende Controls werden für die Cloud appliziert
4. Entsprechende Controls werden für die Cloud-Ressourcen appliziert

Diese Betrachtungsweise erscheint auch grundsätzlich für die Integration der Cloud in ein bestehendes IT Governance und Management Model als sinnvoll.

Business und Strategie

Es sollte nicht verwundern, aber trotzdem: Eine allfällige Cloud-Strategie sollte klar mit Business-Anforderungen unterfüttert werden. Die Argumente der Kosteneinsparungen und Flexibilität sind valide aber noch nicht effektiv ausreichend, um eine allfällige Cloud-Strategie zu definieren. Gerade der Ausblick auf die kurz- und mittelfristige Planung ist wichtig, um grundsätzliche Strukturen und Konzepte von Anfang an im richtigen Kontext und Masse aufbauen zu können. Nicht zu Letzt bestimmt dies auch die Wahl eines oder mehreren Cloud-Providern, deren Produkt-Portfolio den regulatorischen-, Business-, IT- und natürlich den Security-Anforderungen entsprechen soll.

Ein zentraler Security-Gedanke rund um eine Cloud-Strategie sollte die Frage der Kontrolle sein: Welcher Level von Kontrolle ist erforderlich?

Die Frage der Kontrolle kann z.B. konkret auf Datenklassifikation, die definierten Mission-kritischen Prozesse und Regulatorischen-Anforderungen angewandt und gruppiert werden, um dies effektiv in der Strategie zu verankern.

Bei der Umsetzung kann hier auch festgestellt werden, dass ein spezifischer Service als zu kritisch für eine sicheren Betrieb in der Cloud definiert wird. Man könnte nun argumentieren, dass viele Cloud Provider ein umfängliches Security-Feature-Set anbieten und man durchaus auch kritische Prozesse in der Cloud betreiben kann. Es ist korrekt, dass z.B. Azure diverse Möglichkeiten im Bereich der Security bietet. Diese sollten gezielt eingesetzt werden, auch von der Cloud-Intelligenz (Ein erkanntes Angriffs-Pattern auf einem Cloud Tennant kann sogleich bei allen anderen detektiert bzw. verhindert werden.) sollte man profitierten. Jedoch ändert sich hier der Zustand von Kontrolle auf Vertrauen.

Und dies ist ein wichtiger Punkt: Bis wohin will eine Unternehmung ihrem Cloud Provider vertrauen versus wie viel Kontrolle verlangt der Business Case. In dem Fall “Kontrolle vs. Vertrauen” wird empfohlen, eine bewusste Entscheidung zu treffen und klar in der Strategie wiederzugeben.

Cloud Management & Governance

Im Vorteil ist, wer bereits ein IT-Governance-Modell für seine On-Prem-Infrastruktur betreibt, z.B. nach COBIT. Weitere Informationen dazu können in unserem Beitrag über die Diskussion von General Controls in einer Organisation gefunden werden. Damit können bestenfalls bestehende Governance-Prozesse für die Cloud adaptiert werden. Azure bietet einige Features an, um Governance- und Management-Prozesse über die Cloud zu implementieren. Diese sind aber eher technischer und operativer Natur. Für Azure wird dazu die Dokumentation von Microsoft empfohlen:

• Governance: Management Groups
• Architecture: Cloud Adoption

Auf strategischer Ebene sollten die bestehen Governance-Prozesse und -Kontrollen aus der On-Prem-Infrastruktur wiederverwendet werden können.

Neue Faktoren, die bei einer Cloud Governance mit einbezogen werden sollten, sind die Flexibilität und Agilität der Cloud. In diesem Zusammenhang sollte man den raschen Zyklen der neuen Features der Cloud-Provider sowie der Möglichkeit des sehr schnellen Bereitstellens und Löschens von Ressourcen gebührend Aufmerksamkeit schenken.

Datenhaltung

Neben den regulatorischen Anforderungen an die Datenhaltung in der Cloud sollten die Daten (auch die On-Prem-Daten) stets klassifiziert und einem Data Owner zugewiesen werden. Dies ist für die Wahl des Cloud Providers essenziell sowie auch für die Grundsatzentscheidung mit welchen Daten der Schritt in die Cloud gewagt wird. Weitere Informationen dazu finden sich in unserem Beitrag zum Schutz von geschäftlichen Informationen.

Organisations-Strukturierung der Cloud

Als nächster Punkt erscheint wichtig, dass die Cloud nach einer definierten Struktur aufgebaut wird, die mit der Cloud-Strategie einhergeht und mittels Governance-Prozessen verwaltbar wird. Wie diese Struktur aussieht, ist von unterschiedlichen Faktoren abhängig, wie der Art des Business und dessen Organisation, des aktuellen Management-Stils und nicht zu Letzt der verfügbaren Strukturierungs-Features des Cloud-Providers. Azure biete hier eine hierarchische Struktur mit Tennant-, Account- und Subscription-Levels.

Im Sinne der IT Security bringt eine klare Struktur den Vorteil, dass die Cloud-Umgebung besser verstanden werden kann sowie gewisse Komplexität reduziert wird, damit allfällige Security Controls systematisch implementiert und verwaltet werden können.

Idealerweise bieten solche Strukturen genügend Flexibilität, damit die Vorteile der Cloud effektiv genutzt werden können, jedoch auch solide Rahmenbedingungen, damit Security Controls und Security-Prozesse rasch and als Standard appliziert und kontrolliert werden können. Bereits jetzt sollten Überlegungen zur Cloud-Security-Architektur einfliessen.

Verantwortungen

Cloud Administrator klingt zwar sehr technisch, muss es aber nicht sein. Da in Cloud-Umgebungen Kosten überwacht und verwaltet werden, sollte klar definiert werden, welche Aufgaben auf dem jeweiligen Level (Governance, Management, Operativ) anstehen und welche Rollen und Verantwortlichkeiten damit verbunden sind.

Identify und Access Management

Da die Cloud via Internet erreicht werden muss (direkte Backbone-Anbindungen sind möglich, werden aber aktuell eher die Ausnahme bleiben), sind Identify- und Access-Management-Überlegungen zentral. Die Anforderungen sehen jedoch nicht anders aus, als bei anderen kritischen Applikationen. Dabei sollte eine Auslegeordnung von möglichen und gewünschten Zugriffen erarbeitet werden. Diese können mit den Anforderungen der IT Security angereichert und anschliessend implementiert werden.

Es sollte grob zwischen Governance, Management und Operations unterschieden werden. Die jeweiligen Kompetenzen sollten klar definiert werden. Dabei kann es zu diversen Überschneidungen kommen. Da z.B. Azure stark auf die Agilität des Erstellens und Löschens von Ressourcen setzt, sollte hier besonders genau definiert werden, wo Kompetenz anfangen und enden sowie wo allfällige Überschneidungen entstehen. Gerade auch die Definition der effektiven Privilegien von Accounts innerhalb der Cloud soll dabei gut verstanden und angewandt werden. Azure bietet diverse Features an, etwa Role-based Access. Hier sollten die klassischen Security Prinzipien Least-Privileged und Need-to-Know angewandt werden.

Change Management

Die Cloud als Asset betrachtet, weist einige Parallelen zu einer Applikation auf. Diverse Parameter und Prozesse können verändert und genutzt werden, die aber nicht direkten oder keinen Einfluss auf die darin betriebenen Ressourcen haben. Diese Funktionen liegen oft im administrativen Bereich der Cloud oder um die möglichen Hierarchie-Strukturen, die zuvor erwähnt wurden. Dazu macht es Sinn zu definieren, welche Rolle für administrativen Changes autorisiert ist und nach welchem Prozess diese durchgeführt werden dürfen. Azure hat bis dato keinen integrierten Change-Management Workflow, jedoch bietet sie eine Ressource-Lock an. Damit lassen sich Ressourcen sperren, respektive Changes können nur mit Admin-Approval gemacht werden, dies soll z.B. eine versehentliche Löschung von kritischen Ressourcen verhindern.

Logging und Monitoring

Man kann nicht kontrollieren, was man nicht messen kann. Wieder sollte die Cloud als Asset betrachtet werden. Neuralgische Punkte sollten geloggt und überwacht werden. Wer erstellt oder löscht Security-Gruppen, wer verändert die Struktur etc.? Azure bietet ein umfangreiches Activity Log) über diverse Ebene an, darunter ist auch eine Kategorie Namens Administrativ zu finden. Darin werden Aktivitäten (Create, Delete, Update und Action) auf Subscription-Ebene geloggt. Dies alles kommt bei Azure out of the box, jedoch muss das Alerting zu grossen Teilen selbst definiert und entsprechend konfiguriert werden.

Aus Sicht der IT Security sollten Alerts z.B. in folgenden Bereichen (nicht abschliessend) konfiguriert werden:

• Policy Assignments events
• Network Security Group Events
• Security Solution Events
• Security Policy Events

Cyber Security Framework

Nach den Gedanken zu Cloud-Strategie und Cloud Governance sollten dieselben zu einem soliden und transparentes Cyber Security Framework (z.B. NIST oder CIS) und Sicherheitskonzepten gemacht werden. Dabei sollte analog der On-Prem-Infrastruktur vorgegangen werden.

Es erscheint wichtig, dass die Cloud selbst als Entität im Asset Inventory aufgenommen wird, sowie auch alle entsprechenden Prozesse und Ressourcen, die in der Cloud betrieben und genutzt werden. Das heisst auch eine generelle Cloud-Konfiguration sowie die darin betriebenen Ressourcen können z.B. nach einer Security Baseline gehärtet und in einem Security Monitoring überwacht werden.

Weiter bieten Cloud Provider bereits eine grosse Palette von Security Features an. Dies impliziert wiederum, dass Entscheidungen getroffen werden müssen, welche Security-Konzepte für welche Ressourcen zum Zug kommen müssen, respektive ob diese durch die Built-In Features der Cloud selbst oder durch eigenen Produkte und Konzepte abgedeckt werden können (Frage der Kontrolle).

Somit erscheint es sinnvoll, sich mit den Security Features der Cloud Provider vertraut zu machen und zu definieren, ob und wie diese genutzt werden können oder müssen. Wichtig dabei erscheint, dass diese Entscheidungen bewusst getroffen werden. Wiederum ist die Agilität der Cloud, respektive das schnelle Erstellen und Löschen von Ressourcen dabei ein Faktor, der nicht unterschätzt werden sollte.

Folgendes Vorgehen kann dabei Sinn machen:

• Definition der Cloud Assets
• Definition einer Security-Architektur, diese fliesst idealerweise bereits bei der Erarbeitung einer Cloud-Struktur ein und berücksichtigt die Cloud-Strategie
• Definition einer Security-Controls-Strategie, wie und wann sollen Security Features des Cloud Providers eingesetzt werden, z.B. von MS Azure. Dazu ist empfohlen, sich mit den umfangreichen Security Features der Cloud vertraut zu machen. Wo ist man auf die Security Controls der Provider angewiesen (z.B. Physical Security) und wo setzt man seine eigenen Tools und Prozesse ein?
• Befolgen von Best Practice die unter anderem durch CIS und Microsoft angeboten werden.
• Implementierung, Betrieb und Kontrolle der definierten Security Controls mit Berücksichtigung der Agilität der Cloud, was konsequenterweise ein regelmässiges Re-Assessemt der Cloud Security nach sich zieht.

Fazit

Die Nutzung der Cloud ist allgegenwärtig. Die grundsätzliche Frage, ob dies aus Sicht der Security sinnvoll ist oder nicht, lässt sich nicht generell beantworten. Die Exponierung im Internet sowie die Verlagerung von Kontrolle zu Vertrauen müssen auf Business-Risk-Ebene beurteilt werden. Auf Use-Case-Ebene kann sehr genau festgelegt werden, welche Daten und Prozesse effektiv in die Cloud ausgelagert werden, diese Entscheidungen sollten bewusst durch das Management von Business, Risk, IT und IT Security getroffen werden.

Wird der Schritt in die Cloud gemacht, sollte eine Cloud-Strategie gestützt auf einen Business Case gefahren werden. Vorhandene IT Governance und Cyber Security Frameworks sollten transferiert und adaptiert werden. Dabei sollte die Cloud selbst sowie die darin betrieben Ressourcen als Asset betrachtet werden.

Das Management und die Administration der Cloud selbst erscheint dabei genauso wichtig, wie das Management der darin betriebenen Ressourcen. Die Agilität der Cloud ist einer ihrer grossen Vorteile. Jedoch muss dabei sichergestellt werden, dass damit nicht chaotische Zustände erzeugt werden. Mit entsprechender Governance und abgestimmtem Management sollte dem jedoch beigekommen werden, genau so wie in den On-Prem-Infrastrukturen.

Über den Autor

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

• http://www.isaca.org/cobit/pages/default.aspx
• https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/appendix/azure-scaffold
• https://docs.microsoft.com/en-us/azure/azure-monitor/platform/activity-logs-overview
• https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-lock-resources
• https://docs.microsoft.com/en-us/azure/governance/management-groups/
• https://docs.microsoft.com/en-us/azure/governance/policy/overview
• https://docs.microsoft.com/en-us/azure/role-based-access-control/overview
• https://docs.microsoft.com/en-us/azure/security-center/tutorial-security-policy
• https://docs.microsoft.com/en-us/azure/security/
• https://docs.microsoft.com/en-us/azure/security/azure-security
• https://docs.microsoft.com/en-us/azure/security/security-best-practices-and-patterns
• https://docs.microsoft.com/en-us/azure/virtual-network/security-overview
• https://www.cisecurity.org/benchmark/azure/
• https://www.cisecurity.org/cybersecurity-best-practices/
• https://www.microsoft.com/security/blog/2018/06/06/cybersecurity-reference-architecture-security-for-a-hybrid-enterprise/
• https://www.nist.gov/cyberframework