PCI-Konfigurationsanleitung für Edge Public Cloud

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an.
info

Damit ein Kunde in Apigee Edge Public Cloud PCI-konform 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 das PCI-Compliance-Paket erworben haben und PCI-konform sein müssen. Diese Elemente unterliegen in Edge 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.“

Kundenverantwortungsmatrix

Kunden sollten die Google Apigee PCI-DSS 3.2.1-Verantwortungsmatrix verwenden und sie ihrem PCI Qualified Security Assessor zur Verfügung stellen, wenn sie ihre eigene PCI-Prüfung durchführen.

PCI-Anforderungenzuordnung

PCI-Anforderung Section
Anforderung 7: Beschränkung des Zugriffs auf Karteninhaberdaten je nach Geschäftsinformationsbedarf

Nutzung/Autorisierungen

Anforderung 3: Gespeicherte Karteninhaberdaten schützen

Datenmaskierung

Anforderung 10: Tracking und Monitoring des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten

Audit-Trail

Anforderung 8: Zuweisen einer eindeutigen ID für jede Person mit Computerzugriff

Komplexe Passwortanforderungen oder SAML

Anforderung 11: Regelmäßiges Testen der Sicherheitssysteme und -prozesse

Endpunkt-Scans

Anforderung 4: Verschlüsselung bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke

TLS-Konfiguration

Anforderung 3: Gespeicherte Karteninhaberdaten schützen

Datenspeicher

Anforderung 4: Verschlüsselung bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke

Datenverschlüsselung

Wenn Sie eine PCI DSS-Zertifizierung für die Datensicherheit erhalten möchten, erstellen Sie ein Ticket beim Apigee-Support oder wenden Sie sich an Ihr Apigee-Vertriebsteam.

Trace / Debug

Trace/Debug ist ein Tool zur Fehlerbehebung, mit dem Nutzer den Status und die Inhalte eines API-Aufrufs abrufen können, während die Verarbeitung über den Apigee Message Processor erfolgt. „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 der Name desselben Dienstes, wenn er über API-Aufrufe verwendet wird. Der Begriff „Trace“ in diesem Dokument bezieht sich sowohl auf Trace als auch auf Debug.

Während einer Trace-Sitzung wird die Datenmaskierung erzwungen. Mit diesem Tool können Sie verhindern, dass Daten während eines Traces angezeigt werden. Weitere Informationen finden Sie im Abschnitt Datenmaskierung weiter unten.

Verschlüsselte Schlüssel/Wert-Paare (KVMs) können für PCI-Kunden verwendet werden. Wenn eine verschlüsselte KVM verwendet wird, kann Trace weiterhin verwendet werden, einige Variablen sind jedoch auf dem Trace-Bildschirm nicht sichtbar. Es ist möglich, zusätzliche Schritte auszuführen, um diese Variablen auch während eines Traces anzuzeigen.

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 über das RBAC-System (Role-Based Access Control) für Nutzerkonten in Edge verwaltet. Ausführliche Anleitungen zum Gewähren und Entziehen von Berechtigungen für Traces finden Sie unter Rollen zuweisen und Benutzerdefinierte Rollen in der UI erstellen. Mit den Berechtigungen für Traces kann der Nutzer einen Trace starten, einen Trace beenden und von einer Trace-Sitzung auf die Ausgabe zugreifen.

Da Trace Zugriff auf die Nutzlast von API-Aufrufen (früher „Nachrichtentext“ genannt) hat, ist es wichtig, zu überlegen, wer Zugriff auf die Ausführung von Traces erhält. Da die Nutzerverwaltung in der Verantwortung des Kunden liegt, trifft dies auch für die die Gewährung von Berechtigungen für Trace zu. Apigee kann als Plattforminhaber einem Nutzer eine Kundenorganisation hinzufügen und ihm Berechtigungen zuweisen. Diese Funktion wird nur auf Kundenanfrage verwendet, wenn der Kundenservice nicht funktioniert und die Überprüfung einer Trace-Sitzung die besten Informationen zur Ursache liefern soll.

Datenmaskierung

Durch die Datenmaskierung wird die Anzeige sensibler Daten nur während einer Trace-/Debug-Sitzung verhindert, sowohl im Trace (Edge-Benutzeroberfläche) als auch im Back-End von Debug (Edge API). Weitere Informationen zum Einrichten einer Maskierung finden Sie unter Daten maskieren und ausblenden. 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. Wenn Sie Hilfe bei der Datenmaskierung in Protokollen benötigen, können Sie der Datei „logback.xml“ ein reguläres Ausdrucksmuster hinzufügen. 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.

L1- und L2-Cache

Das Caching ist für PCI-Kunden nur für nicht regulierte Daten verfügbar. Der Cache darf nicht für PCI-Karteninhaberdaten (Card Holder Data, CHD) verwendet werden. Er ist von der Apigee-PCI-Compliance-Prüfung nicht als Speicherort für CHD genehmigt. Gemäß den PCI-Richtlinien (Anforderung 3: Gespeicherte Karteninhaberdaten schützen) sollten PCI-Daten nur an einem PCI-konformen Speicherort gespeichert werden. Wenn der L1-Cache verwendet wird, wird automatisch auch der L2-Cache verwendet. Der L1-Cache ist „nur Arbeitsspeicher“, während der L2-Cache Daten auf die Festplatte schreibt, um sie über mehrere L1-Caches hinweg zu synchronisieren. Der L2-Cache sorgt dafür, dass mehrere Message Processors innerhalb einer Region und global synchronisiert bleiben. Derzeit ist es nicht möglich, den L1-Cache zu aktivieren, ohne dass ein L2-Cache dahinter steht. Der L2-Cache schreibt Daten auf die Festplatte, damit sie mit anderen Message Processors für die Kundenorganisation synchronisiert werden können. Da der L2-Cache die Daten auf die Festplatte schreibt, wird die Verwendung des Caches für CHD oder andere eingeschränkte Daten nicht unterstützt.

Die Verwendung des Caches durch Kunden ist für Nicht-CHD- und andere uneingeschränkte Daten zulässig. Wir deaktivieren den Cache für PCI-Kunden nicht standardmäßig, 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 ordnungsgemäß zu verwenden und seine Nutzer darauf hinzuweisen, den Cache nicht zu verwenden, wenn der API-Aufruf wahrscheinlich PCI-Daten enthält. Die PCI-Compliance-Prüfung von Apigee unterstützt keine im Cache gespeicherten Karteninhaberdaten.

Eine ausführliche Anleitung zur Verwendung des Caches finden Sie unter Caching und Persistenz hinzufügen.

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 Verwendung von Trace. Eine ausführliche Anleitung finden Sie in diesem Artikel und unter Trace-Tool verwenden. (PCI-Anforderung 10: Tracking und Monitoring des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten)

Komplexe Passwortanforderungen oder SAML

Kunden mit bestimmten Passwortanforderungen sollten SAML für die individuellen Anforderungen verwenden. Weitere Informationen finden Sie unter SAML-Authentifizierung für Edge aktivieren. Edge bietet auch eine Multi-Faktor-Authentifizierung (PCI-Anforderung 8: Zuweisen einer eindeutigen ID für jede Person mit Computerzugriff). Weitere Informationen finden Sie unter 2-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: Regelmäßiges Testen der Sicherheitssysteme und -prozesse). Bei Edge Cloud sind Kunden für das Scannen und Testen ihrer API-Endpunkte (manchmal auch als „Laufzeitkomponenten“ bezeichnet) in Edge verantwortlich. Die Tests sollten die tatsächlichen, auf Edge gehosteten API-Proxydienste abdecken, bevor der API-Traffic vor der Verarbeitung an Edge 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. Wenn Sie weitere Erläuterungen benötigen, senden Sie uns bitte eine Supportanfrage und verweisen Sie dabei auf Ihre geplanten Tests. 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 Edge-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 eine Selfservice-Funktion in Edge. 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 Edge ist nicht erforderlich, damit Edge ordnungsgemäß funktioniert. Es gibt aber Dienste für die Datenspeicherung in Edge. Kunden können die Verwendung von Cache, Schlüssel/Wert-Zuordnungen oder Analysen für die Datenspeicherung wählen. Gemäß der PCI-Prüfung von Apigee sind diese Dienste nicht zum Speichern von Karteninhaberdaten 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 Edge auf nicht konforme Weise zu vermeiden .

Datenverschlüsselung

Datenverschlüsselungstools werden Kunden nicht zur Verwendung in Edge angeboten. Kunden können ihre PCI-Daten jedoch vor dem Senden an Edge verschlüsseln. PCI-Anforderung 4: (Verschlüsselung bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke): Es wird empfohlen, Karteninhaberdaten in offenen, öffentlichen Netzwerken zu verschlüsseln. Verschlüsselte Daten in der Nutzlast (oder dem 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 wurden. Beispielsweise ist eine Transformation nicht möglich, wenn die Daten selbst für Edge nicht zur Verfügung stehen. Andere Richtlinien sowie vom Kunden erstellte Richtlinien und Bundles funktionieren aber auch dann, wenn die Datennutzlast verschlüsselt ist.