Professional Cloud Security Engineer

Managing privileged roles and separation of duties with Identity and Access Management (IAM) roles and permissions

In GCP, IAM roles are collections of permissions that determine what actions a user or service can take on resources. Privileged roles, such as roles/owner or roles/editor, grant broad access and must be managed carefully to prevent misuse. Separation of duties means splitting critical tasks across different roles so that no single identity has too much power. For example, the person who creates a resource should not be the same person who deletes it or changes its security settings. You can achieve this by assigning specific roles like roles/compute.admin for managing compute resources and roles/storage.admin for managing storage, ensuring that no single role covers both domains. This approach reduces the risk of accidental or malicious changes and aligns with security best practices.

Managing IAM and access control list (ACL) permissions

IAM and access control lists (ACLs) are two different systems for controlling access to resources. IAM works at the project, folder, and organization level, granting permissions to users, groups, or service accounts through roles. ACLs are older and apply to specific objects within services like Cloud Storage, where you can set permissions on individual buckets or objects. When both systems are in use, IAM policies take precedence over ACLs for most operations, but you must understand how they interact to avoid unintended access. For example, if an IAM policy grants a user read access to a bucket but an ACL denies read access to that user, the ACL denial overrides the IAM grant for that specific object. Managing both systems requires careful coordination, and you should migrate away from ACLs toward IAM whenever possible for consistency and simpler auditing.

Granting permissions to different types of identities using IAM conditions and IAM deny policies

IAM conditions let you add extra rules to a role grant, such as restricting access based on time of day, IP address, or resource name. For example, you can grant a user the roles/storage.objectViewer role only when they connect from a corporate IP range, preventing access from outside the network. IAM deny policies are the opposite of allow policies: they explicitly block access even if another policy would grant it. Deny policies are evaluated before allow policies, so they act as a hard stop for any identity, including service accounts and groups. You use deny policies for scenarios like preventing a compromised account from accessing sensitive data, even if that account has a broad role. Together, conditions and deny policies give you fine-grained control over who can do what, under what circumstances, and allow you to enforce security rules without removing roles entirely.

Defining access control at the organization, folder, project, and resource level using the principle of least privilege

The principle of least privilege means giving each identity only the permissions it needs to do its job and nothing more. In GCP, you apply this principle by setting access control at the right level in the resource hierarchy: organization, folder, project, and resource. Organization-level policies apply to all folders and projects underneath, making them ideal for company-wide security rules. Folder-level policies apply to a group of related projects, such as all projects for a specific department. Project-level policies control access to all resources within that project, and resource-level policies apply to individual items like a single Compute Engine instance or Cloud Storage bucket. You should place policies as low in the hierarchy as possible to avoid granting broad access unnecessarily. For example, grant a developer the roles/compute.instanceAdmin role at the project level rather than the folder level, so they can manage instances only in their project, not in others.

Configuring Access Context Manager

Access Context Manager lets you define access levels based on attributes like device type, IP address, and user identity. These access levels are then used by VPC Service Controls and Access Transparency to enforce security boundaries around your resources. For example, you can create an access level that requires users to be on a corporate-managed device with a specific IP range, and then apply that level to a service perimeter that protects your Cloud Storage and BigQuery data. When a user tries to access the data, Access Context Manager checks their context against the defined level and denies access if the conditions are not met. This is useful for preventing data exfiltration and ensuring that only trusted users from trusted environments can reach sensitive resources. You configure access levels in the Access Context Manager API or the Google Cloud Console, and they can be reused across multiple perimeters.

Applying Policy Intelligence

Policy Intelligence is a set of tools that helps you understand and improve your IAM policies. It includes IAM Recommender, which suggests roles to grant or revoke based on actual usage patterns, and Policy Troubleshooter, which explains why a user can or cannot access a resource. For example, IAM Recommender might tell you that a service account has not used a permission in 90 days, so you can safely remove it to follow least privilege. Policy Troubleshooter lets you enter a user, resource, and permission, and it shows you which policies allow or deny that access, including inherited policies from higher levels. You also have Access Analyzer, which finds resources that are shared with external users or the public, helping you identify unintended exposure. Using these tools regularly keeps your authorization controls clean and reduces the risk of over-privileged identities.

Managing permissions through groups

Groups simplify permission management by letting you assign roles to a group instead of individual users. When a user joins the group, they automatically get the permissions that the group has, and when they leave, those permissions are removed. This is especially useful for large organizations where users change roles frequently. For example, you can create a group called "security-team@example.com" and grant it the roles/iam.securityReviewer role at the organization level. Any new member added to that group immediately has the ability to review IAM policies across the entire organization. Groups also support nested membership, where one group contains another group, allowing you to build a hierarchy that matches your company structure. You manage group membership through Google Groups or Cloud Identity, and changes take effect within minutes.

Identifying use cases and configuring Privileged Access Manager

Privileged Access Manager (PAM) provides just-in-time (JIT) access to privileged roles, meaning users request elevated permissions for a limited time and must get approval before they can use them. This reduces the risk of standing privileges, where a user always has high-level access even when they do not need it. Common use cases include granting temporary access to a production database for troubleshooting, or allowing a developer to deploy code to a critical environment during a maintenance window. To configure PAM, you define an entitlement that specifies which role can be requested, the maximum duration of access, and who must approve the request. When a user needs access, they submit a request through the console or API, and the approver reviews and either grants or denies it. Once the time expires, PAM automatically revokes the permissions, so no manual cleanup is needed. This is a key control for environments that require strict separation of duties and audit trails for every privileged action.