© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2021
K. OtsAzure Security Handbookhttps://doi.org/10.1007/978-1-4842-7292-3_1

1. Introduction to Cloud Security Architecture

Karl Ots1  
Zürich, Zürich, Switzerland

Cloud computing is perhaps the largest information technology megatrend of this decade. The promises of commoditization of core infrastructure services, faster time to market, and adoption of brand-new technologies such as artificial intelligence or quantum computing are alluring.

Furthermore, the global disruptions of the COVID-19 pandemic in the beginning of this decade proved that the hyperscale cloud providers can answer the most unpredictable demand thrown at them.

The pandemic validated cloud’s value proposition.

—Sid Nag, Research Vice President at Gartner1

The cloud computing model is now ready to mature from the experiments of early adopters and to become the mainstream computing platform of established enterprises. With this shift, we need to stop thinking about cloud security as an isolated domain of information security where some traditional rules cannot apply. We need to start looking at how the cloud can provide at least the same level of confidentiality, integrity, and availability of our information and assets as any other computing platform.

But with over hundreds of existing services, hundreds of announcements every year, and lack of skilled workforce, taming the beast of cloud security with traditional methods can seem overwhelming. The answer is what I like to call cloud-native security.

In this chapter, we define cloud-native security and preface the subsequent chapters of this book. After reading this chapter, you will be able to describe what cloud-native security is and list what to include in a cloud security framework.

Cloud Security Responsibilities

Did you know that contrary to popular belief, the most common cloud security threats are not outside attacks, but rather misconfigurations?2

Based on this data, we can conclude the following points: First, the cloud can be just as safe (or unsafe) against outside attacks as our on-premises systems. Second, to fully secure public cloud platforms, we need to understand them deeply. This requires both upskilling existing information security office with cloud expertise and shifting the way security responsibilities are spread across the organization.

Shared Responsibility Model

In the world of on-premises computing, cybersecurity risks were perceived to be limited to the organization’s network. In the era of cloud computing, both the impact and likelihood of potential risks are significantly higher.

Figure 1-1 describes how the security responsibilities are shared between the cloud provider (Microsoft) and the customer organization (us) across the various cloud service models: software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS), and, finally, on-premises computing (our own datacenter). We can interpret this model from left to right or right to left.

Let us start by looking at this model from left to right. When using software as a service, we have the highest level of integrated security out of the box. The downside is that we are limited to what the platform offers: if the default settings or limited options for configuration do not meet our security requirements, we need to consider a cloud service model with a lower level of abstraction, such as platform as a service. As we move further to the right, we get lower level of integrated security, but we gain the possibility to implement additional controls to meet our requirements.

Now let us analyze this model from right to left. This might feel more familiar approach when evaluating what needs to change when moving from traditional security to cloud security. As we move from on-premises to infrastructure as a service and further up in the cloud model abstractions, we give up control of configuring and operating said services. As we give up control, Microsoft assumes the responsibility of securing these services.
Figure 1-1.

Shared responsibility model of cloud security from the organization point of view

Shifting Security Left

With the corresponding advent of DevOps methodology, security is now the responsibility of everyone who is part of the application development life cycle, not just security specialists.

Application Developers are no longer limited to services provided by central IT: they can adopt new cloud services on their own. At worst, this might lead into so-called shadow IT. At best, this expands your information security office in the orders of magnitude.

At the same time, the Application Developers are no longer protected by the outside perimeter of central teams: in Azure, they are responsible for more. There is no corporate firewall, access control or centralized audit logging to fall back on. If the developers have direct access to Azure Management pane, day-to-day operations, such as vulnerability management, patching, or monitoring, might fall under their responsibility, too.

Cloud-Native Security

As with any other paradigm-shifting technology, securing the public cloud is not as simple as extending or replicating existing security controls. Some of the differences are because of technical limitations, such as the changes in the network perimeter or access to certain detection and monitoring capabilities. Some changes are required because of the reasons your business units and application development teams are choosing the cloud: flexibility, faster time to market, or access to technologies that are not available in existing hosting platforms.

These differences eventually require you to shift how you implement security architecture. Rather than bolting your existing controls, tools, and processes on top of cloud workloads, you have a unique opportunity to build security into the very platform your workloads are hosted in!

Multi-cloud or Cloud-Native Security?

Multi-cloud solutions are built to be agnostic of the cloud platform they are hosted in. They are often built on services that have comparable services in other cloud providers, such as virtual machines or container hosting services. As such, multi-cloud solutions can use the least common denominator of the cloud services available in the cloud providers of your choice. Designing a multi-cloud solution means compromising features and integrated security in favor of interoperability and the ability to externalize the security controls from the cloud provider. In practice, multi-cloud is both cost prohibitive and slower to implement than building your solution with native platform-as-a-service components of a single cloud solution platform.

Similarly, multi-cloud security tools cannot offer the same level of granularity than those that are built natively for the individual cloud services. You might be able to standardize on a firewall appliance or a workload protection platform across cloud platform, but you will be only covering a subset of the available cloud services, particularly missing the platform-as-a-service services and native platform security features.

Instead of adopting a multi-cloud security model, you should adopt a cloud-native security model.

Companies that are successfully leveraging multiple cloud service providers are often doing so to meet local regulatory requirements or to use existing skills to build native solutions for each of the clouds separately.

Cloud Security Architecture

Designing your cloud security architecture requires a careful balancing act between the brave new world of cloud and the existing internal and external security requirements. Figure 1-2 illustrates the difficulties in balancing these requirements.
Figure 1-2.

Balance of enterprise cloud security

Azure Security Building Blocks

To implement your cloud security architecture, you can conceptualize the required components as reusable and modular building blocks. Figure 1-3 describes the concept of Azure security building blocks.
Figure 1-3.

Azure security building blocks

Workloads (or applications) are typically a collection of one or more Azure services. Depending on your platform controls, these can be manually provisioned Azure services or instances of internal products.

Products are your internal artefacts for Azure services, preconfigured to meet your known good configuration. Typically, these are infrastructure-as-code artefacts, such as Azure Resource Manager templates, Bicep files, or Terraform modules. Building your security controls into the product artefacts enables you to get to a consistent and secure state from the beginning of a workload life cycle.

Landing zone is your secured Azure platform. This means everything from the way you get your Azure (enterprise agreement, cloud solution provider, or others) to networking topologies or enforcement of tenant-level security configuration using policy initiatives.

Landing Zone Security

Out of the cloud security building blocks, the landing zone is key from the security point of view. A landing zone is where you enforce security controls for your products to keep their secure state. Landing zone is also where you prepare for an audit by providing assurance that the workloads deployed to your landing zone are meeting your security requirements. You can have multiple landing zones: for example, your migrated legacy applications might stay within a centrally managed landing zone within a spoke of your centrally managed network. By contrast, your new and experimental workloads might stay within a separate landing zone with more freedom to reach fast time to market but offering less integration to your shared services (such as network).

While the landing zone implementation might vary, the overall approach of securing a platform for your workloads to run is consistent.

Identity and Access Management

The first component of your landing zone security is identity and access management (IAM) . This consists of
  • Integration with existing IAM processes

  • Access control to the management and data plane

  • Access control through the SecDevOps life cycle

We will discuss identity and access management in more detail in Chapter 2.

Detection and Monitoring

The next component of your landing zone security is detection and monitoring. This consists of
  • Enforcing audit logging across the landing zone and any products or workloads deployed onto it

  • Centralized logging architecture

  • Integration with your security information and event management (SIEM) tool and your security operations center (SOC)

We will discuss detection and monitoring in more detail in Chapter 3.

Network Security

The last component of your landing zone security is the network perimeter. This consists of
  • Securing cross-subscription, cross-region, and cross-cloud traffic

  • Securing platform-as-a-service and infrastructure-as-a-service traffic

  • Securing application-level traffic

We will discuss network security in more detail in Chapter 4.

Cloud Security Framework

To secure your cloud building blocks, you will need to define your cloud security framework. A cloud security framework defines the architecture, policies, and controls to secure your cloud environment.

Cloud Control Frameworks

You may use any existing control frameworks to get started building your cloud security framework on. However, simply following a control framework does not mean you are “done” with security. You need to select the appropriate controls for your cloud security framework according to your organization’s risk appetite. Some control frameworks include
  • National Institute of Standards and Technologies: Cyber Security Framework.

  • Center for Internet Security’s Microsoft Azure Foundations Benchmark provides prescriptive guidance for establishing a secure baseline configuration for Microsoft Azure.

  • Cloud Security Alliance’s Cloud Controls Matrix (CCM) is a cybersecurity control framework for cloud computing.

  • Microsoft Azure Security Benchmark: Both documentation of best practices (Azure Security Baseline) and enforceable policy initiative.

Building Your Cloud Security Framework

To develop a cloud security framework that is both consistent with your existing security architecture and effective in securing emerging cloud services, incorporate it with your enterprise security architecture methodology, such as Sherwood Applied Business Security Architecture (SABSA). You can use SABSA to model cloud security in an agnostic manner, defining your control and enablement objectives before looking at control list from security frameworks or choosing your technical implementation.

Figure 1-4 illustrates the various inputs to the cloud security framework . Your cloud security framework should incorporate requirements from all these layers.
Figure 1-4.

Factors influencing your cloud security framework


In this chapter, we introduced the key tenets of cloud-native security. We also learned about the key decisions you need to make to build your cloud security framework.

Chapters 24 of this book define the landing zones further. You should focus on these chapters first, if you are representing a central unit, such as enterprise architecture, information technology, or information security.

Chapters 58 cover how to secure your products. You may use these chapters also as a hardening guide to protect your individual workloads. If you are a cloud solution architect looking for a checklist to secure a specific Azure component, feel free to skip ahead to the specific chapter that covers your workload.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.