AuditIQ keeps track of changes to Magento's configuration. Every change is listed on the Configuration Changes page. This allows you to troubleshoot whether configuration changes contribute to problems being reported by your client.
- The website/store/storeview scope the change happened in.
- The configuration path of the change.
- The database user that made the change.
- The configuration value before the change.
- The configuration value after the change.
- When the change was made.
Using the search filter, you can quickly find every change over time. This is very useful when troubleshooting behaviour changes or bugs that appear in Magento, that could be caused by configuration changes. Having access to the previous value(s) thus enables you to copy and paste these back into Magento in order to restore the configuration of any individual value back to the previous value.
It also helps detect and protect against malicious code that modifies the configuration directly in the database, bypassing the normal method of changing configurations via the admin panel.
How does this differ from the Adobe Commerce Action Logs feature?
Firstly, the Action Logs feature is only available for Adobe Commerce . This means that Magento Open Source merchants do not have a built-in method of detecting configuration changes.
Therefore, AuditIQ provides a very useful additional feature for Magento Open Source.
For Adobe Commerce merchants, AuditIQ's logging of configuration changes captures ALL changes, whereas Action Logs only catch changes made via the admin panel. In situations where malicious code directly changes the database, Actions Logs won't log the change - but AuditIQ will record the change in full.
Disabling the transfer of change data to the portal
If you do not want to transfer the changes to the portal for any reason, you can disable it by adding the
--skip-config-changelog parameter to the Audit Agent's cron configuration.
Preventing sensitive configuration data from being transferred to the portal
If the configuration in the database contains any sensitive human-readable information, such as passwords, etc, then you can prevent the actual being sent to the portal by the Audit Agent. However, firstly consider why you have such human-readable information in the database because your modules should instead be storing such values in an encrypted format. Review such modules because they do represent an inherent security risk.
If modules store sensitive information in an encrypted format, it can be safely transferred to the portal. Because there is no means within the portal of accessing your decryption keys, then the underlying data is safe.
However, if you want to prevent certain configuration fields from being sent to the portal, then you can easily do so. Simply create an "exclusion file" containing the paths to exclude from the core_config_data table. For example...
Then add a new input parameter to the Audit Agent's cron configuration, adding
--config-changelog-exclusions=/home/user/auditiq_exclusions.txt, replacing the file path with wherever you saved the file. Once this is done, the changes is still detected, but the actual changed data is never sent by the Agent. Instead, it sends the text "EXCLUDED FROM AUDIT". Therefore, this allows you to know that a change has occurred, without actually displaying the change in the portal - thus maintaining secrecy.