Analytics and Data Security

Application Analytics provides role-based access control (RBAC) to enable you to control and protect your data. The Analytics permissions enable you to provide granular, controlled access to features and analytics data in your environment. This topic outlines the available permissions.

Roles and Permissions

A predefined role called Analytics Administrator is provided with preset permissions for all Analytics-specific permissions.

You can clone predefined roles as a starting point for creating your own customized roles, but you should not assume the cloned roles have all of the permissions of the predefined role. In some cases, there may be hidden permissions, so you should add or remove permissions as needed for your customized role to ensure that you get the RBAC result you need.

To create roles and assign users to roles for Analytics, users need both the Analytics Administrator and the Account Owner role.

See Transaction Analytics Permissions.

Default Application

To ensure that your users have access to the full Analytics functionality they need, be sure to give them the view permission on the Default Application. This permission is given to all predefined admin roles and to the read-only role, Applications & Dashboards Viewer. If you create new roles for analytics, you need to grant this permission in addition to specific analytics permissions.

When you create a new role, this permission is not automatically given to that role. You can add the read-only role to new users. Alternatively, navigate to Administration > Applications and select the View permission in the Default Application.

Analytics Administration UI Tabs

Access the Analytics tab in the Controller Administration UI when creating new roles to see the available permissions.

General Permissions

This section describes permissions that control access to analytics features:

Search Permissions

All the saved searches created in Analytics appear in this section. The admin role can assign View, Edit, and Delete permissions on a search by search level. The admin can create and save specific searches needed by various roles in your organization. In addition to enabling the permissions, View, Edit, and Delete, for a specific saved search, the admin must also enable access to the related application or log source type for the search. Otherwise, the data access level won't be granted to the role.

To create a new saved search, the user must have the Can Create a Search permission.

View permission: Assigning only the View permission for a saved search means users can not edit or delete the search.

Edit permission: Assigning Edit permission for a saved search means users can modify the filter criteria and save back to the same search.

Delete permission: Assigning Delete permission for a saved search means users can delete the search.

Event Type Permissions

Transactions Permissions: Enables the admin user to assign permissions for viewing application transaction data. Permissions can be granted to view all transaction data for the account or on an application-by-application basis. When creating new roles, remember that granting permissions to view transaction analytics data does not automatically grant permissions to see all application data associated with a specific transaction analytics record.
Attention: You need to grant at least read-only permissions to the application to enable the user to see associated transaction snapshot data such as flow maps.
Log Permissions: Enables the admin user to assign permissions for viewing log data. Permissions can be granted to view log data for all source types configured for the account or on a source by source basis.

Browser Requests Permissions: Enables the admin user to assign permissions for viewing browser request data. Permissions can be granted to view data for all applications for the account or for specific applications.

Mobile Requests Permissions: Enables the admin user to assign permissions for viewing mobile requests and crash report data. Permissions can be granted to view data for all applications for the account or for specific applications.

Custom Analytics Events: Enables the admin user to assign permissions for querying custom analytics events data. Permissions can be granted to view data for all custom analytics events or for specific applications.

Synthetic Permissions: Enables the admin user to assign permissions for querying Synthetic events data. Permissions can be granted to view data for all applications for the account or for specific applications.

Manage API Keys

This page describes how to manage REST API Keys.

The Analytics Events REST API provides three independent endpoints for these responsibilities:

  • Schema Management
  • Publish Events
  • Query Events

API Keys provide a secure authentication mechanism for a caller to prove identity when using these public REST APIs.

Because call sites can vary across your infrastructure, departments, and geographic regions, these credentials could be widely distributed and hard to control. Publishing or querying events from different call sites, therefore, require fine-grained control over the keys and the operations allowed for a particular key. You may also need to revoke these keys on demand if they are found to be compromised.

For these reasons, managing access for the Analytics Events API uses API keys. Your organization can create multiple API keys, manage and distribute them based on your own internal policies. For instance, each department or geographic region may be assigned its own API key for distribution and control management. If an API key is compromised, it can be deleted and a new key created without other undesirable side effects.

API keys are only valid for calling the public Analytics Events REST API and can't be used to access the Splunk AppDynamics Controller or data in any other way. See Analytics Events API.

Permissions

API keys are used only for Analytics Events REST APIs. When you create an API key, you can specify read and write permissions for each API key.

Users with the Manage API permission can do the following actions:

  • Add—Creates an API key
  • Disable—Deactivates the calls using that key temporarily, but does not remove the key
  • Enable—Re-enables a deactivated key
  • Delete—Removes the key permanently
Note: It may take up to 15 minutes for a key that has been deleted or deactivated to be detected and all operations using that key to be rejected.

When you create an API key, you see permissions for the various event types (logs, transactions, browser, and mobile) in our platform. By using these permissions you can limit or grant access to specific event types for each specific API key.

Examples:

Select Publish all Custom Events when you create their API key to generate an API key for your partners allowing them to only publish custom events.

Under Log Permissions, select apache as the source type to generate an API key to allow various users to only query Apache log data.
Attention: Once an API Key is created, you cannot change the permissions.
You can grant permissions for API Keys as follows: Custom Analytics Events
  • Manage Schema— Enables creation of schemas using the Analytics Events Schema Management APIs.
  • Query Custom Events—Enables you to query all Analytics event types (with the appropriate permissions).
  • Publish Custom Events—Enables you to publish Analytics custom events using the Analytics Events Publish APIs.

Transactions—Query all transactions or specific applications.

Logs—Query all logs or specific source types.

Browser Requests—Query all browser requests or specific applications.

Mobile Requests—Query all mobile requests or specific applications.

Synthetic Requests Permissions—Query all synthetic requests data or specific applications.

Connected Devices Permissions—Query all connected device requests data or specific applications.

Note: If you have deployed EUM such that you are using an on-premises Events Service for transaction and log analytics data, and the SaaS Events Service for your EUM data, you can not query the browser or mobile request data using the Analytics API.

Create API Keys

  1. Navigate to Analytics > Configuration > API Keys. You can view existing keys and access actions to manage the keys.
  2. Click +Add to view the configuration panel.
  3. Add a Name and Description.
    Warning: Do not click Create until you finish selecting all the necessary permissions for your use case, including any necessary analytics data permissions. You cannot change the permissions once create the key. You can only edit the description and whether the key is active or inactive.
  4. Expand each permission section to select the permissions for this key.
  5. Click Create.
  6. Copy and save the key.
  7. Select the checkbox indicating you have copied the key and click Done.
    Warning: You cannot retrieve the key once you dismiss this dialog.

Manage Field Visibility

This page describes how to manage the visibility of fields in your analytics data. This capability enables you to prevent fields from being viewed by others in your organization.

You can set the visibility of the fields in most of the analytics event types with the exception of custom events. Hiding fields in custom events is not supported.

Permissions

The Manage Fields permission is required to manage field visibility. If a role has the Manage Fields permission, it means all the users with that role can manage all the fields they have access to. They can unhide the fields or see which fields have been hidden. For instance, if you have Manage Fields permission and View permission for the business transactions in the Ecommerce App, then you can only see and manage fields for that application.

Manage Fields

  1. From the Analytics Search panel, click next to each component grouping to open the Manage Fields panel.
  2. Use the Manage Fields panel to show or hide fields. The list of fields varies based on the event type selected for the search.

Delete Extracted Fields

For >= 4.3, you may have two types of extracted fields, fields created in 4.2 where the Controller version has been upgraded to a higher version and fields extracted from logs with log source rules.

For fields created in 4.2, you can delete the fields:

  1. Hover over the field and click on the view icon that appears.
  2. Click on Delete in the popup.
For fields being extracted from logs using log source rules, you can delete the fields by editing the source rules. See Field Extraction for Source Rules.

Manage Business Journeys and Experience Levels

This page describes how to manage the visibility of business journeys and experience level management (XLM) with role-based access control (RBAC). Business journey and XLMRBAC is required to restrict access to sensitive information among your organization. If a user attempts to access restricted features, a message appears warning the user that access is denied.

Only the analytics admin can grant permissions to business journeys and XLM, as well as with their respective searches, event types, and sources. The admin authorizes access on an individual basis by assigning each user to the applicable role.

Creating Business Journey and XLM Roles

In the Controller UI, navigate to Settings > Administration > Roles.

The analytics admin can view and edit existing roles in the Analytics tab, which contains three sections: General, Searches, and Events. Select +Create to make a new role.

General Permissions

In the General tab, the analytics admin authorizes access to business journeys and/or XLM. This is required for the user to perform any actions on either business journeys or XLM. Check Manage Business Journeys and/or Manage Experience Levels:

With general permission, the user has feature level access to business journeys and/or XLM. However, the user cannot view the definition of existing events or saved searches, or create new events, with only general permission. See the below sections to enable these permissions.

Note:

A user can access business journey data through searches without general permission to business journeys, as long as the user's role permits access to the underlying event type(s) used in business journey definition.

In this way, you can restrict access to define business journeys while also allowing a user to query the data. Ensure the user has all necessary access to event type(s) in the Events tab and leave Manage Business Journeys unchecked.

Search Permissions

There are two search types in Analytics, drag and drop and query language. The analytics admin grants access to both types in the Searches tab.

Choose Can Create a Search to access both search types. Choose +Add to access specific saved searches.

Create search permission is required in order for a user to perform these operations:

  • Save a search
  • Create a metric
  • Create a visual widget

Search access is dependent on event type access. A user has access to create and save searches only for the event type(s) and source(s) assigned in the user's role.

Event Type and Source Permissions

The section describes how to assign event type and source access. Granting permission to business journeys and/or XLM does not provide a user blanket access to all reports. Users have access only to the exact event type(s) and source(s) granted by the analytics admin. For example,  transactions are an event type, and their source is applications. Therefore, if a user requires access to particular applications, the analytics admin must select transactions as well as each necessary application for the user.

This table lists the available event types and their corresponding sources:

Event TypeSource
TransactionApplication
LogSource Type
Browser RecordsApp Key
Mobile Records and SessionsApp Key
Synthetic SessionApp Key
Connected DevicesApp Key
Custom Analytics EventsParticular user-defined event type

You can specify exact access in the Events tab. Select the event type, then specify access for the relevant source. Check "Can View Data from all [source]" to grant blanket access to each source. To select individual sources, click +Add.

With the appropriate event type and source permissions, the user can access existing reports as well as create new reports. For example, a user with permissions to Transactions and all applications can now create a new configuration for any application. However, if this user attempts to create a configuration for Log events, the configuration does not save and an error message appears in the UI:

For XLM configurations, the Filter By field indicates the source(s) of the given Event Type. Users with limited permission to sources need to add their permitted source(s) as filter criteria. If you do not specify filter criteria, you must have permission to all sources for the event type to create the configuration.

Dashboard Access

Grant permission to dashboards in the Dashboard tab. In this tab, the admin specifies if a user can create dashboards and time permissions, as well as custom permissions.

If an Analytics dashboard contains data from business journeys and/or XLM, access to the dashboard depends on the above permissions. For example, a role that allows its users to create a dashboard, but contains no permission to business journeys, does not permit the user to access a business journey-related dashboard. Ensure that roles have the necessary permission to access Analytics data and general dashboard access.