After months of feedback and just in time for RSA 2016, I have finally finished the second version of my Secure Hybrid Cloud Reference Architecture. There are some differences between the previous version and V2, but nothing major, as we are talking mostly about semantic changes. However, we did expand storage, add in SaaS-based clouds, and rework all of the diagrams to account for distributed firewalls. Yet, the semantic changes are pretty robust, as they reflect the modern mindset with respect to the secure hybrid cloud. Those changes alone are worth considering.
In this version of the architecture, we have introduced SaaS-based clouds with security proxies or transparent gateways sitting before them. These cloud access security broker (CASB) solutions are an important part for management of all clouds, but they may be more important for SaaS-based clouds, as there are often limited controls available to the tenant.
In addition, the architecture handles encryption a bit differently by changing semantics to include a key management system (KMS). This change allows for the introduction of encryption tools that use the key management interoperability protocol (KMIP). KMIP-enabled tools can work within a single part of the hybrid cloud or be present in more than one. Personally, I see them used everywhere as privacy issues grow. Any secure hybrid cloud needs to maintain private data but have centralized control of encryption keys.
There are also two changes to how we define firewalls, using new semantic terms such as “distributed firewall” and “internal segmentation firewall.” The goal is once more to allow choice in how one uses the architecture. An introspective firewall, for example, could be the basis for a distributed firewall, yet is not required these days. Nor are introspective (within the hypervisor) firewalls even required to implement microsegmentation these days. The internal segmentation firewall expands the concept of edge protection between multiple trust zones without the need to go all the way to the physical edge of any network. In a cloud, for example, where would one define the edge? While we need edge devices, they can sit anywhere within a virtual, cloud, or physical network. Actually, they should, as it moves control closer to the trust zones while controlling bandwidth requirements. Lastly, internal segmentation firewalls and distributed firewalls provide a fundamental building block for network function virtualizaiton (NFV).
Many security architectures tend to ignore storage. We have expanded our security look into storage to include not only the standard protocol-based storage—such as iSCSI, NFS, CIFS, and FC—but now also direct-attached storage, object storage, and PCIe extended storage. The new forms of storage, storage hypervisors, and storage front ends require a new way to look at how to secure storage. More layers imply more ways into storage. All of these items need to be considered from a security perspective as well, while not impacting throughput, IOPS, etc.
As before, there is a balancing act when creating any architecture, but we can never forego security. V2 answers questions posed to me over the last year, as well as expanding on new terminology. While this was reviewed by security professionals, I am always open to more questions and comments. Let me know if you would like to see anything added or expanded upon.
You can find the architecture at: