This page describes how to use Identity and Access Management (IAM) to control access to resources in an organization-level activation of Security Command Center. This page is relevant to you if either of the following conditions apply:
- Security Command Center is activated at the organization level and not at the project level.
- Security Command Center Standard is already activated at the organization level. Additionally, you have Security Command Center Premium activated on one or more projects.
If you activated Security Command Center at the project level—and not the organization level—see IAM for project-level activations instead.
In an organization-level activation of Security Command Center, you can control access to resources at different levels of your resource hierarchy. Security Command Center uses IAM roles to let you control who can do what with assets, findings, and security sources in your Security Command Center environment. You grant roles to individuals and applications, and each role provides specific permissions.
Permissions
Required for activation
To activate Security Command Center, see one of the following based on your service tier:
Activate Security Command Center Standard tier for an organization.
Activate Security Command Center Premium tier for an organization.
Required for ongoing administration and use
This section describes permissions needed to administer and use Security Command Center Premium and Standard. For information about Security Command Center Enterprise, see Configure permissions for ongoing use of Security Command Center Enterprise.
To change the configuration of your organization, you need both of the following roles at the organization level:
-
Organization Administrator (
roles/resourcemanager.organizationAdmin) -
Security Center Admin (
roles/securitycenter.admin)
If a user doesn't require edit permissions, consider granting them viewer roles.
To view all assets, findings, and attack paths in Security Command Center, users need the
Security Center Admin Viewer
(roles/securitycenter.adminViewer) role at the organization level.
To view settings, users need the
Security Center Admin (roles/securitycenter.admin) role at the organization level.
To restrict access to individual folders and projects, don't grant all roles at the organization level. Instead, grant the following roles at the folder or project level:
-
Security Center Assets Viewer (
roles/securitycenter.assetsViewer) - Security Center Findings Viewer
(
roles/securitycenter.findingsViewer)
Each detection service may require additional permissions to enable or configure it. See the documentation specific to each service for more information.
Organization-level roles
When IAM roles are applied at the organization level, projects and folders under that organization inherit its role bindings.
The following figure illustrates a typical Security Command Center resource hierarchy with roles granted at the organization level.
IAM roles include permissions to view, edit, update, create, or
delete resources. Roles granted at the organization level in Security Command Center
let you perform prescribed actions on findings, assets, and security sources
throughout your organization. For example, a user granted the
Security Center Findings Editor role (roles/securitycenter.findingsEditor)
can view or edit findings attached to any resource in any project or folder in
your organization. With this structure, you don't have to grant users roles in
each folder or project.
For instructions on managing roles and permissions, see Manage access to projects, folders, and organizations.
Organization-level roles are not suitable for all use cases, particularly for sensitive applications or compliance standards that require strict access controls. To create fine-grained access policies, you can grant roles at the folder and project levels.
Folder-level and project-level roles
Security Command Center lets you grant Security Command Center IAM roles for specific folders and projects, creating multiple views, or silos, within your organization. You grant users and groups different access and edit permissions to folders and projects across your organization.
With folder and project roles, users with Security Command Center roles have the ability to manage assets and findings within designated projects or folders. For example, a security engineer can be given limited access to select folders and projects while a security administrator can manage all resources at the organization level.
Folder and project roles allow Security Command Center permissions to be applied at lower levels of your organization's resource hierarchy, but do not change the hierarchy. The following figure illustrates a user with Security Command Center permissions to access findings in a specific project.
Users with folder and project roles see a subset of an organization's resources. Any actions they take are limited to the same scope. For example, if a user has permissions for a folder, they can access resources in any project in the folder. Permissions for a project give users access to resources in that project.
For instructions on managing roles and permissions, see Manage access to projects, folders, and organizations.
Role restrictions
By granting Security Command Center roles at the folder or project level, Security Command Center administrators can do the following:
- Limit Security Command Center view or edit permissions to specific folders and projects
- Grant view and edit permissions for groups of assets or findings to specific users or teams
- Restrict the ability to view or edit finding details, including updates to security marks and finding state, to individuals or groups with access to the underlying finding
- Control access to Security Command Center settings, which can only be viewed by individuals with organization-level roles
Security Command Center functions
Security Command Center functions are also restricted based on view and edit permissions.
In the Google Cloud console, Security Command Center lets individuals without organization-level permissions choose only resources to which they have access. Their selection updates all elements of the user interface, including assets, findings, and settings controls. Users see the privileges attached to their roles and whether they can access or edit findings at their current scope.
The Security Command Center API and Google Cloud CLI also restrict functions to prescribed folders and projects. If calls to list or group assets and findings are made by users granted folder or project roles, only findings or assets at those scopes are returned.
For organization-level activations of Security Command Center, calls to create or update findings and finding notifications only support the organization scope. You need organization-level roles to perform these tasks.
To view the attack paths that are generated by attack path simulations, the appropriate permissions must be granted at the organization level and the Google Cloud console view must be set to the organization.
Parent resources for findings
Usually, a finding is attached to a resource, like a virtual machine (VM) or firewall. Security Command Center attaches findings to the most immediate container for the resource that generated the finding. For example, if a VM generates a finding, the finding is attached to the project that contains the VM. Findings that are not connected to a Google Cloud resource are attached to the organization and are visible to anyone with organization-level Security Command Center permissions.
Security Command Center roles
The following IAM roles are available for Security Command Center. You can grant these roles at the organization, folder, or project level.
| Role | Permissions |
|---|---|
Security Center Admin( Admin(super user) access to security center Lowest-level resources where you can grant this role:
|
|