This content originally appeared as a whitepaper on InsideTrack. This three-part blog series will explore the advantages of going cloud native and offer tips for organizations that are ready to modernize their IT system. Part 1 is a discussion of the term “cloud native” and zero trust network architecture.
What is cloud native?
“Cloud native” is increasingly being used as a marketing term. But as Justin Garrison and Kris Nova point out, “It can still be meaningful for Engineering and Management.”1 Broadly, it assumes and likely depends upon public cloud infrastructure that didn’t exist a decade ago. Cloud native goes beyond simply copying legacy on-premise solutions in their current form into the cloud. Rather, it involves higher levels of abstractions with public cloud, scalability, and internet-hardened security as first-class priorities rather than afterthoughts. As the name implies, the solution is native to the cloud.
Cloud native vs. “in the cloud”
Unfortunately, simply lifting legacy anti-patterns into the cloud results in services that are nominally in the cloud but still have most, if not all, the weaknesses, vulnerabilities, and risks associated with legacy corporate IT infrastructure. How does an organization differentiate when evaluating SaaS? When researching providers, here are some common hallmarks to look for:
- Public API
- SSO as default
- Free tier, or “try before you buy” with self-registration
- Open documentation that doesn’t require login
- Not only monthly pricing but monthly billing allowing for cancellation anytime
- OS agnostic (including ChromeOS) or web-based client software
- Real-time collaboration
- Transparent history of incidents and outages
This blog series will review the mutually reinforcing advantages brought by cloud native patterns that diverge from traditional corporate IT infrastructure. This series will conclude with recommendations for getting started with a transformation to a cloud native architecture.
Zero trust network architecture
Traditional network and security center around trusted local networks that are ostensibly protected by perimeter defense, limiting inbound ports and inspecting inbound and outbound traffic. There is no assurance that the reported IP address in an IPv4 packet in fact came from that address, but it often completely obscures the actual originating IP. In other words, “You have no idea where that packet’s been.” It is still common to attempt a secure architecture that primarily allows and disallows traffic based on the IP address primarily at the perimeter. This made sense when IT was less mature, and securing and inspecting every connection to file servers, sensitive databases, and systems was uncommon and largely cost-prohibitive. The model was to build an intranet with all the resources needed locally, and safety behind a firewall was assumed. Even with the addition of defense in depth, end users’ laptops ultimately become possible vectors for a pivot behind the firewall if the machine is compromised by a malicious web page or email.
This perimeter defense in traditional network security is often referred to by security professionals as “hard on the outside, soft on the inside.” Even today there are zero-day exploits that remain open for months. This means that anyone with a little knowledge can compromise a workstation and thus pivot to attack other local resources using that compromised workstation.
A zero trust network architecture turns this concept on its head and assumes nothing. Access to resources is based upon mutual cryptographic authentication rather than the hope that an IP address that matches an internal office subnet is, in fact, the origin of the traffic. Rather than assuming trust and dangerously transmitting in cleartext far too often, communication is authenticated, authorized, and encrypted by default.
This approach not only facilitates security and flexibility but also recognizes the increasingly important role remote workers play across industries. In a zero trust environment it doesn’t matter whether an employee is in an office or traveling, whether at a coffee shop or at home. When the infrastructure supporting internal business processes assumes nothing and requires all connections to be authenticated and encrypted, all traffic is treated the same, untrusted until proven otherwise.
1Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment, by Justin Garrison and Kris Nova, O’Reilly, 2017, pp. 6.
Stay tuned for Part 2 of our blog series!