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. Visit the blog maintained by Juha Holkkola 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

IP Geolocation: Four Reasons It Beats the Alternatives

A Look at Traffic Management for External "Cloud" Load Balancing

Dyn Acquires Mobile Dashboard App Trendslide

Dyn Research: Where Do Companies Host Their Websites?

Hope is Not a Strategy: Neustar Releases 2012 Annual DDoS Attack and Impact Survey

Dyn Adds Tech Company Leader Michael Boustridge To Board of Directors

How Neustar Technology Can Help Mitigate DDoS Attacks

CentralNic Powers First New Top-Level Domains Announced by ICANN

DCA Registry Services Participates in ICANN Africa Strategy Meeting, Addis Ababa

Reducing the Risks of BYOD with Nominum's Security Solution

Neustar Launches Enterprise Professional Services Offerings

Dyn Adds Claudia Santoro, Dave Connors and Andrew Sullivan to Technical Team

Dyn Acquires Website Monitoring Startup Verelo

Why Website Downtime Is Amateur Hour

Nominum Releases New Security Intelligence Application

Mitigating DDoS Attacks: A Global Challenge

New Nixu NameSurfer 7.3 Series Powers the Software-Defined Data Centre

Our New Initiatives To Combat Botnets

Recent Trends and Options to Mitigate DDoS Attacks (Webcast)

PIR Survey Reveals That Most Americans Are Uninformed About DDoS Attacks

Sponsored Topics

dotMobi

Mobile

Sponsored by
dotMobi
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
Neustar

DNS

Sponsored by
Neustar
Afilias

DNS Security

Sponsored by
Afilias