Superset Business Intelligence
You set up a superset business intelligence platform by linking your data store to the web app. Then you assign user roles to control who can read charts and run SQL queries. Most teams start by sharing one database login across the whole analytics tool. This fast setup creates big risks when roles are too broad. Users with broad rights can query sensitive tables or pull raw customer records. How superset business intelligence roles and data links work The platform uses a role system to manag
Threat Intelligence Feeds + Business Continuity & Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a superset business intelligence platform by linking your data store to the web app. Then you assign user roles to control who can read charts and run SQL queries. Most teams start by sharing one database login across the whole analytics tool. This fast setup creates big risks when roles are too broad. Users with broad rights can query sensitive tables or pull raw customer records.
How superset business intelligence roles and data links work
The platform uses a role system to manage what users can do in the app. Admins map users to preset roles or build custom roles for specific teams. Each role holds a list of rules for views, menus, and data sources. A basic reader role lets a user open a dashboard and filter a chart. A stronger SQL role lets an analyst write and run raw queries against linked databases.
To read data, the app needs a link to your database or warehouse. You enter the database host, port, and login key into the app settings. When a user loads a chart, the app builds a query and sends it out. It uses that saved database login to run the query and fetch the rows. You can also turn on row rules to filter data by user group. The app adds a filter clause to the query before the database runs it.
Why shared database logins create risks in analytics apps
Native roles work well when users only look at preset charts and dashboards. They stop basic viewers from opening the SQL editor or adding new data sources. Row filters also help segment data when everyone uses standard visual views.
Still, the native setup leaves a major gap for live SQL queries and shared logins. The database only sees the shared app login, not the actual person behind the screen. Your database logs will show thousands of queries coming from one single service account. If an analyst runs a bad query, you must dig through two separate log systems. You have to match app logs with database logs just to find the user.
Native app roles also decide who logs in, not what individual statements do in flight. Once a user has SQL editor access, they can query any table that login can read. If the shared database role can read customer tables, the analyst can pull private fields. Raw emails, phone numbers, and card numbers return right to the browser screen. Exporting a CSV file takes one click and moves raw data onto a local laptop.
Threat Intelligence Feeds + Business Continuity & Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten database rules for analytics teams
Start by creating a read-only database user just for your analytics app. Never use an admin account or a write-enabled login for chart queries. Grant read rights only to the specific schemas and views that reports need. Keep raw staging tables and secret system tables off limits to that database role.
Next, split your app users into clear groups based on their daily work. Give dashboard viewers a role that blocks the SQL lab editor completely. For analysts who write SQL, link a separate database connection with tighter table limits. Check your role mappings every month to remove old accounts and unused permissions. Even with clean roles, teams still need a way to inspect queries and mask fields in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do you restrict table access in a superset business intelligence setup?
You limit table access by combining database read grants with app data source permissions. First, give the database login read rights only to safe reporting views. Then, assign specific dataset roles inside the app to match each team.
Can analysts see raw personal data when running SQL queries?
Yes, if the underlying database account can read those columns, SQL users can query them. Native app roles do not rewrite emails, phone numbers, or card numbers in query results. You need inline data masking to rewrite matched fields before results reach the browser.
Why do database logs only show one user for all chart queries?
Most teams set up the data link with one shared service account key. The app sends every user query through that single database login. To track individual users at the database layer, you must tie queries to user identity.