In diesem Dokument werden Best Practices beschrieben, mit denen Sie Ihre Anwendungen und APIs mit der Apigee API-Verwaltung und den folgenden Google Cloud-Produkten sichern können:
Dieses Dokument richtet sich an API-Architekten, Sicherheitsarchitekten und leitende Mitarbeiter der Entwicklung, die die Infrastruktur einer Anwendung verwalten und sichere, skalierbare und leistungsstarke APIs bereitstellen möchten.
In diesem Dokument werden verschiedene Beispielarchitekturen verwendet, um Best Practices für die Verwendung der Apigee API-Verwaltung zu demonstrieren. Außerdem werden Best Practices für die Verwendung von Web App and API Protection (WAAP) erläutert, einer umfassenden Sicherheitslösung, mit der Sie Ihre Anwendungen und APIs schützen können.
In diesem Dokument wird davon ausgegangen, dass Sie mit Netzwerken, APIs und Google Cloud vertraut sind.
API-Verwaltung mit Apigee
Apigee ist eine Plattform zum Entwickeln und Verwalten von APIs. Wenn Sie Ihren Diensten eine Proxy-Ebene hinzufügen, bietet Apigee eine Abstraktion oder Fassade, mit der Sie Ihre Back-End-Dienst-APIs schützen können.
Nutzer können mit Anwendungen, die OAuth 2.0 oder IP-Adressbereiche auf der Zulassungsliste verwenden, interagieren. Wie in der folgenden Abbildung dargestellt, können Nutzer mit einer Anwendung interagieren und Daten und Dienste werden in einem bidirektionalen Ablauf bereitgestellt.
Dies sind die Sicherheitspunkte:
- Nutzer:
- OAuth 2.0
- Zugriffssteuerung für IP-Adressen
- Anwendungen
- API-Schlüssel
- OAuth 2.0
- TLS
- Entwickler und Partner
- SSO, die
- RBAC
- APIs
- OAuth 2.0
- OpenID Connect
- Kontingente
- Spike Arrest
- Schutz vor Bedrohungen
- API-Team
- IAM RBAC
- Föderierte Logik
- Datenmaskierung
- Audit-Logs
- Backend
- Privates Netzwerk
- Gegenseitiges TLS
- Zugriffssteuerung für IP-Adressen
Wie in der vorherigen Abbildung gezeigt, können Sie in einer Anwendung verschiedene Sicherheitsmechanismen wie API-Schlüssel oder OAuth 2.0 mit Transport Layer Security (TLS) verwenden. Sie können auch Ratenbegrenzungen, Richtlinien für den Schutz vor Bedrohungen hinzufügen und gegenseitiges TLS im Back-End Ihrer API-Ebene konfigurieren.
Apigee bietet eine rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und eine föderierte Anmeldung, damit Sie den Zugriff für ein API-Team innerhalb der Apigee-Plattform verwalten können.
Wir empfehlen, Ihre APIs mit den Standardrichtlinien von Apigee zu schützen. Die Richtlinien sind:
- Trafficverwaltung: Hilft Ihnen, das Caching zu konfigurieren, Kontingente zu steuern, die Auswirkungen von Spitzen zu mindern und den API-Traffic zu steuern.
- Schutz auf Nachrichtenebene: Ermöglicht die Untersuchung und Validierung von Anfragenutzlasten zum Schutz Ihres Back-Ends vor böswilligen Angreifern.
- Sicherheit: Hilft Ihnen, den Zugriff auf Ihre APIs zu steuern.
Sie können eine oder mehrere dieser Richtlinien an Ihre Proxy-Ebene anhängen. Die folgende Tabelle enthält den Sicherheitsanwendungsfall für jede Richtlinie, kategorisiert nach Richtlinientyp.
| Richtlinientyp | Richtlinienname | Anwendungsfall für Sicherheit |
|---|---|---|
| Trafficverwaltung | SpikeArrest-Richtlinie | Wendet die Ratenbegrenzung auf die Anzahl der Anfragen an, die an das Back-End gesendet werden. |
| Trafficverwaltung | Kontingentrichtlinie | Unterstützt Ihre Organisation beim Erzwingen von Kontingenten (Anzahl der API-Aufrufe) für jeden Nutzer. |
| Trafficverwaltung | ResponseCache-Richtlinie | Speichert Antworten im Cache, sodass weniger Anfragen an das Back-End gesendet werden. |
| Schutz auf Nachrichtenebene | OASValidation-Richtlinie | Validiert eingehende Anfragen oder Antwortnachrichten anhand einer OpenAPI 3.0-Spezifikation (JSON oder YAML). |
| Schutz auf Nachrichtenebene | SOAPMessageValidation-Richtlinie | Prüft XML-Nachrichten anhand eines Schemas Ihrer Wahl. Validiert SOAP-Nachrichten anhand einer WSDL und bestimmt, ob JSON- und XML-Nachrichten korrekt formatiert sind. |
| Schutz auf Nachrichtenebene | JSONThreatProtection-Richtlinie | Hilft Ihnen, das Risiko von Angriffen auf Inhaltsebene zu verringern, indem Sie Limits für JSON-Strukturen wie Arrays und Strings festlegen. |
| Schutz auf Nachrichtenebene | XMLThreatProtection-Richtlinie | Hilft Ihnen, XML-Sicherheitslücken zu beheben und das Risiko von Angriffen zu verringern. Dazu werden Nachrichteninhalte ausgewertet und beschädigte oder fehlerhafte Nachrichten erkannt, bevor sie geparst werden können. |
| Schutz auf Nachrichtenebene | RegularExpressionProtection-Richtlinie | Wertet Inhalte anhand vordefinierter regulärer Ausdrücke aus und lehnt sie ab, wenn der Ausdruck wahr ist. |
| Sicherheit | BasicAuthentication-Richtlinie | Base64 codiert und decodiert Nutzeranmeldedaten. |
| Sicherheit | VerifyAPIKey-Richtlinie | Erzwingt die Überprüfung und Validierung von API-Schlüsseln zur Laufzeit. Nur Anwendungen mit genehmigten API-Schlüsseln, die mit Ihren API-Produkten verknüpft sind, können auf Ihre APIs zugreifen. |
| Sicherheit | OAuthV2-Richtlinie | Führt OAuth 2.0-Berechtigungstypen aus, um Zugriffstokens zu generieren und zu validieren. |
| Sicherheit | JWS- und JWT-Richtlinien | Generiert, prüft und decodiert JSON Web Tokens (JWT) und JSON Web Signatures (JWS). |
| Sicherheit | HMAC-Richtlinie | Berechnet und verifiziert den Hash-basierten Nachrichtenauthentifizierungscode (HMAC) für die Authentifizierung und Integritätsprüfungen auf Anwendungsebene. |
| Sicherheit | SAMLAssertion-Richtlinie |
|
| Sicherheit | CORS-Richtlinie | Hiermit können Sie CORS-Header (Cross-Origin Resource Sharing) für APIs festlegen, die von Webanwendungen verwendet werden. |
Wir empfehlen die Verwendung von Google Cloud Armor für die IP-Adressen- und Geo-basierte Zugriffssteuerung. Wenn dies jedoch nicht möglich ist, können Sie die AccessControl-Richtlinie verwenden. Apigee bietet auch eine Schlüsselspeicherverwaltung, mit der Sie den Schlüsselspeicher und den Truststore für TLS-Handshakes konfigurieren können, um die Verbindungen von Apigee zu Ihrem Back-End zu sichern.
Mit Apigee können Sie API-Produkte erstellen, mit denen Sie Ihre API-Vorgänge gruppieren und für Entwickler zur Nutzung bereitstellen. API-Produktsets umfassen einen oder mehrere Vorgänge. Ein Vorgang gibt einen API-Proxy und die Ressourcenpfade an, auf die mit diesem Proxy zugegriffen werden kann. Ein Vorgang kann den Zugriff auch durch HTTP-Methoden und Kontingente beschränken.
Mit API-Produkten können Sie den Zugriff auf Ihre APIs steuern. Wenn Sie ein oder mehrere API-Produkte in einer Entwickleranwendung definieren, können Sie den Zugriff auf Proxys mit einem API-Schlüssel einschränken. Beispielsweise können mobile Anwendungen, die von Kunden verwendet werden, nur einen POST-Vorgang auf dem Endpunkt /v1/payments ausführen, in diesem Fall https://$DOMAIN/v1/payments. In einem anderen Beispiel können Callcenter-Anwendungen, die von Callcenter-Mitarbeitern verwendet werden, Vorgänge wie PUT oder DELETE auf dem /payments-Endpunkt ausführen, z. B. https://$DOMAIN/v1/payments/1234, um Zahlungen rückgängig zu machen.
Anfängliche Architektur
In diesem Abschnitt wird eine beispielhafte Mikrodienstarchitektur mit den Diensten beschrieben, die im Rechenzentrum und beim Cloud-Anbieter bereitgestellt werden. Die folgenden Best Practices für die Architektur zeigen, wie Sie die ursprüngliche Architektur iterieren und verbessern können.
Die ursprüngliche Architektur sieht so aus:
- Die Zahlungs- und Kontodienste werden im Rechenzentrum und der Überweisungsdienst in Google Cloud gehostet.
- Der externe Anwendungs-Load-Balancer steuert und konfiguriert den eingehenden Traffic zu den Diensten.
- Der externe Anwendungs-Load-Balancer leitet die Anfrage an den entsprechenden Backend- oder Drittanbieterdienst weiter und verarbeitet den TLS-Handshake.
Im Ausgangszustand hat die Beispielarchitektur die folgenden Einschränkungen:
- Eine Skalierung ist unwahrscheinlich.
- Es ist unwahrscheinlich, dass ein System vor böswilligen Angriffen geschützt wird.
- Konsistente Best Practices für Sicherheit und Logging werden nicht widergespiegelt, da diese Dienste von verschiedenen Teams innerhalb der Organisation entwickelt und verwaltet werden.
Best Practices für die Architektur
Apigee kann einen Mehrwert bieten und die Bereitstellung Ihrer Dienste für Ihre Nutzer vereinfachen, indem für alle APIs ein Standardsatz von Sicherheitsrichtlinien implementiert wird. In diesem Abschnitt werden Best Practices für den Einsatz von Apigee zum Schutz Ihrer APIs erläutert.
Apigee als Proxy-Ebene verwenden
Das folgende Diagramm zeigt die anfängliche Architektur mit Hinzufügung von Apigee als Proxy-Ebene (Fassadenebene):
Apigee wird in einem Google Cloud-Projekt bereitgestellt und die Laufzeit wird über VPC-Netzwerk-Peering in einem Mandantenprojekt bereitgestellt und über Peering verbunden. Anstatt Daten über das Internet zu senden, können Sie Apigee als Proxy-Ebene verwenden, um mit Cloud Interconnect eine direkte (private) Verbindung zu Ihrem Rechenzentrum herzustellen und Ihr System zu sichern.
Der Anfrageablauf sieht so aus:
- Der Client sendet die Anfrage mit den Anmeldedaten für die Anwendung, z. B. einem Schlüssel, einem Token oder einem Zertifikat, an den externen Anwendungs-Load-Balancer.
- Der Load-Balancer leitet die Anfrage an Apigee weiter.
- Apigee verarbeitet die Anfrage, führt die Sicherheitsrichtlinien aus, wie in der Apigee API-Verwaltung beschrieben, und lässt die Anfrage zu oder lehnt sie ab. Apigee kann auch verwendet werden, um die Anfrage basierend auf dem Client, der Anfrage oder sowohl dem Client als auch der Anfrage an verschiedene Back-Ends weiterzuleiten.
- Apigee leitet die Anfrage direkt über interne IP-Adressen an die GKE-Back-Ends weiter. Die Kommunikation zwischen Apigee und dem Geldtransferdienst kann über eine RFC 1918-Adresse (interne IP-Adresse) erfolgen, da sie sich im Peering-Netzwerk befinden.
- Apigee sendet die Anfrage über Cloud Interconnect an die Back-Ends der privaten Rechenzentren.
- Apigee sendet die Anfrage über die NAT-IP-Adresse von Apigee an Dienste von Drittanbietern.
Google Cloud Armor als WAF-Ebene mit Apigee verwenden
Sie können der Architektur Google Cloud Armor hinzufügen, um Ihren Sicherheitsbereich zu erweitern. Google Cloud Armor ist Teil der globalen Load-Balancing-Infrastruktur für Google Cloud. Es bietet Funktionen für die Web Application Firewall (WAF) und hilft, DDoS-Angriffe (Distributed Denial of Service) zu verhindern. Außerdem können Sie die Sicherheitsrisiken für Anwendungen minimieren, die in den OWASP-Top-10-Risiken aufgelistet sind.
Sie können in Google Cloud Armor Regeln und Richtlinien konfigurieren, um alle Aufrufe vom Client auszuwerten, die den externen Anwendungs-Load-Balancer erreichen. Sie können auch die Konfiguration von Google Cloud Armor-Richtlinien automatisieren. Weitere Informationen zum Konfigurieren von Regeln in Google Cloud Armor finden Sie in den Anleitungen von Google Cloud Armor.
Das folgende Diagramm zeigt die Beispielarchitektur mit Apigee und Google Cloud Armor:
Der Ereignisfluss in dieser Architektur ähnelt dem Ereignis, das weiter oben in diesem Dokument unter Apigee als Proxy-Ebene verwenden erläutert wurde. Der Anfrageablauf sieht so aus:
- Der Client sendet die Anfrage mit den Anmeldedaten für die Anwendung, z. B. einem Schlüssel, einem Token oder einem Zertifikat, an den externen Anwendungs-Load-Balancer.
- Google Cloud Armor filtert die Anfrage, da sie vom externen Anwendungs-Load-Balancer aktiviert wurde. Alle konfigurierten Regeln und Richtlinien werden erzwungen und evaluiert. Wenn eine Regel verletzt wird, lehnt Google Cloud Armor die Anfrage ab und sendet Ihnen eine Fehlermeldung und einen Statuscode.
- Wenn es keine Google Cloud Armor-Regelverstöße gibt, leitet der externe Anwendungs-Load-Balancer die Anfrage an Apigee weiter.
- Apigee verarbeitet die Anfrage, führt die Sicherheitsrichtlinien aus und lässt die Anfrage zu oder lehnt sie ab. Es kann auch verwendet werden, um die Anfrage basierend auf dem Client, der Anfrage oder sowohl dem Client als auch der Anfrage an verschiedene Back-Ends weiterzuleiten.
- Apigee leitet die Anfrage direkt über interne IP-Adressen an die GKE-Back-Ends weiter. Die Kommunikation zwischen Apigee und dem Geldtransferdienst kann über eine RFC 1918-Adresse (interne IP-Adresse) erfolgen, da sie sich im Peering-Netzwerk befinden.
- Apigee sendet die Anfrage über Cloud Interconnect an die Back-Ends der privaten Rechenzentren.
- Apigee sendet die Anfrage über die NAT-IP-Adresse von Apigee an Dienste von Drittanbietern.
WAAP verwenden
Zur weiteren Verbesserung Ihres Sicherheitsprofils können Sie auch WAAP verwenden, das Google Cloud Armor, reCAPTCHA und Apigee zusammenbringt, um Ihr System vor DDoS-Angriffen und Bots zu schützen. Es bietet außerdem WAF- und API-Schutz.
Wir empfehlen WAAP für Anwendungsfälle in Unternehmen, bei denen die API-Aufrufe von einer Website und mobilen Anwendungen ausgeführt werden. Sie können festlegen, dass Anwendungen die reCAPTCHA-Bibliotheken laden und so ein reCAPTCHA-Token generieren und senden, wenn sie eine Anfrage stellen.
Das folgende Diagramm zeigt den Workflow:
Der Anfragefluss im vorherigen Diagramm sieht so aus:
- (1) Alle HTTP(S)-Anfragen von Kunden und API-Nutzern werden an den externen Anwendungs-Load-Balancer gesendet.
- (2) Der erste Kontakt in der WAAP-Lösung ist Google Cloud Armor.
- (2a) Wird keine dieser Regeln durch die Google Cloud Armor-Richtlinien ausgelöst, wird eine Anfrage an die reCAPTCHA API gesendet, um festzustellen, ob der eingehende Traffic eine legitime Anfrage ist.
- (3a) Bei einer legitimen Anfrage wird die Anfrage an das Back-End weitergeleitet.
- (2b) Wenn die Anfrage nicht legitim ist, kann Google Cloud Armor die Anfrage ablehnen und dem Nutzer den Antwortcode 403 senden.
- (3b) Eingehende API-Anfragen werden nach der Auswertung der OWASP-Regeln und DDoS-Schutz von Google Cloud Armor an Apigee weitergeleitet, um die Gültigkeit der API-Anfrage zu prüfen.
- (4) Apigee ermittelt, ob die in der Anfrage verwendeten API-Schlüssel oder Zugriffstokens gültig sind. Wenn Apigee feststellt, dass die Anfrage nicht legitim ist, kann Apigee den Antwortcode 403 senden.
- (5) Wenn die Anfrage legitim ist, leitet Apigee die Anfrage an das Backend weiter.
Das folgende Diagramm zeigt die Architektur von WAAP mit Google Cloud Armor, reCAPTCHA und Apigee für die API-Anfragen.
Der Anfragefluss im vorherigen Diagramm sieht so aus:
- Der Client sendet die Anfrage mit den Anmeldedaten für die Anwendung, z. B. einem Schlüssel, einem Token oder einem Zertifikat, an den externen Anwendungs-Load-Balancer.
- Da Google Cloud Armor für den externen Anwendungs-Load-Balancer aktiviert ist, wählt Google Cloud Armor die Anfrage aus. Alle konfigurierten Regeln und Richtlinien werden erzwungen und evaluiert. Wenn eine Regel verletzt wird, lehnt Google Cloud Armor die Anfrage mit einer Fehlermeldung und einem Statuscode ab.
- Bei Websiteaufrufen wie dem Senden von Formularen für eine Anmeldeseite ist Google Cloud Armor in reCAPTCHA eingebunden. reCAPTCHA wertet eingehenden Traffic aus und erhöht die Risikowerte für zulässigen Traffic. Bei nicht legitimem Traffic kann Google Cloud Armor die Anfrage ablehnen.
- Wenn es keine Google Cloud Armor-Regelverstöße gibt, leitet der externe HTTP(S)-Load-Balancer die API-Anfrage an Apigee weiter.
- Apigee verarbeitet die Anfrage, führt die Sicherheitsrichtlinien aus und lässt die Anfrage zu oder lehnt sie ab. Apigee kann auch verwendet werden, um die Anfrage basierend auf dem Client, der Anfrage oder sowohl dem Client als auch der Anfrage an verschiedene Back-Ends weiterzuleiten.
- Apigee leitet die Anfrage direkt über interne IP-Adressen an die GKE-Back-Ends weiter. Die Kommunikation zwischen Apigee und dem Geldübertragungsdienst kann über die RFC-1918-Adresse erfolgen, eine interne IP-Adresse, da sich beide im Peering-Netzwerk befinden.
- Apigee sendet die Anfrage über Cloud Interconnect an die Back-Ends der privaten Rechenzentren.
- Apigee sendet die Anfrage über die NAT-IP-Adresse von Apigee an Dienste von Drittanbietern.
Cloud CDN für das Caching verwenden
Cloud CDN nutzt das globale Google-Netzwerk, um Inhalte näher an die Nutzer heranzubringen, was die Antwortzeiten für Ihre Websites und Anwendungen beschleunigt. Cloud CDN bietet auch Caching-Funktionen, mit denen Sie das Back-End sichern können, indem Sie die Antwort aus dem Cache zurückgeben. Durch das Caching häufig aufgerufener Daten in einem Google Front End (GFE) am Rand des Google-Netzwerks werden die Daten so nah an den Nutzern wie möglich gespeichert und der schnellste Zugriff ermöglicht.
Cloud CDN unterstützt Organisationen außerdem bei der nahtlosen Bewältigung saisonaler Trafficspitzen, wie sie beispielsweise zu Ferienzeiten oder zu Schulbeginn auftreten können. Dieser Ansatz für das Caching trägt dazu bei, die Zuverlässigkeit und Nutzerfreundlichkeit in einer Umgebung zu verbessern. Außerdem können Sie damit die Webserverlast, die Rechenleistung und die Netzwerknutzung minimieren. Wenn Sie diese Architektur implementieren möchten, müssen Sie Cloud CDN auf dem Load-Balancer aktivieren, der Traffic für Apigee bereitstellt.
Cloud CDN kann mit allen in diesem Dokument beschriebenen Optionen verwendet werden. Das folgende Diagramm zeigt die anfängliche Beispielarchitektur von WAAP mit zusätzlichem Cloud CDN.
Der Anfragefluss im vorherigen Diagramm sieht so aus:
- Der Client ruft mit reCAPTCHA-Bibliotheken ein Token ab und sendet die Anfrage mit den Anmeldedaten für die Anwendung, z. B. einem Schlüssel, einem Token oder einem Zertifikat, an den Anwendungs-Load-Balancer.
- Cloud CDN prüft den Cache mit dem Cache-Schlüssel und gibt die Antwort zurück, wenn der Cache-Treffer wahr ist.
- Wenn der Cache-Treffer „falsch“ ist, filtert Google Cloud Armor die Anfrage, da der externe Anwendungs-Load-Balancer Google Cloud Armor aktiviert hat. Google Cloud Armor erzwingt und evaluiert alle konfigurierten Regeln und Richtlinien. Bei einem Verstoß wird die Anfrage mit einer Fehlermeldung und einem Statuscode zurückgewiesen.
- Google Cloud Armor ist in reCAPTCHA eingebunden, das den legitimen eingehenden Traffic mit Risikowerten bewertet. Bei nicht legitimem Traffic kann Google Cloud Armor die Anfrage ablehnen.
- Wenn es keine Google Cloud Armor-Regelverstöße gibt, leitet der externe Anwendungs-Load-Balancer die Anfrage an Apigee weiter.
- Apigee verarbeitet die Anfrage, führt die Sicherheitsrichtlinien aus, wie in der Apigee API-Verwaltung beschrieben, und lässt die Anfrage zu oder lehnt sie ab. Er kann auch verwendet werden, um die Anfrage basierend auf dem Client, der Anfrage oder sowohl dem Client als auch der Anfrage an verschiedene Back-Ends weiterzuleiten.
- Apigee leitet die Anfrage direkt über interne IP-Adressen an die GKE-Back-Ends weiter. Die Kommunikation zwischen Apigee und dem Transferdienst kann über die RFC 1918-Adresse erfolgen. Dabei handelt es sich um eine interne IP-Adresse, da sie sich innerhalb des Peering-Netzwerks befinden.
- Apigee sendet die Anfrage über Cloud Interconnect an die Back-Ends der privaten Rechenzentren.
- Apigee sendet die Anfrage über die NAT-IP-Adresse von Apigee an Dienste von Drittanbietern.
- Wenn eine Antwort zum Client zurückkehrt, wird sie von Cloud CDN im Cache gespeichert, sodass sie für zukünftige Aufrufe aus dem Cache zurückgegeben werden kann.
Nächste Schritte
- Weitere Informationen zu den Bereitstellungsoptionen von Apigee
- Mehrschichtige API-Sicherheit mit Apigee und Google Cloud Armor
- Leistungsfähige globale APIs mit Apigee X und Cloud CDN bereitstellen
- Fragen in der Apigee-Community finden und stellen
- Informationen zum Apigee-Repository auf GitHub
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.