Perfecting the second iteration of your cloud security architecture is very easy. The real challenge is having a proper first iteration. If the former is the case, engineers will have to spend weeks resetting their configurations or starting the implementation from scratch. Worse still, your initial cloud security posture may have more holes in it than Swiss cheese than Emmental.
Cloud vendors provide thousands of articles, tutorials, and web pages that explain every detail of cloud security. But what matters most for the first design is to guide security engineers to systematically develop a “grand design” to protect the cloud infrastructure. The methodology should be useful to both experienced architects and architects working with a particular cloud for the first time.
So, how important are a well-designed AWS framework, the Google Cloud Security Foundation guide, and the various Microsoft Azure frameworks? Let's analyze the Security Guide offerings of these popular vendors.
Google Cloud Security Foundation Guide
Google's 130-page GCP Security Foundation Guide introduces Google's GCP security philosophy and principles and a model of a GCP environment that serves as an example in the central portion of the document. It covers in detail eight security-related topics, from network, identity, and access management (IAM) to billing and application security (subchapters II.5 to II.12, see Figure 1). The centerpieces of all these subchapters are architecture diagrams and security architecture patterns.
Who is the best?
Figure 2 depicts the document style: a large architectural diagram, explanation text, and a table containing details for setting up the exact configuration. Motto: “Give a chart and explain it.” Therefore, security engineers who are new to Google Cloud Platform or who are tackling one of these security topics for the first time benefit from a well-crafted initial design pattern that they can review and customize to fit the company's concrete context.
Well-designed AWS framework
Amazon actually launched the AWS Well-Architectured framework in 2015. It initially consisted of five pillars but today includes six: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. In recent years, AWS has supplemented these pillars with technology and industry-specific lenses (Figure 3).
The AWS Security Pillar Framework documentation consists of 155 pages detailing 66 security topics. It describes needs and requirements organized into seven areas: security foundation, identity and access management, detection, infrastructure protection, data protection, incident response, and application security. Architecture may differ from Google Cloud Platform architecture. However, the main difference in AWS's approach is providing topics.
Google Cloud Platform puts architecture diagrams at the center of the explanations, while AWS provides a well-designed framework with (almost no) diagram. AWS follows a very strict structure, as Figure 4 shows. It's the same for all topics: desired outcomes and anti-patterns (i.e., bad designs that are commonly observed), followed by a short risk statement explaining the consequences of not addressing a particular topic appropriately. Next comes implementation guidance with a mix of tasks and steps. Topic descriptions conclude with links to additional articles that provide further insights and highlight other closely related AWS Framework topics.
Who is the best?
So, who is the AWS framework useful for? It is clearly every project manager's best friend. It lists the designs that security engineers must submit and which engineers must implement. However, architects should not expect any design or pattern to help them design solutions, although the framework contains links to information that may be useful for the latter purpose.
Azure security documents
Azure contains not just one framework and methodologies, but several competing and overlapping frameworks and methodologies. In particular, there is the well-designed framework, Architecture Center, and Azure Security Essentials documentation. As Figure 5 shows, the latter has two sections that focus on security infrastructure topics: Securing Cloud Solutions and Protecting Azure Resources. Both sections link to multiple web pages. In the case of cloud security best practices, they cover different security areas, from networking to PaaS security. Individual pages offer subtopics, often with best practices explained in a single sentence — “Don't set permission rules for broad domains” or “Enable single sign-on” — followed by more short explanations. But how does Azure Security Essentials documentation help security engineers structure their work and design security architectures?
Who is the best?
The documentation provides great explanations of key topics and motivates readers to click on links to read additional articles, helping them increase their overall understanding of security topics. However, you do not learn civil engineering efficiently by reading all the relevant Encyclopedia Britannica articles. Likewise, junior security engineers in Azure learn concepts but don't learn a methodology or get a definitive to-do list when going through this documentation. There are also no architectural diagrams explaining the interaction between the different Azure cloud components and security services.
Also worth noting is Microsoft's suite of Azure Architectures, many of which address security-related topics (for example, “Secure MLOps Solutions with Azure Network Security”). Again, it is well written and informative. It helps architects and engineers understand best practice designs for specific and even very specialized topics. However, the diagram view is not a systematic introduction that will help security engineers in an initial IaaS or PaaS data center.
Then there is the well-designed Azure framework. It is based on five pillars, one of which is dedicated to security. The Security pillar covers five areas – identity management, protecting your infrastructure, application security, data sovereignty and encryption, and security resources (Figure 6). Unlike AWS, the Azure framework does not provide a structured list of requirements. Instead, it succinctly explains the concepts and links to additional resources – not directly executable, neither for security engineers nor for project managers or architects.
minimum
Azure has many educational resources and documentation for all security-related and non-security-related features, but the learning curve for security engineers is high. Architects have to self-structure the security domain and consider how to address different topics in their grand design. In contrast, the Google Cloud Platform Security Foundation Guide provides basic, ready-to-use architectural diagrams that address the interaction between various cloud security features and components for critical security domains. Finally, there's the well-designed AWS framework: stodgy, Prussian, humorless, precise to the point, and overly structured. It provides a clear overview and list of things to do. It may be reusable as input for the initial definition of work packages for other clouds.