An attempt to improve PAAs Security

Cloud services have become part of modern life. The photos on your mobile phone will be automatically synchronized to the cloud; your emails will be stored in the cloud; office software will be running in the cloud; and your health data will be uploaded to the cloud in real time; the calories consumed by your daily life track will be uploaded to the cloud. cloud services will gradually be accepted by the public like electricity and water, which is the inevitable trend of technological progress.

Cloud Service Security? This question has been answered many times. As a software engineer, I am talking about my own security attempts. For reference.

Big security topics include many aspects. Is data reliable? Are data peeked or tampered?

The basic requirement of no data loss can be said to be very good. AWS S3 has reached durability, and a will is stored on S3, it is estimated that it is more reliable than it is stored in the bank safe (it is not easy to lose, but it is hard to say whether it is Snoop ). Someone may ask another question. Why are there so many bitcoin losses? Saving the Bitcoin digital certificate should not only be lost, but also stolen. If the bitcoin Certificate file is stored on S3, it is estimated that there will be more thieves. We will not discuss this in depth.

Data confidentiality issues, such as not being peeked or tampered. The essence of this problem is whether there are technical means to ensure security. If not, it can only be based on the trust mechanism. For example, if you use a bank service, you only trust him and believe that he will not steal your money. However, if there is a technical digital currency protection mechanism, you do not need to be forced to trust any individual or institution. You only need to trust science. Perhaps in the near future, digital currency will replace banks. At present, cloud services are still in the trust-based stage in terms of data confidentiality.

When you open an online software (qq mail, tower. Im, etc.), you have started to use the services provided by SaaS, and most of your data will be stored in Saas service providers. Do you trust your SaaS service provider?

Online software developed by SaaS service providers is usually run on services provided by more basic PAAs service providers. For example, Database Service RDS, virtual host service EC2, ECs, file storage service S3, and OSS. As a SAAS Development Engineer, do you trust the PAAs service provider?

Trust in Saas. If there is an end-to-end technology that implements encryption and decryption at the end of the browser, there is no need to worry about SaaS data theft. For example, you can produce data by yourself and consume data by yourself (for example, you can upload a photo for yourself only), which is easy to implement. You can use a locally stored symmetric key to complete encryption and decryption. However, if two people are involved in the action, such as sending an email, sending it by one person, and receiving it by one person, end-to-end encryption should be implemented. This requires asymmetric password technology. However, if multiple people participate in the action, such as online assistance services, and the content submitted by one person needs to be read by multiple people, end-to-end encryption is more complicated. If the SAAs service provider cannot provide a technical solution satisfactory to you, your only choice is to trust him or not trust him. There is no better way.

Is there a technical means to get rid of trust in Paas? PAAs provides basic services, stores data, stores files, and provides computing capabilities. SaaS data stored in PAAs can only be accessed by SaaS itself. In this scenario, you can use symmetric key encryption technology. SAAS stores an aes256 random key, and all SaaS servers share the key. SAAS uses aes256 to encrypt the data submitted by users and then saves the data to Paas. SAAS reads PAAs data, decrypts the data, and returns it to the user.

Browser user ---- SaaS engineering code -- AES key ----- PAAs Database

We now discuss whether the data is secure because the code, key, and database leaks, or any two leaks, or both of them leak?

After the sensitive fields in the database are encrypted with AES, even if the database is dragged (only the database is leaked), it cannot be decrypted. The password strength of the AES-256 is theoretically not cracked. -- It is safe to drag the database after the transformation.

The database encryption method is good. The question is how to protect the key itself? It is not appropriate to write in the code. Because of the Code, programmers can see it. The Code may also leak when it is submitted to GitHub. The compiled binary code can also reverse crack such fixed passwords. So the AES-256 key cannot be placed in the source code. The AES-256 key, which should be written in the configuration file keyconf, and which is not part of the project and only stored in the operating system's configuration directory (such as/etc. Only the O & M personnel can access this file. If the file is consistent on all SaaS servers, encryption and decryption are completed. -- After this transformation, the source code and data are leaked at the same time (the key is not leaked), which is also safe.

The key information is stored in the configuration file, which can be easily leaked once the server is logged on illegally. There is one way to deal with this risk, saving an asymmetric key RSA in the project code, using the public key to encrypt the original AES key once, the encrypted Keyfile is saved in the/etc directory as the configuration file. When SaaS starts the service, it decrypts the Keyfile with its own private key to get the most primitive AES-256. -- After this transformation, AES keys (after RSA processing) and databases leak simultaneously (source code does not leak, RSA does not leak), which is also safe.

In an extreme situation, is the source code leakage, key leakage, database leakage, and data security? From the source code can get RSA private key, with this private key can decrypt the AES-256 symmetric key, with this AES-256 key can decrypt the database. There is also a way to address this situation. Generally, Keyfile does not need to be retained on the server for a long time. This file is only useful when the service is started, the decrypted AES-256 is stored in the process's memory, and this Keyfile is no longer needed. The method is to encrypt the Keyfile with the password and generate keyfilessl again. The generated environment only keeps the keyfilessl file. When the script is executed, the system prompts you to enter a password. If the password is correct, the system decrypts the Keyfile and starts the service normally. After the service is started, the script immediately deletes the Keyfile. -- After this transformation, the source code leaks, keyfilessl leaks, and database theft is also safe (because there is no Startup Password ).

The preceding method has two disadvantages: one is that a password is required for startup, which causes the service to fail to be automatically pulled up after a crash occurs. Passwords should never be recorded in any script. Another drawback is that the AES-256's original key is stored in the memory of the service process, if the production environment host is hijacked, hackers have a way to obtain the key by analyzing the memory (this is a bit difficult, but it is possible ). To address this vulnerability, AWS's best practice is to prohibit all shell logins on production environment hosts (AWS's practice is recommended. AWS Virtual Machine EC2 recommends that you use the login prohibited mode. No developer or O & M personnel can log on to the production environment host. EC2 initialization and environment deployment are automated without human intervention, and data theft is prevented to some extent .).

An attempt to improve PAAs Security