Guest post by Klaus Muehlbradt, HP Software Database and Middleware R&D
When it comes to Data Base as a Service (DBaaS), there are two fundamental questions regarding compliance testing and remediation:
Who is responsible for database compliance testing—the provider of DBaaS or the consumer?
Who is responsible for remediation of the database problems discovered—the provider or the consumer?
Depending on the provider, the answer could be either of those two options or a blend of both; although it is likely that the provider will have some responsibility for database compliance.
Fig. 1: HP Database and Middleware Compliance Dashboard
Commercial vs. internal clouds
In a commercial cloud environment, in which an external third party provisions the database, it depends on the actual scope of the service provided. The scope of the service may only be a basic database provisioning and the consumer might be able to customize at will; the provider would only be responsible for the initial compliance of the provisioned database. However, if the service is a fully managed database, the provider will likely share compliance responsibility or own it completely.
For internal cloud services, the same basic principles apply, with one difference; as both provider and consumer belong to the same legal entity, a provider rarely has the opportunity to move all responsibility to the consumer. At the very minimum, the in-house provider has to provide a mechanism that allows the in-house consumer to understand if databases are compliant. This mechanism can be a testing tool, for example, or regular compliance status reports.
Sharing test results
Testing is a prerequisite for remediation, of course—nothing will be fixed unless you are aware of a problem. The provider must be prepared to test for compliance in the first place and share the results with the consumer.
HP Database and Middleware Automation (DMA) tests databases according to the established CIS benchmarks and maps the results to SOX and PCI, and then automatically sends results of the compliance scans via email (Figure 2). The compliance runs can be scheduled to execute at regular intervals or could be started by a monitoring tool using DMA’s RESTful API. These types of small features often make a big difference.
Fig. 2: An example of HP DMA Compliance scan results
Remediating compliance issues
When an issue is identified, actual remediation is guided by DMA’s detailed explanation of why a database failed the automated compliance test and, wherever possible, any information it can provide about how to resolve the compliance issues. Additionally, DMA offers a set of database patching and database configuration workflows that can be applied (Figure 3).
Fig. 3: Example of Oracle Compliance Audit workflow in HP Database and Middleware Automation
Preventing compliance issues
Standard database configurations and regular patching of database systems are two proven mechanisms to prevent compliance issues in the first place, and DMA can help improve both.
The DMA concept of deployments allows senior DBAs to define standard configurations for databases. With many configuration parameters locked down in the DMA deployment, human error is significantly reduced if not completely eliminated. Regular patching processes, such as with Oracle’s quarterly patch, are also improved through the standardization imposed by deployments, as well as from the automation services offered by DMA.
Using automation can greatly streamline how you as a provider meet your obligations to test and remediate compliance issues in DBaaS.