Cohesity Cloud Services
You set up cohesity cloud services by linking your cloud account to the control plane. Then you assign backup roles and retention rules to your data sources. Most teams start by creating one broad admin role to test their first backups. Still, broad permissions let one bad script or stolen key wipe out vital snapshots. Teams must scope roles down before moving backup jobs into production. How cohesity cloud services works The platform uses a central control plane to manage backups across clou
Cloud Services: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cohesity cloud services by linking your cloud account to the control plane. Then you assign backup roles and retention rules to your data sources. Most teams start by creating one broad admin role to test their first backups. Still, broad permissions let one bad script or stolen key wipe out vital snapshots. Teams must scope roles down before moving backup jobs into production.
How cohesity cloud services works
The platform uses a central control plane to manage backups across cloud accounts. You begin by linking your cloud provider account through an identity role. That role grants the platform permission to read volumes and write snapshot data. Next, you group your cloud databases and virtual machines into protection groups. Each group follows a set schedule that defines how often backups run. You also set retention rules that control how long the system keeps each snapshot.
Human users log in through an identity provider using single sign-on. The platform maps each user group to a built-in role or custom role. A viewer role lets an engineer check job status and read log alerts. An operator role lets a team member start a backup or restore a volume. A top admin role can change retention rules, delete snapshots, and add new cloud accounts. Automated scripts and CI pipelines use API keys to trigger these same workflows.
What the native setup solves and what keeps the session active
This native role system solves the problem of basic account entry and job scheduling. It stops unverified users from logging into the web console or calling the API. It also separates basic viewers from engineers who need to run restores. For scheduled backups that run on their own, these built-in controls work well. You can see who logged into the console and which protection group they edited.
Yet role checks only decide who can log in to start a session. They do not inspect what individual commands or API requests do during that session. Once an engineer or script holds an operator role, every allowed action runs right away. A careless command can still restore sensitive production data into an open test bucket. If an engineer exports a backup to a local database, raw fields stay intact. Emails, phone numbers, card numbers, and national IDs sit exposed in that restored copy. Also, static API keys stored in automation scripts often stay valid for months. If a key leaks, an attacker gains full power to run those role actions.
Cloud Services: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten backup and restore workflows
Teams reduce this risk by splitting daily operations from high-impact tasks. First, remove admin rights from daily user accounts and shared automation scripts. Give engineers read-only roles so they can check backup status without changing data. Second, require a peer review before anyone alters a retention rule or deletes a snapshot. Third, watch how teams query and inspect restored database snapshots during bug fixes. When engineers query restored data, masking rewrites matched fields like emails or card numbers in results. This step keeps sensitive records safe while devs fix app bugs.
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 should teams assign roles for cloud backup tasks?
Give most engineers viewer roles so they can check job logs and alerts. Grant restore permissions only to specific on-call staff who handle recovery tickets. Keep full admin roles locked away for rare setup changes.
What happens when developers restore production snapshots for testing?
Restored snapshots carry all the live user data from the source database. If teams query that restored database directly, sensitive fields like phone numbers appear in results. Teams should apply data masking on query results to rewrite those matched fields.
Why are long-lived API keys risky for backup automation?
Scripts use API keys to trigger backups and restores without a human login. If a long-lived key leaks in a code repo, anyone can run those commands. Rotate keys often and limit each key to one specific protection group.