Audit

The audit data is stored in InfluxDB with the following configuration of Buckets and Measurements. Each measurement contains Tags and Fields.

ℹ️ The details of these topics can be read in the official documentation.

Configuration

  • Bucket: mail_audit
  • Measurement: audit

audit measurement

The audit measurement has the following tags and fields.

Tags

  • entity: The value will always be 'email'.
  • scope: The value can be 'compose' or 'read'. The 'compose' scope refers to the events happening when user is trying to send a fresh mail. The 'read' scope refers to the events hapening in the context of reading a mail and any event on that received mail.
  • auth_type: Refers to an authentication method that a user would have used while authenticating itself, for example 'password' or 'email_otp'.
  • path: Refers to the API endpoint through which the user request arrived in the system. Please note that we do not store the secure link of the mail in the audit entry when user attempts to read the mail.
  • http_method: Refers to the HTTP method (ex: GET, POST, PUT, or DELETE) that is associated with an API endpoint.
  • state: Refers to 'successful' or 'unsuccessful' states of a user's request.
  • source: There are two possible sources - 'API' and 'SMTP'. The API source indicates the mail originating from an API client, such as Secure Mail web client. The SMTP source indicates the mail originating from an SMTP client, such as Microsoft Outlook. Note that only some audit entries have source annotation. Any audit entry that has an empty value of the source is considered the API source.

Fields

  • id: This is a unique identifier for an audit entry.
  • parent_id: An audit entry may refer to another audit entry (identified as 'parent_id') if the two entries have a relationship. For example, in order to complete a process, the user might have to go through multiple sequential steps. As a result, there will be more than one audit entry corresponding to multiple sequential steps. These audit entries then form a parent-child relationship.
  • user_email: The audit entry contains full email of the user.
  • mail_id: Refers to the unique identifier of the mail.
  • user_ip: Refers to the full IP address of the user.
  • query_params: The audit entry may contain query parameters that are part of an http request. Please note that we do not expose any sensitive information as part of query params of the API endpoints.
  • recip_selected_auth_type: Refers to the authentication method selected by a recipient, if the recipient gets an opportunity to do so. Such an opportunity is available to a recipient if the mail was sent with authentication method 'cookie'. At this stage, the recipient gets the opportunity to either continue with 'cookie' or opt for a different authentication method.
  • auth_type_previous: When we capture the authentication method selection by a recipient, we also capture the authentication method that was applied by the sender on that mail.
  • other_info: Might contain other general info, such as attachment identifier and others.

Audit entry

An audit entry contains the information about tags and fields that are described above. However, not all tags and fields are populated with their respective values for an audit entry. If a specific tag or field is not relevant to an audit entry, it will have an empty value.

An audit entry gets generated for every key action that a user takes. For example, if a user wants to authenticate, the user might be required to take two key actions:

  1. Initiate authentication
  2. Submit OTP

As a result of these two steps, two audit entries will be generated. These two entries will form a relationship with the help of id and parent_id. In this example, the audit entry for the 2nd action (Submit OTP) will contain a parent_id, which will be same as the id of the first entry (Initiate authentication).

A longer relationship chain can be formed if user continues to perform additional actions within the same active session. Such relationships among audit entries help in analysing the full course of a user's journey.

Sample query

With the understanding of the above data model and audit entry, different kinds of audit data can be queried and analysed for different purposes.

A sample query is below to see a table of audit data for the past 300 days.

from(bucket: "mail_audit")
    |> range(start: -300d)
    |> filter(fn: (r) => r["_measurement"] == "audit")
    |> group()

The result of the above sample query in a sample tabular data is below.

influxdb sample audit data

Please refer to the official documentation for more on the InfluxDB's query capabilities.

Was this page helpful?