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 eingeschränkte Anzahl von Funktionen für vom Kunden verwaltete Verschlüsselungsschlüssel. Um versehentliches Löschen von CMEK-Schlüsseln oder Schlüsselversionen zu verhindern, empfehlen wir Ihnen, Folgendes zu implementieren:

  • 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.
  • Berechtigungen regelmäßig prüfen:Achten Sie darauf, dass Berechtigungen 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 der Schlüsselvernichtung und ‑rotation 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 des Schlüssels eine benutzerdefinierte Dauer für das Löschen festlegen oder eine längere Dauer über Organisationsrichtlinien erzwingen, haben Sie im Falle eines versehentlichen Löschens mehr Zeit für die Wiederherstellung. Wenn Sie der Meinung sind, dass längere Löschzeiten ein höheres Risiko darstellen, sollten Sie bedenken, dass eine längere Löschdauer auch verhindert, dass Sie den Schlüssel versehentlich löschen. Sie können den Nutzen und das Risiko abwägen, um herauszufinden, welche Dauer für Sie am besten geeignet ist.
  • Schlüssel müssen vor dem Löschen deaktiviert werden : Wir empfehlen, Schlüsselversionen zu deaktivieren, bevor Sie sie zum Löschen vormerken. So lässt sich prüfen, ob der Schlüssel aktiv verwendet wird. Das ist ein wichtiger Schritt, um festzustellen, ob eine Schlüsselversion gefahrlos gelöscht werden kann.
  • Schlüsselrotation implementieren:Durch regelmäßiges Rotieren 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 es, die Datenmenge zu reduzieren, die mit einem einzelnen Schlüssel verschlüsselt wird, nicht die alte Schlüsselversion vollständig zu ersetzen. Sowohl bei Laufzeitschlüsseln als auch bei Schlüsseln für die Steuerungsebene 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 Erstellen des Proxy-Bundles 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 keine automatische Neuverschlüsselung vorhandener Daten, wenn ein Schlüssel rotiert wird. Nur eine begrenzte Menge neuer Daten wird mit der neuen primären Schlüsselversion verschlüsselt. Der Großteil Ihrer Daten, z. B. Analysen, Laufwerkdaten und ältere Proxy-Revisionen, wird weiterhin mit der alten Schlüsselversion verschlüsselt.

Schlüssel deaktivieren

Durch das Deaktivieren oder Löschen von Schlüsseln wird die Apigee-Funktionalität 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, gehen Sie so vor:

  • Szenario mit hohem Risiko:Wenn Sie der Meinung sind, dass Ihre Apigee-Daten sensibel sind und ein Angreifer sie mit hoher Wahrscheinlichkeit ausnutzen kann, deaktivieren Sie den Schlüssel sofort und widerrufen Sie den Zugriff darauf. Sie sollten den Schlüssel zuerst deaktivieren, bevor Sie eine apigee-Instanz und eine apigee-Organisation neu erstellen.
  • Szenario mit geringem Risiko:Wenn die Minimierung von Ausfallzeiten wichtiger ist als das potenzielle Risiko, sollten Sie zuerst die apigee-Instanz und die apigee-Organisation neu erstellen, bevor Sie den CMEK deaktivieren/löschen. Unten erfahren Sie, wie Sie Ausfallzeiten proaktiv verhindern können, indem Sie in Sicherung 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, des Widerrufs oder der Vernichtung eines Schlüssels. Nachdem Sie den Schlüssel deaktiviert haben, müssen Sie Ihre apigee-Organisationen/-Instanzen neu erstellen. Siehe Best Practices.

  • CMEK-Kompromittierung in der Laufzeitumgebung:Erstellen Sie neue Instanzen mit einem neuen CMEK und löschen Sie dann die ursprünglichen Instanzen sowie den alten CMEK für die Laufzeitumgebung, nachdem der Traffic migriert wurde.
  • Alle CMEK-Schlüssel kompromittiert:Erstellen Sie eine neue apigee-Organisation mit einem neuen CMEK-Schlüssel, replizieren Sie Ihre Konfiguration, leiten Sie den Traffic um und schließen Sie dann die alte Organisation und deaktivieren/löschen Sie Ihren 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/der Löschung von Schlüsseln

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

  • Gesamten Schlüssel deaktivieren/widerrufen/löschen:Die kundenorientierten APIs von Apigee funktionieren dann ab sofort nicht mehr. Interne Systeme fallen innerhalb von Minuten aus, was sich auf die Proxybereitstellung, den Laufzeittraffic, die Analysen und die API-Sicherheit auswirkt. Die Instanz kann in wenigen Wochen aufgrund von Problemen beim nochmaligen Bereitstellen des Laufwerks nicht mehr gestartet werden.
  • Schlüsselversion deaktivieren/widerrufen/zerstören (einschließlich Primärschlüsselversion oder vorheriger Schlüsselversion): Die kundenorientierten APIs von Apigee, die diese Schlüsselversion verwenden, funktionieren sofort nicht mehr. Einige interne Systeme und Laufzeittraffic sind betroffen. Die Instanz kann nicht mehr gestartet werden, wenn die Schlüsselversion für die Festplattenverschlüsselung verwendet wurde.

Schlüssel reaktivieren

Wenn es sich bei der Gefährdung um einen Fehlalarm handelt oder die Deaktivierung des Schlüssels nicht beabsichtigt ist, können Sie den Schlüssel wieder aktivieren, sofern er deaktiviert wird. Durch die Reaktivierung eines Schlüssels wird die Funktionalität von kundenorientierten APIs wiederhergestellt. Interne Systeme sollten sich innerhalb weniger Minuten wieder erholen. 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 der Zeitraum, in dem der Schlüssel deaktiviert ist, kurz ist:Das System sollte sich erholen, mit Ausnahme einiger Datenverluste bei der API-Sicherheit und -Analyse.
  • Wenn der Zeitraum, in dem der Schlüssel deaktiviert ist, lang ist:Das System wird wiederhergestellt, um Traffic zu verarbeiten. Dies kann jedoch zu Dateninkonsistenzen führen, bei denen eine Region einen Wert und die zuvor ausgefallene Region einen anderen Wert zurückgibt. Wenden Sie sich an Google Cloud Customer Care, um Ihren Apigee-Cluster reparieren zu lassen.

Schlüssel löschen

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

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

Im Falle eines CMEK-Hacks (Customer-Managed Encryption Keys) ist es entscheidend, sofort Maßnahmen zu ergreifen, um den gehackten Schlüssel zu deaktivieren, zu widerrufen oder zu löschen. 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 Leistungsfähigkeit von CI/CD und IaC

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

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 Abschnitt Apigee-Instanz ohne Ausfallzeiten neu erstellen.
  • Wenn Sie Terraform verwenden möchten, können Sie sich Ideen aus dem 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 mehr Ressourcen als die oben aufgeführten 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 aktuelle Konfiguration haben. Weitere Informationen finden Sie unter Organisationen exportieren/neu erstellen.
  • Sichere Speicherung: Speichern Sie Ihre Sicherungen an einem sicheren Ort, z. B. in einem verschlüsselten Repository.
  • Wiederherstellung testen: Testen Sie Ihren Wiederherstellungsprozess regelmäßig, um sicherzustellen, dass Sie Ihre Apigee-Organisation effektiv wiederherstellen können. Testen Sie Ihren Wiederherstellungsprozess regelmäßig, um sicherzustellen, dass Sie den Traffic schnell auf neu erstellte Apigee-Organisationen umleiten können.

Organisationen exportieren/neu erstellen

Das apigeecli-Tool ist ein Befehlszeilentool, mit dem Sie Apigee-Ressourcen verwalten können. Damit können Sie dieselben Aktionen wie mit der Apigee API in einer benutzerfreundlichen Befehlszeilenschnittstelle ausführen, ä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 kann Ressourcen wie die folgenden exportieren und importieren:

  • API-Portal-Dokumentation
  • 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
  • Keystores und Aliaszertifikate auf Umgebungsebene
  • Zielserver auf Umgebungsebene
  • Referenzen auf Umgebungsebene
  • Schlüssel/Wert-Zuordnungen (KVMs) und Einträge auf Organisations-, Umgebungs- und Proxy-Ebene
  • Keystores und Aliaszertifikate mit Ausnahme privater Schlüssel

Mit dem Tool können alle anderen Apigee-Ressourcen verwaltet werden. Die vollständige Liste der Befehle kann mit apigeecli tree aufgerufen werden.

Dieses Tool hat einige Einschränkungen:

  • Bei Schlüsselspeichern muss der private Schlüssel bei der Erstellung gespeichert und in die lokalen Sicherungsdateien aufgenommen werden.
  • OAuth-Tokens können nicht gesichert und wiederhergestellt werden. Das bedeutet, dass sich Ihre Kunden bei 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.
  • Der Export von Analytics-Berichten wird nicht unterstützt und Analysemesswerte werden nicht in die neue apigee-Organisation kopiert.
  • Mit dem Befehl import werden keine Instanzen, envGroups, EnvAttachments, Endpunktanhänge oder Bereitstellungsproxys automatisch erstellt. Sie können diese Ressourcen verwalten, aber nicht direkt über den Befehl import.
  • Mit diesem import-Befehl werden keine Portalsites automatisch erstellt. Portalsites 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 Ihren Wiederherstellungsprozess regelmäßig zu testen, damit Sie den Traffic schnell auf neu erstellte Apigee-Organisationen umleiten können.

Vorbereitung

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

  • Apigee CLI installiert: Installieren Sie apigeecli, indem Sie der -Installationsanleitung folgen.
  • Authentifizierung: Sie benötigen die erforderlichen Berechtigungen und Authentifizierungsdaten, um mit den Apigee-Organisationen interagieren zu können. Achten Sie darauf, dass Sie Folgendes eingerichtet haben:
    • Google Cloud SDK (gcloud): Installiert und authentifiziert.
    • Zugriffstoken: Rufen Sie ein Zugriffstoken mit gcloud auth print-access-token ab.
  • 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 verschiedene Arten von apigee-Organisationen erstellen. Achten Sie jedoch darauf, dass Sie denselben Organisationstyp (Pay-as-you-go oder Abo) und dieselbe Art von Netzwerkrouting verwenden, die Sie für Ihre ursprüngliche Organisation verwendet haben.

Apigee-Organisation exportieren

Unten sehen Sie einen Beispielbefehl. 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 einen Beispielbefehl. 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. Folgen Sie der Anleitung unter Neue Instanz erstellen, 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 dafür sorgen, dass Sie die PSC oder VPC richtig konfigurieren, damit 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 Optionen, um andere Konfigurationen zu sichern/wiederherzustellen:

Proxys bereitstellen

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

Traffic umstellen

So schalten Sie den Traffic um:

  1. Bereiten Sie automatisierte Integrationstests für die neue Instanz vor.
  2. Konfigurieren Sie einen Load Balancer, um den Traffic schrittweise auf die neue Instanz zu verschieben und gleichzeitig die Leistung zu überwachen.