Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
Damit ein Kunde in Apigee Edge Public Cloud PCI-konform ist, gibt es einige Aktionen und Prozesse, die dem Kunden im Rahmen des "Modell der geteilten Verantwortung" gehören. Die folgenden Punkte sollten von Kunden geprüft werden, die das PCI-Compliance-Paket erworben haben und PCI-konform sein müssen. Diese Elemente sind Self-Service-Elemente in Edge und müssen für die Kundenorganisation (Organisation) bearbeitet werden, um PCI-konform zu sein. Das übergeordnete Konzept lautet: „Google schützt die Plattform, der Kunde sichert seine Daten.“
Kundenverantwortungsmatrix
Kunden sollten auf die PCI-DSS 3.2.1-Verantwortungsmatrix von Google Apigee verweisen und sie ihrem PCI Qualified Security Assessor vorlegen, wenn sie ihr eigenes PCI-Audit durchführen.
PCI-Anforderungenzuordnung
| PCI-Anforderung | Section |
|---|---|
| Anforderung 7: Beschränkung des Zugriffs auf Karteninhaberdaten je nach Geschäftsinformationsbedarf | |
| Anforderung 3: Gespeicherte Karteninhaberdaten schützen | |
| Anforderung 10: Tracking und Monitoring des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten | |
| Anforderung 8: Zuweisen einer eindeutigen ID für jede Person mit Computerzugriff | |
| Anforderung 11: Regelmäßiges Testen der Sicherheitssysteme und -prozesse | |
| Anforderung 4: Bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke verschlüsseln | |
| Anforderung 3: Gespeicherte Karteninhaberdaten schützen | |
| Anforderung 4: Bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke verschlüsseln |
Wenn Sie eine Compliance-Bescheinigung über den PCI-Datensicherheitsstandard (AOC) erhalten möchten, öffnen Sie ein Ticket beim Apigee-Support oder wenden Sie sich an Ihr Apigee-Vertriebsteam.
Trace / Fehlerbehebung
Trace/Debug ist ein Tool zur Fehlerbehebung, mit dem Nutzer den Status und den Inhalt eines API-Aufrufs einsehen können, während dieser durch den Apigee Message Processor verarbeitet wird. Trace und Debug sind zwei Namen für denselben Dienst, auf den aber über unterschiedliche Mechanismen zugegriffen wird. Trace ist der Name dieses Dienstes in der Edge-Benutzeroberfläche. Debug ist bei API-Aufrufen der Name desselben Dienstes. Die Verwendung des Begriffs „Trace“ in diesem Dokument gilt sowohl für Trace als auch für Debug.
Während einer Trace-Sitzung wird die Datenmaskierung erzwungen. Dieses Tool kann die Anzeige von Daten während eines Trace blockieren. Weitere Informationen finden Sie unten im Abschnitt Datenmaskierung.
Encrypted Key Value Maps (KVMs) können für PCI-Kunden verwendet werden. Wenn eine verschlüsselte KVM verwendet wird, kann Trace zwar weiterhin verwendet werden, aber einige Variablen werden auf dem Trace-Anzeigebildschirm nicht angezeigt. Es können zusätzliche Schritte ausgeführt werden, damit diese Variablen während eines Trace ebenfalls angezeigt werden.
Eine ausführliche Anleitung zur Verwendung von Trace finden Sie unter Trace-Tool verwenden.
Details zu KVMs, einschließlich verschlüsselter KVMs, finden Sie unter Mit Schlüssel/Wert-Zuordnungen arbeiten.
Nutzung/Autorisierungen
Der Zugriff auf Trace wird für Nutzerkonten in Edge über das RBAC-System (Role-Based Access Control, rollenbasierte Zugriffssteuerung) verwaltet. Ausführliche Anleitungen zur Verwendung des RBAC-Systems zum Gewähren und Widerrufen von Trace-Berechtigungen finden Sie unter Rollen zuweisen und Benutzerdefinierte Rollen in der UI erstellen. Trace-Berechtigungen ermöglichen es dem Nutzer, einen Trace zu starten, zu stoppen und auf die Ausgabe einer Trace-Sitzung zuzugreifen.
Da Trace Zugriff auf die Nutzlast von API-Aufrufen (formell als "Nachrichtentext" bezeichnet) hat, ist es wichtig zu berücksichtigen, wer Zugriff zum Ausführen eines Trace hat. Da die Nutzerverwaltung in der Verantwortung des Kunden liegt, liegt auch die Erteilung von Trace-Berechtigungen in der Verantwortung des Kunden. Als Plattforminhaber hat Apigee die Möglichkeit, einer Kundenorganisation einen Nutzer hinzuzufügen und die Berechtigungen zuzuweisen. Diese Funktion wird nur auf Kundenanfrage verwendet, wenn der Kundenservice offenbar ausfällt und die Überprüfung einer Trace-Sitzung vermutlich die besten Informationen zur Ursache liefert.
Datenmaskierung
Die Datenmaskierung verhindert, dass sensible Daten während einer Trace/Debug-Sitzung angezeigt werden, sowohl in Trace (Edge-UI) als auch im Back-End durch Debug (Edge API). Details zum Einrichten der Maskierung finden Sie unter Datenmaskierung und -ausblendung. Das Maskieren sensibler Daten ist Teil der PCI-Anforderung 3 – Gespeicherte Karteninhaberdaten schützen
Die Datenmaskierung verhindert NICHT, dass die Daten in Protokolldateien, im Cache, in Analysen usw. sichtbar sind. Wenn Sie Hilfe bei der Datenmaskierung in Logs benötigen, sollten Sie der Datei „logback.xml“ ein Regex-Muster hinzufügen. Sensible Daten sollten ohne stichhaltige geschäftliche Begründung und Überprüfung durch die Sicherheits- und Rechtsteams der Kunden in der Regel nicht in den Cache oder in Analysen geschrieben werden.
L1- und L2-Cache
Caching ist für PCI-Kunden nur für die Verwendung mit nicht regulierten Daten verfügbar. Der Cache sollte nicht für PCI-Karteninhaberdaten (PCI Card Holder Data, CHD) verwendet werden. Er ist beim Apigee PCI-Compliance-Audit nicht als Speicherort für Karteninhaberdaten zugelassen. Gemäß den PCI-Richtlinien (Anforderung 3: Gespeicherte Karteninhaberdaten schützen) sollten PCI-Daten nur an einem PCI-kompatiblen Speicherort gespeichert werden. Bei der Nutzung des L1-Caches wird automatisch auch der L2-Cache verwendet. Der L1-Cache ist "nur Arbeitsspeicher", während der L2-Cache Daten zur Synchronisierung über mehrere L1-Caches auf das Laufwerk schreibt. Der L2-Cache sorgt dafür, dass mehrere Message Processor innerhalb einer Region und global synchronisiert sind. Derzeit kann der L1-Cache nicht ohne einen dahinter liegenden L2-Cache aktiviert werden. Der L2-Cache schreibt Daten auf das Laufwerk, damit sie mit anderen Nachrichtenprozessoren der Kundenorganisation synchronisiert werden können. Da der L2-Cache die Daten auf das Laufwerk schreibt, wird die Verwendung des Cache für CHD oder andere eingeschränkte Daten nicht unterstützt.
Die Verwendung des Cache durch Kunden ist für Daten ohne CHD und für andere uneingeschränkte Daten zulässig. Wir deaktivieren den Cache nicht standardmäßig für PCI-Kunden, da einige Kunden sowohl PCI- als auch nicht-PCI-bezogene API-Aufrufe über eine einzige Organisation ausführen. Da die Funktion für PCI-Kunden weiterhin aktiviert ist, liegt es in der Verantwortung des Kunden, den Dienst angemessen zu verwenden und seine Nutzer darin zu schulen, den Cache nicht zu verwenden, wenn wahrscheinlich PCI-Daten im API-Aufruf vorhanden sind. Die Prüfung der Apigee PCI-Compliance unterstützt keine im Cache gespeicherten Kartendaten.
Eine ausführliche Anleitung zur Verwendung des Cache finden Sie unter Caching und Persistenz hinzufügen.
Audit-Trail
Kunden haben die Möglichkeit, den Audit-Trail aller administrativen Aktivitäten zu überprüfen, die in der Organisation des Kunden ausgeführt wurden, einschließlich der Verwendung von Trace. Eine ausführliche Anleitung finden Sie hier und unter Trace-Tool verwenden. (PCI-Anforderung 10: Tracking und Monitoring des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten)
Komplexe Passwortanforderungen oder SAML
Kunden mit speziellen Passwortanforderungen sollten SAML nutzen, um ihre individuellen Anforderungen zu erfüllen. Weitere Informationen finden Sie unter SAML-Authentifizierung für Edge aktivieren. Edge bietet auch Multi-Faktor-Authentifizierung (PCI-Anforderung 8: jeder Person mit Computerzugriff eine eindeutige ID zuweisen). Weitere Informationen finden Sie unter Zwei-Faktor-Authentifizierung für Ihr Apigee-Konto aktivieren.
Endpunktsicherheit
Endpunktsuche
Das Scannen und Testen von Hosts ist für die PCI-Compliance erforderlich (Anforderung 11: Sicherheitssysteme und ‐prozesse regelmäßig testen). Für Edge Cloud sind Kunden für das Scannen und Testen ihrer API-Endpunkte (manchmal als „Laufzeitkomponenten“ bezeichnet) in Edge verantwortlich. Kundentests sollten die tatsächlichen auf Edge gehosteten API-Proxy-Dienste abdecken, über die der API-Traffic in Edge gesendet wird, bevor sie verarbeitet und dann an das Kundenrechenzentrum gesendet werden. Das Testen gemeinsam genutzter Ressourcen, z. B. der Benutzeroberfläche des Verwaltungsportals, ist nicht für einzelne Kunden zulässig. Ein Drittanbieterbericht über Tests der gemeinsam genutzten Dienste ist für Kunden im Rahmen einer Vertraulichkeitsvereinbarung und auf Anfrage verfügbar.
Kunden sollten ihre API-Endpunkte testen und auch aufgefordert werden, diese zu testen. Ihre Vereinbarung mit Apigee verbietet nicht das Testen Ihrer API-Endpunkte. Es ist jedoch nicht gestattet, dass Sie die gemeinsam genutzte Verwaltungs-UI testen. Wenn Sie zusätzliche Erläuterungen benötigen, können Sie eine Supportanfrage stellen, in der Sie auf Ihre geplanten Tests verweisen. Wir möchten Sie vorab an Apigee benachrichtigen, damit wir über den Testtraffic informiert sind.
Kunden, die ihre Endpunkte testen, sollten nach API-spezifischen Problemen und allen Problemen mit Apigee-Diensten suchen sowie die TLS und andere konfigurierbare Elementen überprüfen. Alle Informationen im Zusammenhang mit Apigee-Diensten sollten über eine Supportanfrage an Apigee gesendet werden.
Die meisten mit dem Endpunkt verbundenen Elemente sind Self-Service-Elemente des Kunden und können durch Lesen der Edge-Dokumentation behoben werden. Wenn es Fragen gibt, bei denen nicht klar ist, wie das Problem behoben werden kann, stellen Sie bitte eine Supportanfrage.
TLS-Konfiguration
Gemäß den PCI-Standards müssen SSL und frühes TLS zu sicheren Versionen migriert werden. Kunden sind für die Definition und Konfiguration ihrer eigenen TLS-Endpunkte für API-Proxys verantwortlich. Dies ist ein Self-Service-Feature in Edge. Die Kundenanforderungen in Bezug auf Verschlüsselung, Protokoll und Algorithmusauswahl sind variabel und spezifisch für einzelne Anwendungsfälle. Da Apigee die Details des API-Designs und der Datennutzlasten jedes Kunden nicht kennt, sind Kunden dafür verantwortlich, die angemessene Verschlüsselung für Daten bei der Übertragung zu bestimmen. Eine ausführliche Anleitung zur TLS-Konfiguration finden Sie unter TLS/SSL.
Datenspeicher
Die Speicherung von Daten in Edge ist nicht erforderlich, damit Edge ordnungsgemäß funktioniert. Es gibt jedoch Dienste für die Datenspeicherung in Edge. Kunden können zur Datenspeicherung Cache, Schlüsselwertzuordnungen oder Analysen verwenden. Keiner dieser Dienste ist gemäß dem Apigee PCI-Audit für die Speicherung von Karteninhaberdaten autorisiert. Gemäß PCI-Anforderung 3 (Gespeicherte Karteninhaberdaten schützen) sollten PCI-Daten nur an PCI-konformen Orten gespeichert werden. Die Nutzung dieser Dienste steht Kunden zum Speichern von Nicht-PCI-Daten oder anderen uneingeschränkten Daten zur Verfügung, die den Sicherheits- und rechtlichen Anforderungen des Kunden unterliegen. Bei diesen Diensten handelt es sich um Self-Service-Artikel für Kunden. Daher liegt es in der Verantwortung des Kunden, sie so zu konfigurieren, dass keine Karteninhaberdaten erfasst oder gespeichert werden. Es wird empfohlen, Konfigurationen, Richtlinien und Bereitstellungen durch Kundenadministratoren zu prüfen, um eine versehentliche oder böswillige Nutzung von Datenspeicherdiensten in Edge auf nicht konforme Weise zu vermeiden .
Datenverschlüsselung
Datenverschlüsselungstools werden Kunden nicht für die Verwendung in Edge angeboten. Kunden können jedoch ihre PCI-Daten vor dem Senden an Edge verschlüsseln. PCI-Anforderung 4 (Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke verschlüsseln) wird empfohlen, Karteninhaberdaten über offene, öffentliche Netzwerke zu verschlüsseln. Verschlüsselte Daten in der Nutzlast (oder im Nachrichtentext) verhindern nicht, dass Edge funktioniert. Einige Edge-Richtlinien können möglicherweise nicht mit den Daten interagieren, wenn sie vom Kunden verschlüsselt empfangen werden. Beispielsweise ist eine Transformation nicht möglich, wenn Edge die Daten selbst nicht ändern können. Andere Richtlinien sowie von Kunden erstellte Richtlinien und Bundles funktionieren jedoch auch, wenn die Datennutzlast verschlüsselt ist.