Rubrik Cloud Platform
A rubrik cloud platform manages your backups and restores across local and cloud systems. You set it up by linking your storage accounts and assigning roles to your team. Most teams start by linking their main identity provider to the management console. They map existing user groups to built-in admin roles to move fast. Still, broad admin roles give too many people full control over critical backup data. When an account has wide permissions, one mistake can wipe out recovery points. How the r
Platform Engineering Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A rubrik cloud platform manages your backups and restores across local and cloud systems. You set it up by linking your storage accounts and assigning roles to your team. Most teams start by linking their main identity provider to the management console. They map existing user groups to built-in admin roles to move fast. Still, broad admin roles give too many people full control over critical backup data. When an account has wide permissions, one mistake can wipe out recovery points.
How the rubrik cloud platform handles roles and permissions
The platform uses role-based controls to manage who can view or change backup rules. Admins create custom roles that limit what a user or script can do. You can scope a role down to specific virtual machines, databases, or cloud buckets. This keeps a database admin from changing rules for file servers or network shares. Teams also use service accounts to run automated backup checks and recovery tests. These accounts use API keys to talk to the platform without a human login.
Identity providers pass group claims to the console when a team member logs in. The platform checks those claims and applies the matching role for that active session. You can also set up multi-factor checks and require two people for destructive actions. This native architecture works well for standard tasks inside the main web console. It sets clear boundaries for daily backup schedules and basic restore jobs.
Where native backup roles leave operational gaps
Native roles decide who can log in and start a job inside the console. Still, they do not inspect the live commands or queries running after a restore. When an engineer restores a database to fix a bug, they need direct access. They log in to the restored database instance using a broad admin role. Once inside that database session, the backup platform cannot see what SQL statements run.
A user could run a wide select query that pulls sensitive customer details. That query result might include raw emails, phone numbers, card numbers, or national IDs. Native backup permissions also do not rotate the local database keys used during testing. Shared keys for restored test instances often sit in team chat logs or scripts. Also, audit logs in the backup tool only show that a restore happened. They do not record the exact commands run against the restored data afterward.
Platform Engineering Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to secure restored data and admin workflows
To close this gap, teams must separate backup management from live data sessions. Start by removing standing admin roles from your daily user accounts right away. Give your automation scripts the smallest set of permissions needed for their specific tasks. Rotate all API keys on a set schedule and delete unused service accounts.
Next, put controls in front of the databases and servers that your team restores. Every command or query should pass through a check before it hits the database. You should require a quick peer approval before someone runs a destructive command. Finally, apply data masking to rewrite sensitive fields like card numbers in query results. This lets engineers fix issues on restored systems while keeping private customer data safe.
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 inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
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 approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do we limit what service accounts can do in our backup tool?
Create a custom role that only allows the exact API calls your script needs. Assign that role to the service account and scope it to specific target objects. Rotate the account keys often and watch the audit logs for odd requests.
Why are native backup roles not enough for data privacy rules?
Backup roles only control who can start a backup or restore a data volume. Once a team member mounts a restored database, the backup tool steps out. It cannot inspect live queries or mask emails and phone numbers in results.
How should engineers check restored databases during an incident?
Engineers should connect to the restored database using short-lived credentials instead of static keys. Every query should be logged at the statement level for a clear audit trail. Masking rules should rewrite sensitive fields like national IDs in the query output.