Amazon QuickSight Security: Identity, Data Access, Row Level Security and Embedding

A business intelligence service sits on top of your most sensitive data, so who can sign in, which data sources it can reach and which rows each viewer sees decide whether dashboards stay safe to share. Amazon QuickSight continues as Amazon Quick Sight within Amazon Quick, and its security model gives administrators a clear set of customer-side controls: an identity method chosen at subscription, user roles and custom permissions, IAM roles that govern access to AWS data sources, row-level and column-level security, VPC connections for private data, and server-side controls for embedded analytics. This guide explains how each layer works, the settings to choose, how to roll them out and how to monitor them. It is for BI platform owners, AWS security teams and developers who embed dashboards in applications.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation for Amazon Quick Sight as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Choose the identity method carefully at sign-up. AWS states that identity methods cannot be changed after the account is created, so decide between IAM Identity Center, IAM federation and Quick-managed users before subscribing.
• Treat the service's IAM role as a data access boundary. The role Quick Sight uses for AWS services decides which S3 buckets, Athena workgroups and secrets every author can reach; scope it to named resources.
• Row-level security denies by default once applied. A user or group with no rule in the permissions dataset sees no rows, which makes RLS a safe default for multi-team and multi-tenant dashboards.
• Embedding is controlled server-side. Embed URLs carry a bearer token valid for 5 minutes and redeemable once; session tags that drive tenant filtering must be set only by your backend.
• CloudTrail covers both API and console activity. Events from quicksight.amazonaws.com include non-API events such as CreateDataSource, UpdateDashboardAccess and BatchCreateUser, which are the core signals for detection.

How identity and access work in Amazon Quick Sight

Access in Quick Sight has three layers that are configured separately. The first is the AWS control plane: IAM policies decide who can subscribe, manage the account, register users and call APIs such as RegisterUser or GenerateEmbedUrlForRegisteredUser. The second is the Quick Sight user layer: every person has a Quick Sight user with a role (reader, author or admin, plus the Pro variants) and optional custom permissions, and every asset (data source, dataset, analysis, dashboard, folder) has its own sharing permissions. The third is the data layer: the IAM role, credentials or secrets the service uses to query the underlying data, filtered further by row-level and column-level security.

Identity methods

The RegisterUser API lists three identity types: IAM, QUICKSIGHT and IAM_IDENTITY_CENTER. The Amazon Quick documentation also describes Active Directory integration. AWS states plainly that the identity method cannot be changed after the account is created, so this is the most important early decision.

Decision guidance: where IAM Identity Center is already the workforce entry point to AWS, it gives the cleanest lifecycle, because joiners and leavers are handled in the identity provider and groups flow through. IAM federation suits applications that register users programmatically for embedding. Quick-managed users are simplest but put password and lifecycle management inside the BI tool, so reserve them for small or temporary deployments. AWS also notes that some Identity Center actions are irreversible for sign-in (for example disabling or deleting the Quick application in Identity Center), so put those under change control. See the AWS IAM Identity Center Guide for the identity side.

User roles and custom permissions

Custom permissions profiles (Enterprise edition) restrict any combination of creating and updating data sources, creating and updating datasets, creating and updating email reports, and subscribing to email reports. AWS states these are applied through IAM policies and override the default role permissions. A common pattern is an "analyst" profile that can build analyses on curated datasets but cannot create new data sources, which keeps data connections in the hands of the platform team.

Admin roles and privileged access

Privileged access in Quick Sight comes from two directions, and both need controlling.

• Quick Sight admins: users with ADMIN or ADMIN_PRO manage account settings, including which AWS services the service can reach, the Secrets Manager secrets it can read and the VPC connections it uses. Keep this to a small group, mapped to a dedicated identity provider group, and review membership quarterly.
• IAM principals with quicksight:* permissions: anyone who can call RegisterUser, UpdateUser, UpdateDashboardPermissions or the embedding APIs can grant access without using the console. Scope these actions to the automation roles and administrators that need them.
• Security and permissions settings: AWS documents the IAM actions quicksight:AccountConfigurations (set default access to AWS resources) and quicksight:ScopeDownPolicy (scope permissions to AWS resources) for administrators who manage Manage Quick > Security & permissions. Grant them only to the platform administrators.
• Passing an IAM role: to make the service use an existing role, the administrator needs iam:PassRole on that role. AWS's example scopes iam:PassRole to one role ARN with the condition iam:PassedToService equal to quicksight.amazonaws.com, plus quicksight:UpdateResourcePermissions. Use the same pattern so administrators cannot pass broader roles. See the AWS IAM Policies and Roles Guide.

Asset ownership is a second form of privilege. Dataset owners always see all data, even when row-level security is applied, so co-owner permissions on a dataset are effectively unrestricted read access to that data. Grant owner rights on sensitive datasets to the platform team and share with others as viewers.

Integrations, API tokens and service accounts

The service role for AWS data sources

When an account is set up, it uses either the Quick-managed default role or an existing IAM role you pass in. The role must trust the service principal quicksight.amazonaws.com, and administrators choose which AWS services it can reach under Quick Sight access to AWS services. AWS's examples attach the managed policy AWSQuicksightAthenaAccess for Athena and a policy granting list and get actions on specific buckets for S3. Because every author's queries to those services run through this role, scope S3 access to named buckets and prefixes rather than all buckets, and pair Athena access with workgroup and Lake Formation controls described in the Amazon Athena Security guide. Bringing your own role makes the permissions visible in your IAM tooling and reviewable alongside other workload roles.

Database credentials and Secrets Manager

For databases that use a user name and password, Quick Sight can reference an AWS Secrets Manager secret instead of storing the credential pair in the data source. An administrator selects the secrets under Amazon Quick access to AWS resources > AWS Secrets Manager, and the service creates the role aws-quicksight-secretsmanager-role-v0 with read-only access to those secrets. Points to plan for:

• If the secret uses a customer managed KMS key, add kms:Decrypt for aws-quicksight-secretsmanager-role-v0 on that key.
• At create or update time, access to secretsmanager:GetSecretValue is authorised against the API caller's IAM policy, so the people or pipelines creating data sources need that permission for the specific secret ARN.
• Editing the data source in the console removes the secret reference; restore it with update-data-source, so manage secret-backed data sources through infrastructure as code.
• Rotation happens in Secrets Manager and Quick Sight picks up the new value on its next request. Use a dedicated, read-only database account per data source. See the AWS Secrets Manager guide.

VPC connections for private data

A VPC connection (Enterprise edition) lets the service reach databases that are not on the public internet, including on-premises data through Direct Connect or VPN. Registering a connection adds elastic network interfaces to your VPC, and AWS states that route tables, network ACLs, subnets and security groups apply to that traffic as to any other. Give the connection its own security group, allow outbound traffic only to the database ports needed, and allow inbound on the database security group only from that group. See the Amazon VPC Security Guide.

Embedding

Embedded analytics requires Enterprise edition and uses GenerateEmbedUrlForRegisteredUser or GenerateEmbedUrlForAnonymousUser; AWS notes the older GetDashboardEmbedUrl and GetSessionEmbedUrl still work but lack newer capabilities. The application calling these APIs assumes an IAM role, which can be in a different account from the subscription. Controls documented in the API reference for anonymous embedding:

For anonymous embedding, tenant isolation depends on two things the application controls: the dashboard ARNs it authorises and the session tags it passes, which must match a dataset configured with RowLevelPermissionTagConfiguration. Test that a session tagged for one tenant cannot see another tenant's rows before go-live.

Row-level and column-level security

Both features are Enterprise edition and are the main tools for sharing one dataset safely across teams or customers.

• User-based RLS: a permissions (rules) dataset with one identifier column (UserName and GroupName, or UserARN and GroupARN) plus one column per restricted field. Field names and values are case-sensitive. Groups must be Quick Sight groups or Microsoft AD groups.
• Deny by default: once RLS is applied, a user or group with no rule sees no rows. A rule with all other columns empty grants access to all data, so review such rules as privileged.
• Limits to design around: 999 rule records per user (direct plus via groups), and RLS works only on string fields, not dates or numbers. Create rules datasets with NEW RULES DATASET or UseAs RLS_RULES; they use strict ingestion that fails on invalid rows.
• Inheritance: child datasets inherit the parent's rules, and you can add rules but not remove inherited ones. Children of an RLS-enabled parent must use Direct Query.
• Tag-based RLS: used with embedding, where session tags supply the filter values at runtime.
• Column-level security: restrict columns to named users or groups. Visuals that use a restricted field do not appear for users without access; in tables, restricted values in the Values field well show as "Not Authorized". CLS carries over when an analysis is published as a dashboard.

Changes to a rules dataset take effect immediately for existing users, so manage rules datasets as code with review, and keep the source table that feeds them under the same access control as the data it protects.

Logging and detection

CloudTrail records Quick Sight API calls and a set of non-API events with event source quicksight.amazonaws.com. AWS lists, among others, user management events (CreateAccount, BatchCreateUser, UpdateGroups, DeleteUser, Unsubscribe), subscription events, dashboard events (GetDashboard, CreateDashboard, UpdateDashboardAccess, DeleteDashboard), analysis events, data source events (CreateDataSource, UpdateDataSource, DeleteDataSource) and dataset events (CreateDataSet, UpdateDatasetAccess, Querydatabase). Data events such as InvokeAction for action connectors are off by default and enabled through advanced event selectors. AWS notes that chat conversations and feedback are logged in CloudWatch Logs rather than CloudTrail.

Alert on the first and third rows. See the AWS CloudTrail Guide.

Metrics that show the controls are working:

• Percentage of users provisioned through the identity provider rather than created manually.
• Number of ADMIN and ADMIN_PRO users, tracked against an agreed ceiling.
• Percentage of datasets containing personal or regulated data with RLS or CLS applied.
• Percentage of database data sources using Secrets Manager secrets.
• Number of dashboards shared with all users or large groups, reviewed monthly.
• Time to remove Quick Sight access after a leaver event.

Hardening baseline

A phased rollout keeps disruption low:

1. Decide identity and edition first. Choose IAM Identity Center or federation and Enterprise edition before subscribing, because the identity method is fixed. Name an admin group in the identity provider.
2. Bring your own service role. Pass an existing IAM role scoped to named buckets, Athena workgroups and services, with iam:PassRole restricted by iam:PassedToService.
3. Move credentials into Secrets Manager. Select secrets for the service, create secret-backed data sources through the API and retire stored credential pairs.
4. Route private data through VPC connections. Use dedicated security groups and private subnets.
5. Apply custom permissions. Restrict data source creation to the platform team; let analysts build on curated datasets.
6. Apply RLS and CLS to sensitive datasets. Pilot on one dashboard with test users per rule, confirm a user with no rule sees nothing, then extend. Keep the previous rules dataset version so you can reapply it quickly, since applying a new version overwrites the old one.
7. Harden embedding. Restrict AllowedDomains, set a session lifetime that matches the application, and generate session tags only on the server.
8. Turn on monitoring. Alerts on data source, sharing and user changes; quarterly access reviews of admins, owners and broad shares.

Small and large organisations: a small team can run a single namespace with IAM Identity Center groups, one service role and RLS on a few key datasets. Larger and multi-tenant deployments benefit from separate namespaces per tenant, infrastructure as code for data sources and rules datasets, and a separate AWS account for the subscription so its roles and logs are isolated.

Framework mapping

In MITRE ATT&CK terms, the identity controls defend against misuse of valid cloud accounts (T1078.004) and the data controls limit collection from cloud data stores (T1530).

Common misconfigurations

• Service role with access to all buckets: every author inherits it. Scope S3 and Athena access to the data the BI platform is meant to serve.
• Credential pairs stored in data sources: rotation becomes manual and owners differ. Use Secrets Manager secrets and a read-only database account.
• Broad "all data" RLS rules: a rule with all restricted columns empty grants everything. Review these rules like admin grants.
• Session tags taken from the browser: tenant filtering must be derived from the server-side session, as AWS advises.
• Manual users alongside federation: accounts created outside the identity provider are missed by leaver processes. Provision through the identity provider and review the user list regularly.

Practitioner checklist

• Confirm the identity method and Enterprise edition before subscribing; record the decision.
• Map ADMIN and ADMIN_PRO to one identity provider group and review it quarterly.
• Pass an existing, scoped IAM role and restrict iam:PassRole with iam:PassedToService.
• Grant quicksight:AccountConfigurations and quicksight:ScopeDownPolicy only to platform administrators.
• Use Secrets Manager secrets for all credential-pair data sources, with kms:Decrypt for customer managed keys.
• Connect private databases through VPC connections with dedicated security groups.
• Apply custom permissions so only the platform team creates data sources.
• Apply RLS and CLS to every dataset with personal or regulated data, and test with a user who has no rule.
• For embedding: restrict AllowedDomains, set SessionLifetimeInMinutes deliberately, and set session tags on the server only.
• Alert on CreateDataSource, UpdateDashboardAccess, UpdateDatasetAccess, BatchCreateUser and changes to the service roles.

Standards and references

• AWS: Security in Amazon Quick
• AWS: Configure your Amazon Quick account with IAM Identity Center
• AWS: RegisterUser API reference
• AWS: Passing IAM roles to Amazon Quick
• AWS: Using AWS Secrets Manager secrets instead of database credentials
• AWS: Using row-level security with user-based rules
• AWS: GenerateEmbedUrlForAnonymousUser API reference
• AWS: Logging operations with AWS CloudTrail

Related NHI Mgmt Group resources: Amazon S3 Security Guide · Amazon Athena Security · AWS IAM Identity Center Guide · AWS Secrets Manager