Last week we released SQL Compliance Manager 5.6. Along with it are some new and exciting changes in the product. We thought we would share some more detailed notes on the new functionality.
SQL Compliance Manager now has the capability to set default settings at both the Server Level and the Database Level. Previously, when a new server or database was created you had the option to use the IDERA defaults, choose from a Regulation Guideline or customize the audit settings.
This new functionality makes it really easy to set new Servers and Databases exactly the way you want without having to make additional updates to the configurations. In addition to that functionality, you also have the option to apply those default settings out to selected Servers and Databases that are already being audited.
The default settings are the same settings that you would see in the properties for the Server or Database (except that they apply to the default and not a given Server or Database). Sensitive Columns and BAD are not available for the Database Default settings since those tables will vary greatly from database to database.
SQL Compliance Manager allows you to set configurations at the Server level and the Database level. Previously, you might have set a configuration on the Server level and not know that information was being monitored when you reviewed the Database settings. This could lead to either too much data collection or too little.
In SQL CM 5.6, we have added new logic that will show on both the Database level as well as the Privileged User settings which items have already been selected at the Server level. Items selected at the Server level will be checked and unavailable for selection (greyed out).
When you deselect an item from auditing, you will receive a popup message to ask you if you’d like to deselect it at that level or deselect at that level and each level beneath it.
Server Level Auditing selections will impact both the Server Level Privileged User and the Database Level Auditing. All three levels of Auditing will impact the Database Level Privileged User.
Please note that with the new clearer inheritance of these settings, it is possible that you may be collecting more data than you were before. You will want to review your settings upon upgrade to ensure that all items are still collected as you expect (see the new Configuration Check Report below).
SQL Compliance Manager has functionality to allow you to track Privileged Users or rule out Trusted Users at the Database Level. While Privileged User functionality has been available at the Server Level for some time, in this new release, we are adding in the capability to add Trusted Users at the Server Level. This allows you greater control over who is monitored at what level.
With the new addition of the Default Database Settings, we have added the ability to add new databases automatically upon creation. If you choose to select this option, any new database that is created on an audited server will automatically be added with the default database settings. This can be set on a per Server basis.
SQL Compliance Manager has always been able to capture Logins and Failed Logins. However, the Logouts have not been available to track as easily. In this release, we have added Logouts as a separate tracking option on your Servers.
Most of our customers use the Web Console to grant access to reports and alerts to executive teams and auditors. They do not want these teams to be able to change or update the configurations. In this release, we have removed all of the configuration settings from the web console. This way you can have greater control over who can change your audit data while still allowing granted users to see the information that was audited. Of course, all functionality is available in the Windows Console.
GDPR went into effect on May 25, 2018. While our product has always supported functionality to help our clients meet the GDPR guidelines (blog), we have added it as a selectable option in our Regulatory Guideline Wizard in this release.
Now that we have added new default configuration settings, we have something that we can compare other settings against. The new Configuration Check Report in SQL CM 5.6 compares the settings on your servers and databases with the settings that you have set up as your default settings. This allows you to quickly see where your settings may vary from what you have defined as default settings. It also allows you to quickly identify the differences between database and servers when you see inconsistencies in your collected data.
It also allows you to take a snapshot in time of what your settings are currently set to. This assists auditors with the details they need to know to understand what information should be captured. This will also assist IDERA support teams to set their configurations identically in order to troubleshoot issues more quickly.
SQL Compliance Manager has Regulation Guideline Wizards that help you to set good audit settings that will apply to various regulations. Once you have enabled one of the Regulation Guidelines, you may later go and amend your settings and this could potentially put you out of compliance for that regulation. The new Regulatory Compliance Check Report allows you to review all of your servers and databases and determine if they are in compliance based on the IDERA defined standards for those regulations.
This functionality will also help you to review servers and databases where you may not have run the Regulatory Guideline Wizard but would like to know if they are in compliance. This is also helpful to show auditors what you are doing to stay in compliance with your settings in case your organization defines compliance differently than the IDERA standards.
Similar to the Configuration Check Report (which compares your server and database settings to your default settings), the Regulatory Compliance Check Report compares your server and databases settings to the predefined settings for any or all of the IDERA supported regulations.
In order to meet GDPR control over who can and cannot see PII data, we have implemented new functionality with the Sensitive Columns. Here you can select if would like to capture Selects Only, Selects and DML or All Activity on your PII data. If you choose to collect data other than Selects for the selected Sensitive Columns and Datasets via this setting, you will not receive the SQL statements. Should you want to collect the full SQL statements, you can do that via the Before-After Data monitoring.
We have updated our documentation to make it more user-friendly and to follow our UI structure more clearly. This should help make it easier for you to find quick answers to your questions.
SQL Compliance Manager 5.6 will be the last version of SQL CM that will support SQL Server 2005 as an agent. The collection server has already discontinued support for SQL Server 2005. SQL Server 2005 will be discontinued in the next release, please contact your account rep or support for any concerns.
In SQL Compliance Manager 5.6, we add a new log file that keeps track of your versions and upgrades. This will help your support team to better understand timelines for your upgrades and upgrade versions.
In SQL Compliance Manager 5.6, we added new capabilities to increase the number of threads that can be used to process your trace files. Previously the product only processed 25 threads at a time. By default, SQL CM will now process 100 threads at a time and this can be adjusted.
Here's the official GA announcement Blog Post.