Audit Log (also known as Access Monitor) is an feature introduced in AMT 4.0 that provides a place to record events and introduces a new type of user called Auditor.
Key features of the Audit Log are:
- Auditor user type that cannot be removed or altered by the Administrator
- Policy based events that are selected by the Auditor to be logged
- Configurable alerts associated with the logged events
- Unprovisioning requires collaboration between Auditor and Administrator
Typical usage will start with an Administrator enabling auditing and establishing the Auditor account (after this, the Auditor cannot be affected by the Administrator). There can only be one Auditor on a system at a time. The Auditor will then set policies that define which events will be logged and which will produce alerts. The audit log can be read by any AMT user with General Info permissions. The Auditor will keep track of the audit log and periodically clean it out (this is important because when the log becomes full it will prevent any new critical AMT events from occurring). To shut off auditing, the Auditor must configure the system for unprovisioning, which will then allow the Administrator to disable auditing.
Roll Over
The initial implementation of Audit Log did not allow the log to roll over. To ensure the Auditor had a chance to see all the events flagged as "critical", these events would not be allowed to run when the log was full. This was a security feature to ensure that a sneaky admin (or other user with sufficient privilege) would not be able to perform some improper activity and slip it by the Auditor because the log was full. However, this also created a situation where systems could be prevented from getting managed properly due to events being blocked by a full audit log. If something happened to the Auditor (or group of people with Auditor permissions) that prevented them from cleaning the log, it could easily become full and block critical events. So starting with AMT 5.1, the feature was updated to provide a choice to users on how to configure their implementation of Access Monitor to allow the log to roll over when full. The following policies can now be set by the Auditor:
- No Roll Over: When full, critical events will fail and others won't be logged
- Roll Over: When full, overwrite the oldest
- Restricted Roll Over: Only overwrite if oldest are past given date
Security Monitoring by Default
Using the log to monitor for security reasons became popular aside from the auditing capability. Starting with AMT 8.0 the log is enabled by default with all Administrators having Auditor rights. By default several events will be logged and available for viewing. The original use of auditing can still be initiated by defining an Auditor.
Reference
To learn more about Audit Log, please downloadthe latest AMT SDK, read the documentation and try the sample. The sample provides code to run a fairly comprehensive API test as well as examples to enable auditing, manipulate the audit policy, manipulate the audit log, view the audit log, clear the audit log, unprovision auditing, add an auditor, and cleanup the sample stuff from your system. When building the sample be sure to view the readme. I found out that I needed to install a root certificate on my management console system to be able to successfully run all the samples.
If you would like to be able to keep track of things happening on your AMT system, independent of your Administrator, you probably want to use the Audit Log feature.
Icon Image:
