Close
Close

Modernize Your Payment System with Microservices: Part 4 – Security in Transition and Tackling Unique Challenges During Migration

Wednesday, Apr 03, 2024

Our most recent blog discussed the complexity and criticality of incorporating microservice design principles to mitigate and safeguard against prolonged downtimes and potential financial risks. In this 4th installment of our Legacy Migration Series, we focus on the pivotal aspect of Security. As organizations transition from monolithic systems to microservices, they encounter unique challenges. Join us as we dissect the intricacies of securing this dynamic landscape.

This is doubly challenging as microservices are often deployed to the cloud while monoliths remain hosted on-premises. Your security architecture needs to encompass both. Additionally, microservice instances are plentiful and may communicate with each other, the monolith, and other services. This should be secured yet remain flexible enough to allow controlled growth and evolution.

Problem Areas

  • Data Migration: When migrating data from the monolith to microservices it is important to ensure that it is secured in transport and secured at rest. Often data migration involves moving on-premises data stores to the cloud. A secure channel for transport is a given but equal consideration must be devoted to securing temporary data stores and any cloud-based data transformation processes.
  • Service Communication: Services need to communicate with each other, either within the same system or across different systems. This can expose the services to attacks, like impersonation, replay, or injection. Securing communication channels reduces the attack surface and raises the bar for malicious actors.
  • Version management: Services may be running different versions of the code, due to the independent development and deployment of microservices. If not managed correctly, applying security patches becomes difficult and hodge podge at best. As a result, some microservices may run with known vulnerabilities.

Why do we need to How to Address the Security Challenges Effectively? Security Challenges?

To effectively address security challenges, payment systems should adhere to established best practices and employ effective techniques.

  • Data encryption: Ensure that all data in transit and at rest is encrypted using modern standards. This applies to both monolithic systems and microservices.

During data migration, temporary data stores should be encrypted and only decryptable by migration tools. Depending on the type of data, you may need to go beyond default cloud provided at rest encryption options. Once migrated, temporary data stores should be purged.

In hybrid cloud / on-prem deployments use consistent encryption practices across environments. Encryption keys should be managed securely and periodically rotated. Consider hardware security modules (HSMs) for added protection.

The effectiveness of encryption relies on strong access controls, regular audits and following updated security practices.

  • Service authentication: Access to services should be Authenticated and Authorized either within the same system or across different systems. There are many options for AuthN and AuthZ and many standards and solutions. e.g.: mTLS, Access tokens, or OAuth. Avoid re-inventing the wheel when it comes to security. Preference should be given to established products or frameworks that follow industry standards.

    Ingress: Ingress to your microservices should be limited to secured channels and should be Authenticated and Authorized. Incoming requests should pass through multiple layers of security (WAF, DDOS, Rate Limiting, Auth, etc.) and via a common entry point, like a CDN or API gateway. This will reduce the number of public entry points to your system reducing your attack surface while also providing a common security plane for ease of management and monitoring.

    Egress:  Likewise, egress should be secured and limited. Outgoing communications should be limited to known secure channels. Arbitrary outgoing requests should be prohibited. Consider locking down your internal network and require all outgoing traffic to use a proxy. If a malicious actor gains access, do not let them out.

    Egress to existing systems: Connectivity between clouds or on-prem systems should use secured dedicated channels rather than the open internet. Consider solutions like MPLS or VPN tunnels. MPLS dedicated circuits are preferred. They are reliable and are high bandwidth but come with a higher price tag.

    Often egress requests are requests back to the monolith. Like all egress, this should be performed over secure channels and follow Auth standards. Extra effort may be required to map monolith sessions to microservice Auth / context.

    Inter-service communication: Interservice communication is often required but should be employed only when necessary.  When required, Microservice-to-Microservice comms should be limited. A Microservice should not be allowed to communicate with arbitrary Microservices, it should be restricted to just those it needs to communicate with (Principle of Least Privilege).

    Consider a Service Mesh solution to manage and secure your microservices. This limits the spread or damage from a compromised component and provides ease of management and scaling via a common control plane.

To effectively address security challenges, payment systems should adhere to established best practices and employ effective techniques.

  • Data encryption: Ensure that all data in transit and at rest is encrypted using modern standards. This applies to both monolithic systems and microservices.

During data migration, temporary data stores should be encrypted and only decryptable by migration tools. Depending on the type of data, you may need to go beyond default cloud provided at rest encryption options. Once migrated, temporary data stores should be purged.

In hybrid cloud / on-prem deployments use consistent encryption practices across environments. Encryption keys should be managed securely and periodically rotated. Consider hardware security modules (HSMs) for added protection.

The effectiveness of encryption relies on strong access controls, regular audits and following updated security practices.

  • Service authentication: Access to services should be Authenticated and Authorized either within the same system or across different systems. There are many options for AuthN and AuthZ and many standards and solutions. e.g.: mTLS, Access tokens, or OAuth. Avoid re-inventing the wheel when it comes to security. Preference should be given to established products or frameworks that follow industry standards.

    Ingress: Ingress to your microservices should be limited to secured channels and should be Authenticated and Authorized. Incoming requests should pass through multiple layers of security (WAF, DDOS, Rate Limiting, Auth, etc.) and via a common entry point, like a CDN or API gateway. This will reduce the number of public entry points to your system reducing your attack surface while also providing a common security plane for ease of management and monitoring.

    Egress:  Likewise, egress should be secured and limited. Outgoing communications should be limited to known secure channels. Arbitrary outgoing requests should be prohibited. Consider locking down your internal network and require all outgoing traffic to use a proxy. If a malicious actor gains access, do not let them out.

    Egress to existing systems: Connectivity between clouds or on-prem systems should use secured dedicated channels rather than the open internet. Consider solutions like MPLS or VPN tunnels. MPLS dedicated circuits are preferred. They are reliable and are high bandwidth but come with a higher price tag.

    Often egress requests are requests back to the monolith. Like all egress, this should be performed over secure channels and follow Auth standards. Extra effort may be required to map monolith sessions to microservice Auth / context.

    Interservice communication: Interservice communication is often required but should be employed only when necessary.  When required, Microservice-to-Microservice comms should be limited. A Microservice should not be allowed to communicate with arbitrary Microservices, it should be restricted to just those it needs to communicate with (Principle of Least Privilege).

    Consider a Service Mesh solution to manage and secure your microservices. This limits the spread or damage from a compromised component and provides ease of management and scaling via a common control plane.
  • Single Control Plane and Monitoring: As a best practice, a single control plane (that includes monitoring) provides a consistent experience which can increase oversight and rapid control over all microservices. If a microservice is compromised or is misbehaving, it can be quickly identified and isolated.
  • Regular Technical Hygiene: Regular processes and practices should be tweaked and applied to microservices. This includes standard development practices like code reviews, code scans, build and release pipelines. Security starts in code.

    Maintain and track library versions, update, and release regularly, create a malleable codebase rather than a brittle one.

    Additionally, regular penetration testing of your microservices should be performed. Pen tests validate your security controls.

  • Version Management: Ensuring your monolith is up to date with the latest code and libraries is a challenging task. Microservices can help alleviate the pain by segmenting your monolith into smaller pieces which can be upgraded and deployed in isolation. The downside is that multiple Microservices may use the same library, resulting in updates to the same library in many places.

    Since microservices are individually deployable, they should be deployed more frequently and with more confidence. This applies to library updates.

    Like all good practices, dependency updates should be part of your regular development and deployment routines. Teams should be empowered to introduce library updates with code updates. Consider adding library upgrade checkpoints to your development and release processes along with modern dependency management tools to your build pipelines (e.g.: Artifactory or Nexus).

    Utilization of blue green or canary deployment strategies to gain further confidence during rollouts.

    For microservices that are infrequently updated consider periodic security reviews and library update releases.

Closing Thoughts

Security should be top of mind for any system and the transition from monolith to microservices is no exception. Microservices present their own unique security challenges and can expose existing gaps in your on-prem systems. Addressing these concerns in a unified manner will ensure that you are on the right path to a modernized future, one that is protected from modern attacks and vulnerabilities.

In our next installment of the Legacy Migration blog series, we will examine Modernization Frameworks and how they benefit your modernization journey through efficiencies and decreased dependencies. Thank you for reading and we invite you to follow Level19 for more great content!