In this blog post series, I will introduce you to the concept of the cloud reference architecture (CRA) as defined in ISO/IEC 17789 standard, and why you should consider having one. The end result of a cloud reference architecture is to achieve a balance between cloud agility from one side, and security and governance from the other side.
So why you should care about having a Cloud Reference Architecture after all? well, think bout how you would deploy resources today in the cloud. Do you have workload islands deployed in different accounts or subscriptions, each with separate management and infrastructure supporting functions?
- Did you plan for financial accountability and have cloud financial governance in place to track and isolate cost across different business units?
- Do you have a consistent policies and controls so that any cloud workload you deploy today is configured from day one to ensure governance and compliance?
- And finally, do you have visibility on all your cloud resources so that you can account for each resource and plan your budget accordingly?
I want to start by sharing with you some insights to help you understand the urgency of what I am trying to talk about today, and I will start by asking you if you know, that as per today, that the biggest blockers for organizations to adopt a cloud first strategy are security and compliance?
I work a lot with banks, and this is the first thing that I hear when someone talks about cloud computing. It is not secured and can’t be trusted. In fact, the CEO of AvaLan wireless warns that ” The United States next pearl harbor will be cyber-attack“. The nightmare of data leaks and the fear of losing reputation and customer trust is top of mind of every CEO when thinking of moving to the cloud.
While cloud computing offers a lot of security features to customers that sometimes even on-premises deployments can’t provide, 95% of cloud security failures will be customer’s fault according to a recent Gartner report. Security in the cloud is a shared responsibility between you as a customer and the cloud provider. Many organizations fail to identify this trust boundary, and “who is responsible of what” is often lost in translation.
So, I want you to pause for a minute and think about these facts. I mean, your job as a security professional is to bridge that gap after all, and this is exactly what we are trying to achieve today.
Bridging The Gap
You might be asking, what gap are you talking about? Well, organizations want to use cloud computing to take advantage of the agility and elasticity of the cloud and to help them digitally transform. However, the fear from trusting the cloud to host their data is still a concern and is slowing the cloud migration process for many organizations.
But you might agree with me that the cloud is not evil, it gives you the agility and elasticity your business needs to grow and transform, while security and compliance are slowing you down.
What you need is a way to balance the two sides, to have the agility of the cloud without compromising security and compliance and also to trust your cloud to host your data and workloads. In other words, you need to extend the trust you have for your on-premises infrastructure to the cloud computing so that you can migrate and deploy workloads with confident. This is exactly your role as a cloud architect, as a security professional or a as a compliance officer.
Congratulations, you are the cloud builder. You are assigned the task of achieving this balance by understanding the nature of cloud computing and by deeply considering your organization’s security and compliance requirements.
I know this is much to ask for, but don’t worry, I am going to help you understand how to achieve this balance in this blog series.
One way to accomplish that is to plan and design a blueprint. You can give your DevOps team this blueprint and ask “Could you please use this blueprint when you deploy any resource in the cloud?”. The DevOps team might ask for a reason, so you would tell them “well, deploying cloud resources using this blueprint means what you build in the cloud is compliant, secure and meets your company’s policies and governance“.
Now between us, this blueprint is what we will be calling the cloud reference architecture or CRA for short.
The Need For Cloud Reference Architecture (CRA)
Before digging into the definition of the Cloud Reference Architecture (CRA) and its benefits, it is better to look at how things can go wrong without having one. You will quickly realize that it is better to spend some time before migration to plan your cloud migration journey with security and governance in mind. Doing that will not only save you time and money but will help you meet your security and governance needs. So let’s get started.
When organizations start planning their cloud migration, and like anything else new, they start by trying and testing some capabilities. Perhaps they start hosting their development environment in the cloud while keeping their production one on-premises.
It is also common to see small and isolated applications being migrated first, perhaps because of their size, low criticality and to give the cloud a chance to prove it is trust worthy. After all, migration to the cloud is a journey and doesn’t happen overnight.
Then the benefits of cloud solutions became apparent and companies started to migrate multiple large-scale workloads. As more and more workloads move to the cloud, many organizations find themselves dealing with workload islands that are managed separately with different security models and independent data flows.
Even worse, with the pressure to quickly get new applications deployed in the cloud with strict deadlines, developers find themselves rushing to consume new cloud services without reasonable consideration to organization’s security and governance needs.
The unfortunate result in most cases is to end up with a cloud infrastructure that is hard to manage and maintain. Each application could end up deployed in a separate island with its own connectivity infrastructure and with poor access management.
Managing cost of running workloads in the cloud becomes also challenge. There is no clear governance and accountability model which leads to a lot of management overhead and security concerns.
The lack of governance, automation, naming convention and security models are also even hard to achieve afterwards. In fact, it is nightmare to look at a poorly managed cloud infrastructure and then trying to apply security and governance afterword because these need to be planned a head before even deploying any cloud resources.
Even worse, data can be hosted in geographies that violates corporate’s compliance requirements, which is a big concern for most organizations. I remember once asking one of my customers if they knew where their cloud data is hosted, and most of them just don’t know.
The Benefits of Cloud Reference Architecture (CRA)
Simply put, the Cloud Reference Architecture (CRA) helps organizations address the need for detailed, modular and current architecture guidance for building solutions in the cloud.
The Cloud Reference Architecture (CRA) serves as a collection of design guidance and design patterns to support structured approach to deploy services and applications in the cloud. This means that every workload is deployed with security, governance and compliance in mind from day one.
The ISO/IEC 17789 Cloud Computing Reference Architecture defines four different views for the Cloud Reference Architecture (CRA) :
- User View
- Functional View
- Implementation View
- Deployment View.
We will be focusing on the Deployment View of the Cloud Reference Architecture (CRA) for now.
The Cloud Reference Architecture (CRA) Deployment View provides a framework to be used for all cloud deployment projects, which reduces the effort during design and provides an upfront guidance for a deployment aligned to architecture, security and compliance.
You can think of the Cloud Reference Architecture (CRA) Deployment View as the blueprint for all cloud projects. What you get from this blueprint, the end goal if you are wondering, is to help you quickly develop and implement cloud-based solutions, while reducing complexity and risk.
Therefore, having a foundation architecture not only helps you ensure security, manageability and compliance but also consistency for deploying resources. It includes network, security, management infrastructure, naming convention, hybrid connectivity and more.
I know what you might be thinking right now, how does one blueprint fit the need for organizations with different sizes? Since not all organizations are the same, the Cloud Reference Architecture (CRA) Deployment View does not outline a single design that fits all sizes. Rather, it provides a framework for decisions based on core cloud services, features and capabilities.
The Need for Enterprise Scaffold
One of the main concepts of the Cloud Reference Architecture (CRA) that I would like to share with you today is the concept of an enterprise scaffold.
Let’s start from the beginning. When you decide to migrate to the cloud and take advantage of all what the cloud has to offer, there are couple of concerns that you should address first. Things like:
- A way to manage and track cost effectively (how can you know what resources are deployed so you can account for it and bill it back accurately).
- Establishing governance framework to address key issues like data sovereignty.
- Deploy with mindset of security first (defining clear management roles, access management, and security controls across all deployments).
- Building trust in the cloud (have peace of mind that cloud resources are managed and protected from day one).
These concerns are top priority for every organization when migrating to the cloud and should be addressed early in the cloud migration planning phase.
To address all these key concerns, you need to think of adopting a framework or an enterprise scaffold that can help you move to the cloud with confidence. Think about how engineers build a building. They start by creating the basis of the structure (scaffold) that provides anchor points for more permanent systems to be mounted.
The same applies when deploying workloads in the cloud. You need an enterprise scaffold that provides structure to the cloud environment and anchors for services built on top. It is the foundation that builders (IT teams) use to build services with speed of delivery in mind. The enterprise scaffold ensures that workloads you deploy in the cloud meet the minimum security and governance practices your organization is adopting while giving developers the ability to deploy services and applications quickly to meet their goals and deadlines, which is a win win solution.
To accomplish this, we need to define the components of the cloud reference architecture that we will use to build secure, compliant and flexible framework that developers can build application on top with agility and speed of delivery in mind.
At the core of building an enterprise scaffold for cloud migration is the Enterprise Structure Layer which act as the foundation on which all other layers are built. Here you define a hierarchy that maps to your organization departments and cost centers to govern spending and get visibility of cost across departments, line of business applications or business units. On top, you define a Management Hierarchy that gives you even more flexibility when assigning permissions and applying policies to enforce your governance in the cloud.
With that carefully defined, you start adopting key best practices and patterns that maps to your organization’s maturity level. You can think of these as the Deployment Essentials which includes establishing a proper naming convention, deploying with automation and using Infrastructure as Code instead of using the web interface to deploy resources which can cause a snow ball effect of changes that in the future become hard to manage, track or even audit. The idea here is to have a consistent way of deploying resources over and over again. Not only it gives you that speed of delivery we all want to have, but also a piece of mind that what you verified as a compliant environment in code, is the blueprint used to deploy resources across your subscriptions.
Now it is time to start building the foundation infrastructure and this is the Core Networking layer. At this layer, governance can be achieved using different technologies that helps you isolate and deploy security controls to monitor and inspect traffic across your cloud infrastructure. One of the best recommendations here is to use a hub and spoke topology and adopt the shared service model where common resources are consumed from different LOB applications which has many benefits that we will discuss in great details later.
In this layer, you decide how to extend your on-premises data center to the cloud. You also define how to design and implement isolation using virtual networks and user defined routes .This is also the time where you deploy Network Virtual Appliances (NVAs) and firewalls to inspect data flow inside your cloud infrastructure.
Another key feature of the cloud is the Software Defined Networks (SDNs) that gives you the opportunity to do micro-segmentation by implementing Network Security Groups and Application Security Groups to better control traffic even within subnets, not only at the edge of the network which is an evolution of how we think about isolation and protection in such elastic cloud computing environment.
After you are done with the core networking layer, and just before deploying your resources, you should consider how are you going to enforce Resource Governance. This is important because the goal of the cloud reference architecture is to give developers more control and freedom to deploy workloads quickly and meet their deadlines, while adhering to corporate security and governance needs. One way to achieve this balance is by applying resource tags, implementing cost management controls, and also by translating your organizational governance rules and policies into Azure policies that governs the usage of cloud resources.
Once all this foundation work is finished, you can start planning how to deploy your line of business applications (LOB applications). Most likely you need to define different application life-cycle environments like (Production, Dev, and QA).
Here you can also establish a shared services workspace to hosts shared infrastructure resources for your line of business applications to consume. If one of your business applications requires a connectivity to on-premises resources, it can use the VPN gateway for example deployed in the shared services workspace instead of implementing a gateway for each application’s workspace. The shared services workspace is a key element when defining your CRA as it hosts shared services like domain controllers, DNS services, jumpbox devices and security controls like firewalls.
But your job is far from finished, as security is a never-ending process, and this is where the Security Layer comes to the picture. Here you define proper identity and access management model using Azure RBAC. Security practices like patching, encryption and secure DevOps are key areas in this layer.
Furthermore, to gain the visibility and control you need in such rapidly changed environment, you need to think of a security as a service model which natively integrate with the cloud platform and services, so here you can use Azure security center to assess your environment for vulnerabilities but also as enabler to your incident response in the cloud, as you need to detect and remediate security incidents.
You can also implement Just-in Time Virtual Machine Access to lock down management ports on your virtual machines. If you are highly regulated environment, you can also look at VNET Service Endpoints to protect access to PaaS Services like Azure Storage so that accessing these services does not pass through the public internet.
With all this in mind, you need to consider Business Continuity, high availability and backup, and here I want to remind you of the shared reasonability model of the cloud. You are responsible of many things which might include planning how to do backups, how to design for high availability and even for disaster recovery.
And finally, How to think of monitoring and auditing in the cloud. Is there is a performance bottleneck that you should address right away? Do you require that changes to your cloud environment is audited, so where are you going to keep the logs, are you going to integrate that with your on-premises SIEM solution, or use a cloud logging mechanism, and if so, does that solution retain the logs for the duration you need?
In this blog post, we defined the Cloud Reference Architecture (CRA), which helps you achieve the balance between security and governance from one side and agility and speed of delivery from the other side.
To achieve this balance, we need to adopt a framework or and enterprise scaffold that helps you achieve governance at different levels. Deploying resources using this framework ensures that resources you deploy in the cloud are secure and adhere your corporate policies.
In the upcoming blog series, I am going to help you carefully design key areas of the enterprise scaffold to act the basis for any cloud workload you deploy with agility and governance in mind.
Get the Cloud Migration Handbook Vol.1
This book covers a practical approach for adopting and migrating on premises systems and applications to the Public Cloud. Based on a clear migration master plan, it helps companies and enterprises to be prepared for Cloud computing, what and how to successfully migrate or deploy systems on Cloud, preparing your IT organization with a sound Cloud Governance model, Security in the Cloud and how to reach the benefits of Cloud computing by automation and optimizing your cost and workloads.
Watch It on YouTube
You can watch this on YouTube as I explain the whole cloud reference architecture in great details on YouTube here.