hi
We are looking for a possibility to use Tyk in our company and replace legacy API GW solution.
One of the features we do use is payload logging of requests and replies (currently into Kafka topic).
From there a streaming app process them and in case the request ended up with a failure, both: the request and the replay (payloads) are stored into Elastic for analysis.
Thanks to that we:
do not store all payloads (successfully processed) in Elastic (not needed),
we do not have to write any plugins which do request+replay aggregation within API GW, which would require storing request payloads in memory until replies (or timeouts) are returned - which is a huge risk due to memory usage explosion in case of increased latency of API providers (in a peak we can process 4-5k messages/sec).
But … due to PCI DSS 4.0 which is coming it is NOT allowed to store in a disc unencrypted credit card numbers (written in point 3.5.1 of the PCI DSS 4.0 spec) - including our Kafka topic.
Question:
how solution used in Tyk for auditing (I guess Tyk pump) can help here and whether there is any option to filter/mask credit card numbers before the audit message leaves the Tyk or is written to a disk within Tyk.
Not all APIs contain PCI DSS data, but these which do have it, can have the PCI data in different parts of payloads (xml/soap) .
If Tyk does not provide such a feature is there any way to extend it so that the solution can be certified towards PCI DSS 4.0.
Thanks for your interest and consideration of Tyk. Tyk is a product that is used in PCI-compliant environments and can be configured as part of a PCI-compliant service. Part of that configuration might include never logging requests, associated metadata and payloads (enable_detailed_recording which is disabled by default), and in a Hybrid Architecture never sending analytics logs to a Tyk Cloud Control Plane.
The Tyk Gateway does not offer built-in features for specifically filtering or masking credit card data within the payload for PCI DSS 4.0 compliance. However, you can achieve this by utilizing Tyk pump to perform some basic filtering and masking, or by developing a custom analytics plugin to handle the required or more advanced data manipulation within the Tyk environment before it’s sent to Redis temporarily (the gateway does not write analytics data to disk or local storage but you can use pump for this).
You can use our example of masking a JSON login body analytics plugin as a starter to help you along your requirements. Or you can use Tyk Pump to move analytics to your own Business Intelligence platform (Splunk, Prometheus, ElasticSearch for example), and obfuscate cardholder data in that system. Tyk Pump enables you to configure an ignore_fields to prevent sensitive data from being logged in the analytics record.
@Olu - many thanks for the replay.
I have one more question, regarding tyk/test/goplugins/test_goplugin.go at master · TykTechnologies/tyk · GitHub
PCI data will be processed be approx 5% of our endpoints, is there any way to apply the masking to only data coming from them instead of processing everything (100% of payloads coming from all endpoints)?
If not, using API sharding and target PCI APIs to a dedicated API GW instances would help here ?
Thanks in advance for help
PCI data will be processed be approx 5% of our endpoints, is there any way to apply the masking to only data coming from them instead of processing everything (100% of payloads coming from all endpoints)?
What does 5% of your endpoints mean?
Do you mean sub-endpoints within the API definition, because the analytics plugin is scoped to the API definition and not the gateway globally?
If not, using API sharding and target PCI APIs to a dedicated API GW instances would help here ?
Thanks in advance for help
I think there might be some misunderstanding with how analytics plugins work. It might be easier if you setit up first.
