Die Gefahr blinder Flecken im Sicherheitsbereich

Da Unternehmen auf die Cloud umgestiegen sind, verlassen sie sich zunehmend auf CSPM-Lösungen, um ihre Infrastruktur zu sichern. CSPMs decken Sicherheitslücken in Cloud-Umgebungen auf, wie z. B. falsch konfigurierte Speicher-Buckets oder unsichere Firewallkonfigurationen.

CSPMs haben jedoch einen großen blinden Fleck. CSPMs konzentrieren sich ausschließlich auf die Sicherung der Kernkonfiguration der Cloud-Infrastruktur und überspringen die Sicherheit der eigentlichen Workloads, die auf Servern oder Kubernetes-Clustern ausgeführt werden. Dadurch bleiben Sicherheitsfehlkonfigurationen und Softwareschwachstellen im vielleicht wichtigsten Teil Ihrer Cloud-Infrastruktur zurück.

Mondoo: Cloud-Komplettsicherheit für GCP

Den Angreifern ist es egal, welchem Team ein bestimmter Teil Ihrer Infrastruktur gehört oder wo die Grenzen zwischen KSPM, CPSM, CWPP oder anderen Sicherheitstools liegen. Sie suchen nach Sicherheitslücken, wo auch immer sie in Ihrer Infrastruktur existieren. Deshalb legen wir bei Mondoo großen Wert auf die Sicherheit Ihrer gesamten Cloud-Infrastruktur, vom Cloud-Konto bis hin zu Server-Workloads und allem dazwischen.

Mit der fortschrittlichen Open-Source-Scan-Engine von Mondoo, cnspec, können Sie nicht nur Ihre GCP-Organisationen und -Projekte nach Sicherheitsfehlkonfigurationen scannen, sondern auch einzelne virtuelle Maschinen und Kubernetes-Cluster/Workloads. Und das Beste daran: Sie können all dies tun, ohne Agenten in Ihrer gesamten Infrastruktur einsetzen und verwalten zu müssen.

‍

Vollständige GCP-Sicherheit über die CLI

Wir beginnen unsere Sicherheitsreise mit einem privilegierten GCP-Jump-Host, auf dem wir die cnspec-CLI mit dem automatisierten Mondoo-Installationsskript installieren können:

Wenn cnspec installiert ist, können wir mit einem Scan unseres GCP-Beispielprojekts luna-common beginnen, indem wir cnspec scan gcp-Projekt Befehl:

cnspec scan gcp project luna-common
→ loaded configuration from /home/tim/.config/mondoo/mondoo.yml using source default
→ using service account credentials
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1

Asset: GCP project luna-common
------------------------------

Checks:
✕ Fail: C 30 Ensure oslogin is enabled for compute instances
✓ Pass: A 100 Ensure instances are not configured to use the default service account with full access to all Cloud APIs
…
✓ Pass: A 100 Ensure that instances are not configured to use the default service account
✕ Fail: C 30 Ensure "Block Project-wide SSH keys" is enabled for VM instances
✓ Pass: A 100 Ensure that Cloud Storage buckets are not anonymously or publicly accessible
✓ Pass: A 100 Ensure that Cloud Storage buckets have uniform bucket-level access enabled

Scanned 1 assets

GCP Project
 D GCP project luna-common

Nach Abschluss des ersten Scans unseres GCP-Projekts müssen wir mehrere Probleme lösen. Von den 95 Prüfungen der im Paket enthaltenen CIS Google Cloud Platform Foundation- und CIS Google Kubernetes Engine-Richtlinien sind 24 fehlgeschlagen. Wir können diese Fehler mit einer detaillierten Protokollierung genauer untersuchen, um die vollständige Ausgabe der Scans anzuzeigen, oder wir können direkt zur Mondoo-Konsole springen, um die Ergebnisse grafisch zu untersuchen.

Sicherung von VM-Instanzen

Unser GCP-Projekt besteht jedoch aus mehr als nur Speicher-Buckets und Load Balancern. Schauen wir uns an, wie es unseren VM-Instanzen geht. Wir können diese Instanzen lokal mit cnspec direkt auf den Instanzen scannen oder einen anderen agentenlosen Ansatz verwenden: SSH-, WinRM- oder Snapshot-Scannen. Warum so viele Optionen? Wir bei Mondoo sind der Meinung, dass es Ihre Entscheidung ist, wie Sie Ihre Infrastruktur am besten scannen, nicht die Ihres Anbieters. Das bedeutet, Ihnen die Optionen zu geben, die Sie benötigen, um Sicherheit in Ihre Infrastruktur zu integrieren. Unsere VM-Instanz reagiert besonders empfindlich auf Störungen, daher verwenden wir das Snapshot-Scannen. Beim Snapshot-Scannen erstellt und scannt cnspec automatisch einen Snapshot Ihrer VM, sodass keine Auswirkungen auf die laufende Instanz entstehen. Sie können einen Snapshot-Scan einer GCP-VM-Instanz mit dem cnspec scannt die GCP-Instanz Befehl.

cnspec scan gcp instance importantserver --project-id luna-common --zone us-west1-b
→ loaded configuration from /home/tim/.config/mondoo/mondoo.yml using source default
→ using service account credentials
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1

importantserver ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% score: C

Asset: importantserver
----------------------

Checks:

✓ Pass:  A 100  Ensure NFS and RPC are stopped and not enabled
✓ Pass:  A 100  Ensure root group is empty
...
✓ Pass:  A 100  Ensure UID_MIN is set to 1000
✕ Fail:  D  20  Ensure system administrator actions (sudolog) are collected
✕ Fail:  F   0  Ensure only strong ciphers are used
✕ Fail:  D  20  Ensure auditd is installed
✕ Fail:  F   0  Ensure source routed packets are not accepted

Scanned 1 assets

Debian GNU/Linux 12 (bookworm)
  C importantserver

Diese wichtige Serverinstanz schnitt ziemlich schlecht ab, da 125 von 300 Prüfungen in den gebündelten CIS Debian 11-Benchmarks fehlschlugen. Dies ist ein hervorragendes Beispiel für Sicherheitslücken in den Standard-GCP-Images, die behoben werden sollten. Bauen Sie Ihr eigenes, robustes Gerät benutzerdefinierte Bilder mit Packer und Mondoo ist ein ausgezeichneter erster Schritt, aber eine Geschichte für einen anderen Blogbeitrag.

Sicherheit jenseits von Cloud und Servern

Auch wenn unsere Cloud- und Serverinfrastruktur vollständig gesichert ist, gibt es immer noch kritische Lücken in unserer Infrastruktursicherheit: Kubernetes, Kubernetes, Kubernetes! Kubernetes hat die Infrastrukturwelt verschluckt, und herkömmlichen CSPM-Lösungen fehlt der Einblick in den Kubernetes-Cluster und die Workload-Konfiguration. Auch hier können wir mit cnspec tief in die Sicherheit des Clusters und der Workloads innerhalb des Clusters eintauchen, einschließlich der Container, auf denen Ihre Apps ausgeführt werden. Um unseren Cluster und alle Workloads zu scannen, können wir Folgendes ausführen cnspec-Scan k8s, das unsere bestehende Kubectl-Authentifizierung verwendet, um unseren Cluster zu scannen.

cnspec scan k8s
→ loaded configuration from /home/tim/.config/mondoo/mondoo.yml using source default
→ using service account credentials
→ discover related assets for 1 asset(s)
→ discovery option auto is used. This will detect the assets: cluster, cronjobs, daemonsets, deployments, ingresses, jobs, pods, replicasets, statefulsets
→ use cluster name from kube config cluster-name=gke_luna-common_us-central1-c_production
→ resolved assets resolved-assets=75

 K8s Cluster gke_luna-common_us-central1-c_production  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% score: D
 gmp-system/gmp-operator                               ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% score: C
...

Kubernetes ReplicaSet
C gmp-system/gmp-operator-855fb88544
C gmp-system/rule-evaluator-6dc998c878
C gmp-system/rule-evaluator-84b694f679
C kube-system/event-exporter-gke-7bf6c99dcb
C kube-system/konnectivity-agent-755467dfb5
C kube-system/konnectivity-agent-autoscaler-5d9dbcc6d8
C kube-system/kube-dns-5bfd847c64
C kube-system/kube-dns-autoscaler-84b8db4dc7
C kube-system/l7-default-backend-d86c96845
C kube-system/metrics-server-v0.5.2-6bf74b5d5f
C kube-system/metrics-server-v0.5.2-8569bc4cf9

Kubernetes StatefulSet
C gmp-system/alertmanager

Summary
=======

Score Distribution          Asset Distribution
------------------          ------------------
A   0 assets                Kubernetes ReplicaSet    11
B   0 assets                Kubernetes Cluster       1 
C  74 assets                Kubernetes StatefulSet   1
D   1 assets                Kubernetes Pod           28
F   0 assets                Kubernetes DaemonSet     25

Unser Scan ergab insgesamt 75 Assets zwischen dem Cluster selbst und den verschiedenen Workloads, die auf dem Cluster ausgeführt werden. Diese Ressourcen wurden anhand von 230 Checks aus dem CIS-Benchmark Google Kubernetes Engine (GKE) und dem NSA/CISA Kubernetes Hardening Guide Version 1.2 bewertet. Zwischen diesen beiden Richtlinien wurden bei unserem sofort einsatzbereiten Cluster eine Reihe erheblicher Sicherheitsmängel entdeckt.

Kein Kubernetes-Asset, das wir gescannt haben, erzielte eine bessere Punktzahl als ein „C“ und, um meine Mutter zu zitieren: „Sei besser als der Durchschnitt, Tim. Nie wieder ein C mit nach Hause nehmen.“ Die sofort einsatzbereite GKE-Sicherheit ist bestenfalls durchschnittlich. Mit diesen Ergebnissen haben wir die Hilfe, die wir benötigen, um besser zu werden. Sobald wir unsere vorhandenen Workloads gesichert haben, können wir Container-Images, Kubernetes-Manifeste und Terraform-Konfigurationen mit scannen Mondoo in CI/CD-Pipelines um unseren Cluster sicher zu halten.

Schützen Sie Ihre moderne Infrastruktur

Angreifer und CPSM-Anbieter haben eines gemeinsam: Sie möchten nicht, dass Sie die gesamte Breite und Tiefe der GCP-Sicherheit oder die vielen Lücken in einer typischen Lösung berücksichtigen. Mondoo bietet eine Komplett Bewertung Ihrer GCP-Sicherheitslage und detaillierte Informationen, die Sie zu deren Verbesserung benötigen.

Erhalte vollen Zugriff auf Mondoo, eine kostenlose Beratung durch unsere Sicherheitsexperten und alle Funktionen der Enterprise Edition völlig kostenlos für 30 Tage. Starte jetzt deine 30-Tage-Testversion!

‍