Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen.
In diesem Dokument wird beschrieben, wie Google Sicherheitslücken und Patches für Apigee Hybrid verwaltet. Sofern nicht anders angegeben, umfasst Apigee sowohl die Verwaltungsebene als auch die Datenebene.
Verantwortung für das allgemeine Patchen
Das Patchen ist eine geteilte Verantwortung zwischen Google und dem Kunden. Apigee X und Apigee Hybrid haben unterschiedliche geteilte Verantwortlichkeiten, da die Datenebene für Apigee Hybrid vollständig vom Kunden verwaltet wird. Informationen zu den gemeinsamen Verantwortlichkeiten von Apigee Hybrid finden Sie unter Modell der geteilten Verantwortung von Apigee Hybrid.
Sicherheitslücken ermitteln
Google verfolgt einen proaktiven Ansatz in Bezug auf die Sicherheit von Softwaresystemen, nutzt die Grundsätze des sicheren Standarddesigns und implementiert verschiedene Sicherheitshärtungsverfahren.
Beispielsweise unterstützen containerisierte Anwendungen die verschiedenen Features der Apigee API-Verwaltungsplattform. Die Containeranwendungen werden in Kubernetes bereitgestellt. Die Container-Images basieren auf minimalen Basis-Images (z. B. Distroless-Basis-Images), um maximale Sicherheit und verbesserte Leistung zu erzielen.
Aber selbst die besten Softwaresysteme können Sicherheitslücken haben. Um diese Sicherheitslücken zu finden und zu patchen, bevor sie ausgenutzt werden können, hat Google erhebliche in mehrere Bereiche investiert.
Sicherheitsscanner
Google identifiziert und behebt Sicherheitslücken in verschiedenen Arten von Container-Images proaktiv:
- Eigene Container: Container-Images, die von Google als Teil der Apigee-Plattform erstellt und verteilt werden. Dies sind Google-eigene Anwendungen, die die Apigee API-Verwaltungsplattform unterstützen, einschließlich Kernfunktionen wie Traffic-Routing, Kontingentverwaltung und Schlüsselverwaltung.
- Container von Drittanbietern: Container-Images, die von der Open-Source-Community erstellt, aber von Google als Teil der Apigee-Plattform verteilt werden. Dies sind hauptsächlich Open-Source-Komponenten, die von der Plattform für gängige operative Aufgaben wie Logging, Monitoring und Zertifikatsverwaltung verwendet werden.
Google scannt Container mit Container Registry Container Analysis, um Sicherheitslücken und fehlende Patches in eigenen und Drittanbietercontainern zu ermitteln. Wenn Fehlerkorrekturen verfügbar sind, startet Google den Patch- und Releaseprozess. Diese Scans werden regelmäßig ausgeführt (wenn neue Images veröffentlicht werden) und on demand (vor einer Veröffentlichung), um die Wahrscheinlichkeit auf die Entdeckung neuer Schwachstellen und die frühzeitige Planung von Abhilfemaßnahmen zu maximieren.
Sicherheitsforschung
Zusätzlich zu automatisierten Scans erkennt Google Sicherheitslücken, die Scannern unbekannt sind, und behebt sie so:
- Google führt alle Sicherheits- und Compliance-Audits, Anwendungs- und Netzwerk-Penetrationstests, Segmentierungstests sowie Sicherheitslückenerkennung für alle Apigee-Komponenten durch.
Spezialisierte Teams innerhalb von Google und vertrauenswürdigen Drittanbietern von Sicherheitslösungen führen eigene Angriffsuntersuchungen durch. - Google arbeitet mit anderen Branchen- und Open-Source-Softwarepartnern zusammen, die Sicherheitslücken, Sicherheitsforschung und Patches vor der Veröffentlichung der Sicherheitslücke teilen.
Das Ziel dieser Zusammenarbeit besteht darin, große Teile der Internetinfrastruktur zu patchen, bevor die Sicherheitslücke öffentlich bekannt gegeben wird. In manchen Fällen informiert Google diese Community über Sicherheitslücken. Beispielsweise hat Project Zero von Google die Sicherheitslücken Spectre und Meltdown entdeckt und veröffentlicht. Das Google Cloud-Sicherheitsteam sucht und behebt auch Sicherheitslücken in der kernel-basierten virtuellen Maschine (KVM).
Prämienprogramme zu Sicherheitslücken
Google interagiert aktiv über mehrere Prämienprogramme zu Sicherheitslücken mit der Sicherheitsforschungs-Community. Ein dediziertes Google Cloud-Programm zu Sicherheitslücken bietet erhebliche Vorteile, unter anderem 133.337 $ für die bedeutendste Cloud-Sicherheitslücke des Jahres. Das Programm deckt alle Apigee-Softwareabhängigkeiten ab.
OSS
Die Sicherheitszusammenarbeit von Google findet auf vielen Ebenen statt. Gelegentlich geschieht dies über Programme, bei denen Organisationen sich anmelden, um Vorabbenachrichtigungen über Software-Sicherheitslücken für Produkte wie Kubernetes und Envoy zu empfangen. Die Zusammenarbeit erfolgt auch informell durch unsere Beteiligung an vielen Open-Source-Projekten wie dem Linux-Kernel, den Containerlaufzeiten, der Virtualisierungstechnologie und anderen.
Außerhalb dieser Prozesse werden weniger schwerwiegende Sicherheitslücken erkannt und gepatcht. Die meisten Sicherheitslücken werden über einen der zuvor aufgeführten Kanäle privat gemeldet. Die frühzeitige Berichterstattung gibt Google genügend Zeit, bevor die Sicherheitslücke veröffentlicht wird, zu erfahren, wie sie sich auf Apigee auswirkt, Patches oder Abhilfemaßnahmen zu entwickeln und Beratung und Kommunikation für Kunden vorzubereiten. Wenn möglich, patcht Google alle Cluster (für Apigee X) vor der Veröffentlichung der Sicherheitslücke. Für Apigee Hybrid werden Patchreleases regelmäßig bereitgestellt, um Sicherheitslücken in den Container-Images zu beheben. Kunden wird empfohlen, auf dem neuesten Stand zu bleiben.
Klassifizierung von Sicherheitslücken
Apigee investiert viel in die Sicherheit des gesamten Stacks ein, einschließlich des Basis-Images, der Bibliotheken von Drittanbietern und der eigenen Anwendungssoftware, zusätzlich zu guten Standardeinstellungen, sicherheitsoptimierten Konfigurationen und verwalteten Komponenten. In Kombination werden diese Anstrengungen dazu beitragen, die Auswirkungen und die Wahrscheinlichkeit von Sicherheitslücken zu reduzieren.
Das Apigee-Sicherheitsteam klassifiziert Sicherheitslücken gemäß dem Common Vulnerability Scoring System (CVSS).
In der folgenden Tabelle werden die Schweregrade von Sicherheitslücken beschrieben:
| Schweregrad | Beschreibung |
| Kritisch | Eine Sicherheitslücke, die in allen Clustern leicht ausnutzbar ist durch einen nicht authentifizierten Remote-Angreifer, der zu einem vollständigen Systemmissbrauch führt. |
| Hoch | Eine Sicherheitslücke, die für viele Cluster ausgenutzt werden kann, was zum Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit führt. |
| Mittel | Eine Sicherheitslücke, die für einige Cluster genutzt werden kann, bei denen der Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit durch allgemeine Konfigurationen, der Schwere des Exploits, den erforderlichen Zugriff oder die Nutzerinteraktion beeinträchtigt wird. |
| Niedrig | Alle anderen Sicherheitslücken. Die Ausnutzung ist unwahrscheinlich oder die Konsequenzen der Ausnutzung sind begrenzt. |
So wird über Sicherheitslücken und Patches informiert
Das Ziel von Google ist es, erkannte Sicherheitslücken innerhalb eines Zeitraums zu minimieren, der für damit verbundene Risiken angemessen ist. Apigee ist in der vorläufigen FedRAMP ATO von Google Cloud enthalten. Dies erfordert, dass bekannte Sicherheitslücken innerhalb bestimmter Zeiträume entsprechend ihres Schweregrades behoben werden, wie unter FedRAMP RA-5d angegeben. Die vorläufige FedRAMP ATO von Google Cloud enthält keine Komponenten der Apigee Hybrid-Datenebene (vom Kunden verwaltet), aber wir bemühen uns, dieselben Zeitrahmen für die Problembehebung bei diesen Produkten zu erreichen.
Sicherheitslücken wurden durch proaktives Scannen erkannt
Google erkennt Sicherheitslücken durch proaktives Scannen der Binärdateien und der zugrunde liegenden Infrastruktur, die die Apigee-Plattform hostet. Apigee veröffentlicht regelmäßig Patches zur Behebung dieser Sicherheitslücken, je nach Schweregrad der zugrunde liegenden CVEs. Das Patchen einer Sicherheitslücke umfasst das Upgrade auf eine neue Apigee Hybrid-Version. Entweder wird ein Upgrade auf eine Nebenversion oder auf ein Patchversionsupgrade durchgeführt, je nach Art der Sicherheitslücke. Solche Sicherheitslücken werden hauptsächlich im Rahmen der monatlichen Patchreleases für Apigee Hybrid behoben und im Rahmen von regelmäßigen Softwareupdates für unsere verwaltete Flotte im Fall von Apigee X aufgenommen. Sicherheitspatches werden über Versionshinweise für Apigee X und Apigee Hybrid kommuniziert.
Das Beheben einiger Sicherheitslücken erfordert nur ein Upgrade der Steuerungsebene, das automatisch von Google in Apigee durchgeführt wird, während für andere neue Binärdateien auf der Datenebene eingeführt werden müssen. Bei Apigee X übernimmt Google die Einführung der neuen Binärdateien für die gesamte Flotte. Kunden, die Apigee ausführen, müssen den Patchrelease auf ihre Apigee Hybrid-Cluster anwenden, um die aktualisierten Binärdateien bereitzustellen.
Damit Cluster immer gepatcht und vor Sicherheitslücken geschützt bleiben, empfehlen wir, den neuesten Patchrelease für jede Nebenversion von Apigee Hybrid anzuwenden. Für diejenigen, die Apigee Hybrid in Anthos ausführen, empfiehlt Google, Ihre Anthos-Komponenten mindestens einmal pro Monat zu aktualisieren.
Vom Kunden gemeldete Sicherheitslücken
Mit Apigee Hybrid erhalten Kunden Apigee-Binärdateien, die in ihren Rechenzentren oder ihren bevorzugten Cloud-Plattformen ausgeführt werden. Als Teil der Sicherheitsstandards eines Kunden für die Einführung von Software in der Produktion in seinen eigenen Rechenzentren können sie eine Reihe von Sicherheitstests ausführen. Diese Tests können Penetrationstests, Containerscans, statische Codescans usw. umfassen. Diese Tests können mögliche Sicherheitslücken in der Apigee-Software melden. Bevor diese Pakete in ihren Rechenzentren aktiviert werden, müssen Kunden prüfen, ob diese gemeldeten Elemente ausgenutzt werden können und somit ein Sicherheitsrisiko darstellen.
Sicherheitslücken mit einem Exploit Proof of Concept
Wenn der Kunde eine ausnutzbare Sicherheitslücke feststellt und einen Proof of Concept (POC) zur Ausnutzung der Sicherheitslücke hat, sollte er dieses Problem über das Google Vulnerabilities Reward Program (Programm unter goo.gle/vulnz) melden. Dadurch wird das Problem dem Google-Sicherheitsteam gemeldet, das den Proof of Concept validiert und seinen Schweregrad und seine möglichen Auswirkungen ermittelt. Das Problem wird dann an Apigee eskaliert. Der Kunde hat möglicherweise Anspruch auf eine Prämie über das VRP-Programm.
Sicherheitslücken, die von einem automatisierten Tool erkannt werden
Wenn der Kunde einen Bericht über mögliche Sicherheitslücken im Apigee-Produkt basierend auf statischem Scan oder einem anderen Tool oder einer anderen Technik generiert hat, aber keine Proofs of Concepts zum Ausnutzen des Problems/der Probleme hat, kann er sich an den Support über das Google Cloud-Supportportal wenden. Durch das Melden des Problems an den Support hat der Kunde eine Ticketnummer für die Verfolgung und kann Aktualisierungen und Antworten auf den Bericht sehen. Das Supportteam eskaliert dann die gemeldeten Probleme intern entsprechend.
CVE-Kennungen
Kunden sollten so viele Informationen wie möglich über die Sicherheitslücke angeben, insbesondere die CVE-Kennung, den Bibliotheks-/Paketnamen, den Namen des Container-Images usw. für jeden Artikel. Mithilfe von CVEs können wir feststellen, dass wir dieselbe Sicherheitslücke betrachten. Wenn Sie nur das Problem oder eine andere proprietäre Tracking-Nummer angeben, ist es nicht möglich, das Problem über Erkennungstools oder Berichterstellungsprozesse hinweg zu korrelieren. Ohne CVE kann Google möglicherweise nicht auf das angegebene Element reagieren.
Antwort
Bei Artikeln, die dem Support gemeldet werden und einen Schweregrad von kritisch oder hoch haben, können Kunden eine Antwort über das Support-Ticketing-System erwarten. Informationen zu Elementen, die an die VRP gesendet werden, finden Sie in den Regeln und Dokumentationen des Programms.