Cloud Native Applications benötigen Cloud Native SecuritySicherheit der Container-Software-Lieferkette muss stimmen

Mit der Nutzung der Cloud werden auch immer mehr Cloud-native Anwendungen eingesetzt. Dies erfordert auch neue Security-Ansätze, um den Zugriff auf die Cloud und die dort abgelegten Daten und verwendeten Informationen vor Angriffen zu schützen. Devops-Prozesse, -Technologien und -Tools sind zu einem Mittel für die Steigerung des Geschäftserfolges oder zum Experimentieren mit neuen Ideen und deren Markteinführung geworden.

Cloud-native Technologien wie Container, Kubernetes (Container Orchestrator), Service Meshes usw. werden heutzutage gerne als Enabler für Devops eingesetzt. Mit der zunehmenden Akzeptanz von Cloud-native-Technologien auf Unternehmensebene werden nun viele Aspekte dieser Technologien auf den Prüfstand gestellt.

Cloud-native Security kann ein sehr umfangreiches Thema sein, deshalb liegt hier der Fokus auf den Anforderungen in zwei spezifischen Bereichen: Sicherheit der Cloud-nativen-Infrastruktur und Sicherheit der Container-Software-Lieferkette.

Cloud-native Infrastruktursicherheit

Devops ist durch die Geschwindigkeit und den Umfang der Serviceentwicklung und -bereitstellung gekennzeichnet. Dies hat zu Herausforderungen bei der Absicherung von Workload-Identitäten geführt, da Services häufiger bereitgestellt und je nach Bedarf hoch- oder herunterskaliert werden. Anwendungen werden in Form von vielen kleineren miteinander agierenden Diensten neu geschrieben.

Nicht zuletzt aus diesem Grund besteht ein wachsender Bedarf an der Verwaltung von Secrets und an Zugangsberechtigungen, die von diesen Diensten für den Zugriff auf andere Dienste und Ressourcen verwendet werden. Sowohl der Schutz von Workload-Identitäten als auch von Secrets ist ein wesentlicher Bestandteil der Gesamtsicherheit der Lösung. Unternehmen sollten sich auf die Absicherung dieser hochsensiblen Assets konzentrieren.

Ähnlich wie Workload-Implementierungen in virtualisierten Umgebungen stützen sich auch Cloud-native Workloads auf eine Public Key Infrastructure (PKI) für ihre Identität. In den ersten Phasen der Anwendung durch die Entwickler wurden die integrierten Zertifizierungsstellen (CA) der Cloud-nativen Technologien genutzt.

Da Unternehmen jedoch die Überführung dieser Workloads in die Produktion planen, traten die Anforderungen in Bezug auf Zertifikatsrichtlinien, zentralisierte Sichtbarkeit, Verwaltung und Sicherung sensibler Kryptoschlüssel in den Vordergrund. Dies hat zu einer steigenden Nachfrage nach Lösungen für die Ausstellung und Verwaltung von Zertifikaten für Cloud-native Technologien wie Kubernetes, Istio Service Mesh usw. geführt. Infolgedessen hat die Integration von Lösungen für die Ausstellung und/oder Verwaltung von Zertifikaten mit Kubernetes und Istio CA an Dynamik gewonnen.

Lösungen für die Ausstellung/Verwaltung von Zertifikaten stützen sich wiederum auf Hardware-Sicherheitsmodule (HSMs) als Root of Trust, welche die Sicherheit der Gesamtlösung untermauern, um sicheres kryptografisches Material zu erzeugen und zu speichern. Daher gibt es vermehrt Integrationen mit sowohl lokalen als auch cloudbasierten HSMs und diesen Lösungen zur Zertifikatsausstellung und -verwaltung, um eine unternehmensgerechte Lösung für die Verwaltung von Cloud-nativen Workload-Identitäten bereitzustellen.

Die Verwaltung von Kubernetes-Geheimnissen ist ein weiterer Anwendungsfall, der zunehmend von IT-Sicherheits-Teams in Unternehmen geprüft wird. Mit Kubernetes-Geheimnissen können Benutzer sensible Informationen wie Passwörter, Docker-Registry-Anmeldedaten und TLS-Schlüssel über die Kubernetes-API speichern und verwalten. Kubernetes speichert alle geheimen Objektdaten innerhalb des etcd (Key-Value-Store).

Während etcd-Daten auf Festplattenebene verschlüsselt werden können, besteht ein zunehmendes Interesse an kundeneigenen/verwalteten Schlüsseln für die Verschlüsselung von Kubernetes-Geheimnissen (auch als Verschlüsselung auf Envelope- oder Anwendungsebene bezeichnet). Je nach Kubernetes-Software oder Dienstanbieter und der zugrundeliegenden Infrastruktur des Kubernetes-Deployments reicht die Auswahl für die Schlüsselverwaltung von cloudbasierten HSM oder Schlüsselverwaltung bis hin zu physischen HSMs.

Es ist zu erwarten, dass Kubernetes-Software- und -Dienstanbieter den Besitz von Schlüsseln durch Kunden für die Verschlüsselung von Kubernetes-Geheimnissen weiter fördern werden. Die Nutzung von Lösungen zur Verwaltung von Geheimnissen von Drittanbietern für Kubernetes-Workloads ist ebenfalls eine Option. Unabhängig von der Entscheidung werden HSMs (cloudbasiert oder vor Ort) als die logische Wahl angesehen, um die zugrunde liegende Root of Trust als Teil einer Defense-in-Depth-Strategie bereitzustellen.

Für die beiden oben genannten Anwendungsfälle wird von Zeit zu Zeit auch der Einsatz von vertraulichen Computertechnologien wie sicheren Enklaven in cloudbasierten Umgebungen diskutiert, obwohl sich diese Technologie noch in der Early-Adopter-Phase befindet.

Sicherheit der Container-Software-Lieferkette

Die Absicherung der Software-Lieferkette wird von ISVs (Independent Software Vendor) vorangetrieben, die ihren Kunden die Integrität der veröffentlichten Software zusichern und gleichzeitig die Freigabe und Bereitstellung von Anwendungen und Diensten sicher über interne Entwicklungs-, Test- und Produktionsteams hinweg automatisieren wollen. Es gibt ein zunehmendes Bewusstsein für eine nötige Weiterentwicklung der bestehenden Mechanismen für die Verteilung von signierten Container-Images und zusätzlichen OCI-Artefakten wie Helm, Singularity und Cloud-native Application Bundle (CNAB), um die Benutzerfreundlichkeit zu verbessern.

Außerdem muss angesichts der zunehmenden Anzahl von Container-Registry-Anbietern die Interoperabilität für das Signieren von Container-Artefakten zwischen den Anbietern sichergestellt werden, um eine breitere Akzeptanz zu erreichen. Ein Open-Source-CNCF-Projekt wurde ins Leben gerufen, um diese Herausforderungen anzugehen. Einer der Hauptbereiche, der als Teil dieser Open-Source-Initiative identifiziert wurde, ist die Benutzerfreundlichkeit in Bezug auf die Schlüsselverwaltung.

Die Einführung von Cloud-nativen Technologien geht mittlerweile über das reine Testen hinaus, weshalb sich viele sicherheitsrelevante Aspekte weiterentwickeln werden, um die individuellen Sicherheitsanforderungen von Unternehmen zu erfüllen. Unternehmen verfolgen diese Entwicklungen und die Integration des Cloud-nativen Ökosystems.

In der Zwischenzeit können Integrationen von Lösungen für die Ausstellung und Verwaltung von Zertifikaten sowie HSMs, Cloud HSMs als auch Cloud-Key-Management genutzt werden, um hochsensible Assets wie Workload-Identitäten und Kubernetes-Geheimnisse zu sichern, ohne die Modernisierung von Anwendungen zu verlangsamen.

Thorsten Krüger ist Vice President Sales Data Protection für die Regionen DACH, BLX, CEE, CIS, Russia bei Thales.

Thales