History of Public Cloud Security

If the answer to all three questions is yes, then your organization must have considered security very thoroughly and must belong to the small percentage of companies that focus on security. The bad news is that this approach could need a major overhaul when your organization decides to leverage cloud computing services.

Traditional security in the IT world was implemented from the mindset of limiting access boundaries to applications. In traditional security architectures , security controls resided in the data center and applications lived happily under the protection of the data center. Organizations had complete control of the data center and could operate the security controls the way they wanted in terms of racks, cables, rooms, and access to comply with security policies. This required proper management.

More often than not, reluctance to move to public cloud architectures is due to the fear of giving up data centers rather than any other rational cost benefits. The fear of not being able to trust someone else is understandable. And even with organizations that are brave enough to go ahead, the estimation provided by the engineers to implement new security controls can seem like a gigantic investment, as it also must include the cost of procuring new tools, teaching new skills, and implementing the system.

Risk assessment needs to be based on the organization’s risk appetite, so it can evaluate which security controls could live in a public cloud. Normally, when organizations perform this exercise, it is an eye-opener and more often than not the gaps are really wide. Most traditional security controls are not applicable to risk assessment, as the parameterization in the public cloud is not as strong as with traditional or on-premises data centers.

Enterprises are rapidly moving toward cloud technology and cloud services. This trend will only increase in the coming future. Cloud computing is not the future anymore; it is already everywhere, although most end users don’t even realize it. In the cloud computing world, security policies need to change their focus from “controlling access” to “protecting data”.

In cloud computing, two security controls become more important than ever before. The first is certificate management. It plays a very important role in all web service security solutions. Organizations need to make sure that they can create, renew, and revoke certificates from a central place in no time. The requirements to use the Public Key Infrastructure (PKI) must be well established, understood, and followed. The other control is Identity and Access Management (IAM) , which has become the most important security control in the cloud computing world, where a lot of solutions like OpenID Connect (OIDC) , Security Assertion Markup Language (SAML) , and Open Authentication (OAuth) exist.

With cloud computing, security breaches can happen easily at multiple levels of technology. Therefore, defense-in-depth and complete mediation are the most important principles to follow. For business leaders, it’s hard to know whether a cloud service is secure enough for their IT applications to work accurately. Business leaders have to trust their cloud providers in this regard. But security is a shared responsibility , and no cloud provider will provide a full guarantee for securing the workloads. The shared responsibility is the very reason that security architecture needs to be reconstructed in the view of risk assessments for the cloud computing model . See Figure 1-1.

A model of the control provider, multitenancy risk, protest data, S a a S control, visualization security, and protect the workload of public and private cloud security.

In a nutshell, cloud computing growth has been truly astonishing and it will continue to grow in the future. Although cloud computing has many benefits, it doesn’t reduce existing network security risks .

• Security risks threaten the data center and network change once the applications move to the cloud. Such security risk remains. For example, data center applications use a wide range of ports that make traditional security considerations ineffective when those applications move to the cloud. See Figure 1-2.

A block diagram represents the business model, threat assessment, security culture, security policies, and security controls of network security.

• Cloud computing works on the model of shared resources . It is best to separate mission-critical applications and data applications into secure network segments. This separation is also known as zero trust segmentation. See Figure 1-3. It is very straightforward to implement zero trust segmentation on a physical network of the enterprise data center using firewalls and virtual LANs based on the application and user identity. However, in a cloud computing environment, direct communication between the virtual machines occurs constantly. This makes the segmentation task difficult since cloud computing works on the concept of shared resources.

A flow diagram from 1 to 4. They are never trust always verify, least privilege and default deny, full visibility and inspection, and centralized management.

• In cloud computing, virtual workloads can be modified in seconds/minutes. But in a traditional workload, security and other configurations can take hours. This imbalance causes problems in security policy and workload deployment during cloud migration. See Figure 1-4.

A circular model represents the D D o S, hygiene and visibility, access management, and configuration issues of cloud security configurations.

When you dive deeper into cloud security considerations , you see that it is basically a shared responsibility between the cloud providers and the customers. In a shared responsibility model , there are three main categories:

• Completely the provider’s responsibility: Securing the infrastructure as well as patching the compute resources

• Completely the customer’s responsibility: Managing users and access privilege, preventing unauthorized access to the data, encrypting data and protecting cloud resources

• Responsibilities that differ based on the cloud service model are as follows (see Figure 1-5):

  • Infrastructure as a Service

  • Software as a Service

  • Platform as a Service

A text of the l a a S contain infrastructure, P a a S contain platform, and infrastructure, and S a a S contain applications, platform, and infrastructure.

• Threat intelligence : Third-party cloud security vendors work by collecting all the cloud-native logs with internal data, such as asset and configuration management systems, and vulnerability detection, as well as external data such as threat intelligence feeds, and so on. They also provide tools to visualize and query the landscape and incident response times. Real-time alerts about policy violations shorten time to remediation. There are various types of intelligence threats, as highlighted in Figure 1-6.

The four blocks represent strategic, tactical, operational, and technical threat intelligence types.

Cloud Security Boundaries and Responsibilities

Decoding what “cloud-ready application ” means is like opening a can of worms. First of all, there are no basic steps, as it’s still a new topic and can depend on assumptions and opinionated views. If you Google “cloud-ready” it’s sometimes defined as “designing applications for the Internet”. Well, frankly that’s like saying “a car is designed for the road”. Although this is not wrong, such definitions are not helpful, as it is hard to write any requirements with this explanation.

Given the evolution in technology today, being “cloud-ready” could be as simple as containerizing an application and hosting it over a managed infrastructure. While this is partially correct, cross-cutting concerns like security and resiliency are the ones that create havoc in the quest to become cloud-ready. The scope of cloud-ready does look small and manageable at first, but the further down it goes, the bigger it gets.

Cloud-ready applications adhere to the following three principles (see Figure 1-7):

• The infrastructure must no longer be perceived as a bunch of physical boxes of hardware, but rather a bunch of managed services. In the cloud-ready world, an infrastructure platform is an integrated set of equipment, operating software, middleware, databases, and centralized services that help the applications run seamlessly.

• The infrastructure platform includes the provisioning, hardening, and configuration of the platform services and is based on easily-scalable, hyperconverged infrastructure. The infrastructure platform must be easily reproducible and leverage the Infrastructure as Code (IaC) .

A model of on premises, I a a s, P a a s, and S a a s with the application, data, runtime, middleware, operating system, virtualization, networking, storage, and servers.

These are possible by embracing new resilience patterns like retry, circuit breakers, Command and Query Responsibility Segregation (CQRS) , sharding, and many more. Technology architecture plays an important role here, by designing systems that are loosely coupled, auditable, and based on proven resilience patterns. It is also common to embrace principles of microservices for application development and event sourcing via immutable events for auditing. In addition, any file sharing or direct database interactions need to be replaced with asynchronous or synchronous communication styles.

A model of a cloud and 4 circles of threat monitoring, identity and access management, encryption, and security testing.

Traditional security controls are not enough and security architecture needs revamping. Traditional security was implemented from the mindset of limiting access boundaries toward the applications.

These three pointers highlight where energy and design efforts need to go to create a cloud-ready enterprise application. More importantly, a cloud-ready organization also needs a cultural change , which includes embracing new skills. To begin, your organization needs a good vision and strategy. Such transformations can take time. Just like it takes a whole village to raise a baby, it will take the whole organization to become cloud-ready!

Pattern-Based Security

We often talk about modern principles like infrastructure as code, microservices for applications, service-oriented approaches with enterprise bus, and so on. How often do we underestimate the work that needs to go into these principles?

In the good old days, the simple architecture of the client-server database was centralized. Its simplicity was the key to keeping it running in a confined network space. Access was controlled using simple firewalls and login passwords with basic authentication.

Figure 1-10 shows how to identify the list of threats for each asset and identify the controls that mitigate each threat. Once the assets are identified, the next step is to create an asset-centric access list for each asset.

A model is labeled for each asset, creates a list of threat for each asset, controls which mitigate each threat, and create asset centric access control list.

These worked brilliantly in the 1990s, as connections were small and distribution was not a requirement, but a wish. The challenge in those days was about balancing cost to meet timelines rather than dealing with complexity. Architecture was not in the limelight, as more often than not, the architecture would just be a few flows in a client-server database set.

Times have changed. Distribution is a requirement and delimiting access is not considered a smart thing to do. Today, client-server-databases are considered an anti-pattern to modernization. Speaking about client-server-databases sounds like the 1990s.

Today’s architecture needs to be built on high-level principles of scalability , with the core requirements to protect data and allow access in a controlled fashion. The needs of a scalable architecture are moving to a pluggable interface, where ubiquity is the norm. Client-server, microservices, and service-oriented architecture all work together brilliantly well in a pluggable way in hybrid cloud models. But to do this, the architecture roots have to be very strong, and security is one of the biggest pillars of this foundation. See Figure 1-11.

Two model diagrams, with the left model representing a combined set and the right model representing a separated set.

A fundamental part of a scalable, modernized architecture is pattern-based security. This is fundamental for companies looking at a hybrid cloud model , as networking partitions will blur over time and applications are becoming more accessible and vulnerable than in the 1990s.

Pattern-based security is based on the fundamentals of compartmentalization with security zones. The compartmentalization is logical and achieved with security dimensions. As a simple example, assume you have a very simple service-oriented architecture with three layers—a consumer, an API gateway, and a provider. The layers are one security dimension. Then comes the famous CIA (Confidentiality, Integrity, and Availability) ratings, which is another security dimension. Another security dimension is the consumer type, internal or external. Based on your organization, more security dimensions could be added. See Figure 1-12.

A model which includes non repudiation, authentication, confidentiality, integrity of information, and availability of information.

This table can go on, to an enterprise security model . What is important is that it is clear how many security zones you need. As a rule of thumb, there should not be more than ten security zones.

The aforementioned security zones and their security controls are only examples. A real example of any medium-to-large enterprise would include more. (At rare times, it could be more than ten zones. If this is the case, the architecture may be very complex due to other reasons not related to security.)

Each of these security controls must be then governed with security policies and rich sets of standards, guidelines, and acceptance criteria, probably also dash-boarded to show the weak points of the application landscape.

Such a model is a holistic approach toward pattern-based security and has rich scalability. Such a model allows decision-making toward a hybrid cloud strategy, enabling decisions like what to offload into the public cloud and what to retain in private data centers.

Pattern-based security is a prerequisite of any scalable, modernized architecture . It keeps the complexity in control and still leads to a complete mediation. In addition, such a strong foundation with pattern-based security enables higher management to make strategic decisions on the future of data centers and, more importantly, estimate costs better.

In addition to understanding pattern-based security, you need to understand the software layers that create a scalable application security model for moving to a distributed architecture. See Figure 1-13.

A circular model includes the human layer, perimeter security, network security, endpoint, application, data security, and mission critical assets.

Azure’s Defense-in-Depth Security Architecture

Defense-in-depth is a security risk management approach that defines multiple security layers in an IT environment, so that if a security attack is not caught by one layer, it will more likely be caught by another layer. Multiple security layers increase the overall security score of an environment and reduce the probability of a security breach.

Looking back at the Open Systems Interconnection (OSI) model , there are seven layers. Possible threats and security measures can be applied to mitigate/control the threats.

A table depicts the protocols, possible threats, and security measures of the O S I layers such as application, presentation, session, transport, network, datalink, and physical layer.

Implementing security at every OSI layer will never protect against all cyberattacks. But the more the layers that are protected, the more hardened your application and system are from unintentional mishaps. Security is a continuous beast and it needs to be looked on with discipline and knowledge in order to close up any new open holes.

Although it is rather hard to project cost to implementing security measures, it should be done from a business mindset. This implies that mission-critical applications and data need to be better protected, as they can put an enterprise out of business; this risk should be addressed.

Conclusion

This chapter explored the various dimensions of cloud security. It explored in detail the history of security and the public cloud. It also took a deep dive into the boundaries and responsibilities to be considered when adopting cloud security. You also learned about the need for pattern-based security and about Azure’s defense-in-depth security architecture.

This next chapter explains how to configure Identity and Access Management using Azure Active Directory with various features.