Amazon QuickSight: Implementing Row-Level Security

Row-Level Security (RLS) in QuickSight ensures users only access data relevant to their roles, enhancing data confidentiality and compliance. It enables secure, multi-tenant analytics by restricting visibility at the row level. RLS is crucial for delivering personalized insights without compromising sensitive information.

This is especially important when embedding dashboards for different audiences—whether authenticated internal users or anonymous public viewers.

Understanding Row-Level Security in QuickSight

Row-Level Security (RLS) filters data at the dataset level based on user identity or attributes. When RLS is applied, users only see the subset of data they are authorized to view, even if they access the same analysis or dashboard.

QuickSight supports two main types of RLS:

• User-Based Rules: RLS based on specific usernames or group memberships.
• Tag-Based Rules: RLS using session tags passed during dashboard embedding (commonly used for anonymous or dynamic users).

Quicksight: User-Based Rules

🔐 Use Case: Internal Embedded Dashboards for Registered Users

Imagine a SaaS application where internal users (e.g., sales reps, regional managers) log in and access embedded dashboards tailored to their roles or regions. You want each user to only see the data relevant to them.

How It Works

1. Create a dataset in QuickSight.
2. Define a permissions dataset with mappings like:
3. Apply the RLS rules to your main dataset using this permissions table.
4. Embed the dashboard using authenticated embedding, typically via AWS IAM federation or QuickSight's user-based embedding APIs.

Benefits

• Fine-grained access control tied to user identities.
• Easily integrates with corporate identity providers (e.g., Okta, Active Directory via SAML).
• Ideal for internal or registered user scenarios.

Quicksight: Tag-Based Rules

Tag-based RLS is designed for use cases where the user is anonymous or you don’t want to manage individual QuickSight users. Instead, you use session tags passed during embedding to dynamically filter data.

🌐 Use Case: Anonymous Embedded Dashboards for Public or External Viewers

Suppose you offer a public dashboard embedded in a customer portal that shows each user their own billing summary or KPIs, without requiring them to log in to QuickSight. You still need to enforce data security at the row level.

How It Works

1. Your application authenticates the user (e.g., via JWT or session cookies).
2. It generates a QuickSight embedding URL with session tags such as:

   {
       "Key": "Company_ID",
       "Value": "2"
   }
   

3. In QuickSight, define a permissions dataset that uses the tag Company_ID to filter rows.
4. Apply the tag-based RLS to your dataset.

Benefits

• No need to create QuickSight users for every viewer.
• Dynamic and scalable for large public-facing dashboards.
• Ideal for SaaS apps with large or anonymous customer bases.

🔢 Pricing Considerations for Row-Level Security in QuickSight

Understanding the pricing implications of RLS in AWS QuickSight is crucial, especially when designing for scalability and embedding dashboards in different contexts.

1. User-Based RLS Pricing (Registered Users)
   When using user-based rules:
   • Each QuickSight user (Standard or Enterprise edition) incurs a monthly subscription fee.
   • For embedded dashboards, you'll likely use authenticated embedding, which means you need to provision users through IAM federation or QuickSight accounts.
   • Each registered user is billed based on Role assigns.
   • Row-Level Security (RLS) does not add extra cost per se, but more users = more costs. If you want more information about it, visit Quicksight User Pricing.

Good for: Internal apps where user count is known and limited.

2. Tag-Based RLS Pricing (Anonymous Users)
   For anonymous users using tag-based rules:
   • You leverage anonymous embedding, introduced under QuickSight’s session-based pricing model.
   • Pricing is usage-based, with charges per session (30-minute blocks).
   • ~$0.30 per session for Enterprise edition (subject to region).
   • No need to manage or pay for individual QuickSight users.
   • RLS is applied dynamically using session tags, at no additional charge.

Good for: Large-scale SaaS or public-facing dashboards with thousands of unique viewers.

Best Practices

• Use user-based RLS when you control identity via IAM, SSO, or QuickSight groups.
• Use tag-based RLS when embedding dashboards for external or unauthenticated users.
• Always validate session tag values in your backend before embedding to avoid spoofing.
• Leverage parameterized datasets to further optimize performance and security.