cloud security architecture

Why is a cloud security architecture important?

The difference between "cloud security" and "cloud security architecture" is that the former tends to be built up from problem-specific measures while the latter is built down from threats. A cloud security architecture can reduce or eliminate holes in security that point-solution approaches are almost certainly going to leave. It does this by building down -- defining the threats starting with the users, moving to the cloud environment and service provider and then to the applications. Cloud security architecture can also reduce redundancy in security measures -- things that won't contribute to threat reduction but will increase both capital and operations costs.

A cloud security architecture also organizes security measures, making them more consistent and easier to sustain over time, in particular during cloud deployment and redeployment. Security often erodes because it's illogical or complex, and these defects can be identified with a proper cloud security architecture.

Elements of a cloud security architecture

Probably the best way to approach a cloud security architecture is to start with a statement of goals.  The architecture has to address three things, an attack surface presented by external access interfaces, a protected asset set that represents the information being protected, and attack vectors and mechanisms that are designed to inflict indirect attacks somewhere along the path -- including the cloud.

The goal of a cloud security architecture is met through a series of functional elements. These elements are often considered separately rather than as part of a coordinated architectural plan. This includes access security or access control, network security, application security and contractual security as well as monitoring, sometimes called service security. Finally, there's data protection, which is the measures that are applied at the protected-asset level.

A complete cloud security architecture addresses the goals by uniting the functional elements.

Cloud security architecture and the shared responsibility model

Security and security architectures for the cloud aren't single-player processes. Most enterprises will retain a large chunk of their IT workflow within their data center, local networks and VPN. The cloud adds additional players to this, so it's critical that a cloud security architecture be a part of a broader shared-responsibility model.

A shared responsibility model is both an architecture diagram and a contract form. It exists in a formal sense between a cloud user and each cloud provider -- as well as providers of a network service if they're contracted separately. Each will typically divide the components of a cloud application into layers, with the top layer being the responsibility of the customer and the bottom layer being the responsibility of the cloud provider. Each separate function or component of the application is mapped into the appropriate layer depending on who provides it. The contract form then describes what each party is responsible for doing, how the boundary points are recognized and how problems are isolated and assigned to a party.

A master model can be constructed to combine the individual responsibility models for all the service providers used. If done carefully, this is a critical tool in assigning fault and coordinating remediation when something goes wrong.

Cloud security architecture design patterns

There are two levels of "design pattern" used in cloud security architectures. The general, high-level patterns describe the:

• security controls -- defining the overall interplay of the functional elements in a security architecture;
• trust boundaries -- defining the relative level of security and the scope of any identity or permission rights;
• standard interface points and API models;
• encryption algorithms and key management;
• token management for identity and permission exchanges; and
• security event logging.

Those developing their own cloud applications can utilize design patterns to create a secure application access framework. Note that this option is not likely available for third-party software, but it may be possible to audit the design patterns used by the vendor as part of the selection process. Design patterns also typically address access security, but won't eliminate the need for other functional elements of a good security architecture, introduced above.

The three dominant cloud security architecture design patterns are the federated identity pattern, the gatekeeper pattern and the valet key or token that conveys specific rights to access a resource. The first is a means of establishing user identity and sharing identity credentials. The second defines a "firewall" element that sits between user and resource and validates credentials and rights. The third is a token or mechanism to allow a user (or module) to access a resource or service for a specific, limited purpose.

Variations on the theme for SaaS, IaaS and PaaS

Cloud services vary from IaaS where a virtual host is provided, through PaaS which incorporates platform tools and middleware, to SaaS where cloud providers offer the entire application. The shared responsibility model will look different for each type of cloud service.

With IaaS, the cloud provider is offering only a hosting resource, and the majority of application-related security responsibilities will lie with the customer or a contracted agent. The relationship between the network, application and the IaaS is defined by network middleware. IaaS places greater network security requirements on the user.

PaaS will typically include middleware and other software elements. These elements are presented as "services" to the application. This means that the cloud security model must focus more on the securing of services and the creation of trust zones -- which include the service elements such as microservices that make up an application. The user is responsible for maintaining overall application security.

With SaaS, the cloud provider has responsibility for security within the application, meaning internal component workflows. The network relationship between the SaaS services and the user is typically defined as a set of RESTful APIs. Both the user and network provider share responsibility for the security of access to those APIs.

Where there are multiple cloud service types in use, users often employ the concept of "cloud security postures" and cloud security posture management (CSPM) to automate security responses across the full collection of cloud services.

Cloud security architecture planning and best practices

The best way to plan and execute a proper cloud security architecture is to work outward from the key resources. This means that an organization should identify any APIs that are used to connect workflows within the cloud between applications, as well as those that connect the cloud with the data center or other clouds and databases. These define the protected assets.

Each of these assets is referenced by users, applications or components. And each of these references must be validated, meaning that the elements certified to use them have to be identified and their scope of use established. This creates a chain of reference that will ultimately reach the users themselves.

The functional elements of a cloud security architecture (access security, network security, application security, contractual security and monitoring and data protection) are then applied within this structure. At any point where a protected asset or reference chain is exposed, it creates an entry point for a security threat. Most cloud security architectures will impose layers of protection based on those five functional elements, a "defense in depth" model.