March 28, 2017

IT Concerns With Transaction On The Cloud

You read that right! Somebody is dumb crazy enough to put transactions in the “insecure” clouds.  I mean, look at all of the threats and compliance issues:

  • Consumer privacy
  • PCI compliance
  • Security
  • Lack of control
  • Data location requirements

Where have I heard of these issues before?  Oh yeah, when we were moving from the mainframe to client server.  How did we solve those issues?  Oh yeah, we designed for these issues and mitigated the risks.  What does it mean to the business if I can figure this out?

  • Huge reduction in infrastructure costs
  • More flexible and affordable disaster recovery and business continuity
  • Possibly even better security
  • Easier growth/expansion into new markets/countries
  • Pay-as-you-go scalability

As I have mentioned in the past, I am working for a startup building our core product/services from the ground up.  We have no plans on having our own data center and are leveraging the cloud as a low cost to entry into the market place.  Also, the cloud gives us world class infrastructure and scalability that we would never be able to afford or raise capital for.  So we have all of the incentive in the world to figure out how to use the cloud for transactions.  We have no legacy to bog us down, no data to port, no culture transformations to lead…..just a blank sheet a paper, an open mind, and an entrepreneur spirit!

So how can we build a secure enterprise in the cloud?  We started by adopting the E2AF framework and defined the business architecture first which is completely agnostic of the technology.  Some of the many items that were identified from the business architecture were:

  • Security and compliance are critical to the success of the business model
  • Data may be required to physically be stored within a country or customer boundary
  • Need to be able to scale quickly (customer acquisition cycles should be same day, not months)
  • Speed to market and low cost is a key differentiator

The bottom two bullets scream out for the cloud.  The top two scream out for on-premise.  Maybe we could compromise.  How about a hybrid model?  Public cloud for speed, scale, cost and private cloud for security, compliance, and co-location.  What would that look like?

From Cloud Computing

You can see from this picture that all sensitive data is kept on a private cloud. In this model, we are not putting consumer and financial data in a shared environment as is the case in the public clouds. Here we are dedicating specific servers that we can lock in a cage and harden just like many people do on their own raised floor. In fact, if I already had an existing data center, I would have the physical data layer deployed in it and not on the private cloud. The private cloud is not as cost effective as the public cloud, but is a heck of a lot cheaper than buying and maintaining a full blown data center. So how does the public cloud access the data on the private cloud? Can you say SOA, specifically data services. That’s right. SOA is alive and kicking in this architecture! The services in the public cloud talk to the data services layer and have no idea of how and where the data is physically located. To these services, a customer, an order, an invoice are all defined in business terms and the data services layer will figure out how to retrieve the physical data from the appropriate location over a secure protocol. This also addresses the data location requirement which is not addressed with typical on premise solutions. Imagine an architecture that leverages both public and private clouds across the globe that looks like this.

From Cloud Computing

In this example I focused on the US and Europe (apologies to my colleagues in other countries/continents). Since the data location requirements dictate that data may need to be stored at a client’s headquarters or within the boundaries of that client’s country, separating the data into the private cloud or a remote data center allows me to still leverage the low cost capabilities of the public cloud to run the rest of my services.

IaaS vs. PaaS

One of the keys to this architecture is the use of Infrastructure as a Service (IaaS) and not allowing Platform as a Service (PaaS) solutions for delivering our services in the public cloud (see “Clearing up the Cloud Picture” definitions).  The reason is simple.  Our transactions must be up 24×7×365.  That means that we will use two providers in case one fails.  To do that, we must not use a proprietary platform that would require a rewrite to move to another platform.  We must build our services to be agnostic to the vendor platform (did I hear you say SOA again?).  One of the big risks of cloud computing is an organization’s dependency on a third party for up-time.  Vendors also go out of business or get bought by other vendors, see my response to the Coghead fiasco.  It is key that the architecture does not get married to the vendor’s platform and is free to move when and if the need arises.

Security & Compliance

I already addressed some of these issues by leveraging the private cloud and dedicating servers for the physical storage of sensitive data.  But that by itself is not enough.  You still need to protect against unauthorized access from your vendors’ employees and you still need to do the basics for securing the servers.  Here is a short list of things to plan for:

  • Secure the OS
  • Secure the database
  • Secure the network
  • Secure the endpoints
  • Have a logging storage and retrieval strategy
  • Restrict access (Ex: cages, fingerprint ID, etc.)

From a compliance standpoint, adopt some formal standard and build those standards into the security layer of the architecture.  This allows you to manage security in a centralized place by those that know security instead of depending on every developer to do the right thing when they are building services.  I had a security company do an assessment of all regulatory constraints across all countries and found that the combination of PCI compliance and ISO 27001/27000  covers the majority of regulatory requirements across the globe.  That is the advantage of adopting an internationally accepted standard from the ISO.


Most of the control issues are geared around knowing where sensitive data lives so audits can be performed.  In a public cloud environment you have no idea where your data is which makes auditing for things like SOX or PCI next to impossible.  Also, since  you are on a shared environment, another company’s actions could lead to the government seizing assets under the Patriot Act (thanks W!).  If all of your sensitive data is on your private cloud on dedicated servers, the Patriot Act is a non-issue (assuming you have redundancy in the public cloud).  I also recommend using cloud management software to effectively manage virtual servers across the various vendors and across the public and private cloud.  Even on the dedicated servers in the private cloud, you can still leverage virtualization to scale up and down and quickly launch new images.


Many pundits will tell you that the cloud is not secure, not reliable, and not ready for prime time.  If we are talking about the cloud as a stand alone entity, then the pundits are correct.  But if we take the various cloud offerings and build an architecture that addresses redundancy, security, compliance, location specific data requirements, and is vendor neutral, then the cloud can create a major competitive advantage that can enable a company to leap frog its competition.


About Mike Kavis 4 Articles
Mike Kavis is a veteran Chief Architect with over 23 years of IT experience including distributed computing, SOA, BPM, data warehouse, business intelligence, and enterprise architecture. Read Mike's blog at Enterprise Initiatives.