Securing the BI and analytics platform itself: admin roles, service accounts, keys, logs and lifecycle

A business intelligence platform holds standing, stored credentials to the warehouse, the finance system and the CRM, and it can publish what it reads to anyone with a link, so whoever controls its administration and service identities controls a large share of the organisation's data. Most BI security work is about what report viewers may see: row-level security, sensitivity labels and sharing settings. This guide covers the inside view: tenant and site administrators, service principals and service accounts, embed tokens and app secrets, on-premises data gateway credentials, audit logs and the platform lifecycle. It is vendor-neutral and applies to cloud BI services, self-hosted BI servers and embedded analytics. It is written for BI platform owners, data platform engineers and security teams. For product-specific settings see the Power BI Security Guide and Tableau Cloud and Server Security (listed alphabetically); where examples from vendor documentation are used below, they are given for both products, also alphabetically.

Key takeaways

• The BI admin is a data admin. A tenant or site administrator can change sharing, export and embedding settings for every report, so it needs privileged account controls, not ordinary user controls.
• Stored data source credentials are the real prize. Scheduled refresh and gateway connections run as one stored identity regardless of which user views the report, so that identity must be read-only and scoped.
• Embedding creates new non-human identities. Every embedded analytics application has a service identity and a secret that mints viewer tokens; treat it like any other production API credential.
• Export is the exfiltration path. Export to file, publish to web, subscriptions and API extraction move data out without touching the warehouse's own controls.
• Logs live in the BI platform, not the warehouse. The warehouse sees one service account querying; only the BI activity log shows which person viewed or exported what.

The BI platform attack surface

Terminology differs between products, but every BI platform has the same building blocks, each with identities that need an owner.

The relevant ATT&CK techniques include T1078.004 Cloud Accounts (stolen BI or admin logins), T1213 Data from Information Repositories (bulk reading of reports and semantic models), T1552.001 Credentials In Files (connection strings and secrets in report files, scripts and embedding code), T1528 Steal Application Access Token and T1567 Exfiltration Over Web Service (export and publishing paths).

Administrative roles and separation of duties

Every BI platform has a top-level administrator role that sets tenant or site-wide policy, and most add server, capacity or content administration below it. NIST SP 800-53 AC-5 Separation of Duties and AC-6(5) Privileged Accounts apply directly.

• Use groups: assign every role through identity provider groups, ideally provisioned with SCIM, so leavers lose access when their account is disabled. See the SCIM Provisioning Guide.
• Separate admin identities: administrators use a dedicated admin account for tenant changes, not the account they read email with.
• Break-glass: keep one emergency administrator outside SSO, vaulted and alerted on, so an identity provider outage does not lock the platform.

Service accounts, service principals and stored credentials

Non-human identities usually outnumber administrators on a mature BI platform. They fall into four classes.

The data source credential deserves the most attention. Vendor documentation for on-premises gateways describes the cloud service passing encrypted credentials to the gateway, which decrypts them and connects; the stored credential is used for the connection regardless of which user runs the query, with exceptions for some direct query and live connection modes. In practice that means the effective data access of every report is the access of its stored identity, and row-level security in the semantic model is the only thing between a viewer and the full data set. Where the platform supports it, pass the viewer's identity through to the source (single sign-on to the data source) for sensitive sets, and use a stored service account for the rest. Warehouse-side settings for these accounts are covered in Securing the data warehouse and lakehouse itself.

Never let a person's own account be the stored credential or the embedding identity: when that person leaves, either refresh breaks or, worse, their account is kept alive to stop it breaking.

Embed tokens, app secrets and gateways

Embedded analytics follows the same pattern across products: a back-end application holds a long-lived secret, uses it to obtain a short-lived token for each viewer, and the browser presents that token to the BI service. Examples from vendor documentation, alphabetically:

• Microsoft Power BI: the application authenticates to Microsoft Entra ID as a service principal (the recommended option) or a master user account, then calls the Embed Token REST API. The embed token specifies the content the viewer may access and the access level (view, create or edit). Service principal use requires API access to be enabled in admin settings and workspace membership.
• Tableau: connected apps establish trust between a site and an external application, by direct trust (the application signs a JSON Web Token) or OAuth 2.0 trust through the identity provider. A direct trust JWT must expire within 10 minutes; access level controls restrict which content can be embedded and where, and scopes such as tableau:views:embed limit what the token can do. Each connected app can hold two secrets so one can be rotated while the other is active, and secrets remain valid until deleted.

The controls are the same whichever product you run:

1. Keep the long-lived secret server-side in a secrets manager, never in front-end code, report files or source control. See Securing the secrets manager itself.
2. Mint the narrowest token: one report or view, view-only unless editing is the product, row-level identity set from the application's authenticated user, shortest lifetime the user experience allows.
3. Restrict where content can render with the platform's allowed domain or access level controls.
4. Rotate on a schedule and on staff change, using the overlap the platform offers (two secrets, or credential rollover) so rotation does not cause an outage.
5. Harden gateways: both gateway designs described in vendor documentation connect outbound from the private network to the cloud service, so no inbound firewall opening is needed. Run them on dedicated, patched hosts, restrict who can administer them, and limit each gateway to the data sources it serves.

Distribution and export controls

• Publish to web or anonymous sharing: disable tenant-wide, or allow only for a named group with approval. Review existing public links before go-live.
• Export to file and data download: limit underlying data export for sensitive workspaces; keep summarised export where the business needs it.
• External guests: allow only through the identity provider's guest process, with expiry and review.
• Subscriptions and alerts: restrict email delivery to internal domains unless a business owner approves an external recipient.
• Personal workspaces: no production data sources or stored credentials in personal areas.

For choosing between masking and row filtering in the semantic layer, see Dynamic Data Masking vs Row-Level Security.

Logging and monitoring

The warehouse sees the refresh service account; only the BI activity log shows which person viewed, exported or shared which report. Export it to the SIEM and keep it beyond the platform's default retention. NIST SP 800-53 AU-2, AU-6, AU-9 and AC-6(9) Log Use of Privileged Functions apply.

Lifecycle: build, operate, change, retire

1. Build: set tenant policy (export, sharing, embedding, API access, guest access) before the first workspace; create admin groups, break-glass, log export and the data source service accounts.
2. Onboard content: each workspace gets an owner, a classification and a data source identity; production content is deployed from a pipeline, not uploaded by hand.
3. Operate: patch self-hosted servers and gateways promptly with vendor security updates; rotate embedding secrets and stored credentials; review administrators quarterly.
4. Change: treat tenant setting changes as changes to a production system, with a ticket and a second approver.
5. Retire: when a workspace, report or embedded app is retired, delete its stored credentials, secrets, gateway data sources, public links and subscriptions, and disable the service accounts at the source. Orphaned refresh credentials are a common finding long after the dashboard is gone; the NHI offboarding and decommissioning guide covers the identity side.

Hardening an existing platform: a phased approach

1. Weeks 1 to 2, inventory: export the list of administrators, workspaces, data sources and their stored identities, gateways, embedding identities, API tokens and public links. Record metadata only.
2. Weeks 2 to 4, quick wins: remove surplus administrators, revoke public links nobody owns, replace personal accounts used as stored credentials, turn on log export.
3. Weeks 4 to 8, tighten: scope data source accounts to read-only, move embedding secrets to the secrets manager, restrict export and guest settings, starting with sensitive workspaces as a pilot ring.
4. Weeks 8 to 12, operate: alerts live, quarterly review scheduled, rotation automated.
5. Rollback: tenant settings can usually be reverted in minutes; rotate secrets with overlap so a failed rotation falls back to the previous secret rather than breaking every embedded report.

Decision guidance

Small organisations can usually run with two administrators, one stored credential per source and the provider's default log retention exported weekly. Large organisations need separate administrators per capacity or region, a pipeline for content deployment and continuous log export with detections.

Detection and measurement

• Administrator count: standing tenant or site administrators. Target two or three, plus break-glass.
• Personal stored credentials: data sources whose stored identity is a person. Target zero.
• Secret age: embedding secrets and API tokens older than the rotation policy. Target zero.
• Public links: anonymous or publish-to-web items without an approved owner. Target zero.
• Orphaned credentials: stored credentials attached to no active report or refresh.
• Log coverage: days of activity log available in the SIEM against the retention policy.

Framework mapping

Common failure patterns

• The analyst's own login as the refresh credential: every viewer inherits that person's access, and the account cannot be disabled when they leave.
• Embedding secret in front-end code or a public repository: anyone who finds it can mint tokens for any content the service identity reaches.
• Write-capable warehouse account behind dashboards: a read-only use case runs on an identity that can alter or drop data.
• Publish to web left open: a report with customer data is reachable by anyone with the link, with no sign-in in the logs.
• Gateway on a shared server: the host that decrypts stored credentials also runs unrelated software with many local administrators.
• No log export: the activity log rolls off at the platform default and an export investigation has nothing to work with.

Practitioner checklist

• Tenant or site administrators limited to named groups, phishing-resistant MFA, just-in-time where possible.
• Break-glass administrator vaulted and alerted on.
• Every stored data source credential is a read-only service account with an owner; no personal accounts.
• Embedding secrets in a secrets manager, rotated with overlap, tokens scoped to content and lifetime.
• Gateways on dedicated hardened hosts, outbound-only, with restricted administrators.
• Publish to web, external sharing and underlying data export restricted at tenant level.
• Activity log exported to the SIEM with alerts for setting changes, admin grants, public links and bulk export.
• Quarterly review of administrators, service identities, tokens and public links.
• Retirement procedure removes credentials, secrets, links and subscriptions with the content.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• Microsoft: Power BI embed tokens
• Microsoft: On-premises data gateway architecture
• Tableau: Connected apps
• Tableau: Bridge for private network data
• MITRE ATT&CK: T1213 Data from Information Repositories

Related NHI Mgmt Group resources: Power BI Security Guide, Tableau Cloud and Server Security, Securing the data warehouse and lakehouse itself, Securing the secrets manager itself.