Before You Connect a Self-Hosted BI Tool to a Database: A Least-Privilege Checklist

Start by mapping the connection

This is a general planning checklist, not a description of controls available in every BI application or database. Use the documentation for the specific products, versions, and connection method you plan to run to answer the questions below.

Before configuring a connection, record which BI application will connect, which database account it will use, how the application reaches the database, and who can open saved questions or dashboards. Keep application permissions and database permissions as separate items to investigate.

• Name the BI application instance and the database or databases it will contact.
• Record who can sign in, create or edit reports, and view shared dashboards.
• Identify where connection credentials are stored and who is authorized to change them.
• Sketch the network path and note which systems or teams administer each part.

Review application roles and database permissions separately

Treat this as a verification task, not an assumption about how roles work in a particular product. Check the documentation for your BI application and test what viewer, report editor, and administrator accounts can do. Separately, verify what the database account configured for the connection is permitted to read.

If saved questions, dashboards, exports, or scheduled queries are part of your plan, include them in the review. Do not count an application role as a substitute for checking database grants.

• List the application roles you intend to use and the actions each is meant to allow.
• Document the database privileges granted to the BI connection account.
• Test what representative users can see through the reports and sharing methods you plan to use.
• Record any behavior you cannot verify as an open question.

Create a narrowly scoped source account

Use a dedicated account for the BI connection rather than connecting as root or using an account with write access. A [Basedash guide to building dashboards on MySQL data](https://www.basedash.com/blog/how-to-build-dashboards-on-mysql-data) recommends a dedicated, least-privilege read-only user.

Then determine the appropriate read scope for your reporting needs. Check your database documentation and ask a database administrator whether access can be limited to selected schemas, tables, or views. Verify the effective grants rather than assuming the BI application sets those limits.

• Create a distinct account used only for the BI connection.
• Prefer read-only privileges; do not use a root or write-enabled account for routine reporting.
• Grant access only to the reporting data the team has approved.
• Ask a database administrator to verify the effective grants, including inherited or broader permissions.

Decide how to handle sensitive fields and rows

Identify fields and records that should not be broadly available through analytics, using your organization’s policies to determine what is sensitive. This checklist does not prescribe a particular legal or regulatory standard.

For each item, consider whether your design should exclude it, expose a reduced set through database views, or use masking where your systems support it. If access should vary by row, document where the restriction is intended to be enforced and test permitted and prohibited cases through the actual BI connection.

• List sensitive fields and record groups before building reports.
• Decide whether each item should be excluded, reduced, masked, or available only to specific users.
• Test any required row-level restriction at its intended enforcement point.
• Include reports, exports, and shared dashboards in checks for unintended exposure.

Assess query impact before routine use

Include source-system impact in your review; read-only access alone does not answer what running reports will mean for your environment. Consider the reports you expect to run, their frequency, and whether multiple people may use them at once.

Test representative reports and refresh patterns in an environment appropriate to your risk. Consult the documentation for your BI application and database about any available query limits, timeouts, scheduling controls, or other safeguards, and verify their behavior in your setup. If you cannot assess a material concern, resolve it before enabling routine reporting.

• Identify reports that may scan or aggregate substantial amounts of data.
• Estimate expected refresh frequency and overlapping use.
• Review representative tests with the people responsible for the database.
• Record which query controls you verified and which remain unknown.

Plan for credential changes and ownership

Record who owns the BI connection and who is authorized to change its database credential. Note which reports or scheduled tasks depend on the connection, if applicable.

Document how your team will rotate or revoke the credential. Before making a change, check the relevant application documentation for the behavior you need to understand. Afterwards, test the connection and important reports rather than assuming how they will respond.

• Assign an owner for the connection and an owner for database permissions.
• Record the credential’s purpose, scope, and change procedure without storing its secret in the checklist.
• Identify dependent dashboards and scheduled queries, if used.
• Test the documented rotation or revocation procedure for your setup.

Use a pre-launch test matrix

A successful connection is only one test. Use the matrix below to check the access, visibility, and source-system behavior relevant to your design. Record the results and distinguish verified controls from unanswered questions.

Use the findings to decide whether the connection is ready for its intended audience. If an important restriction cannot be demonstrated, reconsider the data scope or design before launch.

• Allowed read: confirm the connection can access approved reporting data.
• Denied read: where intended, test that it cannot access an unapproved table, schema, or view.
• User access: test representative viewer, editor, and administrator accounts against the reports they should and should not see.
• Sensitive data: check that restricted fields and rows are not exposed through the tested reports.
• Source impact: observe representative queries and refresh behavior with the database owner.
• Change response: test the documented procedure for changing or revoking the credential.
• Record the test date, responsible person, outcome, and unresolved questions.

Treat hosting and data governance as separate decisions

A managed deployment can reduce the work involved in operating application infrastructure, but it does not decide which database records the BI connection should read or who should see the results. Your team still needs to make and verify those access and governance choices.

Airbip offers managed deployment for applications in its public catalog, with application instances running as Docker workloads on Airbip cloud servers. It automates routing and TLS certificates and includes DNS checks, service lifecycle management, and configurable daily, weekly, and monthly backups. These infrastructure capabilities do not replace least-privilege database design or verification of the selected BI application’s controls.