Berücksichtigen Sie die Sicherheitsrisiken von Cloud Agnostic vs. Cloud. Cloud-native Infrastruktur

Laut Gartnerwerden sich die Ausgaben für öffentliche Clouds im Jahr 2022 auf 500 Milliarden Dollar und im Jahr 2023 auf 600 Milliarden Dollar belaufen, .

Darüber hinaus werden bis 2025 51 % der Ausgaben für traditionelle IT, einschließlich Anwendungssoftware, Infrastruktursoftware, Geschäftsprozessdienste und Systeminfrastruktur, in die öffentliche Cloud verlagert.

As organizations around the world increasingly adopt and migrate to cloud, one of the many decisions they will need to make is whether to be cloud agnostic or cloud native. Entscheidend für diese Entscheidung ist das Verständnis der Sicherheitsrisiken der einzelnen Cloud-Modelle.

Nehmen wir zum Beispiel das Szenario einer dreistufigen Legacy-Website-Architektur, die aus einem Webserver, einem Anwendungsserver und einem Datenbankserver besteht. Um einfach zu einem Cloud-unabhängigen Modell zu migrieren, könnte die Architektur in Webserver-, Anwendungsserver- und Datenbank-Container aufgeteilt werden. Bei einer Migration mit einem nativen Cloud-Modell würden dagegen Cloud-Services für Web-, Anwendungs- und Datenbankrollen verwendet (z. B. AWS S3, AWS Lambda und AWS RDS). In diesem hypothetischen Beispiel können wir sehen, wie die Sicherheitsunterschiede langsam Gestalt annehmen.

Cloud-agnostische Sicherheitsverantwortung

Die agnostische Cloud-Sicherheit kann auf die verschiedenen Ebenen heruntergebrochen werden und ergibt sich aus einigen Konzepten. Anwendungssicherheit ist das Konzept der Sicherung des Anwendungscodes. Die Anwendungseigentümer sind für die Sicherstellung der Fertigstellung in Bereichen wie SAST und Code-Review verantwortlich (die Richtlinien können vorschreiben, dass die Entwickler diese Aufgabe übernehmen).

Die nächste Stufe ist die Software-Sicherheit von Containern. Dies umfasst Middleware und andere Sicherheitssoftware, die in den Containern installiert ist (z. B. Apache Tomcat). Auch dafür ist der Inhaber der Anwendung verantwortlich. 

Weiter unten im Stapel folgen die Anforderungen an die Absicherung aller verwendeten Container und Images. So sollte beispielsweise das Problem des Root-Benutzernamensraums durch Benutzerzuordnung entschärft werden. Diese Verantwortung liegt irgendwo zwischen dem Eigentümer der Anwendung und dem Administrator der Container-Orchestrierung.

Noch weiter unten im Stapel steht die Anforderung der Containerplattformhärtung. Dieser Schritt beinhaltet die Einschränkung und Deaktivierung des Zugriffs auf exponierte Angriffsflächen. Die Verantwortung liegt im Allgemeinen beim Administrator der Container-Orchestrierung.

Am unteren Ende des Stapels schließlich befindet sich die Infrastruktur, auf der die Orchestrierungsplattform sitzt. Die Sicherheit dieser Infrastruktur liegt in der Verantwortung des Cloud-Service-Anbieters (Public-Cloud-Modell) oder des Virtualisierungsadministrators (Private-Cloud-Modell).

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Verantwortung für die Sicherheit in der Cloud

Die Sicherheit nativer Cloud-Anwendungen ist dieselbe wie beim agnostischen Cloud-Modell.

Die weitere Entwicklung dieses Stapels führt zur Konfiguration und Absicherung der Cloud-Plattform. Dieses Verfahren stellt sicher, dass Fehlkonfigurationen, wie z. B. ein vollständig offener und öffentlicher Zugang, vermieden werden. Hierfür ist der Administrator der Cloud-Plattform zuständig.

Die nächste Stufe ist die Sicherheit der Infrastruktur. Hierfür ist der Anbieter des Cloud-Dienstes verantwortlich (die Kunden haben in der Regel keinen Zugang oder Einblick in diese Infrastruktur).

Komplexität der Sicherheit berücksichtigen

Es ist kein Geheimnis, dass Komplexität das Sicherheitsrisiko erhöht - und das gilt auch für Cloud-Modelle. Eine agnostische Cloud-Infrastruktur erhöht die Komplexität durch mehrere Ebenen und zusätzlichen Overhead. Wenn eine Cloud-unabhängige Infrastruktur in Betracht gezogen wird, muss sich die IT-Leitung fragen: Verfügt mein Unternehmen über das Know-how und die Fähigkeit, Anwendungen, Container und Plattformen effektiv und sicher zu verwalten?

Ein Mangel in einem dieser Bereiche erfordert Expertenressourcen, um die Lücken zu schließen. Zu diesen Ressourcen können interne Personalentwicklung, externe Partner und Auftragnehmer gehören, um den Mangel an Fachkräften für befristete und unbefristete Stellen auszugleichen.  

Native Cloud-Infrastrukturen stellen ganz eigene Sicherheitsanforderungen. Die IT-Leitung muss sich die Frage stellen: Verfügt mein Unternehmen über die Fähigkeiten und Möglichkeiten, sowohl die Anwendungen als auch die Cloud-Plattform effektiv und sicher zu verwalten? 

Auch hier gilt, dass ein Mangel Ressourcen erfordert, um Lücken zu schließen. Im Vergleich zur Container-Infrastruktur lassen sich die Funktionen der Cloud-Plattformen jedoch leicht ausgliedern oder auslagern.

Eine Risikobewertung kann Unternehmen bei der Entscheidung helfen, ob sie sich für eine Cloud-Agnostik oder eine Cloud-Native entscheiden. Nachdem die Entscheidung getroffen und die Anwendung migriert wurde, kann die Bedrohungsmodellierung etwaige Bedrohungen, Schwachstellen und Lücken ermitteln und mitteilen.

Sowohl Cloud-native als auch Cloud-agnostische Infrastrukturen haben ihre eigenen Risiken und Vorteile. IT-Entscheidungsträger müssen die Sicherheitsrisiken verstehen, bevor sie sich für eine bestimmte Infrastruktur entscheiden, und sich letztlich die Frage stellen: Überwiegt die Komplexität von Cloud Agnostic das Risiko der Anbieterbindung bei Cloud Native?

Unabhängig davon, für welche Architektur man sich entscheidet, wird das Unternehmen erhebliche Vorteile gegenüber einer Legacy-Architektur haben.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.