Transitioning to microservices with sensitive data at stake. How will you ensure its security?

One of the main pitfalls when transitioning from a monolithic application to microservices is trust. Great care should be taken when designing the trust boundaries between the different micro-applications, and ideally Zero Trust should be used instead. This, however, leads to a substantial overhead and complexity increase for each application, and increases the chances that someone breaks the design during the implementation phase due to time constraints. Centralising the Identity and Access Management (IAM) and using modern standards (OIDC, OPA...) alleviates the implementation pressure on each individual application whilst also improving the overall security posture.

Whether to use microservices or monoliths is more of a use case based decision, so design wisely. If you decide microservices is the better solution for your case, then following the below would be beneficial- *Designing applications with secure by design principles will help avoid many security issues that could crop up later on. *PoLP(principle of least privilege) giving access to only what is needed. *Authentication & Authorization mechanisms which will help prevent unauthorized access to sensitive data.

Encrypting data is a no-brainer, especially when dealing with sensitive info. I make sure data is encrypted both at rest and in transit. For data at rest, I use strong encryption standards like AES-256. For data in transit, TLS is our go-to for securing communication channels between services. Managing encryption keys securely is also crucial, so we use a key management system that restricts access and keeps track of key usage. This way, even if someone intercepts the data, it’s just gibberish without the right keys.

The key (pun intended) issue with enabling and using encryption, whether at rest or in transit, is how to store and manage the secret keys. Choosing a centralised tool to achieve this leads to much greater efficiency and will reduce the likelihood of losing the keys. Assuming a cloud environment, most cloud providers have some form of secrets vault, and it is often best to stick with them. However, especially in multi-cloud environments, it might also be worth taking a look at open-source alternatives, either self-hosted or SaaS.

Separating between audit logs and non-audit logs is often a good idea. Audit logs often contain PII, which should be protected in line with relevant legislation (GDPR, HIPAA...), and should be protected against tampering in order to be forensically receivable (e.g. immutable databases). Non-audit logs should still be adequately protected, but don't have the same stringent requirements and need to allow a greater degree of accessibility for debugging purposes. One way of achieving all of this is to aggregate incoming logs from an application, and forward the logs in 2 separate streams: - One where PII has been filtered away, to the non-audit logs system - Another, unfiltered, to the audit logs system

It is important to ensure your microservices architecture complies with relevant data protection regulations like GDPR or HIPAA. This isn’t just about ticking boxes—it’s about handling data responsibly and legally. It is important to provide users with control over their data, ensure data portability, and promptly report breaches. Regularly reviewing your compliance posture and adjusting your architecture as needed keeps organisations in line with these obligations. Compliance is about building trust with users, not just avoiding penalties.