Domino Data for Analytics
Teams set up domino data for analytics by linking data sources to cloud workspaces. Analysts then run notebooks, train models, and build dashboards in shared compute clusters. Most teams start by saving shared database keys inside project settings for fast setup. Broad roles let analysts move fast, but shared keys create big security risks. How domino data for analytics works in practice The platform groups data work into projects with dedicated compute hardware and code storage. Admins assig
User Behavior Analytics (UBA/UEBA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Teams set up domino data for analytics by linking data sources to cloud workspaces. Analysts then run notebooks, train models, and build dashboards in shared compute clusters. Most teams start by saving shared database keys inside project settings for fast setup. Broad roles let analysts move fast, but shared keys create big security risks.
How domino data for analytics works in practice
The platform groups data work into projects with dedicated compute hardware and code storage. Admins assign users to roles that control who can view, edit, or run code. When a user starts a workspace, the platform spins up an isolated container. This container loads the code, libraries, and saved data keys for that project.
Data teams link external databases and cloud storage buckets through shared data connectors. Admins can store static keys at the project level or let each user sign in. Project-level keys let scheduled jobs and shared apps read data without manual sign-ins. Individual user keys pass the analyst identity to the backend database for role checks.
As teams grow, managing these two key types across dozens of projects gets hard. Analysts copy notebooks across projects and expect their database queries to work right away. To avoid delays, admins often grant broad read and write roles to shared service accounts. Every workspace in the project then shares the same wide database permissions.
Where native workspace controls leave gaps
Native project roles do a great job of managing who can launch a notebook. They also track code changes, model runs, and package versions inside the platform. Still, project roles only check who logs in to the workspace container. They do not inspect the actual database queries that run inside a live session.
Once a notebook connects to a production database, the database trusts that session completely. A bad query can pull millions of rows containing emails, phone numbers, or card numbers. Static keys stored in project settings can also leak through notebook outputs or logs. Native workspace rules cannot rewrite sensitive fields in query results on the fly.
User Behavior Analytics (UBA/UEBA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Scheduled jobs and published web apps make this gap even wider for security teams. These background jobs often run under a single shared database account all day long. When a slow or dangerous query hits the database, logs only show the shared account. Admins cannot see which analyst wrote the query or which notebook sent it.
Securing data queries across analytics workspaces
To fix this, teams need controls that work at the query level in real time. Instead of storing database keys in workspaces, teams should verify each user session directly. Every query from a notebook should map back to the person who ran the code. This gives data teams clear audit logs across all databases and cloud storage systems.
Teams also need rules that check queries and results before data reaches the notebook. Masking rules can rewrite emails, phone numbers, and national IDs in query results right away. Analysts still get the rows they need to build charts and train models. At the same time, raw sensitive fields stay out of notebook memory and saved files.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do analysts read production databases from a workspace?
Analysts use saved data connectors or environment variables inside their notebook sessions. These connectors pass credentials to the database so the user can run queries.
Why are shared project keys risky for analytics teams?
Shared keys give every user in a project the same database permissions. Database logs only show the shared account name instead of the actual user.
How can teams protect sensitive fields during notebook analysis?
Teams can apply masking rules that rewrite matched fields like card numbers in query results. This lets analysts run queries while keeping raw sensitive values out of workspaces.