Diese Seite gilt für Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen
Damit ein Kunde in Apigee kompatibel mit PCI (Payment Card Industry) ist, besitzt der Kunde einige Aktionen und Prozesse unter dem "Shared Responsibility Model" für die er verantwortlich ist. Die folgenden Punkte sollten von Kunden überprüft werden, die PCI-konform sein möchten. Diese Elemente unterliegen in Apigee der Eigenverantwortlichkeit des Kunden und die Kundenorganisation (org.) muss darüber informiert werden, dass sie die Erfüllung der PCI-Anforderungen selbst gestalten muss. Das übergreifende Konzept ist: "Google sichert die Plattform und der Kunde sichert seine Daten."
PCI-Anforderungenzuordnung
In der folgenden Tabelle werden die PCI-Anforderungen der zugehörigen Apigee-Dokumentation zugeordnet. Weitere Informationen zu den Anforderungen finden Sie in der Kurzanleitung zu PCI DSS v3.2.1.
| PCI-Anforderung | Bereich |
| Anforderung 3: Gespeicherte Karteninhaberdaten schützen | Datenmaskierung |
| Anforderung 3: Gespeicherte Karteninhaberdaten schützen | Datenspeicher |
| Anforderung 4: Verschlüsselung bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke | TLS-Konfiguration |
| Anforderung 4: Verschlüsselung bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke | Datenverschlüsselung |
| Anforderung 7: Beschränkung des Zugriffs auf Karteninhaberdaten je nach Geschäftsinformationsbedarf | Nutzung/Autorisierungen |
| Anforderung 8: Zuweisen einer eindeutigen ID für jede Person mit Computerzugriff | Komplexe Passwortanforderungen oder SAML |
| Anforderung 10: Tracking und Monitoring des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten | Audit-Trail |
| Anforderung 11: Regelmäßiges Testen der Sicherheitssysteme und -prozesse | Endpunkt-Scans |
Wenn Sie eine PCI DSS-Zertifizierung für die Datensicherheit erhalten möchten, besuchen Sie Google Compliance Report Manager oder wenden Sie sich an Ihr Apigee-Vertriebsteam.
Fehlerbehebungssitzungen
Debug Sessions ist ein Tool zur Fehlerbehebung, mit dem Nutzer den Status und die Inhalte eines API-Aufrufs abrufen können, während die Verarbeitung auf der Apigee-Plattform erfolgt.
Während einer Fehlerbehebungssitzung wird die Datenmaskierung erzwungen. Die Datenmaskierung kann verhindern, dass Daten während einer Fehlerbehebungssitzung angezeigt werden. Weitere Informationen finden Sie im Abschnitt Datenmaskierung weiter unten.
Eine ausführliche Anleitung zur Verwendung der Fehlerbehebung finden Sie unter Fehlerbehebung.
Nutzung/Autorisierungen
Der Zugriff auf Debug Sessions wird über das RBAC-System (Role-Based Access Control) von Cloud IAM (Identity Access Management) verwaltet. Ausführliche Anleitungen zum Gewähren und Entziehen von Berechtigungen für Debug Sessions finden Sie unter Apigee-Rollen und Nutzer in der Apigee-UI verwalten. Mit den Berechtigungen für Debug Sessions kann der Nutzer eine Fehlerbehebungssitzung starten und von einer Fehlerbehebungssitzung auf die Ausgabe zugreifen.
Da Debug Session Zugriff auf die Nutzlast von API-Aufrufen (früher "Nachrichtentext" genannt) hat, ist es wichtig, zu überlegen, wer Zugriff auf die Ausführung von Debug Sessions erhält. Da die Nutzerverwaltung in der Verantwortung des Kunden liegt, trifft dies auch für die die Gewährung von Berechtigungen für Debug Session zu.
Datenmaskierung
Durch die Datenmaskierung wird die Anzeige sensibler Daten während einer Fehlerbehebungssitzung sowohl im Debug-Tool (Apigee-Benutzeroberfläche) als auch im Back-End von Debug (Apigee API) verhindert. Weitere Informationen zum Einrichten einer Maskierung finden Sie unter Daten maskieren und verbergen. Die Maskierung sensibler Daten ist Teil der PCI-Anforderung 3 – Gespeicherte Karteninhaberdaten schützen.
Durch Datenmaskierung werden die Daten NICHT an Orten wie Logdateien, dem Cache und Analysen verborgen. Sensible Daten sollten normalerweise ohne starke geschäftliche Begründung und Überprüfung durch die Sicherheits- und Rechtsabteilung des Kunden nicht im Cache oder in Analysen geschrieben werden.
Caching
Caching ist für alle Kunden verfügbar. Weitere Informationen finden Sie unter Cache-Internes.
Audit-Trail
Kunden haben die Möglichkeit, den Audit-Trail aller administrativen Aktivitäten innerhalb der Organisation des Kunden zu überprüfen, einschließlich der Fehlerbehebung. Eine ausführliche Anleitung finden Sie unter Audit-Logging und Fehlerbehebung verwenden. PCI-Anforderung 10: Tracking und Monitoring des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten
Komplexe Passwortanforderungen oder SAML
Für PCI-Kunden sind Nutzerpasswörter so konfiguriert, dass sie die meisten Anforderungen gemäß PCI-DSS erfüllen. Cloud Identity bietet auch eine Multi-Faktor-Authentifizierung (PCI-Anforderung 8: Zuweisen einer eindeutigen ID für jede Person mit Computerzugriff). SAML kann, wie unter SAML-Übersicht beschrieben, als Alternative zur Authentifizierungssteuerung verwendet werden.
Hinweis: Kunden mit bestimmten Passwortanforderungen empfehlen wir, SAML für die individuellen Anforderungen zu verwenden.
Endpunktsicherheit
Endpunktsuche
Das Scannen und Testen von Hosts ist für die PCI-Compliance erforderlich (Anforderung 11: Regelmäßiges Testen der Sicherheitssysteme und -prozesse). Bei Apigee sind Kunden für das Scannen und Testen ihrer API-Endpunkte (manchmal auch als "Laufzeitkomponenten" bezeichnet) in Apigee verantwortlich. Die Tests sollten die tatsächlichen, auf Apigee gehosteten API-Proxydienste abdecken, bevor der API-Traffic vor der Verarbeitung an Apigee gesendet und dann an das Rechenzentrum übertragen wird. Das Testen gemeinsam genutzter Ressourcen, z. B. der Benutzeroberfläche des Verwaltungsportals, ist für einzelne Kunden nicht genehmigt. Kunden können einen Bericht zu freigegebenen Diensten im Rahmen einer Vertraulichkeitsvereinbarung und auf Anfrage erhalten.
Kunden sollten ihre API-Endpunkte testen und auch aufgefordert werden, diese zu testen. Ihre Vereinbarung mit Apigee lässt Tests Ihrer API-Endpunkte zu. Es ist jedoch nicht zulässig, die freigegebene Verwaltungs-UI zu testen. Benachrichtigungen Sie Apigee im Voraus, damit wir den Test-Traffic erkennen können.
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 Objekte, die sich auf Apigee-Dienste beziehen, sollten Apigee über eine Supportanfrage mitgeteilt werden.
Die meisten mit dem Endpunkt verbundenen Elemente unterliegen der Eigenverantwortlichkeit der Kunden. Probleme können mithilfe der Apigee-Dokumentation behoben werden. Wenn es Unklarheiten gibt, wie Sie diese beheben können, stellen Sie 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 Feature von Apigee, für das Kunden eigenverantwortlich sind. Die Kundenanforderungen in Bezug auf Verschlüsselung, Protokoll und Algorithmusauswahl sind variabel und spezifisch für einzelne Anwendungsfälle. Da Apigee nicht die Details des API-Designs und der Datennutzlasten der einzelnen Kunden kennt, liegt es in der Verantwortung des Kunden, die geeignete Verschlüsselung von Daten bei der Übertragung festzulegen. Eine detaillierte Anleitung zur TLS-Konfiguration finden Sie unter TLS/SSL.
Datenspeicher
Die Speicherung von Daten in Apigee ist nicht erforderlich, damit Apigee ordnungsgemäß funktioniert. Es gibt aber Dienste für die Datenspeicherung in Apigee. Kunden können die Verwendung von Cache, Schlüsselwertzuordnungen oder Analysen für die Datenspeicherung wählen. Analytics ist nicht zum Speichern von Karteninhaberdaten (Card Holder Data, CHD) berechtigt. Gemäß PCI-Anforderung 3 (Gespeicherte Karteninhaberdaten schützen) sollten PCI-Daten nur an PCI-konformen Standorten gespeichert werden. Diese Dienste können von Kunden verwendet werden, um Nicht-PCI-Daten oder andere uneingeschränkte Daten zu speichern, abhängig von den Sicherheits- und rechtlichen Anforderungen des Kunden. Da es sich bei diesen Diensten um Elemente handelt, für die der Kunde selbst verantwortlich ist, liegt es in der Verantwortung des Kunden, sie so zu konfigurieren, dass keine CHD-Daten erfasst oder gespeichert werden. Wir empfehlen die Prüfung der Konfiguration, Richtlinien und Bereitstellung durch Kundenadministratoren, um eine versehentliche oder böswillige Nutzung von Datenspeicherdiensten in Apigee auf nicht konforme Weise zu vermeiden.
Datenverschlüsselung
Datenverschlüsselungstools werden Kunden nicht zur Verwendung in Apigee angeboten. Kunden können ihre PCI-Daten jedoch vor dem Senden an Apigee verschlüsseln. PCI-Anforderung 4: (Verschlüsselung bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke): Es wird empfohlen, Karteninhaberdaten in offenen, öffentlichen Netzwerke zu verschlüsseln. Verschlüsselte Daten in der Nutzlast (oder dem Nachrichtentext) verhindern nicht, dass Apigee funktioniert. Einige Apigee-Richtlinien können möglicherweise nicht mit den Daten interagieren, wenn sie vom Kunden verschlüsselt empfangen wurden. Beispielsweise ist eine Transformation nicht möglich, wenn die Daten selbst für Apigee nicht zur Verfügung stehen. Andere Richtlinien sowie vom Kunden erstellte Richtlinien und Bundles funktionieren aber auch dann, wenn die Datennutzlast verschlüsselt ist.
Datenerfassung
Kunden können die Datenerfassungsrichtlinie verwenden, um benutzerdefinierte Attribute an die Apigee-Analyseplattform zu senden. Apigee empfiehlt, die Datenerfassung nicht zum Speichern der Informationen von Karteninhabern zu verwenden.
Informationssichtbarkeit durch Abfragestrings in der URL
Apigee empfiehlt API-Designs, die sensible Daten (einschließlich, aber nicht beschränkt auf Informationen von Karteninhabern) über Abfragestrings in URLs vermeiden.