Ixxerja permezz ta’

Security Control: Privileged access

  • Artiklu

Privileged Access covers controls to protect privileged access to your tenant and resources, including a range of controls to protect your administrative model, administrative accounts, and privileged access workstations against deliberate and inadvertent risk.

PA-1: Separate and limit highly privileged/administrative users

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
5.4, 6.8 AC-2, AC-6 7.1, 7.2, 8.1

Security principle: Ensure you identify all high business impact accounts. Limit the number of privileged/administrative accounts in your cloud's control plane, management plane and data/workload plane.

Azure guidance: You must secure all roles with direct or indirect administrative access to Azure hosted resources.

Azure Active Directory (Azure AD) is Azure's default identity and access management service. The most critical built-in roles in Azure AD are Global Administrator and Privileged Role Administrator, because users assigned to these two roles can delegate administrator roles. With these privileges, users can directly or indirectly read and modify every resource in your Azure environment:

  • Global Administrator / Company Administrator: Users with this role have access to all administrative features in Azure AD as well as services that use Azure AD identities.
  • Privileged Role Administrator: Users with this role can manage role assignments in Azure AD, as well as within Azure AD Privileged Identity Management (PIM). In addition, this role allows management of all aspects of PIM and administrative units.

Outside of Azure AD, Azure has built-in roles that can be critical for privileged access at the resource level.

  • Owner: Grants full access to manage all resources, including the ability to assign roles in Azure RBAC.
  • Contributor: Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.
  • User Access Administrator: Lets you manage user access to Azure resources.

Note: You may have other critical roles that need to be governed if you use custom roles in the Azure AD level or resource level with certain privileged permissions assigned.

In addition, users with the following three roles in Azure Enterprise Agreement (EA) portal should also be restricted as they can be used to directly or indirectly manage Azure subscriptions.

  • Account Owner: Users with this role can manage subscriptions, including the creation and deletion of subscriptions.
  • Enterprise Administrator: Users assigned with this role can manage (EA) portal users.
  • Department Administrator: Users assigned with this role can change account owners within the department.

Lastly, ensure that you also restrict privileged accounts in other management, identity, and security systems that have administrative access to your business-critical assets, such as Active Directory Domain Controllers (DCs), security tools, and system management tools with agents installed on business-critical systems. Attackers who compromise these management and security systems can immediately weaponize them to compromise business critical assets.

Azure implementation and additional context:

AWS guidance: You must secure all roles with direct or indirect administrative access to AWS hosted resources.

The privileged/administrative users need to be secured include:

  • Root user: Root user is the highest-level privileged accounts in your AWS account. Root accounts should be highly restricted and only used in emergency situation. Refer to emergency access controls in PA-5 (Setup emergency access).
  • IAM identities (users, groups, roles) with the privileged permission policy: IAM identities assigned with a permission policy such as AdministratorAccess can have full access to AWS services and resources.

If you are using Azure Active Directory (Azure AD) as the identity provider for AWS, refer to the Azure guidance for managing the privileged roles in Azure AD.

Ensure that you also restrict privileged accounts in other management, identity, and security systems that have administrative access to your business-critical assets, such as AWS Cognito, security tools, and system management tools with agents installed on business critical systems. Attackers who compromise these management and security systems can immediately weaponize them to compromise business critical assets.

AWS implementation and additional context:

GCP guidance: You must secure all roles with direct or indirect administrative access to GCP hosted resources.

The most critical built-in role in Google Cloud is the super administrator. The super administrator can perform all tasks in the Admin console and has irrevocable administrative permissions. It is advised against using the super admin account for day-to-day administration.

Basic roles are highly permissive legacy roles, and it is advised that basic roles are not used in production environments as it grants broad access across all Google Cloud resources. Basic roles include the Viewer, Editor, and Owner roles. It is instead recommended to use predefined or custom roles. The notable privileged predefined roles include:

  • Organization Administrator: Users with this role can manage IAM policies and view organization policies for organizations, folders, and projects.
  • Organization Policy Administrator: Users with this role can define what restrictions an organization wants to place on the configuration of cloud resources by setting Organization Policies.
  • Organization Role Administrator: Users with this role can administer all custom roles in the organization and projects below it.
  • Security Admin: Users with this role can get and set any IAM policy.
  • Deny Admin: Users with this role has permissions to read and modify IAM deny policies.

Additionally, certain predefined roles contain privileged IAM permissions at the organization, folder, and project level. These IAM permissions include:

  • organizationAdmin
  • folderIAMAdmin
  • projectIAMAdmin

Further, implement separation of duties by assigning roles to accounts for different projects, or by leveraging Binary Authorization with Google Kubernetes Engine.

Lastly, ensure that you also restrict privileged accounts in other management, identity, and security systems that have administrative access to your business-critical assets, such as Cloud DNS, security tools, and system management tools with agents installed on business-critical systems. Attackers who compromise these management and security systems can immediately weaponize them to compromise business critical assets.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

PA-2: Avoid standing access for user accounts and permissions

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/A AC-2 N/A

Security principle: Instead of creating standing privileges, use just-in-time (JIT) mechanism to assign privileged access to the different resource tiers.

Azure guidance: Enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD Privileged Identity Management (PIM). JIT is a model in which users receive temporary permissions to perform privileged tasks, which prevents malicious or unauthorized users from gaining access after the permissions have expired. Access is granted only when users need it. PIM can also generate security alerts when there is suspicious or unsafe activity in your Azure AD organization.

Restrict inbound traffic to your sensitive virtual machines (VM) management ports with Microsoft Defender for Cloud's just-in-time (JIT) for VM access feature. This ensures privileged access to the VM is granted only when users need it.

Azure implementation and additional context:

AWS guidance: Use AWS Security Token Service (AWS STS) to create temporary security credentials to access the resources through the AWS API. Temporary security credentials work almost identically to the long-term access key credentials that your IAM users can use, with the following differences:

  • Temporary security credentials have a short-term life, from minutes to hours.
  • Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested.

AWS implementation and additional context:

GCP guidance: Use IAM conditional access to create temporary access to resources using conditional role bindings in allow policies, which is granted to Cloud Identity users. Configure date/time attributes to enforce time-based controls for accessing a particular resource. Temporary access may have a short-term life, from minutes to hours, or may be granted based on days or hours of the week.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

PA-3: Manage lifecycle of identities and entitlements

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.1, 6.2 AC-5, AC-6 7.1, 7.2, 8.1

Security principle: Use an automated process or technical control to manage the identity and access lifecycle including the request, review, approval, provision, and deprovision.

Azure guidance: Use Azure AD entitlement management features to automate access request workflows (for Azure resource groups). This enables workflows for Azure resource groups to manage access assignments, reviews, expiration, and dual or multi-stage approval.

Use Permissions Management to detect, automatically right-size, and continuously monitor unused and excessive permissions assigned to user and workload identities across multi-cloud infrastructures.

Azure implementation and additional context:

AWS guidance: Use AWS Access Advisor to pull the access logs for the user accounts and entitlements for resources. Build a manual or automated workflow to integrate with AWS IAM to manage access assignments, reviews, and deletions.

Note: There are third-party solutions available on AWS Marketplace for managing the lifecycle of identities and entitlements.

AWS implementation and additional context:

GCP guidance: Use Google's Cloud Audit Logs to pull the admin activity and data access audit logs for the user accounts and entitlements for resources. Build a manual or automated workflow to integrate with GCP IAM to manage access assignments, reviews, and deletions.

Use Google Cloud Identity Premium to provide core identity and device management services. These services include features such as automated user provisioning, app whitelisting, and automated mobile device management.

Note: There are third-party solutions available on the Google Cloud Marketplace for managing the lifecycle of identities and entitlements.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

PA-4: Review and reconcile user access regularly

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
5.1, 5.3, 5.5 AC-2, AC-6 7.1, 7.2, 8.1, A3.4

Security principle: Conduct regular review of privileged account entitlements. Ensure the access granted to the accounts are valid for administration of control plane, management plane, and workloads.

Azure guidance: Review all privileged accounts and the access entitlements in Azure including Azure tenants, Azure services, VM/IaaS, CI/CD processes, and enterprise management and security tools.

Use Azure AD access reviews to review Azure AD roles, Azure resource access roles, group memberships, and access to enterprise applications. Azure AD reporting can also provide logs to help discover stale accounts, or accounts which have not been used for certain amount of time.

In addition, Azure AD Privileged Identity Management can be configured to alert when an excessive number of administrator accounts are created for a specific role, and to identify administrator accounts that are stale or improperly configured.

Azure implementation and additional context:

AWS guidance: Review all privileged accounts and the access entitlements in AWS including AWS accounts, services, VM/IaaS, CI/CD processes, and enterprise management and security tools.

Use IAM Access Advisor, Access Analyzer and Credential Reports to review resource access roles, group memberships, and access to enterprise applications. IAM Access Analyzer and Credential Reports reporting can also provide logs to help discover stale accounts, or accounts which have not been used for certain amount of time.

If you are using Azure Active Directory (Azure AD) as the identity provider for AWS, use Azure AD access review to review the privileged accounts and access entitlements periodically.

AWS implementation and additional context:

GCP guidance: Review all privileged accounts and the access entitlements in Google Cloud including Cloud Identity accounts, services, VM/IaaS, CI/CD processes, and enterprise management and security tools.

Use Cloud Audit Logs and Policy Analyzer to review resource access roles, and group memberships. Create analysis queries in Policy Analyzer to understand determine which principals can access specific resources.

If you are using Azure Active Directory (Azure AD) as the identity provider for Google Cloud, use Azure AD access review to review the privileged accounts and access entitlements periodically.

In addition, Azure AD Privileged Identity Management can be configured to alert when an excessive number of administrator accounts are created for a specific role, and to identify administrator accounts that are stale or improperly configured.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

PA-5: Set up emergency access

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/A AC-2 N/A

Security principle: Set up emergency access to ensure that you are not accidentally locked out of your critical cloud infrastructure (such as your identity and access management system) in an emergency.

Emergency access accounts should be rarely used and can be highly damaging to the organization if compromised, but their availability to the organization is also critically important for the few scenarios when they are required.

Azure guidance: To prevent being accidentally locked out of your Azure AD organization, set up an emergency access account (e.g., an account with Global Administrator role) for access when normal administrative accounts cannot be used. Emergency access accounts are usually highly privileged, and they should not be assigned to specific individuals. Emergency access accounts are limited to emergency or "break glass" scenarios where normal administrative accounts can't be used.

You should ensure that the credentials (such as password, certificate, or smart card) for emergency access accounts are kept secure and known only to individuals who are authorized to use them only in an emergency. You may also use additional controls, such dual controls (e.g., splitting the credential into two pieces and giving it to separate persons) to enhance the security of this process. You should also monitor the sign-in and audit logs to ensure that emergency access accounts are only used when authorized.

Azure implementation and additional context:

AWS guidance: AWS "root" accounts should not be used for regular administrative tasks. As the "root" account is highly privileged, it should not be assigned to specific individuals. It's use should be limited to only emergency or "break glass" scenarios when normal administrative accounts can't be used. For daily administrative tasks, separate privileged user accounts should be used and assigned the appropriate permissions via IAM roles.

You should also ensure that the credentials (such as password, MFA tokens and access keys) for root accounts are kept secure and known only to individuals who are authorized to use them only in an emergency. MFA should be enabled for the root account, and you may also use additional controls, such as dual controls (e.g., splitting the credential into two pieces and giving it to separate persons) to enhance the security of this process.

You should also monitor the sign-in and audit logs in CloudTrail or EventBridge to ensure that root access accounts are only used when authorized.

AWS implementation and additional context:

GCP guidance: Google Cloud Identity super administrator accounts should not be used for regular administrative tasks. As the super admin account is highly privileged, it should not be assigned to specific individuals. It's use should be limited to only emergency or "break glass" scenarios when normal administrative accounts can't be used. For daily administrative tasks, separate privileged user accounts should be used and assigned the appropriate permissions via IAM roles.

You should also ensure that the credentials (such as password, MFA tokens and access keys) for super admin accounts are kept secure and known only to individuals who are authorized to use them only in an emergency. MFA should be enabled for the super admin account, and you may also use additional controls, such as dual controls (e.g., splitting the credential into two pieces and giving it to separate persons) to enhance the security of this process.

You should also monitor the sign-in and audit logs in Cloud Audit Logs, or query the Policy Analyzer, to ensure that super admin accounts are only used when authorized.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

PA-6: Use privileged access workstations

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
12.8, 13.5 AC-2, SC-2, SC-7 N/A

Security principle: Secured, isolated workstations are critically important for the security of sensitive roles like administrator, developer, and critical service operator.

Azure guidance: Use Azure Active Directory, Microsoft Defender, and/or Microsoft Intune to deploy privileged access workstations (PAW) on-premises or in Azure for privileged tasks. The PAW should be centrally managed to enforce secured configuration, including strong authentication, software and hardware baselines, and restricted logical and network access.

You may also use Azure Bastion which is a fully platform-managed PaaS service that can be provisioned inside your virtual network. Azure Bastion allows RDP/SSH connectivity to your virtual machines directly from the Azure portal using a web browser.

Azure implementation and additional context:

AWS guidance: Use Session Manager in AWS Systems Manager to create an access path (a connection session) to the EC2 instance or a browser session to the AWS resources for privileged tasks. Session Manager allows RDP, SSH, and HTTPS connectivity to your destination hosts through port forwarding.

You may also choose to deploy a privileged access workstations (PAW) centrally managed through Azure Active Directory, Microsoft Defender, and/or Microsoft Intune. The central management should enforce secured configuration, including strong authentication, software and hardware baselines, and restricted logical and network access.

AWS implementation and additional context:

GCP guidance: Use Identity-Aware Proxy (IAP) Desktop to create an access path (a connection session) to the compute instance for privileged tasks. IAP Desktop allows RDP and SSH connectivity to your destination hosts through port forwarding. Furthermore, Linux compute instances that are external facing may be connected to through a SSH-in-browser through the Google Cloud console.

You may also choose to deploy a privileged access workstations (PAW) centrally managed through Google Workspace Endpoint Management or Microsoft solutions (Azure Active Directory, Microsoft Defender, and/or Microsoft Intune). The central management should enforce secured configuration, including strong authentication, software and hardware baselines, and restricted logical and network access.

You may also create bastion hosts for secure accessing to trusted environments with defined parameters.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

PA-7: Follow just enough administration (least privilege) principle

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
3.3, 6.8 AC-2, AC-3, AC-6 7.1, 7.2

Security principle: Follow the just enough administration (least privilege) principle to manage permissions at fine-grained level. Use features such as role-based access control (RBAC) to manage resource access through role assignments.

Azure guidance: Use Azure role-based access control (Azure RBAC) to manage Azure resource access through role assignments. Through RBAC, you can assign roles to users, groups, service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal.

The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges will complement the just-in-time (JIT) approach of Azure AD Privileged Identity Management (PIM), and those privileges should be reviewed periodically. If required, you can also use PIM to define a time-bound assignment, which is a condition in a role assignment where a user can only activate the role within the specified start and end dates.

Note: Use Azure built-in roles to allocate permissions and only create custom roles when required.

Azure implementation and additional context:

AWS guidance: Use AWS policy to manage AWS resource access. There are six types of policies: identity-based policies, resource-based policies, permissions boundaries, AWS Organizations service control policy (SCP), Access Control List, and session policies. You may use AWS managed policies for common permission use cases. However, you should be mindful that managed policies may carry excessive permissions that should not be assigned to the users.

You may also use AWS ABAC (attribute-based access control) to assign permissions based on attributes (tags) attached to IAM resources, including IAM entities (users or roles) and AWS resources.

AWS implementation and additional context:

GCP guidance: Use Google Cloud IAM Policy to manage GCP resource access through role assignments. You may use Google Cloud's predefined roles for common permission use cases. However, you should be mindful that predefined roles may carry excessive permissions that should not be assigned to the users.

Additionally, use Policy Intelligence with the IAM Recommender to identify and remove excessive permissions from accounts.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

PA-8 Determine access process for cloud provider support

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.1, 6.2 AC-4, AC-2, AC-3 N/A

Security principle: Establish an approval process and access path for requesting and approving vendor support requests and temporary access to your data through a secure channel.

Azure guidance: In support scenarios where Microsoft needs to access your data, use Customer Lockbox to review and either approve or reject each data access request made by Microsoft.

Azure implementation and additional context:

AWS guidance: In support scenarios where AWS support teams need to access your data, create an account in the AWS Support portal to request support. Review the available options such as providing read-only data access, or the screen sharing option for AWS support to access to your data.

AWS implementation and additional context:

GCP guidance: In support scenarios where Google Cloud Customer Care needs to access your data, use Access Approval to review and either approve or reject each data access requests made by Cloud Customer Care.

GCP implementation and additional context:

Customer security stakeholders (Learn more):