In this 10 part series, we review the key components that are needed to formulate and apply a consistent, regimented cloud database security program that helps ensure data is only available through authorized access. Part 2 explored how people, policies and plans are essential to successfully protecting data. Part 3 below discusses public cloud database configuration best practices.
When considering configuration, users should again look to the old, but still relevant, security concept of defense in depth. Best practices for risk reduction when configuring databases include, but are not limited to:
- Limiting user access and verifying trust.
- Managing users with least-privilege policies so as to avoid unwarranted access and reduce the potential for misused or compromised data.
- Classifying databases by the acceptable level of risk for each database in order to know where to focus efforts.
- Encrypting data at all times and setting up access controls to limit employees’ exposure to customers’ sensitive personal information.
- For access management/IAM systems, keeping IAM rules as simple and straightforward as possible to minimize access points.
In the public cloud, it can be tricky for enterprises to track and confirm configurations. Automating access management ensures key factors such as provisioning, de-provisioning, authentication and authorization, and administration are executed in repeatable ways that aren’t prone to human error. But setting up the automated process for public cloud databases comes with challenges; this is why it’s crucial to double check these configurations. As with anything, the more complicated it is, the more likely it is that a mistake will be made. That is why you want to employ multiple layers of security.
While it’s always possible to test on a development environment before running in production, beware that many data leaks are the result of misconfigurations, or even forgetfulness, when it comes to shutting down clones or copies that were created to support, develop or test new environments. This is yet another reason why regular, automated scanning of your environments to check for vulnerabilities is advised.
Read part 4 of this series where we review considerations related to asset discovery.