Cohesity Encryption
You set up cohesity encryption by turning on cluster and storage domain protection. This process scrambles backup data on disks and across network links. Most ops teams turn on these rules when they first build a cluster. Teams also pair data scrambling with broad admin roles for daily backup tasks. Still, wide roles let too many users read decrypted files during restore jobs. How cohesity encryption works across clusters Data protection in a backup cluster happens at two main points. First,
Encryption at Rest: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cohesity encryption by turning on cluster and storage domain protection. This process scrambles backup data on disks and across network links. Most ops teams turn on these rules when they first build a cluster. Teams also pair data scrambling with broad admin roles for daily backup tasks. Still, wide roles let too many users read decrypted files during restore jobs.
How cohesity encryption works across clusters
Data protection in a backup cluster happens at two main points. First, the system protects data in flight between sources and cluster nodes. When an agent sends files over the network, TLS locks the traffic. Second, the platform scrambles data at rest before writing it to disk. The software uses standard ciphers to lock every storage block and metadata file.
Teams can turn on protection at the cluster level or storage domain level. Cluster settings apply to all storage pools on that hardware from day one. Domain settings let admins pick which backup pools need extra lock rules. Each protected block gets its own unique data key during the write step. A master key then wraps those data keys to keep them safe.
Admins can store the master key inside the local cluster key store. Many teams instead choose an external key server using standard key protocols. External key stores keep the master keys separate from the physical backup disks. If someone steals a hard drive, they cannot read the raw storage blocks. The cluster checks with the key server at boot time to manage disks.
Key rotation and role management basics
Keeping keys fresh is a core part of any backup security plan. Teams set up key rotation schedules to swap master keys on a timer. When a master key rotates, the cluster does not rewrite all stored backups. Instead, the new master key re-wraps the existing data keys in place. This design saves disk work and keeps backup jobs running at full speed.
Access to decrypted data depends on the role assigned to each user. A user who logs in with restore rights can pull clear files out. The storage engine decrypts the blocks on the fly for valid user sessions. Native role rules check who logs in to the management console or API. They also govern which admins can change key server settings or rotation timers.
Encryption at Rest: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native encryption solves and what keeps the session active
Disk and network scrambling stops attackers who steal drives or tap network wires. It also helps teams meet strict audit rules for stored backup copies. Once data lands on a disk, no one can read the raw drive. External key stores also let security teams revoke master keys during an incident.
Still, storage protection only guards data while it sits on disk or wire. It does not check what a logged-in admin does during an active session. Once a user logs in with a broad role, the system trusts them. Native storage rules decide who logs in, not what individual commands run.
Engineers often use shared admin accounts to fix broken backup jobs or scripts. During these sessions, the platform unlocks any file that the role requests. If a restore pulls down database tables, sensitive fields appear in clear text. Emails, phone numbers, card numbers, and national IDs flow straight to the user. Native disk locks cannot rewrite matched fields in results or block single commands.
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
Can you turn on cohesity encryption after creating a cluster?
Cluster-wide protection must be turned on when you first build the cluster. Still, you can create a new encrypted storage domain later and move data.
Does disk encryption slow down backup deduplication?
No, the system deduplicates and compresses data blocks before it scrambles them. This order keeps storage savings high while still locking every block on disk.
Why do teams Still need runtime controls over encrypted backups?
Disk locks do not restrict valid users who log in with restore roles. Runtime controls inspect live commands and mask fields like card numbers in results.