Devs are often tempted to leave data security “as is” while building cloud native apps. With all the options cloud providers give, you can have an illusion of everything running securely by default. But…
...In reality, the need for data protection and app security does not disappear automagically in a cloud and security requires your efforts and a different approach. You’re to protect the data whenever it exists.
🌁 But why?
In a cloud environment, you have many security concerns eliminated or cared by the cloud provider. Simultaneously, you have less control over the perimeter and many things are just checkboxes on the admin panel.
Since infrastructure capacity is no longer a limit in a cloud, you can have multiple complex dataflows – and they require setting out and mapping controls onto them.
❇️ For example, to prevent other developers and DBAs from accessing sensitive data in production you’ll need field level encryption. To stop SQL injections and insiders you’ll have to request firewalls and monitoring tools. To restore the events and find a root cause in case of incidents you’ll need audit logging.
Managing this complexity is challenging.
💡 Here comes the reality check: it’s the data owner but not the infrastructure operator who is responsible for a breach under GDPR, PCI, CCPA, and most other regulations.
Thus, while some security tasks are handled by your cloud provider, you still have to deal with data security and appsec.
🌁 But how?
The process of making security decisions usually comprises such steps as risk assessment and risk mitigation, threat modelling, loss event scenarios, etc. In a cloud environment, you follow the same steps but make them relevant to the cloud.
☀️ 3 main points to focus on for cloud native security are:
✔️ 1. Minimizing the number of products/tools you use for the same security goal. The less tools, configurations, bugs or dependencies you manage, the better.
✔️ 2. Configuring the preventive, detective, and corrective security controls to protect from different threats but to work for the common goal.
✔️ 3. Building a single data security layer with specific controls (like application level encryption, authentication, firewalling, data loss prevention, anomaly detection, anonymization, etc.).
How exactly to build a data security layer and which tools to use depend on your system design and security requirements.
💡 For example, you can put a database encryption proxy between your app and database to get transparent encryption/decryption without big changes in your solution. (Acra database security suite, available from GitHub, perfectly fits this task.)
Data Access Object (DAO) service can be of help when you have multiple databases (especially a mix of SQL and NoSQL, Acra will help here as well).
And sometimes, the only way to integrate cryptographic code right into your application code is to use an encryption library or SDK (like Themis cryptographic library).
😊 Good thing is that we have already built many different data security layers for various use cases, and know approaches, tools, and typical pitfalls. We’re here to support you in cutting through complexity and protecting your valuable data.
Drop us a line if you face a challenge. And follow our blogs on DEV, our website, and Twitter for more security-related updates. 🔐
Top comments (0)