Cohesity Data Cloud
Cohesity Data Cloud unifies backup, recovery, and file storage into one single platform. You set up cohesity data cloud by linking your identity provider and assigning role rules. Most teams start by linking their main directory to manage who can log in. Admins often grant broad backup roles so engineers can restore test databases fast. Broad permissions create risk when one user can read or overwrite every production snapshot. How cohesity data cloud manages roles and storage The platform us
Data Cloud: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Cohesity Data Cloud unifies backup, recovery, and file storage into one single platform. You set up cohesity data cloud by linking your identity provider and assigning role rules. Most teams start by linking their main directory to manage who can log in. Admins often grant broad backup roles so engineers can restore test databases fast. Broad permissions create risk when one user can read or overwrite every production snapshot.
How cohesity data cloud manages roles and storage
The platform uses a cluster design that runs across cloud and on-prem hardware. Every node in the cluster works together to store, dedupe, and index backup files. Admins control this data by setting up role-based access rules inside the main console. You map your corporate directory groups to built-in or custom roles on the platform.
A role defines which backup policies, storage views, and restore tasks a user can run. You can scope a role down to specific virtual machines, database engines, or file shares. When an engineer logs in, the system checks their group and loads their allowed objects. The platform also supports API keys for scripts that trigger backups or mount test clones.
What native roles solve and what they leave open
Native roles do a great job of splitting duties between storage admins and app teams. You can stop a developer from deleting a backup policy or changing retention locks. Multi-factor login rules and quorum approvals also help block bad changes to key settings. A quorum rule requires a second admin to approve major deletes before they run.
Still, native role checks focus on who logs in and which storage objects they see. Once a user mounts a database clone or opens a shell, role checks step back. The storage platform does not inspect individual SQL queries run against a restored database clone. If a clone holds real emails, phone numbers, or card numbers, queries return them directly.
Managing cloned databases and live command sessions
Teams often use backup snapshots to spin up fast database clones for dev and test. This workflow saves time because engineers test code against real data shapes and sizes. The problem starts when an engineer connects a database client to that fresh clone. Native backup roles only checked if the user had permission to create the clone.
Data Cloud: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
After the database starts, the engineer logs in with standard database credentials to run queries. They might run a broad select query that pulls thousands of customer national IDs. They might also run a script against a live host during a recovery check. To close this gap, teams need controls that check commands and rewrite sensitive fields in flight.
Good security pairs storage role rules with runtime controls on the databases and hosts themselves. Storage rules lock down the snapshots, while runtime controls watch the live sessions and queries. Masking rules can rewrite emails and card numbers in query results during those test sessions. This split lets developers use fast clones while keeping sensitive customer fields under tight control.
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 teams restrict who can restore production data?
Admins create custom roles and bind them to specific data sources and target hosts. You assign these narrow roles to app teams so they only restore their own apps. For high-risk actions, you can turn on quorum rules that require a second admin approval.
Does a backup role mask data inside a restored database clone?
No, a storage role only controls who can create, mount, or delete the database clone. Once the database engine is running, users query it using standard database clients and permissions. You need a separate query control or masking setup to rewrite sensitive fields in results.
How should we manage API keys for automated backup scripts?
Create a dedicated service account for each script and give it the smallest possible role. Do not share one admin key across multiple teams or automation tools. Rotate these keys on a set schedule and remove old keys as soon as projects end.