BankNext Case Study - GDPR challenges solved with SpringCloudGateway

SpringCloudGateway to tactfully solve the PII/PCI/GDPR challenge.

Problem Statement

BankNext is committed to be fully GDPR/PII/PCI compliant but this comes at a very high cost. The intricacies of individually adapting 300+ live production microservices appears unsurmountable. Moreover, the strict constrained timelines & massive testing effort makes this perplex exercise, financially draining. To avoid the heavy non compliance penalties, Banknext needs a practical solution & it needs it fast.

Business Scenario

1. GDPR/PII/PCI mandates that sensitive data fields should be masked.
2. If used in plain text, then additional strenuous procedures are mandated.
3. Every instance of non compliance imposes heavy financial penalties.
4. All request & responses w/ sensitive data fields need modification.
4. Every msvc w/ sensitive data needs this adaptation individually.
5. There is no centralized way to ease this massive undertaking.
6. Manpower, timelines & money required for this approach is colossal.
7. Penalties are piling. Business is Hyperventilating.
8. Houston, we have a problem!

Challenges w/ Current Architecture : Concrete Scenario

1. Viewer msvc calls Payments & Customers msvcs.
2. Payments msvc send PCI sensitive fields in the response.
3. Customers msvc send PII sensitive fields in the response.
4. Viewer msvc must mask these sensitive fields for GDPR compliance.
5. There are many such viewers & source msvcs w/ sensitive data exposure.
6. Individually adapting each of these 300+ msvcs is the not practical.
7. Also GDPR can add more fields to the sensitive fields list in the future.
8. Istio-servicemesh-sidecar was a good solution but requires K8s expertise.

Capabilities w/ New Architecture : Target State

1. Configuration driven solution w/ futureproof flexibility.
2. Centralized routing to seamlessly handle inter msvcs communications.
3. Customized sensitive fields handling of incoming & outgoing traffic.
4. Selective interception of affected msvcs only.
5. Ensure that existing msvcs remain unaffected.
6. Light weight & extensible w/ miniscule latency add.

Solution w/ SpringCloudGateway [SCG] : Final State

SpringCloudGateway GDPR Architecture

1. GitHub : SpringCloudGateway-to-accomplish-GDPR-compliance
2. Single & uniform endpoint host for all msvcs.
3. Routing & interactions is configuration driven w/ application.yml.
4. Externalize selected msvcs handling w/ simple SCG routes config.
5. Incoming & outgoing traffic handled w/ predefined SCG filters.
6. Non blocking architecture ensures rapid processing/high throughput.
7. Future proof flexibility achieved w/ new filter additions.
8. No code change required in existing msvcs.
9. Configuration : application.yml

spring:
  cloud:
    gateway:
      routes:
      - id: payments-aggregate
        uri: http://localhost:8081/  <--2.then route to msvc running on this port
        predicates:
        - Path=/payments/aggregator  <--1.if incoming URL has this string
        filters:
        - MaskSensitiveResponse=x,y  <--3.and apply this filter logic to the req/response

10. Filter : MaskSensitiveResponseGatewayFilterFactory.java

@Component
public class MaskSensitiveResponseGatewayFilterFactory extends AbstractGatewayFilterFactory<Config> {

    final Logger logger = LoggerFactory.getLogger(MaskSensitiveResponseGatewayFilterFactory.class);
    private ModifyResponseBodyGatewayFilterFactory modifyResponseBodyFilterFactory;

    public MaskSensitiveResponseGatewayFilterFactory(ModifyResponseBodyGatewayFilterFactory modifyResponseBodyFilterFactory) {
        super(Config.class);
        this.modifyResponseBodyFilterFactory = modifyResponseBodyFilterFactory;
    }
    
    @Override
    public List<String> shortcutFieldOrder() {
        return Arrays.asList("fields", "replacement");
    }


    @Override
    public GatewayFilter apply(Config config) {
        
        return modifyResponseBodyFilterFactory
          .apply(c -> c.setRewriteFunction(JsonNode.class, JsonNode.class, new MaskFields(config)));
    }
}

11. Your Custom Masking Logic : MaskFields.java

   public class MaskFields implements RewriteFunction<JsonNode,JsonNode> {
        private final Pattern fields;
        private final String replacement;
                
        public MaskFields(Config config) {
            this.fields = Pattern.compile(config.getFields());
            this.replacement = config.getReplacement();
        }

        @Override
        public Publisher<JsonNode> apply(ServerWebExchange t, JsonNode u) {
         
            return Mono.just(readRecursively(u));
        }

        private JsonNode readRecursively(JsonNode u) 
        {
            if ( !u.isContainerNode()) {
                return u;
            }
            
            if ( u.isObject()) {
                ObjectNode node = (ObjectNode)u;
                node.fields().forEachRemaining((f) -> 
                 {
                  handleSensitive(f);          //custom field list to mask - helps externalize

Solution Demo

Results - Before & After

SCG config driven auto mask PCI sensitive fields

SCG config driven auto mask PII sensitive fields

Conclusion -

1. BankNext solved the GDPR problem w/ SpringCloudGateway.
2. Accomplished the goal within the strict time + money constraints.
3. Employed configuration driven approach for flexibility + extensibility.
4. No code change was required in the existing msvcs.
5. SCG solution seamlessly caters to any future GDPR mandates easily.