Switching from traditional software engineering to building modern cloud apps requires multiple changes on several levels, with data-related security often mistakenly pushed to the margins. But in fact, even with all the brilliant cloud providers’ security options, you can't duck data protection issues in a cloud, you just face new priorities in your data security design.

For example, you are still to impose restrictions on sensitive data access and protection (check out field level encryption), block SQL injections and stop insiders by implementing more security controls, use audit logs to have a clear understanding of the sequence of events in case of an incident, accommodate architectural assumptions (state management, disposable replicas, load-balancing, etc.), and so on. 

This looks like a really huge pile of work! Keep calm and follow the plan.

Generally, while building data security in a cloud you’re to focus on this trio of tasks: 

1. Trying to use fewer products/tools to reach the same security goal. If successful, the business spends less funds and time on management tasks, while the engineering team deals with a smaller number of tools, configurations, bugs, and dependencies.

2. Making preventive, detective, and corrective security controls work in concert for the common goal. A quick example: normally triggering security events is interconnected with access controls and monitoring.

3. Developing the data security platform inside your solution to manage encryption and data security controls (in case you have dozens of interconnected apps in one cloud account) or a single data security layer with specific controls (like application level encryption, authentication, firewalling, data loss prevention, anomaly detection, anonymisation, etc.). 

As for the encryption engine in the data security layer, it could take various shapes depending on the design of your system. 

For example, if you want to integrate encryption without making large changes in your already built solutions, use transparent encryption/decryption. Your first choice would be to deploy a database encryption proxy. The proxy sits between your application and database, intercepts, encrypts, and sends data to the database; and later when an application reads the data back, the proxy decrypts and sends it to the application. There are open-source database security proxies available for SQL and NoSQL databases.

If you work with multiple databases (especially a mix of SQL and NoSQL), it’s worth considering building and deploying a Data Access Object (DAO) service. DAO encapsulates data access allowing operating with the data without exposing database details. The DAO is responsible for data exchange between backend apps and databases, managing which data is sensitive and needs to be decrypted before operations and which data is stored in plaintext and can be used just directly.

Using the Database proxy or DAO doesn’t work for every case. Sometimes, the only choice is to integrate cryptographic code directly inside the application code using an encryption library (SDK) responsible for data protection. In this case, you do not need to deploy and maintain any additional encryption services, since encryption/description happens right in your application (client-side encryption). However, the security risks for the application increase dramatically, since it has access to the encryption keys. It’s better to hire applied cryptographic engineers to ensure that encryption is integrated correctly, as developers often don’t have any experience with cryptography and can’t recognize good from bad.

So, after all, to run your project high in a cloud you are to make quite practical, specific, and down-to-earth data security decisions. And it’s better to start earlier to minimize time and cost for the developments.