The Cloud Security Alliance (CSA) 's latest report, "The main threat to cloud computing", presents some emerging risks and modifies and reordered existing risks. The report, entitled "Nine sins: the main threat to cloud computing in the 2013", is based on feedback from cloud computing and the security community, where many individuals and organizations weigh the risks they face, which are the most recent reports that deserve more attention.
As one of the three co-chairs of the Working group responsible for the report, I raised a number of questions about the fourth threat on the list, such as what does "unsafe interfaces and APIs" represent?
What are the risks involved?
And how does the organization assess and ensure these cloud APIs?
In this article, we will explore the security of cloud APIs and answer these urgent questions.
Defining the risks posed by unsafe APIs
First, for those who are unfamiliar with cloud APIs and how cloud APIs are used, cloud APIs are essentially software interfaces, and cloud providers use cloud APIs to allow users to manage cloud services, typically such as standards-based cloud APIs. APIs can make many common cloud processes easier, automate more complex business requirements, such as configuring various clouds across multiple vendors, and applying third-party management platforms for cloud and internal deployment systems.
However, the Cloud API pays particular attention to cloud providers and cloud customers. As described in the nine sins report, unsafe cloud APIs pose multiple risks in terms of confidentiality, integrity, availability, and accessibility. Although all cloud service providers should pay close attention to the security of their APIs, they vary from person to person. Therefore, it is important to understand how to analyze the security of the Cloud API.
A good starting point for analyzing the cloud provider API is to view the Gunnar Peterson Web Services Security Checklist (PDF), which presents many of the same issues as the CSA report. The following are some of the key areas that customers should focus on:
Transport security. Most APIs are provided through a variety of channels, but APIs that need to interact or carry sensitive data should be protected through secure channels, such as TLS or IPSec. Establishing an IPSec channel between a cloud service provider (CSP) and a customer can be difficult or impossible, so establishing a TLS channel is easier to implement. However, this poses a number of potential problems, such as the generation and management of internal or (more commonly) valid certificates for external certificate authorization, the configuration of platform services, software integration, and end-to-end protection, if the proxy platform must be used as intermediate media.
Authentication and authorization. Cloudy APIs are primarily concerned with authentication and authorization, so this is also a key area of concern for many customers. Questions to ask CSP include: Can the API manage the encryption of username and password? Can I manage two-factor identity authentication properties? Can you create and maintain fine-grained authorization policies? Is there continuity between the internal identity management system and the attributes? and is there continuity between the internal identity management system and the API extension attributes provided by the cloud provider?
Code and development practices. Any APIs that are delivered through JSON and XML messages, or that accept user and application input, must undergo rigorous testing of standard injection attacks and cross-site request forgery (CSRF) attacks, schema validation, input and output encoding, and so on.
Message protection. In addition to ensuring that coded builds follow best practices, other factors that the API primarily considers include message structure, integrity validation, encryption, or encoding.
How to secure the Cloud API
Once the organization has a good grasp of the problems posed by the unsafe APIs, it can take the best measures to ensure the cloud API. First, through the cloud provider's API documentation, determine its API security, including existing application assessment results and reports, which are documented in the 16th report of the Forensic Business Guidelines (Statement on standards for attestation engagements no.16) or other forms of reporting that demonstrate security best practices and audit results. The Dasein Cloud API is a good example of open source and extensible Cloud API documentation.
In addition to the documentation, customers should request to the cloud provider that they be able to conduct penetration testing and vulnerability assessments of the APIs, or that the cloud provider can complete these tests themselves, or that these tests be completed by a third-party vendor, and that customers reach a confidentiality agreement with potential customers so that they can assess security practices. Leverage the combination of network and application controls, as well as good development practices and QA testing, to protect the Web Services API from the top 10 vulnerabilities in open Web application security projects that are common to the list of application vulnerabilities.
In addition, many cloud service providers provide customers with cryptographic keys that take advantage of the access and authentication mechanisms of the APIs. Protecting these keys is critical for both customers and cloud service providers.
Security policies ensure the rationalization of key generation, transmission, storage, and processing, and that keys should be securely stored in hardware security modules or other encrypted file stores. You should avoid embedding keys in configuration files or other scripts, or embedding them directly into your code, as these will update the key, making the key a nightmare for developers and others.
Cloud service providers, such as the Amazon and Microsoft Azure, include a hash based message authentication code with symmetric keys, which is both integrity and avoids sharing secrets through untrusted networks. Any third party that builds the CSP API should follow this recommendation, with the emphasis on the key (and General API Security), as the CSP does.
Conclusion
With the development and integration of cloud applications, there is no doubt that cloud users are facing a serious threat posed by unsafe APIs. Fortunately, suppliers are also facing the same problem, this issue will not appear in the next generation of CSA list of popular threats.