|
Cloud
Application Platforms
I’m going
to start this issue by highlighting two different
types of virtualization, specifically as they
pertain to cloud computing.
The
first, infrastructure virtualization, is what Amazon
offers with its Elastic Compute Cloud (known as EC2;
for a more detailed introduction, click
here). The key point is that, at first blush,
infrastructure virtualization feels like an easy
transition from onsite servers to cloud computing,
because it gives you the ability to remotely manage
your own servers in cloud in much the same way that
you manage them in an onsite datacenter (for
example, via RDP or SSH).
However, like any technology transition,
infrastructure virtualization places a burden on IT
staff to develop new tooling and management scripts.
That’s because the underlying virtual fabric is
different from what was being used before (for
example, ESX or bare metal).
The
second type of virtualization I want to highlight is
application runtime virtualization. This is the
model used by Windows Azure and Google App Engine.
This approach places a different kind of burden on
the IT staff because it’s difficult to control,
regulate, and monitor. There are two challenges,
both of which I’ll return to in the next two
sections:
-
Line of business (LOB) developers can deploy
apps directly to the cloud without going through
IT approval processes.
-
Virtualized storage provided in the cloud may
not comply with IT controls such as data loss
prevention, access and auditing policies,
encryption, and sovereignty (I wrote about the
latter in the
previous issue of the Informer).
Despite
the challenges, it’s important to note that
application virtualization in the cloud is a boon
for developers and software start-ups for many of
the same reasons that it’s painful to IT. From a
cost perspective, cloud computing is proving to be
irresistible to larger businesses because it
facilitates the current trend of transforming
capital expenses, such as in-house servers, into
operational expenses, such as a monthly cloud
services bill.
Plus,
once developers have been trained on the new cloud
computing environment, the result may be an overall
reduction in the cost of LOB app deployment and
lifecycle management. And let’s not forget the
inherent scalability benefits of cloud computing.
The
major tech vendors recognize this, of course, and
are doing everything they can to entice LOB
developers to use their cloud platforms. Tight
integration with the developer tool chain is the
key.
Cloud
Strategy: Developer Tool Chain Integration
VMware
announced on August 31 its competitive answer to
Windows Azure:
vFabric. The most notable quality of vFabric is
its tight integration with the Java-based
SpringSource Tool Suite, which includes a reputable
runtime library and also offers tight integration
with the Eclipse integrated development environment
(IDE).
This is
the same approach that Microsoft is using: deploying
applications directly from the developer’s desktop
to the cloud is becoming easier with each new
version of its Visual Studio IDE and the Azure
integration tools.
Why
does IDE integration matter? Because building a
cloud computing platform is enormously expensive,
and the only way companies like Microsoft and
VMware/EMC stand a chance of making back their
investment is to make it brain-dead simple for every
developer in the world to run his or her app in the
cloud. That means lowest common denominator: write a
Visual Basic app, click a button, it’s running in
the cloud and you’re done – next project. No setup,
no confusing configuration, no keys, etc.
Problem: the focus on this one-click-deployment
strategy is convenient, but it leaves some
unanswered questions in the security department.
More
on Cloud Security
Cloud
security faces two challenges. The first is data
sovereignty, which basically boils down to this: if
I’m an American company, then data stored on my
servers is subject to American data sovereignty laws
(same concepts apply worldwide, of course). Those
laws determine, for example, who is able to demand
access to that data, when, and why. If you’re a
foreign government, or a company that does business
with one, you’re unlikely to want to store your data
on my cloud service, because my government can
basically seize it whenever it wants. That puts a
dent in my prospective customer base.
The
second security challenge is data encryption. An
informative reference on the subject is
this TechNet article, which mentions the threat
of data compromise from within the cloud. To
mitigate that threat, the article suggests creating
and storing keys in the cloud. However, that’s not
going to work if someone from within the cloud
compromises your keys, or compromises whatever
secret protects those keys. The only solution is to
store the secret outside of the cloud and never
transmit it to the cloud. That greatly limits the
scalability benefit of the cloud – which is supposed
to be one of its main selling points – unless all
you’re looking for is pure storage space.
Let’s
be realistic, though – applications are being
migrated to the cloud. To that end, a good blog post
on Azure Security is
here – it links to a lengthy paper on Azure
security. The paper offers some useful threat
modeling checklists in the References section at the
end. For example, see the section entitled Cheat
Sheet - Web Application Security Threats and
Countermeasures at a Glance starting on page 86. I
couldn’t find a similar reference for vFabric, but
all of the points raised by the Azure paper are
applicable.
Want to
read more about the cloud? See also
this post on cloud dev resourcing, plus my
upcoming TechNet article on local and cloud resource
coexistence. |
Welcome
to the fourth edition of the JW Secure Informer, our
bi-monthly newsletter. This is an opportunity to
share what’s on our radar, specifically with respect
to enterprise network security, but also regarding
IT and business more generally.
