Home / Blogs

Cloud Security Hinges on IP Addressing

Juha Holkkola

In the first part of this trilogy, I discussed the importance of automatically provisioned second generation DNS in connection with Software Defined Networking (SDN) and Software Defined Data Centre (SDDC). In the second post, I talked about IP addressing, private enterprise networks, and how DHCP does not meet the requirements of multitenant Infrastructure-as-a-Service (IaaS) cloud environments. I will now wrap up this trilogy by putting these two thesis into real-life context.

Over the last 10 years, the principle of security by design has been gaining popularity within software engineering. This concept should also be incorporated into the SDDC and cloud architectures, to ensure that organizations leveraging the promise of cloud computing will not be compromised for their forward looking thinking.

I guess it would be fair to say that perimeter security is currently the most widely used protection for IT infrastructure. By implementing firewalls, VPNs, intrusion prevention, attack detection and the like, it has been possible to deploy reasonably secure private computing environments. To complement the perimeter security, most organizations are taking further measures inside their enterprise networks, to make sure that threats are promptly detected and dealt with.

With all this in mind, it is no wonder that information security professionals are skeptic about public and hybrid clouding models. After all, both introduce a number of new attack vectors into the secured environments. But what if the hybrid cloud did not require communication with applications and servers running in the public Internet, but rather involved an architecture that was secure by design?

The problem with most IaaS cloud offerings out there today is that their hybrid offering usually relies on public IP addresses. The customers are expected to network to the extra capacity over the Internet. While this may be an easy solution for an IaaS cloud provider leveraging standard cloud stacks and DHCP, the publicly routed IP addresses assigned to the workloads introduce a new attack vector to the end-user's private network environment.

The simplest way to overcome this security issue is to create a secure tunnel between the IaaS cloud and its end-users' enterprise networks, and to assign every single workload an IP address that matched with the IP addressing scheme used in end-users' private networks. While Cisco says that VXLAN is intended for intra data center connectivity only, for example VPN could be used for tunneling just as well.

This straightforward solution brings about two major benefits. First, since the IP addresses in the IaaS cloud are part of every end-user's own IP addressing scheme, the hosts will have no trouble networking between the cloud and the enterprise network back home. Second, if the VLANs in which the workloads are deployed are not routed to the public Internet at all, they will be less prone to various security threats lurking there.

When an IP addressing model described above is merged with a dynamic DNS provisioning engine, the outcome becomes extremely powerful. After all, what organization would not want to tap into is the economics of an IaaS cloud, knowing that it was as secure as their enterprise network. This proposition becomes even more compelling when the workloads have names and IP addresses that match with end-users' own enterprise networks, making the IaaS cloud a transparent extension of one's own computing resources.

In the context of orchestrated cloud application deployment, the technologies I've outlined in this trilogy are generally related to release parameters. So rather than talking about DHCP, IP addressing or DNS as isolated technologies, I argue that they should be merged into automated and holistic Release Parameter Provisioning (RPP). More importantly, rather than trying to make cloud orchestration solutions perform tasks they are not good at, I claim that RPP merits its own layer in the SDDC and cloud stacks, functioning as a neat bridge between the SDN and the cloud orchestration layers.

By Juha Holkkola, Managing Director of Nixu Software. More blog posts from Juha Holkkola can also be read here.

Related topics: Cloud Computing, Data Center, DNS, IP Addressing, Security

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Nominum Announces Future Ready DNS

New from Verisign Labs - Measuring Privacy Disclosures in URL Query Strings

DotConnectAfrica Delegates Attend the Kenya Internet Governance Forum

3 Questions to Ask Your DNS Host about Lowering DDoS Risks

Continuing to Work in the Public Interest

Verisign Named to the OTA's 2014 Online Trust Honor Roll

4 Minutes Vs. 4 Hours: A Responder Explains Emergency DDoS Mitigation

Dyn Acquires Internet Intelligence Company, Renesys

Tips to Address New FFIEC DDoS Requirements

Smokescreening: Data Theft Makes DDoS More Dangerous

Introducing getdns: a Modern, Extensible, Open Source API for the DNS

Why We Decided to Stop Offering Free Accounts

dotStrategy Selects Neustar's Registry Threat Mitigation Services for .BUZZ Registry

Tony Kirsch Announced As Head of Global Consulting of ARI Registry Services

24 Million Home Routers Expose ISPs to Massive DNS-Based DDoS Attacks

Dyn Acquires Managed DNS Provider Nettica

What Does a DDoS Attack Look Like? (Watch First 3 Minutes of an Actual Attack)

Joining Forces to Advance Protection Against Growing Diversity of DDoS Attacks

Why Managed DNS Means Secure DNS

SPECIAL: Video Interviews from NamesCon 2014 in Las Vegas

Sponsored Topics