Rational Survivability

Mary Jo Foley asked the question in her blog titled: ‘Private cloud’ = just another buzzword for on-premise datacenter?

What’s really funny is that she’s not really asking.  She’s already made her mind up:

Whether or not they admit it publicly (or just express their misgivings relatively privately), Microsoft officials know the “private cloud” is just the newest way of talking about an on-premise datacenter. Sure, it’s not exactly the same mainframe-centric datacenter IT admins may have found themselves outfitting a few years ago. But, in a nutshell, server + virtualization technology + integrated security/management/billing  = private cloud.

Microsoft’s “official” description of the distinction between private and public clouds basically says as much. From a press release the company issued this morning:

The private cloud: “By employing techniques like virtualization, automated management, and utility-billing models, IT managers can evolve the internal datacenter into a ‘private cloud’ that offers many of the performance, scalability, and cost-saving benefits associated with public clouds. Microsoft provides the foundation for private clouds with infrastructure solutions to match a range of customer sizes, needs and geographies.

The public cloud: “Cloud computing is expanding the traditional web-hosting model to a point where enterprises are able to off-load commodity applications to third-party service providers (hosters) and, in the near future, the Microsoft Azure Services Platform. Using Microsoft infrastructure software and Web-based applications, the public cloud allows companies to move applications between private and public clouds.”

Firstly, Microsoft defines their notion of Public and Private Clouds based upon the limits of their product offerings.  In their terms, Private Clouds = Hyper-V, Public Clouds = Azure.  Never the two shall meet. So using these definitions, sure, Private Clouds are just “on-premise datacenters.”  She ought to know.  She wrote about it here and I responded in a post titled “Incomplete Thought: Looking At An “Open & Interoperable Cloud” Through Azure-Colored Glasses”

Private Clouds aren’t just virtualized datacenters with chargeback/billing.

As I’ve said here many, many times, this sort of definition is short-sighted, inaccurate and limiting:

Private Clouds: Even A Blind Squirrel Finds A Nut Once In A While
The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don’t Work…
Internal v. External/Private v. Public/On-Premise v. Off- Premise: It’s all Cloud But How You Get There Is Important.
Private Clouds: Your Definition Sucks
Mixing Metaphors: Private Clouds Aren’t Defined By Their Location…

Can we stop butchering this term now, please?

So no, Private Cloud is NOT just a euphemism for on-premise datacenters.

/Hoff

I’ve said it before and I’ll say it again: SaaS is not the definition of Cloud Computing.  It’s one element of Cloud Computing.  In the same vein, when you mention “Cloud Security,” it means more than the security features integrated by a SaaS provider to protect their stack.  Oh, it’s an interesting discussion point, but Google and SalesForce.com are not the end-all, be-all of “Cloud Security.”  Unfortunately, they are the face of Cloud Security these days.  Read on as I explain why.

Almost every webinar, presentation and panel I’ve seen in the last six months that promises to discuss “Security Services in the Cloud” usually ends up actually focused on three things:

1. Managed security services (on-premises or off-premises) of traditional security capabilities/solutions, re-branded as Cloud offerings and
2. Managed services utilizing a SaaS model for one or more security functions, re-branded as Cloud offerings
3. A hybrid model involving both managed services of devices/policies and one or more hosted applications (nee SaaS) re-branded as Cloud offerings

Let’s take a look at what these use cases really mean within the context of Cloud Computing.

Managed security services (on-premises or off-premises) of traditional security capabilities/solutions:
Basically, these services are the same old managed services you’ve seen forever with the word “Cloud” stuck somewhere in the description for marketing purposes.
An example is a provider has NOCs/SOCs and manages security infrastructure on your behalf.  This equipment and software can be located on your premises or externally
and because it’s Internet connected, it’s now magically Cloud based.  These services have nothing to do with protecting Cloud-based services, but rather they suggest that
they *use* the Cloud to deliver service.

Managed security services utilizing a SaaS model for one or more security functions:
Any managed services provider who uses a SaaS stack to process information on behalf of their customers via the Internet is re-branding to say they are Cloud based.
The same is true from a security perspective.  Anti-spam, anti-virus, DDoS, URL filtering services, vulnerability management,  etc. are all game. From Google’s Postini
to OpenDNS’ services to Qualys’ vulnerability management, we’re seeing the rampant use of Cloud in these marketing efforts.  Further, vendors who offer
some sort of Cloud-based service that has integrated security functionality (as it should) claim to offer “Cloud Security.”  In all of these cases, scaling is traditionally
done at the software layer and is generally hidden from the customer and how the service scales isn’t usually based on Cloud Computing capabilities at all.

The Hybrid Model
Some providers offer a combination of managed on/off-premise security devices used in conjunction with SaaS offerings to broaden the solution.  There are any number
of MSSP’s who have an Internet-based portal (via VPN) and an on- or off-premise set of capabilities involving appliances and SaaS to deliver some combination of service.
This model can extend to fixed or mobile computing services where things like Clean Pipes are provided.

The challenge is trying to understand how, where and why the word “Cloud” ought to be applied to these services.  Now I want to be clear that there’s nothing particularly “wrong” with branding these services as “Cloud” except for the following:

If you look at the definition of Cloud (at least mine,) it involves the following:

• Abstraction of Infrastructure
• Resource Democratization
• Services Oriented
• Elasticity/Dynamism
• Utility Model Of Consumption & Allocation

In the case of security solutions which are generally based on static allocation of resources, static policies, application controls built into an application and in many cases dedicated physical appliances (or fixed-utilization shared virtualized instances,) customers can’t log into a control panel and spin up another firewall, IDP or WAF on-demand. In some cases, they don’t even know these resources exist.  Some might argue that is a good thing.  I’m not debating the efficacy of these solutions, but rather how they are put forward.

Also important is that customers don’t get to pay for only the resources used for the same reasons.

So whilst many services/solutions may virtualize the network stack or even policy, the abstraction of infrastructure from resources and resource democratization get a little fuzzy definitionally.  That’s a minor point, really.

What’s really interesting is the two items I highlighted in boldfaced: Elasticity and the utility model of consumption and allocation.  Traditional security capabilities such as firewalls, IDP, A/V, etc. are generally implemented on physical appliances/networking equipment which from a provisioning and orchestration perspective don’t really subscribe to either the notion of self-administered elasticity or the utility model of consumption/allocation whereby the customer is charged only for what they use.

To me, if your Cloud Security solution does not provide for all of these definitional elements of Cloud, it’s intellectually dishonest (the definition of marketing? 😉 to call it “Cloud Security.”

This is important because “security” is being thought of from the perspective of SaaS or IaaS and each of these models have divergent provisioning, orchestration and management methods that don’t really jive with multi-tenant Cloud models for security.*  As it turns out, the most visible and vocal providers of application services are really the ones peddling “secure cloud” to serve their own messaging needs and so in SaaS stacks, the bundled security integrated into the application is usually a no-cost item.  In other models, it *is* the service that one pays for.

I’ve talked about this quite a bit in my Frogs presentation in which I demonstrate how the lower down the stack provider stops (from SaaS down to Iaas,) the more security a customer is generally still responsible for — or that of a provider.  Much of this is due to the lack of scale in security technology today and static policies with a network disconnected from context and state and unaware of the dynamism of the layers above it:

Without invoking the grumpy-magic-anachronism-damage +4 spell, I am compelled to mention the following.

Back in 1995 I architected one of the world’s first global managed security services using a combination of multi-layered VPNs from across the globe to a set of four regional Internet gateways through which all Internet traffic was tunneled. We manually scaled each set of dedicated clustered firewalls for each customer based on load.  We didn’t even have centralized management for all these firewalls at the time (Provider-1 and VSX weren’t born yet — we helped in their birth) so everything was pretty much a manual process.  This was better than managing CPE devices and allowed us to add features/functions centrally…you know, like the “Cloud.” 😉

Not much has changed with managed security services and their models today.  While they have better centralized management, virtualized policy and even container-based virtual security functions, but we’re still stuck with mostly manually provisioning and a complete disconnect of the security policies from the network and virtualization layers.  Scale is not dynamic.  Neither is pricing.

At the end of the day, from a managed security perspective, be wary of claims of “Cloud Security” and what it means to you.

/Hoff

*This is one of the compelling elements of converged/unified compute fabrics; the ability to tie all the elements together and focus on consistent policy enforcement up and down the stack but for managed security providers, this will take years to make its way into their networks as the revenue models and cost structures for most MSSP’s are simply not aligned with virtualization platform providers.  Perhaps we’ll see a bigger uptake of OSS virtualization platforms in order to deliver these converged services.

Two years ago VMware announced their intention to develop and release a set of capabilities which would provide a more resilient and secure hypervisor while also extending a set of API’s to a limited number of vetted third-party security ISV’s.

These APIs were designed to regain visibility and add capabilities such as virtual introspection across compute, network and storage realms in order to solve some really difficult issues that I’ve spoken about extensively in my Four Horsemen of the Virtualization Security Apocalypse talks.

The reality is that VMsafe required two very important things to happen before it could see the light of day:

1. A new version of VMware platform with a substantial overhaul of virtual networking capabilities and
2. New versions of every ISV’s products who wish to take advantage of the API’s

Both of these things take substantial time and engineering effort and make for some very challenging integration, testing and product management challenges for both VMware and the security ISVs in the ecosystem.  I’ve lived this life on both sides of the fence and it ain’t pretty folks.

Here’s the cool thing, although it’s arrived out of order, the integration of technology from the Blue Lane acquisition (with the IPS and patch proxy functions removed) adds the capability to provide for logical zoning and policy/firewalling enforcement and yields a very interesting side effect..

For all those vendors struggling with having to retool their virtual appliances and write kernel-level drivers for fastpath functionality in order to work with VMsafe API’s as well as their own slowpath drivers in the VA, vShield ultimately offers a solution that instead depends upon VMware’s dvFilters to redirect certain protocols to a virtual appliance based upon zones.

I saw a demo of how RSA has taken their DLP solution (from the Tablus acquisition) and by using  vShield/Zones to provide for the filtering and agreeing on a comms. path between the VMM and the RSA virtual appliance, they can integrate their solution without having to re-write their code or  develop fast path drivers!

Now, there’s a trade-off in extensibility because the capabilities of what are exposed are limited since VMware effectively controls that in this scenario; you might expect only fixed protocol redirection or some other prescribed limitation.

Regardless of how this plays out functionally, both ISV’s and customers now have an expanded choice when it comes to deciding how they might integrate security controls:

1. Use VMsafe API’s but wait for a vendor to re-write their code, integrate and test and get the best balance of performance, extensibility and customization of the solution or
2. Use vShield/Zones with shorter development and test cycles without having to modify their code.  This offers potentially less optimized performance, less extensibility but again potentially less attack surface since API’s are not exposed and there is no third party code in the VMM.

vShield/Zones will help the security ISV’s integrate their solutions more easily and hopefully quicker and will give customers the CHOICE of the trade-off between security, performance and functionality in terms of security solution integration.  It also means that the number and choice of ISVs in the ecosystem should expand.

Further, it may mean easier integration of security controls in Cloud scenarios as VMware extends vCloud.

I eagerly await more information regarding how vShield and the VMware/RSA proof-of-concept develops.  I hope that the PoC generates interest and accelerates the delivery of security solutions from ISVs who may not have previously been able to participate in the VMsafe API program.

/Hoff

Hopefully by now you’ve heard that the Cloud Security Alliance team released out initial efforts aimed at identifying key elements and practices in securing Cloud Computing.  Check the link below to download it.

There was a ton of work done in an extremely short timeframe.  There’s still a ton of work to be done. The 83 pages or so represent a good first-pass.  It’s not perfect and we didn’t aim for it to be so.  You’ll find things you may disagree with or think need clarification, please let us know.

As we break down these sections further, we really want people to get involved with subject matter expertise in each of the domains.  We want to take what we have an make it more valuable, more specific and more actionable.

We hope you’ll join us in this effort.

Cloud Security Alliance identifies key practices for secure adoption of Cloud Computing

San Francisco, CA, April 22, 2009 – The information security industry is taking on the task of providing guidance to enable secure Cloud Computing with today’s formal launch of the Cloud Security Alliance. The Cloud Security Alliance’s inaugural whitepaper, “Security Guidance for Critical Areas of Focus in Cloud Computing”, is now available on the Cloud Security Alliance website, and a presentation of the findings will be made at the RSA conference today at 2:45pm at Orange Room 312 in the Moscone Center.

The Cloud Security Alliance is a not-for-profit organization with a mission to promote the use of best practices for providing security assurance within Cloud Computing, and to provide education on the uses of Cloud Computing to help secure all other forms of computing. The founding thought leaders behind the formation of the Cloud Security Alliance are leading security practitioners from a range of private and public organizations and leading security companies PGP Corporation, Qualys, Inc. and Zscaler, Inc.

“Aggressive adoption of cloud computing is clearly underway. The convergence of inexpensive computing, pervasive mobility and virtualization technologies has created a platform for more agile and cost effective business applications and IT infrastructure,” said Jerry Archer, Chief Information Security Officer at Intuit, Inc. and part of the CISO leadership at the Cloud Security Alliance, “The cloud is forcing thoughtful adaptation of certain security controls, while creating an even greater demand for best practices in security program governance.”

The whitepaper being presented at RSA, “Security Guidance for Critical Areas of Focus in Cloud Computing”, outlines key issues and provides advice for both Cloud Computing customers and providers within 15 strategic domains. According to Alliance co-founders Nils Puhlmann and Jim Reavis, the several months of collaboration was worth the effort, “We would like to thank the many contributors to this initial effort. The great diversity of services offered via cloud computing requires careful analysis to understand the risks and mitigation appropriate in each case. At the same time, we see enormous potential for the cloud model to eventually simplify many difficult security problems. This initial deliverable is just the beginning of our efforts, and we would like to extend an open invitation to industry experts to help us create additional best practices for practitioners and the industry.”

The Cloud Security Alliance is building its guidance by engaging with experts from a variety of backgrounds to reflect the many organizational participants that will be involved in cloud computing decisions. Joshua Davis, Director of Information Security & Compliance at Qualcomm and a member of the Cloud Security Alliance, sees this collaboration as timely. “The information risk management factors one must consider when leveraging cloud computing, especially legal and regulatory compliance issues, represent unchartered territory for many enterprises. The Cloud Security Alliance is bringing together information security and legal experts, along with many other domains of knowledge, to see these issues from every stakeholder’s point of view.”

The guidance whitepaper is available online at www.cloudsecurityalliance.org/guidance. Open discussion is welcome at our LinkedIn group and on Twitter at #cloudsa.

About Cloud Security Alliance

The Cloud Security Alliance is a not-for-profit organization with a mission to promote the use of best practices for providing security assurance within Cloud Computing, and to provide education on the uses of Cloud Computing to help secure all other forms of computing. The Cloud Security Alliance is led by industry practitioners and supported by founding charter companies PGP Corporation, Qualys, Inc. and Zscaler, Inc. For further information, the Cloud Security Alliance website is www.cloudsecurityalliance.org

/Hoff

It finally dawned on me that if I have a few hundred to a thousand people sitting in front of me at one of my presentations, I should take advantage of that collective intelligence to perform a little selfish information gathering.

I’ve had an opinion for quite some time that the rampant squawking and generalizations regarding hyper-mobility suggesting VM sprawl and uncontrolled instance spawning was nothing more than FUD given where we are today with the technology and platforms that supposedly enable it.

We constantly hear how organizations big and small are suffering (or will) from the evils of virtualization by way of VM’s and information turning up everywhere, putting your data and assets at risk. It gets worse with the multi-tenancy issues surrounding moving to “The Cloud,” they say.

So in a couple of my panels at RSA, I asked for some sanity and fact checking.

Informally, 95% of those in attendance at the two RSA panels I engaged run VMware in production. I asked that in cases OTHER than failure, how many of those in the audience take advantage of VM mobility (such as VMotion) or some other technological capability to provide autonomic mobility of VM’s in their enterprises.

About 5 people (in crowds of 100+ and 500+ respectively) raised their hands.  Given that I asked this question the second time in front of a huge audience at RSA sitting next to the CTO’s of Citrix and VMware, I’m sure they were pretty surprised by the answer, too.

The reality is that in these environments — even extremely complex and large examples — there simply isn’t that much mobility and customers are more interested in resilience than they are agility in terms of what this feature brings. That’s a really interesting and important point.

The reason for this is pretty simple; the capability to provide for integrated networking and virtualization coupled with governance and autonomics simply isn’t mature at this point. Most people are simply replicating existing zoned/perimertized non-virtualized network topologies in their consolidated virtualized environments and waiting for the platforms to catch up. We’re really still seeing the effects of what virtualization is doing to the classical core/distribution/access design methodology as it relates to how shackled much of this mobility is to critical components like DNS and IP addressing and layer 2 VLANs.  See Greg Ness and Lori Macvittie’s scribblings.

Furthermore, Workload distribution is simply impractical for anything other than monolithic stacks because the virtualization platforms, the applications and the networks aren’t at a point where from a policy or intelligence perspective they can easily and reliably self-orchestrate.

Don’t get me wrong, autonomics and business process/governance feedback loops are most definitely coming — and are absolutely required for Cloud — but they’re not here and not used much today.  This is the hard stuff we’ve skipped over because it’s really freaking hard.  Don’t believe me?  See how long folks like HP have been at their “Adaptive Enterprise” solutions.  That’s why unified fabrics make so much sense; you can get your arms around automating much, much more with a consistent set of enforceable policies and SLAs.

So the next time someone brings up this epidemic of runaway VM’s, ask them to kindly provide you with empirical data demonstrating such as just because it *might* happen, doesn’t mean it *does* happen.

So much of the purported risks associated with virtualization and Cloud are things based on what might happen. There’s a huge difference between possibility and probability. One of them is used for prudent analysis and risk assessment, the other for selling you something. I’ll let you figure out which is which.

The management, visibility and security tools and capabilities are arriving on our doorsteps. When and if this sort of problem actually becomes a problem, it’s quite likely we’ll have a good set of solutions to deal with it.

Until then, challenge these assertions and fears, and ask for proof not pandering to panic.

Today I was rudely interrupted from my Cyber-dopamine-drip as I hungrily anticipated Oprah’s next tweet such that I might become complete.

My Google reader flashed its welcome yellow folder highlight as it indicated an RSS feed had been tickled.

Little did I know this pollen-tinted shimmer would bring such discord to what was shaping up otherwise to be a perfectly lovely spring day.

It seems the singularity is upon us as chronicled by Kris Buytaert in his post titled: On the Dangers of OVF.

It’s not often that I’m awe-struck into silence, but if you read this, I am convinced you will draw your own conclusions:

Usually I`m all in favour of Open Standards that are supported by different parties, and the Open Virtual Machine Format (OVF) pretty much matches these requirements.
The last Virtualbox has support for it, Simon is telling about it being part of the new XenConvert v2 Tech Preview .
However, Reuven wonders why it hasn’t gained widespread adoption yet.

Here’s my take, .. I`m not in favour of a standard as OVF that provides an easy way to transfer packaged virtual machine instance between different platforms.

Why ? Because I don’t think transferring full images of Virtual machines around is a good idea, not on 1 platform, not on different platforms.
And I`m not the only one with that opinion.

A Virtual Machine image is the perfect vehicle for malware in your network … some prepares an image for you , you run it on your network, and you set loose the devil, who knows it does a networkscan in the background and sends the info

OVF is a good breeding area for VM Image Sprawl,the effect you get when the number of images you have grows beyond what you can easily maintain, and this time it can grow beyond the people only using proprietary software , where as Image Sprawl used to be a disease mostly diagnosed within the VMWare usergroups and sysdamins with no clue on large scale deployments OVF

Sure OVF will assist smooth migration between different platforms so vendors want to keep it as far away from their users as possible, but people that already have a platform agnostic deployment framework in place don’t really need to worry about deploying on different platforms.

<Silence punctuated only by the sounds of me choking on my own tongue>

Sigh.  It must be WTF Friday.

/Hoff

I’m looking forward to the RSA conference this year; I am going to get to discuss Virtualization and Cloud Computing security a lot.

One of the events I’m really looking forward to is a panel discussion at the Jericho Forum’s event (Wednesday the 22nd, starting at 3pm) with some really good friends of mine and members of the Forum.

We’re going to be discussing Jericho’s Cloud Cube Model:

I think that the Cloud Cube does a nice job describing the multi-dimensional elements of Cloud Computing and frames not only Cloud use cases, but also how they are deployed and utilized.

Here’s why I am excited; if you look at the Cube above and the table I built below in this blog (The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don’t Work…) to get deeper into Cloud definitions, despite the differences in names, you will notice some remarkable similarities, especially the notion of how “internal/external” is called out separately from “perimertized/de-perimeterized.” This is akin to my table labeling of “Infrastructure located” and “managed by” column headings.  Further the “outsourced/insourced” maps to my “managed by:” column.  I like the “proprietary/open” dimension, also, which I didn’t include in my table, but I did reference in my Frogs presentation. I think I’ll extend the table to show that, also.

I am very much looking forward to discussing this on the panel.  I’ve been preaching about the Jericho Forum since my religious conversion many years ago.

As I said in my Frogs preso, Cloud Computing is the evolution of the “re-perimeterization” model on steroids.

/Hoff

Over the last month it’s been gratifying to watch the “mainstream” IT press provide more substantive coverage on the emergence and acceptance of Private Clouds after the relatively dismissive stance prior.  

I think this has a lot to do with the stabilization of definitions and applications of Cloud Computing and it’s service variants as well as the realities of Cloud adoption in large enterprises and the timing it involves.

To me, Private Clouds represent the natural progression toward wider scale Cloud adoption for larger enterprises with sunk costs and investments in existing infrastructure and it has always meant more than simply “Amazon-izing your Intranet.”  Private Clouds offer larger enterprises a logical, sustainable and intelligent path forward from their virtualization and automation initiatives in play already.

I think my definition a few months ago was still a little rough, but it gets the noodle churning:

Private clouds are about extending the enterprise to leverage infrastructure that makes use of cloud computing capabilities and is not (only) about internally locating the resources used to provide service.  It’s also not an all-or-nothing proposition.

It occurs to me that private clouds make a ton of sense as an enabler to enterprises who want to take advantage of cloud computing for any of the oft-cited reasons, but are loathe to (or unable to) surrender their infrastructure and applications without sufficient control.  Private clouds mean that an enterprise can decide how and how much of the infrastructure can/should be maintained as a non-cloud operational concern versus how much can benefit from the cloud.

Private clouds make a ton of sense; they provide the economic benefits of outsourced scaleable infrastructure that does not require capital outlay, the needed control over that infrastructure combined with the ability to replicate existing topologies and platforms and ultimately the portability of applications and workflow.  These capabilities may eliminate the re-write and/or re-engineering of applications like is often required when moving to typical IaaS (infrastructure as a Service) player such as Amazon.

From a security perspective — which is very much my focus — private clouds provide me with a way of articulating and expressing the value of cloud computing while still enabling me to manage risk to an acceptable level as chartered by my mandate.

Here are some of the blog entries I’ve written on Private Clouds. I go into reasonable detail in my “Frogs Who Desired a King” Cloud Security presentation.  James Urquhart’s got some doozies, too.  Here’s a great one.  Chuck Hollis has been pretty vocal on the subject.

My Google Reader has no less than 10 articles on Private Clouds in the last day or so including an interesting one featuring GE’s initiative over the next three years.

I hope the dialog continues and we can continue to make headway in arriving at common language and set of use cases, but as I discovered a couple of weeks ago, in my post titled “The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don’t Work…”, the definition of Private Cloud is the most variable of all and promotes the most contentious of debates:

Private Clouds seem to point to validate the proimise of what real time infrastructure/adapative enterprise visions painted many years ago, with the potential for even more scale and control.  The intersection of virtualization, automation, Cloud and converged and unified computing are making sure of that.

/Hoff

James Urquhart wrote a great blog today titled “The new cloud infrastructure: do you care?” in which he says:

…if you are a consumer of cloud-based resources, the mantra has long been that you can simply deploy or consume your applications/services without any regard to the infrastructure on which they are being hosted. A very cool concept for an application developer, to be sure, but I think it’s a mistake to ignore what lies under the hood.

At the very least, the future of hardware ought to touch the inner geek in all of us.

What is happening in data center infrastructure is a complete rethinking of the architectures utilized to deliver online services, from the overall data center architectures all the way down to the very components that serve the “big four” elements of the data center: facilities, servers, storage and networking.

Amen!

While James’ post focused mostly on how the underlying compute platforms are changing such as his illustration with Cisco’s UCS, Rackable’s C2 and Google’s custom machines, this trend will expand up and down the infrastructure stack.

From a technologist or architect’s perspective, what powers the underlying Cloud infrastructure is really important. As James alludes to, issues of interoperability can and will be impacted by the underlying platforms upon which the abstracted application resources sit.  This may sound contentious from the PaaS and SaaS perspective, but not so from that of IaaS, afterall the “I” in IaaS stands for infrastructure.

I made this point recently from a security perspective in my blog post titled “The Cloud Is a Fickle Mistress: DDoS&M…”  wherein I said:

We’re told we shouldn’t have to worry about the underlying infrastructure with Cloud, that it’s abstracted and someone else’s problem to manage…until it’s not.

…or here in Cloud Catastrophes (Cloudtastophes?) Caused by Clueless Caretakers?:

The abstraction of infrastructure and democratization of applications and data that Cloud Computing services can bring does not mean that all services are created equal.  It does not make our services or information more secure (or less for that matter.)  Just because a vendor brands themselves as a “Cloud” provider does not mean that “their” infrastructure is any more implicitly reliable, stable or resilient than traditional infrastructure or that proper enterprise architecture as it relates to people, process and technology is in place.  How the infrastructure is built and maintained is just as important as ever.

…

What we’ll also see is that even though we’re not supposed to care what our Cloud providers’ infrastructure is powered by and how, we absolutely will in the long term and the vendors know it.   This is where people start to freak about how standards and consolidation will kill innovation in the space but it’s also where the realities of running a business come crashing down on early adopters. Large enterprises will move to providers who can demonstrate that their services are solid by way of co-branding with the reputation of the providers of infrastructure coupled with the compliance to “standards.”

…

Remember the “Cisco Powered Network” program?  How about a “Cisco Powered Cloud?”  See how GoGrid advertises their load balancers are f5?

In the long term, like the CapitalOne credit card commercials challenging the company providing your credit card services by asking “What’s in your wallet?” you can expect to start asking the same thing about your Cloud providers’ offerings, also.

So, depending on what you do and what you need, your choice of provider — and what sits under their hood — may matter a ton.

/Hoff

This will be a quickie.  

This is such a juicy topic and really merits a ton more than just a mention, but unfortunately, I’m out of time.

Google’s latest updates to the Google App Engine Platform has all sorts of interesting  functionality:

• Access to firewalled data: grant policy-controlled access to your data behind the firewall.
• Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.
• Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.

To me, the most interesting is the boldfaced item above…Google Apps access to information behind corporate firewalls*

From a Cloud interoperability and integration perspective, this is fantastic.  From a security perspective, I am as intrigued and concerned as I am about anytime I hear “access internal data from an external service.”

The capability to gain access to internal data is provided by the Secure Data Connector.  You can find reasonably detailed information about it here.

Here’s how it works:

SDC forms an encrypted connection between your data and Google Apps. SDC lets you control who in your domain can access which resources using Google Apps.

SDC works with Google Apps to provide data connectivity and enable IT administrators to control the data and services that are accessible in Google Apps. With SDC, you can build private gadgets, spreadsheets, and applications that interact with your existing corporate systems.

The following illustration shows SDC connection components.

The steps are:

1. Google Apps forwards authorized data requests from users who are within the Google Apps domain to the Google tunnel protocol servers.
2. The tunnel servers validate that a user is authorized to make the request to the specified resource. Google tunnel servers are connected by an encrypted tunnel to SDC, which runs within a company’s internal network.
3. The tunnel protocol allows SDC to connect to a Google tunnel server, authenticate, and encrypt the data that flows across the Internet.
4. SDC uses resource rules to validate if a user is authorized to make a request to a specified resource.
5. An optional intranet firewall can be used to provide extra network security.
6. SDC performs a network request to the specified resource or services.
7. The service verifies the signed requests and if the user is authorized, returns the data.

From a security perspective, access control and confidentiality are provided by filters, resource rules, and SSL/TLS encrypted tunnels.  We’ll take this apart in detail (as time permits) later.

In the mean time, here’s a link to the SDC Security guide for developers.

…and no, you’re firewall likely won’t help save you (again.) 

At least I won’t be bored now.

/Hoff

* The database import/export is profound also. Craig Balding followed up with his OAuth-focused commentary here.