With the new GDPR regulations kicking in, data protection rules will need to be integrated into the application, product, or service from the initial phase so that a team is well versed at every level and defaults to code that protects the data. This piece will cover key areas for the successful implementation of database audits.
There are lots of components attached to your data, and any one of them can become a reason for data breach or theft. For instance, when you install and configure a new database instance, it creates a starter database with a default configuration including users and passwords.
This may create a database vulnerability due to the fact that a database user, such as a DBA, may have permission to edit data in tables or change permissions on default schemas so that he can access data even if he is not allowed to. So let’s review some of the important activities that need to be audited for security and compliance reasons.
This is the entry point for any culprit from within or outside an organization. A privileged user may be able to change or extract financial information from customer data or he may try to access the system at a time when he is not allowed to with wrong intentions.
Auditing these activities helps companies identify a data breach before it is too late or at least assist with implementing better security configurations to stop losses from occurring.
Database objects that either hold user or company data, as well as procedures or logics that define the functionality of a system, and people with permission on these objects can all manipulate the structure and thus become a reason for data corruption or data theft on a continuous basis. And none of this can be tracked if auditing is not enabled.
Auditing should be implemented for all important tables, views, procedures, database links, and runtime logical flows that control certain functionality for business applications.
The most critical part of any organization is its data. There can be many users who might have permission to manipulate data, and it is important that all confidential and restricted data should not be edited by other unauthorized users.
Identifying and tracking details such as the user, time, data, and change can help companies comply with many data compliance rules, and this auditing function will take on added importance with the new GDPR compliance requirements.
Data today is also huge and mobile. You may have something on-premise as well as some in the public cloud, which may demand a large amount of networking. Auditing a network will help you understand copious volumes of data and also identify the network resource requirement for better configuration of your network infrastructure.
Additionally, when you move data from one location to another, your data is vulnerable to theft and loss. This means you need to set up transparent data encryptions as well.
Auditing the overall database utilization can give you an excellent idea of the cost of running a server as well as enable you to be ready for any resource additions and modifications before they are actually needed. You can also configure helpful alerts based on this auditing.
Different databases provide various options for auditing data at different levels. Here are some of the top database engines and their auditing features.
This system allows for optimized database audits via policies and conditions. Oracle has consolidated and combined its two security products—Audit Vault and Database Firewall—into one product, so that users can enjoy a unified audit data trail.
Compared to previous versions, Oracle Database 12c provides better auditing by providing a targeted, precise, and context-based logging configuration. This improves performance via reduced overhead for the logging of audit data, and also improves on the reporting of audited data as it is already captured in a consolidated fashion.
For example, policies can be configured to audit on different levels, including IP addresses, programs, time duration, or the network access type used in authentication. Oracle can also keep audit trails in the database or in audit log files that should be monitored regularly.
When enabled, IBM’s db2audit generates the audit logs for a set of database operations. Audit trails can be found in the log files generated on the file system, and can use the db2audit tool to configure and monitor audit-related information at the instance or database level.
There are implications of enabling auditing on a partitioned database, due to the fact that a majority of audited database activities occur in associated database partitions, and it is possible that a number of audit records generated will be based on the number of database partitions for an activity on the one object. This is because each record should be able to identify the database partition where the activity occurred.
This solution enables user-friendly policy-based auditing. Once the audit plugin is enabled, users can define options for what needs to be audited. Audit logs are securely generated in XML format and can be viewed with any viewer tool. Audit logs can be encrypted, and then shared and decrypted by other third-party tools with the key for analysis. Additionally, the new enhancement saves on storage by generating compressed log files.
Many databases have built-in capabilities that can provide auditing tools, but meeting compliance requirements is just as important a part of database security.
Organizations are now at the height of preparation for GDPR. Of course, this is not the first data-security measure to be introduced, and organizations have already had issues dealing with existing compliance laws, such as the EU’s Data Protection Directive (which the GDPR is replacing), and HIPAA in the US. It is going to be even harder for DevOps engineers to adopt the right measures before the GDPR is enforced this May and thus essential for them to bring themselves up to speed with the current concept of Data Protection by Design.
The responsibility for implementing auditing protocols on database activities lies in the hands of the relevant team leads or DevOps engineers, depending on organizational structure. Auditing should be in the hands of a single owner, and blocked for editing and access by others. Auditing tools and plugins can help with easy setup and reporting of compliance as well.
What if your enterprise makes use of all three databases we discussed? And maybe MSSQL and MongoDB too? Would it be easy to manage the configuration and setup of your audits and then go through each log separately? Nope.
Nowadays, as most items are scattered between cloud and on-premise, you need to look for tools and third-party options that can provide a single window to cater to all of your auditing and compliance needs. Policy-enforced database security and auditing software are required to easily configure, manage, and monitor database activities.
DBmaestro’s Database DevOps Platform is such a tool — the perfect solution to serve the auditing and compliance requirements of multiple databases while also enabling you to take actions based on the database audit trails. Additional coverage includes documentation on database compliance and assistance with the overall process of development to deployment.
The main function of any DevOps team is to keep your data secure and that’s something that DBmaestro’s Database DevOps Platform is uniquely designed to facilitate.
GDPR is just the latest regulation for data security; many regulations came before it and many will follow. Staying on top of database security — especially when dealing with multiple databases from different providers — is crucial to your organization’s health. Database audits are critical for keeping a detailed history of actions taken, and should be done correctly and thoroughly across all platforms.