Zero-Trust Security — Part 2: Getting Started with Zero-Trust Security

By Raghav K.

In Part 1 of this series, I gave an overview of zero-trust security architecture. The cloud-native architecture has responded to industry demands for software delivery implementation that automates and channels builds to release and helps with management. Containerization is the answer. Kubernetes with cloud-native architecture has led to a significant shift for organizations adopting the cloud-native approach to build business applications.

The concepts of DevOps also lacked a total end-to-end security solution that had a significant impact on services. DevSecOps was introduced to overcome the security shortcomings of DevOps. In Part 3 of this series, I will explain the concepts of applying zero-trust security with cloud-native microservices and Kubernetes.

The zero-trust security architecture offers robust user authentication and device authorization practices for continued access to the system. This access system does not automatically trust any user, agent, or device whether inside or outside the system. The zero-trust security model does not work on a structure that grants access over the network if the user or device’s IP address is in the trusted network channel. Instead, every access request from any medium must be authenticated and authorized.

Technology Usage With Zero-Trust Security Architecture

The zero-trust security model uses the existing systems (like Alibaba Cloud Resource and Access Management (RAM)) or solutions (like Identity as a Service (IDaaS)) to verify identities before granting access. The zero-trust security model uses most of the same security protocols and services, including multi-factor authentication, orchestration, analytics engine, data encryption, and control policies.

The only difference is that the governance over an entire system is led by and not filtered out using trust policies. There are no trust policies, there are only authorized and unauthorized. The zero-trust architecture also implements the least amount of access required policy. This policy says access will only be assigned using factors like time bound access and specific system access.

Implementing Zero-Trust Security

The number of devices and the technologies behind them are increasing ten-folds every few years. The Internet of Things (IoT) and the Internet of Everything (IoE) are prime examples. Implementing the zero-trust security architecture is different from implementing Identity and Access Management products. These products have been in the industry for a while. Implementing the zero-trust security architecture is about strategizing a better way of implementing security that is more effective using a previous set of products.

Implementing a Zero-Trust Security Practice Step-by-Step

  • Assess your system to identify which areas need the most security measures. This should include the types of applications, the access zones, and the cross-communication between cloud resources.

What to Expect

Security is unlike any other system you upgrade or change within your enterprise. The same way DevOps brings a culture change within an organization and requires automation to attain optimal continuous integration and delivery cycles, zero-trust security architecture also requires a cultural shift.

This cultural shift will require decommissioning traditional practices altogether and introducing a significant pattern shift to how security is implemented within an organization. If your organization is considerably large with multiples nodes working across multiple regions, you will face complexities. While these complexities are initially mind-boggling, the benefits that you will leverage will be significantly more.

A Pinch of Familiarity

The zero-trust security model is similar to some things we have used for years:

1. The Access Control Lists (ACL)

An ACL is a list that contains rules that grant or deny access to environments.

2. Principles of Least Privilege

The principle of least privilege only grants the amount of access that is required to complete a task. The principle states, if the subject does not need access, it should not have access.

3. Role-Based Access Control

This access control mechanism is a direct approach to restrict access based on the assigned roles and their associated permissions. This is useful when you have defined specific organizational roles to fathom the width of your solution.

All of these concepts can be the starting point for a zero-trust security practice. However, zero-trust security architecture has more value, security, and authorization compared to the concepts mentioned above:

  • The zero-trust security model does not allow the assignment of multiple roles and permissions for a single subject (user, device, or application.)

In the End — What Matters?

Implementing the zero-trust security architecture while designing solutions using the cloud-native architecture will enable a safe and secure working environment for your applications to yield maximum productivity.

In Part 3 of this series, I will explain scenarios where you can implement zero-trust security with your cloud-native microservices and containers.

Upcoming Articles

  1. Zero-Trust Security — Part 3: Zero-Trust Security With Cloud-Native Microservices and Containers

Original Source:

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store