Die Grand Unified Theory of Cloud Governance verbessern

Vor etwas mehr als einem Jahr habe ich die Grand Unified Theory of Cloud Governance verfasst. Es ist ein Konzept, mit dem ich seit etwa 5 oder 6 Jahren arbeite, um die eigentliche Ursache der Schwierigkeiten zu fassen, die Unternehmen bei der Anpassung an die Cloud haben. Sicher, der Titel ist etwas selbstbewusst, aber ich war einmal Gartner-Analyst, also – Schulterzucken?

Wie jede (hoffentlich) gute Theorie entwickle ich sie im Laufe der Zeit weiter, während ich mit mehr Unternehmen arbeite und mit mehr Menschen spreche. In den letzten Jahren habe ich sie in meinen Vorträgen und Schulungen sehr häufig verwendet, insbesondere da ich zunehmend in Governance-Szenarien hineingezogen wurde. Immer wieder sind die größten Probleme, auf die ich stoße, nicht so sehr technischer, sondern organisatorischer Natur. Ja, es gibt viele, SEHR viele technische Komplexitäten in der Cloud-Sicherheit, und sie können zu Sicherheitsverletzungen führen und tun das auch, aber nach meiner Erfahrung wiegen die Governance-Probleme weit schwerer als die technischen.

Gute Governance kann keinen Zero Day patchen, aber schlechte Governance bedeutet, dass der Angreifer nie einen braucht.

Der Kern der Theorie hat sich nicht wirklich geändert, ich arbeite lediglich weiter an besseren Wegen, sie zu erklären. Außerdem habe ich mich entschieden, sie etwas zu kürzen. So bringe ich sie derzeit auf meine Folien:

• Die Cloud dezentralisiert Betrieb und Infrastruktur
• Aber die Cloud vereinheitlicht alle Administrationsschnittstellen
• Und stellt alle Admin-Portale und Ressourcen ins Internet, geschützt durch einen Benutzernamen und ein Passwort

Im Vergleich zur vorherigen Version sind die Änderungen klein und zugleich groß:

• Alle Administrations- und Verwaltungsfunktionen sind in einer einzigen Benutzeroberfläche vereint, die im Internet liegt.
• Geschützt durch einen Benutzernamen, ein Passwort und, vielleicht, MFA.
• Technologie entwickelt sich schneller als Governance.

Ich verwende in meinem Vortrag nach wie vor „keine Engpässe und Gatekeeper“, habe aber festgestellt, dass dies eine umständlichere Art ist, „dezentralisiert“ zu sagen. Das grundlegende Problem ist die unabhängige Kontrolle über den gesamten Stack außerhalb zentralisierter Infrastruktur. Dass ein Entwicklungs- oder Anwendungsteam die gesamte eigene Infrastruktur in der eigenen Umgebung allein mit einer Kreditkarte aufbauen und verwalten kann. Nun gibt es noch einige Abhängigkeiten und Kontrollen, insbesondere in der Data Plane oder wenn eine Anbindung an Netzwerke erforderlich ist, aber das ändert nichts am Kernpunkt.

Der Versuch, vollständig zu rezentralisieren, wird nur selten funktionieren.

Als Nächstes: An der Vereinheitlichung der Administrationsschnittstellen habe ich nichts wirklich geändert. Um es auszuführen: Wir haben die gesamte Infrastruktur und Kontrolle auf Deployment-Ebene dezentralisiert, aber alle, weltweit, nutzen dieselbe Webkonsole und dieselben API-Endpunkte.

Angreifer haben ein Tor zu unendlich vielen Zielen.

Dann habe ich den Unterpunkt aus Version eins genommen und daraus Punkt 3 gemacht. Diese Admin-Portale liegen alle im Internet und nutzen standardmäßig kaum mehr als einen Benutzernamen und ein Passwort. Auch alle Ressourcen sind nur eine Einstellung davon entfernt, im Internet zu stehen – fragen Sie einfach all die S3-Buckets und ElasticSearch-Cluster.

So einfach ist es wirklich. Teams verwalten ihre eigenen Dinge unabhängig. Alle nutzen weltweit dieselben Webportale und API-Endpunkte. Und jeder Idiot mit den richtigen Zugangsdaten kann am Backend Ihres „Rechenzentrums“ herumstochern.

Und jetzt der verrückte Teil: All das wurde bereits 2011 in NIST 800-145 dargelegt, der 2-seitigen NIST Definition of Cloud Computing. Darin werden die fünf wesentlichen Merkmale des Cloud Computing definiert als:

• On-demand Self Service
• Broad Network Access
• Resource Pooling
• Rapid Elasticity
• Measured Service

Nimmt man die ersten drei Punkte, ergibt sich:

• Teams verwalten ihre eigenen Dinge
• Alles liegt im Internet
• Und alles basiert auf gemeinsamen Ressourcen-Pools

Also gut, was bedeutet das alles und was tun wir?

Akzeptieren Sie es.

Das ist der erste Schritt. Verstehen Sie das Problem und nutzen Sie es als Blickwinkel, um Lösungen zu entwickeln. Wie ich kürzlich in meinem Beitrag zu Strong Authorization schrieb:

Weil sie es nicht gewohnt sind, dass alles (potenziell) im Internet liegt. Die gesamte Management Plane liegt im Internet; wenn ein Angreifer also Zugangsdaten erlangt, können Sie ihn nicht mit einer Firewall oder durch Abschalten des Zugriffs auf einen Server aufhalten.

Beginnen Sie dort. Akzeptieren Sie die grundlegende Realität. Was können wir tun, um dieses Risiko zu verringern? Um diese Angriffe zu reduzieren? Ich halte es für die wirkungsvollste Entscheidung, sich auf IAM und auf die Schnittstelle von Governance und IAM zu konzentrieren. Wer verwaltet bei Ihnen Berechtigungen? Zugriffe? Welche Sicherheitskontrollen können IAM-bezogene Angriffe verhindern, erkennen und korrigieren? Wie sehen Ihre Prozesse rund um IAM aus? Kennen Ihre Incident Responder die Feinheiten des IAM Ihrer jeweiligen Cloud-Anbieter? Nutzen Sie JIT/Strong Authorization? Wie verwalten Sie IAM für Auftragnehmer und externe Dienste?

Beginnen Sie mit Ihrer IAM-Governance und Ihren Prozessen. Wählen und nutzen Sie anschließend Technologien, die diese unterstützen. Das ist der wirkungsvollste Einzelschritt, um Ihre Cloud-Sicherheit zu verbessern. Ich hoffe sehr, dass ich nicht der Erste bin, der Ihnen das sagt.