Zero trust in the cloud: Best practices and potential pitfalls

Architecturally speaking, cloud-native applications are broken down into smaller components that are highly dynamic, distributed, and ephemeral. Because each of these components is communicating with other components inside or outside the cluster, this architecture introduces new attack vectors that are difficult to protect against using a traditional perimeter-based approach. A prudent way to secure cloud-native applications is to find a way to reduce the number of attack vectors, and this is where the principles of zero trust come into play.

With today’s multi-cloud and hybrid-cloud environments, networks are no longer restricted to a clear perimeter with clearly defined borders to defend—and cyber criminals are taking advantage of this fact by tricking users and systems into providing unauthorized access. While a lot of zero trust is focused on limiting access from users and devices, organizations are now also recognizing that in the world of distributed cloud-native applications, workloads themselves are communicating with each other and the same principles of zero trust need to be extended to cloud-native applications.

Because traditional security methods such as network firewalls rely on fixed network addresses, they are insufficient to protect dynamic, distributed, and ephemeral cloud-native workloads, which do not have fixed network addresses. They simply cannot specify access controls at a granular workload level, which is essential for cloud-native application security and compliance. Zero trust is a better security posture because the attack surface of cloud-native applications is so large it’s difficult to secure.

With this in mind, let’s look at some zero trust implementation best practices, and potential pitfalls.

Best practices for implementing zero trust

While there are many ways to implement zero trust in the cloud, I see the following as top best practices for implementing zero trust for your workloads.

Best practices for workloads

• Zero trust workload access controls – Implement zero trust workload access controls to control the flow of data between individual workload components and external resources including databases, internal applications, 3rd-party cloud APIs, and SaaS applications. You should enforce controls using DNS egress policies, use IPs/CIDRs in network policy for access control, and enable network firewalls to identify and secure cloud-native workloads.
• Microsegmentation – Implement zero trust access using identity-aware microsegmentation to divide workloads into distinct security segments, and then define granular security controls for each segment. Microsegmentation is critical as it allows you to isolate workloads based on environments, application tiers, compliance needs, user access, and individual workload requirements.
• Least privilege access controls – It’s important to deny all traffic by default and only allow connections that have been authorized. This applies to traffic between microservices as well as ingress and egress outside the cluster.
• Encryption – Encrypt sensitive data so that no matter where a threat originates, the data is unreadable to anyone except the legitimate keyholder. I recommend implementing data-in-transit encryption using a tool like WireGuard.
• Defense in depth – Monitor and log all changes to policies, including the version history. Make sure you use a tool that alerts you when a policy that implements your security controls changes, and shows exactly what changed and how.
• Monitor and audit – All traffic on a zero trust network must be carefully monitored and subject to regular audits. Pay more attention to privileged roles and access to critical or sensitive assets. Aim to catch suspicious activity immediately when it happens, and if you don’t, you should identify it on the next audit review.
• Use attribute-based controls – Ensure controls are as granular as possible, taking into consideration attributes of the user, device, workload, target application, and the task at hand. This will ensure policies can effectively limit access and block malicious activity.

Potential pitfalls

While there is a lot of focus on zero trust network access (ZTNA), many organizations ultimately forget that the definition of a network itself has changed substantially in the world of cloud-native architectures. In fact, I would go so far as to say that the traditional network no longer exists in the cloud. So if you’re applying zero trust controls via network firewalls or network-based WAF, you are leaving a large portion of your workloads unsecured and vulnerable. That’s why zero trust needs to be extended all the way to individual workloads in order to protect against attacks.

But you shouldn’t stop at extending zero trust to workloads to control access for users and devices—applications themselves are also communicating with other applications. So unless you implement the same principles of zero trust at the application level (e.g. specify in your DNS policy that a particular microservice can communicate with a particular website or 3rd-party API), your workloads could be compromised. By using a workload’s identity to allow/deny communication, organizations can implement zero trust security measures to secure communication between workloads.

Check out this free zero trust maturity assessment tool to see how you’re doing with your zero-trust security posture for cloud-native workloads