Audit Log

  • Article

The audit log for Microsoft.Provisioning.Monitoring .Net Namespace contains a user-defined subset of data that is stored for data mining, error checking, and other reporting and analysis purposes. For example, data on failed transactions, failed procedures, and execution times is often used for performance analysis.

Getting Started [HMC SDK] installs the audit log. An MPF installation can have only one audit log database.

The audit log receives transaction data from Transaction Logs [HMC SDK] via the Provisioning Auditing and Recovery Service [HMC SDK]. Since the number of transactions in a data center can become very large, logging all information about every transaction, procedure, and error would require excessively large databases. Using Provisioning Manager [HMC SDK1], you can reduce the size of the databases by specifying which information to save to the audit log, limiting it to only the required information. The Audit Level property in Provisioning Servers, Provisioning Engines determines which transactions are saved to the audit log and what kinds of data to pass for these transactions. For more information, see Provisioning Engines [HMC SDK].

Depending on the reporting purpose, it may be necessary to modify the audit log database. To add rows of data to the database or execute custom stored procedures, use Custom Audit::Audit.

MPS has a number of built in audit and debug logging mechanisms. The following table list some log examples.

Log Name Description

MPF Transaction logs

Short lived logs, contain transaction specific information necessary for execution and rollback purpose

MPF Audit logs

Historical data pertaining to all completed(successful or failed) transactions

ComTracer logs

Logs saved through either the MPF Profiler or TraceView

Event logs

Many MPF Components including providers will write events to the Event logs

Web Services logging

MPS Web Service logging saves out the XML input (request) as well as the XML output (response) for each Web Service Request. It is turned off by default. For more information, see Web Service Debug logging.

While the logs and data stores can be invaluable in troubleshooting issues or identifying trends, it is important to understand that there may be sensitive data stored in these logs including, Customers PII (Personally Identifiable Information), Security Credentials, internal infrastructure details, billing related information

While some of the mechanisms above offer some protection from exposing things like credentials -- for example, MPF will strip passwords from transaction data as it is being written to the MPF Audit logs and Web Service Debugging strip off passwords as requests and responses are being written to log files, it is imperative that these logs be protected. At a minimum, the following processes should be put in place to protect this data:

  • Logs should be stored only on trusted and physically secured servers

  • Backups should protected under tight security and only shipped to secure locations

  • Debug tracing including ComTrace and Web Service logging should only be enabled when it is absolutely necessary.

    • Debug logs should be destroyed when they are no longer needed

    • Debug logs should only be made available to support personnel who need access to them.

  • Audit logs should be purged on a regular (6 - 12 months) basis depending on auditing requirements.

  • Event logs should be purged on a regular basis depending on operations requirements.