Separation of duties

Resource Hierarchy and Boundary Enforcement

The Google Cloud resource hierarchy organizes cloud assets starting from the Organization node at the top, down through Folders, and finally to Projects. Policies applied at higher levels are inherited by all resources below them, ensuring consistent security management across the entire structure. Separation of duties uses this structure to ensure no single person has too much control over the system.

In GCP, administrators enforce functional boundaries by assigning specific IAM roles based on job functions to control who manages what. This strategy helps mitigate risk and ensure accountability within the cloud environment by using distinct administrative roles. These key roles include:

• Organization Admins who manage the overall structure.
• Folder Administrators who handle access for specific departments.
• Project Owners who manage specific applications and their resources.

To block sensitive data from moving to unauthorized locations, organizations implement VPC Service Controls to establish a service perimeter. This perimeter acts as a virtual wall that prevents data from being shared outside authorized projects or services. Using a common unified perimeter is recommended because it simplifies the management of network security boundaries.

Furthermore, administrators use Organization policies to enforce strict rules, known as constraints, across the hierarchy. These rules can restrict which Google Cloud services can run, require the use of Customer-Managed Encryption Keys (CMEK), or disable external service account keys. For absolute control, deny policies explicitly block specific actions even if an allow policy exists, keeping security oversight independent from daily development.

Auditing, Monitoring, and Multi-Party Authorization

Separation of duties is a security strategy where more than one person is required to complete a sensitive task. Dividing responsibilities prevents a single individual from having too much power, which reduces the risk of fraud or malicious actions. In Google Cloud, this is achieved by separating responsibilities between Google Workspace administrators and Google Cloud administrators. Security teams enforce this by using pre-built administrative roles instead of super admin privileges, managing access through security groups, and applying the principle of least privilege.

When critical system changes must be made, multi-party authorization ensures that actions require independent validation from distinct authorized entities. This workflow requires one person to request access and another authorized user to verify and approve it before the action occurs. Privileged Access Manager (PAM) manages these just-in-time elevation requests, while DevOps pipelines can use service accounts to automate approvals safely.

Comprehensive tracking relies on audit logging to provide a detailed record of who performed an action, which resource was affected, and when it happened. Administrators must regularly review Admin Activity logs and Data Access logs to identify any suspicious behavior. Tools like the Security Command Center analyze these logs to detect anomalies, such as unexpected service account delegation. This monitoring also includes verifying the identity of the caller in a delegation chain and setting up alerts for highly privileged accounts.

When emergency situations arise, organizations rely on breakglass access to bypass normal security restrictions temporarily. Because these accounts have highly privileged access, they must be tightly controlled and monitored with immediate alerts. Organizations must have a clear plan to audit and alert the security team whenever these emergency accounts are activated. Best practices for emergency access include:

• Using split operations where two different people must provide credentials and MFA tokens.
• Ensuring the access is temporary and automatically revoked after a set duration.
• Automating common fixes to reduce the need for human privilege escalation.

IAM Role Granularity and Administrative Isolation

Administrative isolation keeps high-level management tasks strictly separate from daily operational work to prevent a single compromised identity from damaging the entire environment. To maintain these boundaries, organizations must strictly limit the number of super admin accounts and discourage using them for routine tasks. Instead, administrators should use pre-built or custom IAM roles that target only the specific permissions needed. This separation ensures that even if an operational account is compromised, the broader cloud infrastructure remains secure.

Adhering to the principle of least privilege requires assigning permissions at the smallest possible scope, such as a single resource or project. Security teams should regularly review GCP role recommendations to identify and remove excessive or unused permissions before they can be exploited. When temporary high-level access is required, Privileged Access Manager (PAM) grants just-in-time elevation to minimize the duration that sensitive roles remain active. This approach reduces the overall attack surface of the organization by ensuring high-level permissions are only active when necessary.

For rare situations when automation or standard access methods fail, teams set up breakglass access using dedicated emergency identities. These accounts remain under strict monitoring and are protected by multi-party approval workflows and automated alerts that notify security teams immediately upon activation. Finally, isolating service accounts and enforcing OS Login ensures that VM access is tied directly to a user's central identity. This prevents users from performing metadata-based key abuse and ensures all administrative actions on a machine are properly linked to a specific person.