Cloud security Architecture from the perspective of cloud consumers

Brief introduction

Cloud application developers and DevOps have successfully developed tens of thousands of applications for IaaS (Amazon AWS, Rackspace, etc.) and PAAs (Azure, Google App Engine, Cloud Foundry, etc.) platforms. These platforms provide basic security mechanisms such as authentication, Dos attack defense, firewall policy Management, logging, basic user and account management, but security concerns remain the primary obstacle to enterprise cloud implementations. For cloud security concerns, it is not widely possible to deploy virtual machines on the IaaS platform from a security configuration to manage user rights on the PAAs cloud.

Cloud security concerns and solutions are all dependent on context (schema), given that cloud services can be provided in a variety of ways, such as the service delivery model (SaaS, PAAs, and IaaS (SPI)) and the arbitrary mix of operational models (public, private, and mixed). Therefore, the solution architecture should be based on the cloud application architecture to fit these concerns and build security Escorts (controls).

So what are the architectural frameworks and tools available to cloud application architects and DevOps when they develop applications for IaaS and PAAs platforms? In this article, I'll discuss how to embed "enough" security into applications deployed on IaaS and PAAs clouds.

Cloud Security-common responsibilities

First, let's discuss cloud Security's operational model. By definition, cloud security for the public cloud is the responsibility of the cloud consumer (your enterprise) and the cloud service provider, but within the private cloud, consumers themselves need to manage all aspects of the cloud platform. Cloud service providers are responsible for ensuring common infrastructure, including routers, switches, load balancing, firewalls, virtual layer management programs (hypervisor), storage networks, management platforms, DNS, directory services, and cloud APIs.

The following figure depicts the security responsibilities at all levels of cloud services shared by both the provider and the consumer.

(Click the picture to see larger size)

It is important to perform a peak analysis of the cloud's service capabilities before signing a contract with a provider. This exercise provides metrics for cloud platform maturity, transparency, and compliance with enterprise security standards such as ISO 27001 and common standards such as PCI DSS, HIPAA, and Sox. The cloud security maturity Model can help accelerate the application to cloud migration strategy. Here's a set of principles you can use to evaluate the security maturity of your cloud service provider:

• Exposing security policies, compliance, and practices: cloud service providers should demonstrate compliance with industry-standard frameworks such as ISO 27001, SS 16, and CSA Cloud control matrices. A control that is certified by a provider should meet the control standards required by your enterprise data protection standards. When the cloud service meets the requirements of ISO 27001 or ssae 16, the scope of the control should be publicized. The cloud hosting managed data must comply with requirements such as PCI DSS, Oxley, and HIPAA.

· disclosed when required: cloud service providers should disclose relevant data when required to be disclosed due to legal or regulatory requirements.

· Security Architecture: Cloud service providers should expose security architecture details-they can help or hinder security management as required by enterprise standards. For example, a virtualized architecture that ensures that the hirer is isolated from one another should be exposed.

· Security Automation: Cloud service providers should support security automation by publishing APIs that support the following operations (HTTP/SOAP):

· Export and import security event logs, modify management logs, user authorization (permissions), user accounts, firewall policies, and access logs in XML or Enterprise log standard format.

· Ongoing security monitoring, including support for evolving standards such as cloud Auditing (Cloud Audit).

• Supervision and safety responsibilities: cloud consumers and providers of supervision and safety management responsibilities should be expressed clearly.

Cloud security threat and defense

Does cloud computing add a security threat to your application? What are the associated new threats? What traditional threats have increased or diminished? The answers to these questions depend on how the cloud service deployment and operation model are actually used. The following illustration shows the dependencies that security controls should consider when designing an application architecture for deployment to the cloud:

Public/mixed cloud-threat

Private cloud-threat

Defensive measures

IaaS

· OWASP Top 10

· Data leaks (insufficient ACLs)

· Because the administrative console incorrectly configured privilege escalation

· Leverage Virtual Machine Vulnerabilities

· Dos attacks via API

· The protection of the authorization key is too weak

· Virtual Machine Quarantine failed

· OWASP Top 10

· (Insider) Data theft

· Because the administrative console incorrectly configured privilege escalation

· Testing applications and APIs for owasp Top 10 vulnerabilities

· Hardening Virtual Machine Mirroring

· Security control including encryption, multi-factor authentication, good granularity authorization, log, etc.

· Security Automation-Automatically configure firewall policies, authorization accounts, DNS, application identities (see below)

PaaS

[In addition to the above threats, also include--]

· Permission upgrades through the API

· Permissions vulnerabilities in platform services such as Message Queuing, NoSQL, blog services

· The vulnerability in the Run-time engine caused the tenant's quarantine to fail

[In addition to the above threats, also include--]

· Permission upgrades through the API

In addition to the above threats to information confidentiality and integrity, threats to service availability need to be factored into the design. Keep in mind that the basic purpose of the security architecture is to design controls to protect the confidentiality, integrity, and availability of information and services (confidentiality, Integrity, availability, hereinafter abbreviated as CIA).

Threats to cloud service availability--cloud services (SaaS, PaaS, IaaS) can be compromised by DDoS attacks or by the wrong configuration of cloud service operators or consumers. These errors can spread across the cloud, destroying the entire network, system, and storage of the managed cloud application. In order to achieve continuous availability, the cloud application architecture should be able to withstand the destruction of a single data center or a geographic area (geographic Region). Recent Amazon Service Unavailable events--an elastic block store (elastic blocks storage,ebs) is not available for client applications that are deployed throughout the free area (availability Zone) of the US Eastern Region (East region)- is an excellent explanation of this weakness. However, the architecture can tolerate an entire area (Region) error application that greatly avoids the impact of this service being unavailable and continues to provide services to users. As a design principle, assume that everything in the cloud will fail and be designed for failure. The application should be able to withstand the failure of the underlying physical hardware in the geographic area and service crashes. Application and loose coupling of components can play a role in the latter case.

Cloud Security Architecture--planning

As a first step, the architect must understand what security capabilities the cloud platform (PaaS, IaaS) provides. The following figure explains the architecture of cloud service security.

(Click the picture to see larger size)

The security services and capabilities of cloud providers evolve and differ from one another. Therefore, you will often find that security mechanisms, such as key management and data encryption, will not be available. For example, the need for AES 128-bit cryptographic services for cryptographic security materials, such as the key for the storage of key management services. For these key services, you need to continue to rely on internal security services. For applications that rely so much on internal services, the "mixed cloud" deployment architecture pattern may be the only viable option. Another common use scenario is single sign-on (SSO). SSO that is implemented within the enterprise may not extend to cloud applications unless it uses a federated (Federation) architecture based on the SAML 1.1 or 2.0 supported by the cloud service provider.

The following are the cloud security best practices for defending against cloud service risks:

For the security-as-service (security-as-a-service) design architecture-application deployment on the cloud includes a variety of service choreography (orchestraion), including the automation of services such as DNS, load Balancing, and network QoS. The same category of security Automation includes firewall policy between cloud security zones, (SSL) certificate Provisioning (provision), Virtual machine system configuration, account permissions, and automation of log configuration. Deployment processes that rely on firewall policy creation, certificate provisioning, Key distribution, and application intrusion testing (pen testing) should be migrated to the self-service model. This approach will terminate human contact and will make it possible to secure a service scenario. Ultimately, this will eliminate the threat caused by human error, enhance operational efficiency, and embed security controls into cloud applications.

Implement voice recognition, access management architecture and practice-scalable, cloud-based, centralized and resilient architectures will rely less on network-based access control and ensure a strong user access management architecture. The Cloud access control architecture should give end users and authorized users all aspects of the user and access Management lifecycle: User Rights settings (username provisioning) and cancellation (deprovisioning), authentication, federation, authorization, and auditing. The sound architecture makes it possible for identity and access services to be reusable under all scenarios in the public, private, and mixed clouds. At the same time, it is good practice to adopt security token service and appropriate user and authority setting and audit trail. Federated architecture is the first step in extending enterprise SSO to cloud services. Here, you can see the 12th volume of the Cloud Security Alliance for more information.

Automate protection with APIs-any new security service should have an API (REST/SOAP) to support automation. APIs can help automate firewall policies, configuration hardening (revisit hardening), and access control when applying deployment. This can be accomplished by using an open-source tool, such as puppet, with APIs provided by the cloud service provider.

Always encrypt or obscure sensitive data-today's private cloud applications may be deployed in the public cloud tomorrow. So there is no future operational model, and the application architecture should encrypt all sensitive data.

Do not rely on IP address to do authentication services-the IP address on the cloud is loose, so in order to manage the access control of the network, you can't just depend on them. Use a certificate (self-signed or from a trusted CA) to make it possible to connect through SSL between services deployed on the cloud.

logs, logs, logs--the application should centralize logging of all security events, which helps create end-to-end transaction views and is inherently no. For security incident events, log and audit trails make the only reliable data that is used by forensics engineers to investigate and understand how the application is abused. The cloud is resilient and logs are fast moving, so it is critical to periodically migrate log files to different cloud or enterprise data centers.

Continuous monitoring of cloud services-monitoring is an important feature, given that defense controls may not meet all corporate standards. Security monitoring should take advantage of the logs, APIs, and managed cloud applications generated by cloud services to perform security event associations. The Cloud Audit (cloudaudit.org) provided by CSA can be used to accomplish this task.

Cloud Security Principles

Each enterprise has different levels of risk tolerance, which can be seen from product development culture, new technology adoption, IT service delivery model, technology strategy, and investment in security tools and capabilities. The technology architecture should support this model when business units decide to use SaaS to generate business benefits. In addition, the security architecture should be consistent with the technical architecture and principles. The following are examples of cloud security principles that an enterprise Security architect should consider and customize:

Services running on the cloud should follow the principle of least privilege.

Isolation between multiple security zones should be ensured by using layered firewalls-cloud firewalls, Virtual Layer management program (HYPERVISOR) firewalls, guest system (guest) firewalls, and application containers. Firewall policies on the cloud should adhere to the data-sensitive, trusted zone isolation criteria.

Applications should use End-to-end Transport layer encryption (SSL, TLS, IPSEC) to ensure that data is secure between applications deployed on the cloud and between applications deployed within the enterprise.

An application should extend authentication and authorization to a trusted security service. Based on SAML 2.0, single sign-on should be supported.

Data concealment and encryption should be based on data sensitivity and consistent with enterprise data purification standards.

Applications located in a trusted zone should be deployed on an authorized enterprise standard virtual machine image.

When deploying virtual private cloud, VPC, you should use industry-standard VPN protocols such as SSH, SSL, and IPSec.

Security monitoring on the cloud should be integrated with existing enterprise security monitoring tools through APIs.

Cloud Security Architecture Pattern

Add appropriate protection to the cloud during the architecture security control of the CIA can protect against cloud security threats. Security control can be delivered as a service to a provider, enterprise, or Third-party provider (security, service, Security-as-a-service). Security architecture patterns are often elaborated from the perspective of security control (security guard)-technology and process. These security controls and source of service (enterprise, cloud provider, third party) should be highlighted in safe mode.

The security architecture pattern, like Polaris, accelerates migration to the cloud and manages security risks. In addition, the cloud security architecture model should emphasize the trusted boundaries of different services and components deployed on top of cloud services. These patterns should also indicate standard interfaces, security protocols (SSL, TLS, IPSEC, LDAPS, SFTP, SSH, SCP, SAML, OAuth, Tacacs, OCSP, and so on) as well as authentication, token management, authorization, cryptographic methods (hash, symmetric, asymmetric), Cryptographic algorithms (Triple DES, 128-bit AES, 448-bit encryption (Blowfish), RSA, etc.), security event logs, truth sources for policy and user attributes (Source-of-truth), and coupling models (tight or loosely coupled). Ultimately, patterns should be used to create checklists of security checks that need to be automated with configuration management tools such as puppet.

Typically, for each security service that is consumed by cloud applications, the pattern should emphasize the following attributes (but not limited to this):

Logical location-local to cloud services, internal cloud, third party cloud. Locations can be limited by performance, availability, firewall policies, and service supervision.

Protocol-What is the protocol that invokes the service? For example, a restful service request based on a X.509 certificate.

Service function--what is the function of the service? such as encryption, logs, certifications, and machine fingerprints.

Input/output-input (including the control method), what is the output from the security service? For example, enter the =xml file, and the output = XML file that contains the encrypted attribute.

Control description-What security control does the security service provide? For example, defense information confidentiality, user authentication and application certification.

Performer-who is the user of the service? For example, terminal (end point), end-user, Enterprise Manager, it auditor and architect.

The following figure is a subset of the Cloud Security architecture schema published by the Open Security Architecture Group (open Secure Architecture group,opensecurityarchitecturegroup.org).

This pattern shows the performer (architect, end users, business managers, IT managers, and the delivery of systems (terminals, cloud, hosted applications on cloud, security services), and controls used to protect the performer and system (access management, DOS defenses, border protection, key encryption and management, etc.). Let's take a closer look at the details of this pattern description.

Cloud services Provider Infrastructure security Services (control)

As this model shows, cloud service providers should provide security controls for DOS protection and for confidentiality and integrity protection against conversations initiated by mobile phones and PCs. Typically, these sessions are initiated by a browser or client application and are transmitted using TLS until the load balance managed by the cloud service provider. Cloud service providers often do not share DOS protection because hackers can easily misuse it.

Application Security Services for

(internal or cloud service provider)

Security services, such as user identification, authentication, access management, device identification, cryptographic services, and key management, can be combined in both the cloud service provider and the Enterprise data Center.

The second pattern in the figure below shows the identity and access mode from the CSA identity domain.

(Click the picture to see larger size)

This model presents a common set of cloud access control cases, such as user registration, authentication, account permissions settings, policy management (policy enforcement), logging, auditing, and metering. It emphasizes the delivery of the service of the performer (end user, enterprise business user, third party technician, cloud service owner) and hosted services within the cloud, enterprise, or third party.

This model describes the following:

Cloud service Provider Identity Security Service (control)

The following services are running on the cloud:

The authentication service supports user authentication initiated by the Enterprise Portal (the local AUTHN interface) that is often transmitted using the SAML protocol. Authenticated sessions are maintained in session storage on the cloud.

The account and user data settings service supports the creation of new accounts and user profiles-often by calling SPML (service provisioning Markup Language) or a specific API for a cloud service provider. User data storage and user data storage.

Cloud policy Management services are used to manage policies, such as indicating which resources on the cloud can be accessed by end users. With this service, the cloud service owner (Enterprise) can perform administrative functions, and end users can request access to the cloud resources. Cloud policies are stored in the cloud policy store.

Authentication Service log and audit service support dual functions, first, cloud events (including security incidents) of the log, followed by the audit. This service can be accessed using cloud audit protocols and APIs.

The metering service tracks the use of cloud resources. This service can be used by the finance Department for charges or for cost reconciliation.

Enterprise Identity Security Service

In this mode, a subset of the application is hosted within the enterprise:

The Cloud Registration interface provides user interface services for registering, managing, and setting up new cloud resources. Authentication and authorization are managed through cloud services.

The cloud uses a report interface that can be used by end users to claim the use of reports.

Cloud Configuration (provisioning) services are used to configure cloud resources (computing, storage, networking, application services). Access control (AUTHN, Authz) and session management are managed on the cloud server side.

Identity Security Service in a third party

In this mode, the cloud application relies on a third party's body recognition service that is provided and hosted by a third party. These services support Third-party users accessing cloud resources and performing business functions on behalf of the enterprise. such as backup and application monitoring services. In this model, user settings, authentication, and access management functions are delegated to third party services.

Conclusion

By understanding what services can be leveraged from a cloud platform or service provider, you can build security into your programs without having to recreate them within the boundaries of your application-thus avoiding expensive "add-on" safeguards. A good practice is to create security principles and architectural patterns that can be applied at the design stage. Architectural patterns can help in the design phase by figuring out where (cloud, or third-party, or enterprise) controls are implemented, so that proper security controls are incorporated into the design of the application. When creating a cloud security model, remember the relevant threats and the "risk appropriate" principle. Ultimately, the cloud security architecture should support development needs to protect the confidentiality, integrity, and availability of data processed and stored in the cloud.

(Responsible editor: Lu Guang)