RDaaS Security: How to Apply Database Audit and Monitoring Controls

As you move Amazon states that AWS, data security and compliance requirements move along with it. This article explains how you can apply database audit and monitoring controls when migrating your database to cloud services, including the following:

  • Introduction to RDaaS
  • Benefits of RDaaS Adoption
  • Who is responsible for DB security in the cloud?
  • Taking steps to ensure relational database security in the cloud

Introduction to RDaaS

Relational Database as a Service (RDaaS) provides the equipment, software, and infrastructure needed for businesses to run their database on the RDaaS, rather than putting something together in-house. Examples of RDaaS include AWS Relations Database Services (RDS) and Microsoft Azure SQL Relational Database Service

Benefits of RDaaS adoption

The advantages of RDaaS adoption can be fairly substantial. Here are just a few of the benefits:

  • Allows you to reserve capital rather than using it for equipment or software licenses
  • Reduce expenses related to hiring highly-skilled staff and/or consultants
  • Eliminates the pain points associated with building a database system
  • Requires no additional IT staff to maintain the database system
  • Utility fees required to operate an RDaaS are the responsibility of the cloud provider
  • Resiliency and dependability are guaranteed by the cloud provider
  • Cloud provider database teams are experienced, and know how to handle a variety of bugs and problems
  • The RDaaS provider is often housed at a hardened site, and is therefore less vulnerable to natural disasters, loss of power, and other disruptions that could otherwise affect your daily operations.
  • The RDaaS provider is competitively-focused on providing the best possible service. It can devote substantial resources to optimizing equipment and recruiting qualified personnel.

Who is responsible for cloud-based DB security?

From a high-altitude viewpoint, cloud security is based on a model of “shared responsibility” in which the concern for security maps to the degree of control any given actor has over the architecture stack.

Amazon states that AWS has “responsibility for security of the cloud,” while customers have “responsibility for security in the cloud.” What does that mean for you?

Cloud vendors provide the tools and services to secure the infrastructure (such as networking and compute machines), while you are responsible for things like network traffic protection and application security. For example, cloud vendors help to restrict access to the compute instances on which the web server is deployed (by using security groups/firewalls and other methods); they also deny web traffic from accessing restricted ports by setting only the needed HTTP or HTTPS listeners in the public endpoints (usually the load balancer).

But public cloud vendors do not provide the necessary tools to fully protect against application attacks such as the OWASP Top 10 risks or automated attacks. The responsibility falls to you to establish security measures that allow only authorized web traffic to enter your cloud-based data center— just as with a physical data center. Securing web traffic in physical data centers is typically done by a web application firewall (WAF) and fortunately, WAF can be deployed in the public cloud as well.

Ensuring database security in the cloud

Here are some things you can do to ensure the security of your data in the cloud:

  • Monitor Databases in Cloud Services

Use the same scalable architecture proven to cost-effectively monitor thousands of on-premises databases for your databases in AWS. For AWS, non-intrusive virtual appliances, deployed individually or in HA pairs, monitor network traffic and offload processing from the agents, minimizing impact to database performance.

  • Unify security policy

Deploy a common security and compliance policy for consistent security across on-premises and cloud databases. Secure and audit databases in the cloud and on-premises via one lens. Protect data in AWS with alerts and then block unauthorized activity.

  • Extend compliance to cloud databases

Demonstrate compliance with data protection and privacy regulations for databases in AWS. Provide unified audit reports across data in the cloud and on-premises. Get detailed reports for regulations such as SOX, PCI DSS and more.

  • Vulnerability Assessment—Detect Exposed Databases

SecureSphere Discovery and Assessment streamlines vulnerability assessment at the data layer. It provides a comprehensive list of over 1500 tests and assessment policies for scanning platform, software, and configuration vulnerabilities. Database assessments leverage Common Vulnerabilities Scoring System (CVSS) and the latest research from the Imperva Defense Center to assess database servers and assign a vulnerability severity level. Assessment scans can be run on-demand or at scheduled intervals, giving security teams the flexibility to scan when it least impacts IT operations. Assessment policies are available for a broad range of databases including Oracle, Microsoft SQL, IBM DB2 and more. The vulnerability assessment process, which can be fully customized, uses industry best practices such as DISA STIG and CIS benchmarks.

  • Database Auditing and Protection—The Next Step for Data Security

For complete visibility and control of user access to sensitive data, SecureSphere Discovery and Assessment can be extended to include database activity monitoring organizations can implement security policies to block or alert on attempts to exploit a vulnerability, providing virtual patch protection while software patches are developed by software vendors.


The need for quick panoramic visibility to the entire delivered application and data infrastructure, no matter where it is located, is paramount. Quick and coordinated control and mitigation are essential to bring the balance of defense back into the defender’s court.

Learn how Imperva solutions can help you ensure the safety of your database and data when migrating to a RDaaS.

*** This is a Security Bloggers Network syndicated blog from Blog | Imperva authored by Marty Jost. Read the original post at:

Secure Coding Practices