SPLK-3002 Access Control

Access Control Detailed Explanation

1. Why Access Control Matters in ITSI

The Core Idea:

Access Control is about managing who can do what in ITSI.

It ensures that:

• Users only see data that’s relevant to them

• Critical configurations are protected from accidental edits

• Operations teams don’t step on each other’s work

This is key for both:

• Security: Protect sensitive metrics and infrastructure details

• Clarity: Keep teams focused on the systems they’re responsible for

2. Access Control Mechanisms in ITSI

ITSI builds on Splunk’s existing RBAC (Role-Based Access Control) model and adds new tools that are service- and team-focused.

a. Teams

Teams are logical groupings in ITSI that link:

• Users

• Services

• Notable Events

• Dashboards

Example:

• “Web Ops Team” manages web services

• “DB Team” focuses on database performance

Each team can:

• Own specific services

• Receive alerts for only their systems

• Access filtered dashboards and Glass Tables

This makes ITSI much more organized and user-specific.

b. Roles and Capabilities

ITSI uses standard Splunk roles (e.g., admin, power, user) and allows you to create custom roles with specific capabilities.

Capabilities can include:

• Viewing or editing services

• Creating KPIs or Glass Tables

• Managing Notable Events

Example Roles:

• itsi_admin: Full access to everything in ITSI

• itsi_team_lead: Can edit only their team’s services

• itsi_viewer: Can view dashboards, but not edit anything

c. Service-Level Restrictions

ITSI allows fine-grained control down to the service level:

• You can decide who can view or modify each service or even specific KPIs.

Use this to:

• Prevent unauthorized edits to production-critical services

• Let junior team members observe only, without changing configurations

3. Common ITSI Roles

Here's a quick overview of how roles are typically structured in an ITSI setup:

Role	Permissions
ITSI Admin	Full access to all features and settings
Service Owner	Manage specific services, KPIs, and alerts
Viewer	Read-only access to dashboards, Glass Tables, etc.

4. Best Practices for Access Control

Use Inherited Roles

• If you already use RBAC in Splunk, extend those roles into ITSI.

• This keeps role management simpler and more consistent.

Periodically Audit Access

• Review user roles every few months.

• Remove access for users who’ve changed roles or left the team.

• Update team-service mappings as responsibilities shift.

Align Teams with Real Structures

• Set up teams in ITSI to mirror how your organization actually works:

  • Dev teams manage their own apps

  • Ops teams manage shared infrastructure

This improves communication, ownership, and accountability.

Summary: What to Remember About Access Control

• ITSI’s access control ensures that users only see and manage what they’re responsible for.

• It uses a mix of teams, roles, and service-level restrictions to secure the environment.

• Each team can own services, receive events, and access relevant dashboards.

• Use best practices to maintain clarity, security, and operational efficiency.

Access Control (Additional Content)

1. Glass Table Access Control

Access to Glass Tables in ITSI can be restricted by team or role, not just at the dashboard or user level.

• This ensures that sensitive visualizations, such as KPIs related to production environments or executive systems, are only visible to authorized users.

• Teams can be configured so that each user only sees the Glass Tables linked to their assigned services or responsibilities.

Access to Glass Tables can also be restricted per user/team, ensuring sensitive visualizations are only visible to authorized roles.

This aspect of access control helps enforce data confidentiality and operational boundaries. In the exam, this may be tested under phrases like “Glass Table confidentiality” or “role-based visualization access.”

2. Notable Event Ownership Routing

In ITSI, Notable Events can be automatically routed to the correct team based on:

• The service ownership assigned in the service definition

• The entity involved in the incident

• Predefined routing rules tied to roles or team mappings

This ensures:

• Events go to the right people without manual filtering

• Reduces cross-team noise

• Enhances incident accountability

Notable Events can be automatically routed to teams based on service ownership, reducing noise and ensuring alert accountability.

This routing logic is crucial in enterprise environments where different teams monitor different scopes, and is often covered in both multiple-choice and scenario-based questions.

3. Access Control Audit via ITSI Audit Dashboards

ITSI includes audit dashboards that allow administrators to:

• Track who made changes to services, KPIs, or thresholds

• Review what changes were made

• See when those changes occurred

These dashboards are key for:

• Security compliance

• Internal audits

• Troubleshooting misconfigurations

ITSI provides audit dashboards to help track who made configuration changes and when, aiding in compliance and troubleshooting.

This feature becomes especially important in environments with strict change control, and knowledge of it is highly relevant to exam questions on configuration management and auditability.

Summary

• Access control ensures that users only view and manage the services and data they are responsible for.

• Access to Glass Tables is also role/team-controlled, not just dashboards.

• Notable Events can be routed to the appropriate teams automatically, based on service ownership.

• Use audit dashboards to review and track configuration changes, which supports compliance and operational transparency.

• The combination of roles, teams, service-level permissions, and auditing tools makes ITSI highly secure and scalable in multi-team environments.