Cohesity Data Management
Cohesity data management stores, backs up, and recovers company files on one platform. You set it up by linking storage clusters, adding data sources, and assigning user roles. Many engineering teams start with shared admin roles to get backups running fast. Broad roles create risk because one user can delete snapshots or read private files. A secure setup needs strict role limits and checks on every action. How cohesity data management works in practice The platform pulls data from servers,
Data Security Posture Management (DSPM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Cohesity data management stores, backs up, and recovers company files on one platform. You set it up by linking storage clusters, adding data sources, and assigning user roles. Many engineering teams start with shared admin roles to get backups running fast. Broad roles create risk because one user can delete snapshots or read private files. A secure setup needs strict role limits and checks on every action.
How cohesity data management works in practice
The platform pulls data from servers, virtual machines, and cloud storage into one cluster. It removes duplicate blocks of data to save space and speed up transfers. Teams set up protection rules that tell the system when to copy data. These rules also state how long the cluster must keep each backup copy.
To control who can change these rules, the platform uses role-based controls. Admins link the cluster to an external directory or single sign-on tool. When an engineer logs in, the system checks their group and assigns a role. You can scope a role to specific storage views or backup jobs. A user with a read role can check job status but cannot delete backups. An operator role lets a user run a restore job when a server fails. This structure keeps daily work separate from cluster setup tasks.
Where native backup roles leave gaps
Native roles do a good job of deciding who can log into the cluster. They block guests from changing storage settings or reading backup logs. Still, static roles cannot check what a user does inside an active session. Once an admin logs in, the system trusts every command that role allows.
Engineers often use backup data to refresh test databases or fix production bugs. During these tasks, they may mount a backup volume or query restored tables. If an engineer has permission to read that data, the storage platform serves everything. Native storage roles do not mask private fields like emails, phone numbers, or card numbers. They also do not require peer approval before a single high-risk command runs. Standing roles stay active all day, even when no ticket or incident exists. If an attacker steals an admin key, they gain full control over backup copies.
Data Security Posture Management (DSPM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Closing the gap on live data tasks
To reduce this risk, teams should separate storage management from live data queries. Start by removing standing admin roles from daily user accounts. Give engineers read-only roles on the backup cluster for routine status checks. When someone needs to change a retention rule, grant that role for a short window.
Next, look at what happens after a team restores a database or file share. Once data leaves the backup snapshot and sits on a live server, database rules apply. Teams need controls that inspect individual queries and commands in real time. Data masking rewrites matched fields like national IDs or card numbers in query results. Command checks can pause a dangerous drop or delete statement until a lead approves it. Detailed audit logs should record every query run against restored data, tied to user identity.
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
What is the main purpose of Cohesity data management?
It combines backups, file shares, and disaster recovery into a single storage cluster. Teams use it to protect server data and restore files after an outage.
How do you limit user permissions in a backup cluster?
You link your identity provider and assign role-based controls to specific user groups. Scope each role so engineers only manage the workloads their team owns.
Why do restored backups need extra security controls?
Restored backups contain the same real user data found in production systems. Without query checks and masking, test workloads expose emails and card numbers in results.