11.11 The Biggest Deals of the Year. 40% OFF on selected cloud servers with a free 100 GB data transfer! Click here to learn more.
In your application deployment environment, do you experience the following situations?
- Sensitive data, such as database connection strings containing passwords, is stored in the configuration file on the production environment’s server.
- Sensitive information is packaged into a configuration file in the project, and release to various environments.
- During Docker orchestration, sensitive information is stored directly in environment variables.
If any of the above sounds familiar, then your production environment may be at risk of data leakage. Read on further to understand how you can increase your data security with Alibaba Cloud Application Configuration Management (ACM).
Brief History of Configuration Development
- Static Plaintext Configuration: The configuration was initially placed locally in the form of a plaintext file or environment variables.
- Configuration Center-Based Plaintext Configuration: With the rise of microservices and configuration center technologies such as Alibaba Cloud’s ACM, configuration began to shift to the configuration center.
- Configuration Center-Based Configuration Security Enhancements: The configuration center begins to integrate various security tools for configuration enhancements.
Let’s look at why relying solely on the first two methods can be problematic.
Security Problem Overview
Security Problems with Static Plaintext Configuration
Before the distributed Internet architecture, the initial configuration were stored in static files. For example, database connection data (including passwords) is manually packaged in various environments (such as development, testing, pre-release, production) as shown in the following figure:
The biggest problem with this deployment method is that a significant amount of sensitive information will get stored in the configuration file. Regardless of what development, testing or O&M personnel did to secure the file, it is easy for hackers to obtain sensitive data. Although the methods of packaging and deployment have been evolving from static file configuration to environment-based static packaging and deployment and on to container orchestration, the methods of static file configuration are virtually unchanged. With the automation of deployment tools, the security problems of its configuration have become more dangerous, for example:
- In a multi-environment packaging release, all sensitive information of the application gets included in the development project; this is easily accessible to internal employees.
- A container orchestration system also contains all the application’s sensitive information, and most of the container orchestration systems pass the confidential information through the environment variables; this is displayed as plaintext in the container and can be obtained directly through the environment variables.
Security Problems with Configuration Center-Based Plaintext Configuration
Configuration centers’ most significant advantage is that configuration can be dynamically modified and released while configuring and releasing the decoupling. Other benefits and various scenarios of the configuration center are not the focus of this document. Refer to Configuration Center Scenarios to learn more about these scenarios.
The primary impact of the configuration center on configuration security gets described here. A simple schematic of the configuration center storing the configuration is shown in the figure below.
The configuration center has the following security impacts on the application configuration:
- The configuration no longer needs to be stored on the server in plaintext. On the application side, the configuration center connection information gets stored without any sensitive data. All configuration details get stored in the configuration center. On the application side, the configuration information can be stored in the RAM throughout the whole process and not be persisted to the local hard disk; this gets done to minimize the sensitive information leakage.
- At the same time, sensitive information is separated out and stored in the configuration center. All configuration information can be hierarchically configured to ensure that different administrators only access the configuration information they need.
From the security aspect, configuration management based on the configuration center solves the problem of sensitive information leakage in the production environment. However, another issue that arises is the security of the configuration center itself. Almost all products store the actual configuration in plaintext looking at the product design of the above several configuration centers. If the configuration center gets attacked, all stored sensitive information will get leaked entirely. In today’s cloud era, this challenge is particularly critical for cloud vendors that provide configuration center services when facing a security compliance audit such as the level 3 protection.
ACM’s Configuration Security Enhancement Measures
Recently, Alibaba Cloud has released a “security configuration” function for users to store configurations in the configuration center in a more secure way using Application Configuration Management (ACM). The description of its functional details is in the following sections.
ACM Security Configuration Management Design Overview
Alibaba Cloud Application Configuration Management (ACM) recently added a function for configuration security called “Security Configuration”. This is created through the interconnection of a series of configuration security related products, to completely solve the above configuration center security problems. ACM’s approach to solving security problems is similar to other industry-leading configuration center products. It works not by solving security problems independently, but rather by integrating with other security products from Alibaba Cloud. Let’s see how ACM works.
In this regard, Alibaba Cloud ACM solves this problem through integrating with the RAM and KMS products:
- Application Configuration Management (ACM): The primary function of ACM is to store and release the configuration. However, in the security configuration solution, ACM transfers most of the security functions to KMS. KMS encrypts the configuration stored in the ACM server, and the ACM server itself does not directly provide the decryption function; this dramatically improves the security of the configuration. In the reading of the encrypted configuration, the configuration gets finally decrypted by calling the KMS by the ACM client.
- Key Management Service: In security configuration management, it mainly provides users with encryption/decryption services. When configuring encryption/decryption at the ACM based on KMS, users can specify their customized key pair, or use the default KMS key pair provided by ACM to simplify management.
- Resource Access Management: In Alibaba Cloud’s product system, service accounts are independent of products. That is to say, the ACM console itself has no way to access the user’s KMS key configuration. However, on the ACM console, to facilitate configuration management, the user needs to encrypt the configuration on the ACM console. Therefore, the ACM console requires specific minimum operation permission for the user’s KMS key pair. Alibaba Cloud’s security system achieves this through RAM’s Role Authorization.
ACM Security Configuration Principles
The core idea of ACM security configuration is to encrypt/decrypt the configuration through KMS. A detailed description is as below.
User Activation Process
First, we will see what steps are required if a user wants to use ACM’s security configuration function as shown in the following figure.
- Activate ACM; this is required.
- Activate KMS; this is also needed.
- Assign ACM a minimum permission role in RAM to read the user’s KMS encryption. This step is critical. Otherwise, ACM cannot use the key in the user’s KMS as a separate product.
Writing a Security Configuration on the ACM Console
The figure below shows the process for a user to write security configuration on the ACM console:
- The user writes a configuration on the ACM console and sets it as a security configuration on the console.
- ACM identifies it as a security configuration; this relies on the user’s KMS key. Then ACM will call RAM to obtain the role with the minimum permission to read the KMS encryption; this is previously assigned to ACM by the user.
- The ACM uses this role to encrypt the configuration stored on the ACM console with the user’s KMS key pair by calling KMS APIs.
- he ACM console stores the encrypted configuration in the ACM configuration database.
From the above process, we can see that:
- The configuration stored in ACM is ciphertext which it does not store the key. Even if the configuration information gets leaked, the configuration plaintext is not obtainable.
- ACM operates the user’s KMS key through RAM authorization. The authorized role only allows ACM to encrypt/decrypt the configuration, and — to minimize extra security risks — it does not have other permissions (such as key pair deleting operations).
Theoretically, in the above steps, when the user writes the configuration, the user can write on the console after KMS encryption entirely without relying on the ACM console functions. Of course, this will cause a problem with ease of use. In process design of writing ACM security configuration, calling KMS through authorization interconnection with the RAM not only ensures security but also brings great convenience to the user in creation of the configuration; this is a very balanced compromise.
Process for an Application to Read Security Configuration through ACM SDK
The figure below shows the process for an application to read security configuration through ACM SDK:
- The application reads the ACM configuration ID
- he application starts and reads the ACM ciphertext configuration
- If the ACM client identifies the configuration as a ciphtertext configuration, then the KMS client transparently decrypts the ciphertext configuration and returns the plaintext configuration.
- The application reads the plaintext configuration and links to the database. The plaintext configuration is does not get stored in the local disk; this ensures security.
From the above process, we can see that:
- On the application side, the configuration does not contain any sensitive data and only includes one configuration item that the ACM Client needs to read.
- In practice, the ACM SDK will package ACM client and KMS client calls. The detailed calling process is transparent to the application.
From the above sections, it can is visible that the Application Configuration Management (ACM) security configuration achieves a good balance between security and ease of use.
- Regarding ease of use, configuration read/write is transparent for both the server and client.
- Regarding security, the integration of RAM and KMS ensures that the configuration can be encrypted in a sufficiently secure channel and stored in the ciphertext. The above measures better satisfy the current compliance and level 3 protection goals and effectively meet the security needs of most enterprise users.
As a product oriented to the configuration center and focused on user configuration, the primary goal of ACM in the cloud era is to ensure the security of the user’s configuration. On this basis, ACM will protect the security of the user’s configuration through integration with more Alibaba Cloud products. The scenarios will include but are not limited to:
- Secured storage of container service configuration.
- Secure storage of ECS auto scaling configuration
- Secure storage of various other PaaS service link configurations
- More application security enhancement scenarios are coming soon.
Read similar articles and learn more about Alibaba Cloud’s products and solutions at www.alibabacloud.com/blog