The Past: The Client/Server Architecture
Historically, web sites and services were architected in a client/server design, the same design used since the mainframes of the 1970’s.
There was a client; a desktop or laptop, and a server it attached to. That server could be over the network or over the internet, physically located in a colocation site or right next door in the data center.
This client/server architecture was adequate to describe the technologies that were available in the 1990’s and early 2000’s, and security was designed with that architecture in mind, determining ways to control access through this model.
Perimeter came to define the transition zone between your Enterprise Resources and the Internet. It was where the router was, and the logical place to install a firewall. Just like a secured building with one entrance, you place your guards at the door.
It was in 2006 that Google’s Eric Schmidt said the word “cloud” during an industry event.
Up until recently, ‘cloud’ wasn’t much more than a buzzword, used to describe that same client/server model of the past, but with the resources moved from the data center to the internet.
The Present: Cloud Has Grown Up
Over the last 5 years though, Cloud has grown up.
Now, an interface application may run on elastic server clusters provided by Amazon, associated private data may be mirrored both on site in a traditional data center and duplicated to another Amazon resource or a colocation center, and the application used to process, shuttle, and present that information to and from the interface is hosted and provided by a 3rd party that is paid a monthly service fee, versus the software licensing model of the past.
Gartner defines this challenge as ‘Computing Everywhere’, and states it is the number one strategic technology trend of 2015.
With these changes in architecture some areas of IT have not caught up yet. One of those is security. De rigueur du jour remains perimeter firewalls. Firewall products are still most often sold as a device or a server installed on the perimeter, even though the distributed server of today is not located behind one.
In fact, often firewall vendors try to bend the definition of ‘perimeter’ into something that closer fits the overall cloud design yet still sells their perimeter based solution. Keep an eye out for this in the marketing material if you have not seen it yet.
The Future: Continued Fragmentation
Resources are expected to continue fragmentation as more software is sold as a service, data storage becomes further distributed, more services are provided in the cloud, and the line between what is a client and a server becomes further blurred.
Adapt or Obsolesce
The perimeter security model cannot hope to provide adequate security in the decentralized infrastructure of today.
Just as the US recognized that the military could not integrate with the advancements of air power in the early 1940’s, security will have to to catch up ‘Computing Everywhere’.
The result of that recognition was the Us Air Force, a structure that both unified command of all air elements, and gave total autonomy from the ground forces. In the same way, security must evolve from the ‘perimeter’ and adapt.
The good news is that the US Air Force went on to become key to winning World War II, and it still exists today.
A Solution: CloudGenix & the Software Defined Network
Navneet Yadav at CloudGenix describes their solution to this problem as the Software Defined Network or SDN.
When CloudGenix designed their SDN, they identified the need for ‘Security before Service’. Before a service can be used, it must be secured.
CloudGenix provides a unique alternative to firewalls. An agent is installed on your servers and the servers work together to define secure and encrypted sessions for each individual connection used. These encrypted sessions are created on the fly, as needed, and torn down when they are finished. Only minor configuration parameters need to be set by the administrator; the rest is handled automatically by the agents. The SDN includes considerations for redundancy, resiliency, security of the host, and performance, all inclusive.
Imagine the possibility to spin up any application in the cloud and know it will automatically connect over a secure encrypted connection for every service, regardless of the implementation, turned up only when needed, with new keys for each session, and torn down when finished.
SDN allows security to be woven into the connections of your architecture. If you can connect to it, it can be secured.
Another Solution: API’s
To enable ‘Computing Everywhere’, a more common solution employed is via API’s delivered over SSL. This option provides the benefits of a standardized way of working with data, and layers it with the recognized security of SSL.
The downside is that programmers are required to manage and implement the API.