Chapter 7: Access Control — RBAC, Multi-Tenancy & Quorum
Learning Objectives
Configure role-based access control (RBAC) with built-in and custom roles on Cohesity
Implement multi-tenancy security to isolate tenant data and operations
Set up Quorum groups to require multi-person approval for privileged actions
Design least-privilege access strategies for Cohesity administration
Pre-Study Assessment
Answer these questions before reading the material to gauge your current understanding.
Pre-Quiz — Section 1: Role-Based Access Control
1. In Cohesity's RBAC model, what is the relationship between permissions and users?
Permissions are assigned directly to individual users
Permissions are assigned to roles, and roles are assigned to users
Permissions are inherited from the operating system
Permissions are granted automatically based on login frequency
2. Can a Cohesity user be assigned both the built-in Viewer role and the Super Admin role simultaneously?
Yes, all roles can be freely combined
No, default roles like Viewer cannot be combined with Admin or Super Admin
Yes, but only through the API
No, users can only hold one role at a time
3. When a user holds both an individually assigned custom role and an AD-group-inherited role, what are the effective permissions?
Only the individually assigned role applies
Only the AD group role applies
The union (combined set) of all assigned roles
The intersection (overlap) of all assigned roles
4. Which Cohesity feature restricts a user's access to specific VMs or storage arrays rather than granting cluster-wide access?
Quorum Groups
Organizations
Object-level access restrictions
VLAN segmentation
Pre-Quiz — Section 2: Multi-Tenancy & Quorum
5. In a Cohesity multi-tenant deployment, can a service provider decrypt a tenant's backup data if they have physical access to the drives?
Yes, physical access always implies data access
No, per-tenant encryption keys prevent this
Only if the tenant grants explicit permission
Yes, service providers hold a master decryption key
6. What is the recommended approval threshold formula for a Cohesity Quorum Group?
All members must approve unanimously
n/2 + 1 (a simple majority plus one)
Any single quorum member can approve
Two-thirds of all members
7. When a quorum member initiates a protected operation, what happens to their approval count?
Their request starts at 0 approvals like any other user
Their request is auto-approved (counts as 1 approval)
They are removed from the quorum for that request
The operation executes immediately without needing further approval
Section 1: Role-Based Access Control
Role-Based Access Control (RBAC) is a security model in which permissions are assigned to roles, and roles are assigned to users -- rather than granting permissions directly to individual users. Think of it like a corporate badge system: rather than programming each badge individually, you create badge tiers (Executive, Employee, Visitor), define what each tier can access, and then assign the appropriate tier to each person.
Cohesity ships with over a dozen predefined roles. The most important ones include:
Role
Permissions
Typical Use Case
Super Admin
Full access to all actions; can manage other admins. Cannot be deleted.
Platform owner, security officer
Admin
Administrative privileges for cluster operations
Day-to-day cluster management
Viewer
Read-only access to all workflows
Auditors, compliance reviewers
Operator
Viewer privileges plus execute Protection Groups and recovery tasks
Operations staff
Data Security
Create DataLock Views and set DataLock expiration
Compliance teams
Self-Service
Manage clones, protection groups, policies with viewer access
Application owners
DR Admin
Viewer capabilities plus manage DR workflows
DR coordinators
Important constraint: You cannot combine a default role such as Viewer with the Admin or Super Admin role. However, custom roles can be combined with Admin or Super Admin.
Custom Roles
When built-in roles do not match your needs, create custom roles with hand-picked privileges to enforce the principle of least privilege. Privileges span categories like Access Management, DataProtect Services, Recovery Management, Storage Management, and Source Access Control.
Steps: Navigate to Settings > Access Management > Roles > Add Custom Role > define name, description, and toggle specific privilege categories. Note: role names cannot be edited after creation.
Role Assignment: Local Users, AD Groups, and SSO
Cohesity supports three identity sources for role assignment:
Local users -- created in the Cohesity UI, assigned roles individually
AD groups -- mapped to Cohesity roles for centralized identity management
SSO claims -- integration with Azure AD, Okta, Ping Identity, Duo, and ADFS
When a user holds roles from multiple sources, effective permissions are the union of all assigned roles.
The principle of least privilege means every user should have only the minimum permissions necessary. Cohesity enforces this through:
Object-level access restrictions -- limit users to specific VMs, physical servers, or storage arrays
Privilege escalation control -- prevents users from granting themselves unauthorized access
Granular privilege categories -- dozens of specific operations rather than broad read/write toggles
Interactive RBAC Explorer
Click a user to see which role they hold and what permissions that role grants.
Local User
AD Group Member
SSO User
↓
Super Admin
Operator
Custom Role
↓
Manage Clusters
Run Protection Groups
Manage VMware Sources
View Dashboards
Key Points -- RBAC
RBAC assigns permissions to roles, not directly to users
12+ built-in roles; custom roles fill gaps with granular privileges
Default roles (Viewer, Operator) cannot be combined with Admin/Super Admin; custom roles can
Effective permissions = union of all roles from local accounts, AD groups, and SSO
Object-level restrictions enforce least privilege down to individual VMs or arrays
Section 2: Multi-Tenancy Security
Multi-tenancy allows a single Cohesity cluster to serve multiple independent customers (tenants) with logical isolation. Cohesity implements this through Organizations. The analogy is an apartment building: all residents share the same physical structure, but each apartment has its own lock, utility meters, and lease agreement.
Organizations Architecture
Each Organization logically groups users and enforces data boundaries. Key properties:
Each Organization can have its own Active Directory domains or groups
Users within an Organization can only see resources assigned to that Organization
Separate password policies, MFA configurations, and RBAC role assignments per Organization
Each Organization can be assigned a dedicated VLAN for network-level isolation
Tenant Isolation Layers
Isolation Layer
Description
Namespace Isolation
Each tenant has a dedicated data namespace with its own repositories
Per-Tenant Encryption
Data-at-rest and data-in-flight encrypted per tenant; service providers cannot decrypt tenant data
VLAN Network Segmentation
Unique VLAN ID per Organization isolates network traffic
Management-Level Isolation
Service providers cannot restore or download files from tenant backups
Policy Isolation
Protection policies, SLA configs, and retention settings scoped per Organization
Critical security guarantee: Service providers cannot decrypt tenant data even with physical access to the hard drives, because per-tenant encryption keys are not accessible to the service provider.
Tenant Admin Delegation
Within each Organization, a tenant admin manages users and can:
Configure tenant-specific password policies and MFA
Assign RBAC roles within the Organization's scope
Create and manage Protection Groups for assigned resources
Tenant admins operate within strict boundaries -- they cannot view other Organizations or access cluster-level settings.
Cross-Tenant Boundaries
Security boundaries are enforced via Zero Trust principles: data boundaries restrict access to specific VMs/NAS shares, fine-grained RBAC is scoped per data source, and ML-based anomaly detection monitors each tenant's backup ingestion rate and entropy to detect ransomware.
Optional trade-off: Cross-tenant deduplication yields 5-10% storage savings but shares a single encryption key across tenants. Organizations with strict compliance may forgo this.
Key Points -- Multi-Tenancy
Organizations = Cohesity's multi-tenancy implementation (one Organization per tenant)
Five isolation layers: namespace, per-tenant encryption, VLAN, management-level, policy
Service providers cannot decrypt tenant data even with physical drive access
Tenant admins are self-service but confined to their Organization boundary
Cross-tenant dedup saves storage but sacrifices per-tenant encryption independence
Section 3: Quorum Groups for Privileged Actions
A Quorum is a multi-person authorization mechanism requiring a predefined number of approvers to sign off before a sensitive operation executes. The real-world analogy: a bank vault requiring two keys turned simultaneously -- no single person, no matter how trusted, can open it alone.
The Quorum Concept
Quorum Groups address the single-point-of-compromise scenario. If a privileged account is compromised or an insider acts maliciously, quorum protection prevents that single identity from executing destructive operations.
Cohesity provides predefined templates identifying which operations to protect. Cohesity advises against manually selecting individual operations unless instructed by support.
Approval threshold formula:Minimum approvals = n/2 + 1 where n = total quorum members.
Quorum Group Size
Recommended Min. Approvals (n/2+1)
3 members
2 approvals
5 members
3 approvals
7 members
4 approvals
9 members
5 approvals
Operations Requiring Approval
Typical quorum-protected operations include:
Deleting or modifying protection policies
Disabling or deleting Protection Groups
Modifying security configurations
Deleting Views or storage domains
Changing cluster-level settings
FortKnox cloud vault changes
Defense Against Insider Threats
A critical design principle: quorum approvers do not need the RBAC permission to initiate the operation they approve. RBAC controls who can initiate; Quorum controls who can approve. This separation provides defense against:
Threat
How Quorum Protects
Compromised admin credentials
Attacker cannot execute destructive ops without additional human approvals
Rogue insider
Malicious admin cannot act unilaterally; peers must approve
Poorly trained administrator
Accidental destructive ops caught during approval review
Social engineering
Multiple people must be fooled, not just one
Interactive Quorum Simulation
Alice initiated "Delete Protection Policy." Her request was auto-approved (1/2). Click Bob or Carol to approve or decline. Threshold: 2 of 3.
A
Alice (auto)
B
Bob
C
Carol
Pending: 1 of 2 approvals
Key Points -- Quorum
Quorum = multi-person authorization; no single admin can execute protected operations alone
Recommended threshold: n/2 + 1 (majority)
Use predefined templates to select which operations require quorum protection
Quorum approvers do NOT need the RBAC permission to initiate the operation -- separation of initiation and approval authority
Defends against compromised credentials, rogue insiders, accidents, and social engineering
Section 4: Access Control Best Practices
Separation of Duties
No single person should control all aspects of a critical process. In Cohesity administration:
Separate operational and approval authority -- use Quorum so the initiator is not the sole approver
Separate backup admin from security admin -- different custom roles for protection policies vs. access controls
Separate tenant admin from platform admin -- tenant admins manage users/policies; platform admins manage infrastructure
Function
Role(s)
Quorum Member?
Platform infrastructure
Super Admin
Yes
Backup operations
Custom "Backup-Ops"
No
Security and compliance
Data Security + custom access mgmt
Yes
Monitoring and audit
Viewer
No
Disaster recovery
DR Admin
Yes
Access Reviews
Quarterly access reviews -- check all user-to-role mappings for stale accounts and excessive permissions
Quorum group maintenance -- remove departed members from quorum approver lists
SSO/AD audit -- verify AD group memberships reflect current job functions
Audit log review -- examine quorum decisions and admin actions for anomalies
Break-Glass Procedures
Emergency access when normal workflows are unavailable (e.g., quorum members unreachable during an outage):
Document the procedure -- define which scenarios warrant break-glass access and who can invoke it
Use the Cohesity Support Admin role -- this built-in role allows Cohesity support to create a Super Admin user for customers who lose access
Seal and audit -- after the emergency, review all actions taken, reset temporary credentials, document the incident
Test periodically -- run break-glass drills to ensure the procedure works
How RBAC, Organizations, and Quorum Work Together
flowchart LR
USER["User attempts\nan action"] --> RBAC{"RBAC Check:\nDoes role grant\nthis permission?"}
RBAC -- No --> DENY1["Access Denied"]
RBAC -- Yes --> ORG{"Org Check:\nIs target in user's\nOrganization scope?"}
ORG -- No --> DENY2["Access Denied"]
ORG -- Yes --> QUORUM{"Quorum Check:\nProtected operation?"}
QUORUM -- No --> ALLOW["Action Executes"]
QUORUM -- Yes --> APPROVAL["Quorum Approval\nWorkflow"]
APPROVAL --> APPROVED{"Threshold\nmet?"}
APPROVED -- Yes --> ALLOW
APPROVED -- No --> DENY3["Action Blocked"]
Key Points -- Best Practices
Separation of duties: distinct roles for backup ops, security, platform admin, and DR
Quarterly access reviews prevent permission creep and stale accounts
Break-glass procedures use the Cohesity Support Admin role for emergencies
Three layers work together: RBAC (what can you do?) → Organization (on which resources?) → Quorum (do peers approve?)
Post-Study Assessment
Now that you have studied the material, answer these questions again to measure your progress.
Post-Quiz — Section 1: Role-Based Access Control
1. In Cohesity's RBAC model, what is the relationship between permissions and users?
Permissions are assigned directly to individual users
Permissions are assigned to roles, and roles are assigned to users
Permissions are inherited from the operating system
Permissions are granted automatically based on login frequency
2. Can a Cohesity user be assigned both the built-in Viewer role and the Super Admin role simultaneously?
Yes, all roles can be freely combined
No, default roles like Viewer cannot be combined with Admin or Super Admin
Yes, but only through the API
No, users can only hold one role at a time
3. When a user holds both an individually assigned custom role and an AD-group-inherited role, what are the effective permissions?
Only the individually assigned role applies
Only the AD group role applies
The union (combined set) of all assigned roles
The intersection (overlap) of all assigned roles
4. Which Cohesity feature restricts a user's access to specific VMs or storage arrays rather than granting cluster-wide access?
Quorum Groups
Organizations
Object-level access restrictions
VLAN segmentation
5. A managed service provider hosts 50 tenants on one Cohesity cluster. Which isolation layer ensures tenants cannot see each other's backup data even if they share the same physical nodes?
VLAN segmentation alone
Namespace isolation combined with per-tenant encryption
RBAC custom roles
Quorum Groups
Post-Quiz — Section 2: Multi-Tenancy & Quorum
6. What is the recommended approval threshold formula for a Cohesity Quorum Group?
All members must approve unanimously
n/2 + 1 (a simple majority plus one)
Any single quorum member can approve
Two-thirds of all members
7. When a quorum member initiates a protected operation, what happens to their approval count?
Their request starts at 0 approvals like any other user
Their request is auto-approved (counts as 1 approval)
They are removed from the quorum for that request
The operation executes immediately without needing further approval
8. In Cohesity's Quorum design, do quorum approvers need the RBAC permission to initiate the operation they are approving?
Yes, approvers must hold the same RBAC role as the initiator
No, RBAC controls initiation while Quorum controls approval -- they are separate
Only if the operation involves data deletion
Yes, and they must also be Super Admins
9. What built-in Cohesity role is specifically intended for emergency break-glass scenarios when customers lose access?
Super Admin
DR Admin
Cohesity Support Admin
Data Security
10. A Cohesity tenant admin in Organization "Acme-Corp" tries to view protection policies belonging to Organization "Globex." What happens?
They can view but not modify Globex policies
They are denied access -- tenant admins can only see resources within their Organization
They can view if they have the Viewer role
They need Quorum approval to view cross-tenant resources
11. Which of the following best describes how Cohesity's three access control mechanisms work together when a user attempts an action?
Quorum is checked first, then RBAC, then Organization scope
RBAC checks permission, then Organization checks scope, then Quorum checks if multi-person approval is needed
Organization scope is the only check; RBAC and Quorum are optional
All three checks run in parallel and any denial blocks the action
12. What is a potential downside of enabling cross-tenant deduplication in a Cohesity multi-tenant deployment?
It breaks namespace isolation
It shares a single encryption key across tenants, reducing encryption independence