Best Practices für Apigee CMEK

Auf dieser Seite werden Best Practices für CMEK mit Apigee beschrieben.

Risikoprävention

Derzeit unterstützt Apigee nur eine begrenzte Anzahl von Funktionen für vom Kunden verwaltete Verschlüsselungsschlüssel. Um das versehentliche Löschen von CMEK-Schlüsseln oder Schlüsselversionen zu verhindern, empfehlen wir Folgendes:

  • Zugriffssteuerungen verschärfen: Beschränken Sie die Rolle roles/cloudkms.admin oder die Berechtigungen zum Löschen/Aktualisieren von Schlüsseln auf vertrauenswürdige Administratoren oder leitende Teammitglieder.
  • Prüfen Sie regelmäßig die Berechtigungen, damit sie nicht versehentlich im Laufe der Zeit erweitert werden.
  • Automatisches Löschen von Schlüsseln: Richten Sie keine Automatisierungen ein, die Schlüssel automatisch löschen oder deaktivieren.

Dauer und Rotation der Schlüsselvernichtung einrichten

  • Standarddauer für die Vernichtung verlängern: Die standardmäßige Dauer für die geplante Vernichtung beträgt 30 Tage. Wenn Sie beim Erstellen eines Schlüssels eine benutzerdefinierte Dauer für die Vernichtung festlegen oder eine längere Dauer über Organisationsrichtlinien erzwingen, haben Sie bei versehentlichem Löschen mehr Zeit für die Wiederherstellung. Wenn Sie der Meinung sind, dass längere Vernichtungszeiten ein höheres Risiko darstellen, beachten Sie, dass eine längere Vernichtungsdauer auch verhindert, dass Sie den Schlüssel versehentlich löschen. Sie können Nutzen und Risiko abwägen, um herauszufinden, welche Laufzeit für Sie am besten geeignet ist.
  • Schlüssel vor der Vernichtung deaktivieren : Wir empfehlen, Schlüsselversionen zu deaktivieren, bevor Sie sie zum Löschen vormerken. So lässt sich überprüfen, ob der Schlüssel nicht aktiv verwendet wird. Dies ist ein wichtiger Schritt, um festzustellen, ob eine Schlüsselversion sicher gelöscht werden kann.
  • Schlüsselrotation implementieren:Durch die regelmäßige Rotation von Schlüsseln werden die Auswirkungen eines potenziellen Missbrauchs begrenzt. Für den Fall, dass ein Schlüssel manipuliert wurde, beschränkt die regelmäßige Rotation die Anzahl der tatsächlich manipulierbaren Nachrichten.

Schlüsselrotation in Apigee

Primäres Ziel der Schlüsselrotation ist die Reduzierung der mit einem einzelnen Schlüssel verschlüsselten Datenmenge, nicht das vollständige Ersetzen der alten Schlüsselversion. Sowohl bei Laufzeitschlüsseln als auch bei Steuerungsebenenschlüsseln bleibt die ursprüngliche Schlüsselversion ab dem Zeitpunkt ihrer Erstellung mit der Ressource verknüpft.

Beispiele dienen der Veranschaulichung.

  • Für eine Apigee-Instanz wird immer die primäre CMEK-Schlüsselversion verwendet, die zum Zeitpunkt der Erstellung aktiv war, auch nach der Schlüsselrotation.
  • Für ein Proxy-Bundle wird weiterhin die primäre CMEK-Schlüsselversion verwendet, die beim ersten Erstellen aktiv war. Wenn dieses Proxy-Bundle jedoch nach der Schlüsselrotation geändert wird, werden alle neuen Daten darin mit der neuen Primärschlüsselversion verschlüsselt.

Aktuelle Einschränkung: keine automatische Neuverschlüsselung

Wichtig: Apigee unterstützt derzeit nicht die automatische Neuverschlüsselung vorhandener Daten bei einer Schlüsselrotation. Nur eine begrenzte Anzahl neuer Daten wird mit der neuen primären Schlüsselversion verschlüsselt. Der Großteil Ihrer Daten, z. B. Analysedaten, Laufwerkdaten zur Laufzeit und ältere Proxy-Versionen, wird weiterhin mit der alten Schlüsselversion verschlüsselt.

Deaktivierung von Schlüsseln

Wenn Sie Schlüssel deaktivieren oder löschen, werden die Apigee-Funktionen beeinträchtigt. Wenn Sie den Schlüssel zuerst deaktivieren, können Sie ihn wieder aktivieren, falls es sich um einen Fehlalarm handelt.

Wenn Sie den Verdacht haben, dass ein Schlüssel (oder eine Schlüsselversion) manipuliert wurde:

  • Hohes Risiko: Wenn Sie der Meinung sind, dass Ihre Apigee-Daten sensibel sind und ein Angreifer eine hohe Wahrscheinlichkeit hat, sie zu missbrauchen, deaktivieren Sie den Schlüssel und widerrufen Sie den Zugriff darauf. Sie sollten den Schlüssel zuerst deaktivieren, bevor Sie eine apigee-Instanz und eine apigee-Organisation neu erstellen.
  • Niedriges Risiko: Wenn die Minimierung der Ausfallzeit wichtiger ist als das potenzielle Risiko, sollten Sie zuerst die apigee-Instanz und die apigee-Organisation neu erstellen, bevor Sie CMEK deaktivieren oder löschen. Unten erfahren Sie, wie Sie Ausfallzeiten proaktiv verhindern, indem Sie in Sicherungen und Wiederherstellung investieren.
  • Support kontaktieren:Wenn Sie der Meinung sind, dass ein Schlüssel manipuliert wurde und Sie ihn deaktivieren müssen, wenden Sie sich an Google Cloud Customer Care.

Unten finden Sie Informationen zu den Auswirkungen der Deaktivierung, Widerrufung oder Zerstörung eines Schlüssels. Nachdem Sie den Schlüssel deaktiviert haben, müssen Sie Ihre apigee-Organisationen/Instanzen neu erstellen. Siehe Best Practices.

  • Laufzeit-CMEK-Kompromittierung:Erstellen Sie neue Instanzen mit einem neuen CMEK und löschen Sie die ursprünglichen Instanzen sowie das alte Laufzeit-CMEK, nachdem der Traffic migriert wurde.
  • Alle CMEK-Schlüssel manipuliert:Erstellen Sie eine neue apigee-Organisation mit einem neuen CMEK-Schlüssel, replizieren Sie die Konfiguration, leiten Sie den Traffic um und schließen Sie dann die alte Organisation und deaktivieren oder löschen Sie den ursprünglichen CMEK-Schlüssel.
  • Google Cloud-Kundenservice kontaktieren: Wenn die API zum Löschen oder Neuerstellen von Instanzen oder apigee-Organisationen sehr lange dauert, wenden Sie sich an Google Cloud Customer Care.

Auswirkungen der Deaktivierung, des Widerrufs oder der Zerstörung von Schlüsseln

Wenn Sie den Schlüssel deaktivieren, widerrufen oder löschen, funktioniert Apigee nicht mehr richtig. Die Auswirkungen sind:

  • Deaktivierung, Widerruf oder Zerstörung des gesamten Schlüssels:Die kundenorientierten APIs von Apigee funktionieren dann sofort nicht mehr. Interne Systeme schlagen innerhalb weniger Minuten fehl, was sich auf die Proxybereitstellung, den Laufzeitverkehr, Analysen und die API-Sicherheit auswirkt. Die Instanz kann in wenigen Wochen aufgrund von Problemen beim nochmaligen Bereitstellen des Laufwerks nicht mehr gestartet werden.
  • Deaktivierung, Widerruf oder Zerstörung einer Schlüsselversion (einschließlich der primären Schlüsselversion oder der vorherigen Schlüsselversion): Die Apigee-APIs, die diese Schlüsselversion verwenden, funktionieren nicht mehr. Einige interne Systeme und der Laufzeitverkehr sind davon betroffen. Die Instanz kann nicht mehr gestartet werden, wenn die Schlüsselversion für die Laufwerkverschlüsselung verwendet wurde.

Schlüssel wieder aktivieren

Wenn ein Sicherheitsverstoß ein Fehlalarm ist oder die Deaktivierung des Schlüssels nicht beabsichtigt war, können Sie den Schlüssel wieder aktivieren. Wenn Sie einen Schlüssel wieder aktivieren, werden die Funktionen der kundenorientierten APIs wiederhergestellt. Die internen Systeme sollten innerhalb weniger Minuten wiederhergestellt sein. Während der Zeit, in der der Schlüssel nicht verfügbar ist, kann es jedoch zu Datenverlusten bei der API-Sicherheit und bei Analysen kommen.

  • Wenn die Deaktivierungsdauer des Schlüssels kurz ist:Das System sollte sich erholen, mit Ausnahme einiger Datenverluste bei der API-Sicherheit und -Analyse.
  • Wenn die Deaktivierungsdauer des Schlüssels lang ist:Das System wird wiederhergestellt, um Traffic zu verarbeiten. Dies kann jedoch zu Dateninkonsistenzen führen, bei denen eine Region einen Wert zurückgibt und die zuvor ausgefallene Region einen anderen. Wenden Sie sich an Google Cloud Customer Care, um Ihren Apigee-Cluster reparieren zu lassen.

Schlüssel löschen

Berücksichtigen Sie Folgendes, bevor Sie einen Schlüssel löschen:

Apigee-Organisation mit CI/CD-Sicherungen schützen

Bei einem Sicherheitsverstoß bei vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) ist es wichtig, sofort Maßnahmen zu ergreifen, um den manipulierten Schlüssel zu deaktivieren, aufzuheben oder zu zerstören. Diese notwendige Sicherheitsmaßnahme kann jedoch dazu führen, dass Ihr Apigee-System nicht mehr funktioniert, was zu potenziellen Ausfallzeiten und Dienstunterbrechungen führen kann.

Um für Ihre Apigee-Dienste eine minimale oder gar keine Ausfallzeit zu gewährleisten, ist es wichtig, einen proaktiven Ansatz zu implementieren: kontinuierliche Sicherungen der Konfiguration Ihrer Organisation (CI/CD-Sicherungen, d. h. Continuous Integration/Continuous Deployment). Weitere Informationen finden Sie unter Verfügbare Tools und Best Practices für die Wiederherstellung einer Apigee-Organisation.

Die Vorteile von CI/CD und IaC

Wenn Sie in Tools wie Terraform investieren, einer IaC-Lösung (Infrastructure as Code), können Sie ganz einfach eine neue Apigee-Organisation aus Ihrer gesicherten Konfiguration erstellen. Mit diesem optimierten Verfahren können Sie Ihre Apigee-Organisation schnell und effizient neu erstellen, Ausfallzeiten minimieren und die Geschäftskontinuität gewährleisten.

Verfügbare Tools

Sie können alle folgenden Tools kombinieren, um Ihre apigee-Organisation regelmäßig zu sichern und den Wiederherstellungsprozess zu testen.

  • Wenn Sie nur die Apigee-Instanzen neu erstellen möchten, lesen Sie den Hilfeartikel Apigee-Instanz ohne Ausfallzeiten neu erstellen.
  • Wenn Sie Terraform verwenden möchten, können Sie sich Ideen aus der Open-Source- apigee/terraform modules holen.
  • Wenn Sie Apigee-Organisationen neu erstellen möchten, können Sie apigeecli, apigeecli organizations export und apigeecli organizations import als Grundlage für die Sicherung verwenden. Weitere Informationen finden Sie unter Organisationen exportieren/neu erstellen.
  • Wenn Sie neben den oben aufgeführten Ressourcen weitere Ressourcen sichern und wiederherstellen möchten, müssen Sie direkt mit der API interagieren oder einen anderen apigeecli-Befehl verwenden.

Best Practices

  • Regelmäßige Sicherungen: Planen Sie regelmäßige Sicherungen, damit Sie immer die aktuellste Konfiguration haben. Weitere Informationen finden Sie unter Organisationen exportieren/neu erstellen.
  • Sicherer Speicher: Speichern Sie Ihre Sicherungen an einem sicheren Ort, z. B. in einem verschlüsselten Repository.
  • Wiederherstellungen testen: Testen Sie den Wiederherstellungsprozess regelmäßig, um sicherzustellen, dass Sie Ihre Apigee-Organisation effektiv wiederherstellen können. Testen Sie den Wiederherstellungsprozess regelmäßig, damit Sie den Traffic schnell auf neu erstellte Apigee-Organisationen umstellen können.

Organisationen exportieren/neu erstellen

Das apigeecli-Tool ist ein Befehlszeilentool, mit dem Sie Apigee-Ressourcen verwalten können. Sie können damit dieselben Aktionen wie mit der Apigee API ausführen, und zwar in einer nutzerfreundlichen Befehlszeile, ähnlich wie bei gcloud-Befehlen.
Wenn Sie Apigee-Organisationen neu erstellen oder zu einer anderen Apigee-Organisation migrieren möchten, können Sie apigeecli organizations export und apigeecli organizations import verwenden. Dies kann auch als Grundlage für fortlaufende Sicherungen verwendet werden. Es können folgende Ressourcen exportiert und importiert werden:

  • API-Portaldokumente
  • API-Portalkategorien
  • API-Proxys
  • API-Sicherheitskonfiguration und Sicherheitsprofile
  • Freigegebene Abläufe
  • API-Produkte
  • Entwickler
  • Entwickler-Apps einschließlich Anmeldedaten
  • AppGroups und Apps mit Anmeldedaten
  • Umgebungsdetails
  • Umgebungsgruppen
  • Data Collectors-Konfiguration
  • Schlüsselspeicher und Aliaszertifikate auf Umgebungsebene
  • Zielserver auf Umgebungsebene
  • Verweise auf Umgebungsebene
  • Zuordnungen von Schlüssel/Wert-Paar (KVM) und Einträge auf Organisations-, Umgebungs- und Proxyebene
  • Schlüsselspeicher und Aliaszertifikate, mit Ausnahme privater Schlüssel

Das Tool kann alle anderen Apigee-Ressourcen verwalten. Die vollständige Liste der Befehle können Sie mit apigeecli tree aufrufen.

Dieses Tool hat einige Einschränkungen:

  • Bei Schlüsselspeichern muss der private Schlüssel beim Erstellen gespeichert und in die lokalen Sicherungsdateien aufgenommen werden.
  • OAuth-Tokens können nicht gesichert und wiederhergestellt werden. Das bedeutet, dass sich Ihre Kunden in neu erstellten Apigee-Instanzen noch einmal anmelden müssen.
  • Zugriffssteuerungen wie Organisationsrichtlinien und IAM-Regeln werden nicht migriert. Wenn Sie diese Regeln migrieren möchten, müssen Sie die Google Cloud API verwenden.
  • Analytics-Berichtsexporte werden nicht unterstützt und Analysemesswerte werden nicht in die neue apigee-Organisation kopiert.
  • Mit diesem import-Befehl werden keine Instanz, keine envGroup, keine EnvAttachments, keine Endpunktanhänge und keine Proxys automatisch erstellt. Sie können diese Ressourcen verwalten, aber nicht direkt über den Befehl import.
  • Mit diesem import-Befehl werden keine Portalwebsites automatisch erstellt. Portalwebsites müssen manuell über die Benutzeroberfläche erstellt werden.
  • Wir empfehlen Ihnen, in die Notfallwiederherstellung für das Löschen von Schlüsseln zu investieren und den Wiederherstellungsprozess regelmäßig zu testen, damit Sie den Traffic schnell auf neu erstellte Apigee-Organisationen umstellen können.

Vorbereitung

Bevor Sie beginnen, sollten Sie prüfen, dass die folgenden Voraussetzungen erfüllt sind:

  • Apigee CLI installiert: Folgen Sie der Anleitung in der Installationsanleitung, um apigeecli zu installieren.
  • Authentifizierung: Sie benötigen die erforderlichen Berechtigungen und Authentifizierungsdaten, um mit den Apigee-Organisationen interagieren zu können. Sie müssen Folgendes eingerichtet haben:
    • Google Cloud SDK (gcloud): Installiert und authentifiziert.
    • Zugriffstoken: Mit gcloud auth print-access-token ein Zugriffstoken abrufen.
  • Netzwerkzugriff: Achten Sie darauf, dass Ihr Netzwerk den Zugriff auf Apigee APIs zulässt.
  • Organisation erstellen: Erstellen Sie eine neue apigee-Organisation, zu der Sie migrieren möchten. Sie können unterschiedliche Arten von apigee-Organisationen erstellen. Achten Sie jedoch darauf, dass Sie dieselbe Art von Organisation (Pay-as-you-go oder Abo) und dieselbe Art des Netzwerk-Routings verwenden, die Sie für Ihre ursprüngliche Organisation verwendet haben.

Apigee-Organisation exportieren

Unten sehen Sie ein Beispiel für einen Befehl. Weitere Informationen zu den verschiedenen Flags finden Sie unter apigeecli organizations export. 

# Sample command
mkdir apigee_backup
cd apigee_backup

# gcloud auth application-default login
export ORG_FROM=REPLACE
apigeecli organizations export -o $ORG_FROM --default-token

Apigee-Organisation importieren

Unten sehen Sie ein Beispiel für einen Befehl. Weitere Informationen zu den verschiedenen Flags finden Sie unter apigeecli organizations import.

# Sample command
# gcloud auth application-default login
export ORG_TO=REPLACE
apigeecli organizations import -o $ORG_TO -f . --default-token

Schritte nach dem Import

Instanz erstellen und Netzwerke einrichten

So erstellen Sie eine Instanz und richten Netzwerke ein:

  1. Führen Sie die Schritte unter Neue Instanz erstellen aus, um eine neue Instanz zu erstellen.
  2. Northbound-Traffic konfigurieren: Northbound bezieht sich auf API-Traffic von externen oder internen Clients über einen Load Balancer an Apigee. Sie müssen den PSC oder das VPC so konfigurieren, dass Ihre Instanz erreichbar ist. Sie müssen Hostnamen für Umgebungsgruppen in der neuen Organisation einrichten.
  3. Southbound-Traffic konfigurieren: Southbound bezieht sich auf API-Traffic von Apigee zu Ihren API-Proxy-Zieldiensten. Daher müssen Sie neue IP-Adressen für Ihre NAT reservieren und aktivieren sowie Ihre Firewalls/Zulassungslisten auf Ihren Zielendpunkten neu konfigurieren.

Weitere Informationen finden Sie unter Apigee-Netzwerkoptionen.

Andere Konfigurationen sichern/wiederherstellen

Verwenden Sie eine der folgenden Methoden, um andere Konfigurationen zu sichern/wiederherzustellen:

Proxys bereitstellen

Verwenden Sie eine der folgenden Methoden, um Ihre Proxys bereitzustellen:

Traffic umschalten

So schalten Sie den Traffic um:

  1. Automatisierte Integrationstests für die neue Instanz vorbereiten.
  2. Konfigurieren Sie einen Load Balancer, um den Traffic schrittweise auf die neue Instanz umzuverteilen und dabei die Leistung zu überwachen.